В C++20 появятся виртуальные функции!

это как раз костыль для неосиляторов номер один.

Ахаха. Ага мы любим харкор? или

for (std::map<std::string,std::string>::iterator it = mymp.begin(); it != mymp.end(); ++it)

или плодить typedef на каждый чих. Это же так по мастерски раздувать код когда большую часть строки занимает бессмысленная информация.

Yandex в одном ряду с Google и Facebook умилил :)

А что тебя умиляет?

Разница в размерах.

Ну можно и так, но это не отменяет того факта, что в каждом файле будет ифдеф. И когда например появляется третья платформа, то приходится перелопачивать N-файлов (руками, или sedом - вопрос отдельный), что не есть гуд.

Можно и без генериков — присваивание адреса функции в указатель.

При чем тут вообще адрес функции? Oo

Имелось в виду такое

#include <iostream>
#include <map>


void f()
{
    std::cout << "f()" << std::endl;
}

void f(int)
{
    std::cout << "f(int)" << std::endl;
}

void f(std::string)
{
    std::cout << "f(string)" << std::endl;
}

void f(int, int)
{
    std::cout << "f(int, int)" << std::endl;
}
int main()
{
  f();
  f(1);
  f("1");
  f(1,2);

}

Как тут помогут указатели на функцию?

Да и сам range for сильно улучшает читаемость кода.

Да все нормальные люди понимают, что с++11 и выше - добро, но есть некоторые упоротые олдфаги.

ЧЧто он умеет такого, чего не может __attribute__((noreturn))?

То что он есть в стандарте?

move semantic + =delete

это больше про быстродействие

delete/default повышают и читаемость и защиту от ошибок на этапе компиляции. Нет функции (она удалена) - нет проблем.

я иногда сталкивалась с кодом, который быстрее переписать с нуля, чем найти в нём все баги и косяки.

Все сталкивались. Это не макакизация, а плохой менеджмент. Очевидно, набирать команду на 100% из макак не надо. Это же такие простые и очевидные вещи! Что если команда состоит на 100% из макак, то виноват менеджмент, который тупой.

спроси тут на ЛОРе и каждый второй использующий эти auto не сможет написать нормальную точную спецификацию типа, с которым они работают.

Мне кажется ты преувеличиваешь. Как можно юзать auto не зная какой тип за ним скрывается? Это тебе не ява или c#, где у большого кол-во объектов есть базовый набор одинковых методов.

вроде бы мелочь: человек не хочет вникать в типы.

Обычно auto юзается чтобы написать универсальные шаблонные враперы, когда в зависимости от параметров шаблонной функции меняется и тип возвращаемого значения. Ну или чтобы не писать полное название типо, ибо оно иногда оно очень длинным бывает.

Ты приводишь в пример каких-то джуниров, я практически не встречал людей пишущих на си++, которые не вникали бы в типы или юзали бы auto бездумно. Какая-то надуманная проблема. Если ты судишь только по форумам, ну что ж, мне тебя жаль... вроде больше 20 лет в IT, а понимание того, что по форумум и коментариям нельзя судить о сообществе в целом так и не пришло.

Напишите, пожалуйста нормальную точную спецификацию типа для примера, который вы уже однажды проигнорировали выше:

Так это ж не нужно! Это все новомодное хипстерство!

Yandex в одном ряду с Google и Facebook умилил :)

У yandex к слову тоже довольно большой скоп задач=) Просто не все об этом тоже знают.

Так это ж не нужно!

Нужно-ненужно — это другой вопрос. Пускай тип выведет, если не считает себя попадающей в эти самые «каждый второй» :)

Разница в размерах.

А, это не показатель. Ну просто условный Google возьмет 1000 стажеров со всего мира из которых условно 100 будет из России(конечно меньше, но пусть будет 100). Яндекс возьмет те же 100 человек, только они все из России будут.

А в этом треде кто-нибудь код на C++ кроме eao197 пишет?

Я.

Ну, я тоже

Даже банальный [[noreturn]] может сильно упростить жизнь.

ЧЧто он умеет такого, чего не может __attribute__((noreturn))?

Быть в стандарте?

// ну и еще занимать 12 символов вместо 26

Например, поддержку со стороны clang ;)

Не, clang таки умеет (даже без ворнинга)

https://wandbox.org/permlink/wkei9QaBjISVAHyS

Что он умеет такого, чего не может __attribute__((noreturn))?

Быть в стандарте?

И почему это важно? Я понимаю, почему это важно для больших вещей типа auto или там rvalue reference. Но для атрибута?

И почему это важно?

Потому, что есть компиляторы, отличные от gcc и clang. Не?

Потому, что есть компиляторы, отличные от gcc и clang. Не?

Это MSVC или что-нибудь более экзотическое, где вообще совсем нет аналога __attribute__((noreturn))? Боюсь, что такая экзотика совсем замшелая и там даже C++11 нет (вот DigitalMars такой).

Это MSVC или что-нибудь более экзотическое

Это в MSVC c++11 то нет? Там точно есть с++14 и частично с++17(может и полностью, давно не проверял).

Это MSVC или что-нибудь более экзотическое

Это в MSVC c++11 то нет?

Без указания версии этот вопрос не имеет смысла, не? Я не знаю, что там в MSVC, но, судя по таблице https://en.cppreference.com/w/cpp/compiler_support, [[noreturn]] (именно в такой форме) там появился в 2015 году.

Еще раз - я понимаю, зачем нужны стандарты и почему стандарты - это хорошо. Но когда речь об атрибуте, который есть примерно везде и отличается только синтаксисом, его стандартность меня волнует мало.

где вообще совсем нет аналога __attribute__((noreturn))?

Может и есть. Но зачем в XXI-ом веке парится с тем, каким образом в конкретном компиляторе задать атрибут noreturn?

и отличается только синтаксисом, его стандартность меня волнует мало.

Есть подозрение, что ты на работаешь с ограниченным спектром платформ и компиляторов.

Есть подозрение, что ты на работаешь с ограниченным спектром платформ и компиляторов.

Конечно (как все, впрочем). Но [[атрибут]] _сужает_ спектр поддерживаемых платформ/компиляторов (например, мои в этот спектр не входят)..

Но [[атрибут]] _сужает_ спектр поддерживаемых платформ/компиляторов (например, мои в этот спектр не входят)..

Посредством ifdef-ов можно разделить компиляторы на те, что поддерживают __has_cpp_attribute и те, что не поддерживают. Для тех, что не поддерживают, можно (если нужно) потрахаться с compiler-specific атрибутами.

Это лучше и перспективнее, чем сразу (и только) трахаться с compiler-specific атрибутами.

Для тех, что неподдерживают, можно (если нужно) потрахаться с compiler-specific атрибутами.

Конечно. Но, если уж вынужден трахаться с ними, то уже неважно, стандартизована форма записи [[noreturn]] или нет.

Это лучше и перспективнее, чем сразу (и только) трахаться с compiler-specific атрибутами.

Есть разница между compiler-specific attribute и, как бы это сказать, compiler-specific attribute syntax. Атрибут с семантикой noreturn есть везде или почти везде, и давно, про атрибуты с какой-то другой семантикой - ХЗ.

Но, если уж вынужден трахаться с ними, то уже неважно, стандартизована форма записи [[noreturn]] или нет.

Не соглашусь. Если ты отказываешься от работы с [[noreturn]], то ты обрекаешь себя на постоянный трах с compiler-specific attribute syntax.

Особенно не соглашусь в ситуации, когда компиляторы без поддержки стандарта в должной степени можно послать в пешее эротическое.

Если ты отказываешься от работы с [[noreturn]], то ты обрекаешь себя на постоянный трах с compiler-specific attribute syntax.

Зато я не сужаю список поддерживаемых платформ. Конечно, теоретически можно сказать «C++11 или нафиг», но вот лично у меня такой возможности нет.

Но разговор-то начался с того, что _семантика_ [[noreturn]] есть уже давно.

Но разговор-то начался с того, что _семантика_ [[noreturn]] есть уже давно.

Я вмешался в этот разговор только с момента вопроса «зачем [[noreturn]] в стандарте?»

На мой взгляд, ответ очевиден.

Если ты, ссылаясь на свою дыру, в которую хрен знает когда дойдут результаты прогресса, считаешь, что [[noreturn]] в стандарте не нужен, то остается тебе только посочувствовать.

Я вмешался в этот разговор только с момента вопроса «зачем [[noreturn]] в стандарте?»

Я об этом не спрашивал. Я спросил, почему важно, что он в стандарте.

Если ты, ссылаясь на свою дыру, в которую хрен знает когда дойдут результаты прогресса, считаешь, что [[noreturn]] в стандарте не нужен, то [...]

...то любопытно, откуда у тебя возникла такая идея, но это тоже неважно :)

Я спросил, почему важно, что он в стандарте.

Повторю еще раз, специально для тебя ;)

Чтобы не трахаться с тем, как этот атрибут записывается для конкретного компилятора.

Что может быть важно для нового кода, который, скажем, пишется на C++17 и будет затем жить лет 15-20.

откуда у тебя возникла такая идея

Откуда идея, что ты сидишь в дыре? Дык ты ж вроде работу еще не менял :)

Откуда идея, что ты сидишь в дыре?

Нет, это как раз понятно. Откуда идея, что [[noreturn]] не должно быть в стандарте. Просто для протокола: то, что его стандартизовали, это хорошо, но неважно. Использовать семантику noreturn можно уже давно.

Откуда идея, что [[noreturn]] не должно быть в стандарте.

Это не идея. Это ощущение от твоих вопросов.

Начитался первой страницы это дискуссии и прямо захотелось выкинуть плюсы и писать на си. Всякие эти шаблоны на шаблонах и куча очень сложных фич, которые призваны добавлять синтаксический сахар, а добавляют часы чтения документации. Есть одна проблема. Си это такое старое сложночитаемое. А писать какой-нибудь софт который работыет с пользовательским вводом где есть строки это же вообще все, приехали.

А определение «виртуального деструктора» уже есть? Или популярный вопрос про виртуальный деструктор на собеседованиях - это признак буйной фанатзии?

Какая разница кто где пишет код? Мой знакомый из рабочей группы по C++ пишет код в VS.

Хм, кто же это? В РГ два с Яндекса, один из Каспера. Один в свободное время сидит в Qt Creator под убунтой, второй Clang ковыряет, так что винда тоже вроде отметается. Хм-хм-хм

А определение «виртуального деструктора» уже есть? Или популярный вопрос про виртуальный деструктор на собеседованиях - это признак буйной фанатзии?

Какой вопрос? Типо для чего он нужен?=) Так вроде очевидно. Или зачитать стандарт? но такого вроде не спрашивают

Блин, а можно мне полный цитатник нашей любимой барышни?

смысла в большинстве этих нововведений нет абсолютно

да вы что.. а хотя.. ну да, Строустрап то уже давно признал что C++ получился не таким как задумано.. а вот появление Go и других более удачных конкурентов - заставило C++ двигаться в направлении допиливания

Объем комментариев к нику ограничен, так что нет. Но вот еще перл: WASM для самых маленьких (онлайн)(раст включительно) (комментарий)

Стандарт не читал. Вопрос задан так, как он задан.
А то вдруг окажется, что придумали свои «определения» к комбинациям из ключеых слов и пытаются дрессировать собак павлова на правильность интерпретации этих выдуманных определений ударами электрическим током. :)

Хм, кто же это? В РГ два с Яндекса, один из Каспера. Один в свободное время сидит в Qt Creator под убунтой, второй Clang ковыряет, так что винда тоже вроде отметается. Хм-хм-хм

Да не важно кто именно. Это не один случай, когда люди могут писать код под Linux в VS и для этого им не нужнен Emacs и куча магии.

Мне кажется, что стоит как-то вечерком заняться парсингом архивов на её перлы.

Вот тебе заняться нечем. Лучше бы кепку пилил!

что придумали свои «определения» к комбинациям из ключеых слов и пытаются дрессировать собак павлова

Есть деструкторы. Есть ключевое слово virtual. Им можно пометить деструктор. Деструкторы помеченые и не помеченые этим словом имеют свою специфику поведения(как и обычные функции, но в случае деструкторов все интереснее). Даже если в стандарте такого определения нет, то на деле они(виртуальные деструкторы) есть.