Ну можно и так, но это не отменяет того факта, что в каждом файле будет ифдеф. И когда например появляется третья платформа, то приходится перелопачивать N-файлов (руками, или sedом - вопрос отдельный), что не есть гуд.
я иногда сталкивалась с кодом, который быстрее переписать с нуля, чем найти в нём все баги и косяки.
Все сталкивались. Это не макакизация, а плохой менеджмент. Очевидно, набирать команду на 100% из макак не надо. Это же такие простые и очевидные вещи! Что если команда состоит на 100% из макак, то виноват менеджмент, который тупой.
спроси тут на ЛОРе и каждый второй использующий эти auto не сможет написать нормальную точную спецификацию типа, с которым они работают.
Мне кажется ты преувеличиваешь. Как можно юзать auto не зная какой тип за ним скрывается? Это тебе не ява или c#, где у большого кол-во объектов есть базовый набор одинковых методов.
вроде бы мелочь: человек не хочет вникать в типы.
Обычно auto юзается чтобы написать универсальные шаблонные враперы, когда в зависимости от параметров шаблонной функции меняется и тип возвращаемого значения. Ну или чтобы не писать полное название типо, ибо оно иногда оно очень длинным бывает.
Ты приводишь в пример каких-то джуниров, я практически не встречал людей пишущих на си++, которые не вникали бы в типы или юзали бы auto бездумно. Какая-то надуманная проблема. Если ты судишь только по форумам, ну что ж, мне тебя жаль... вроде больше 20 лет в IT, а понимание того, что по форумум и коментариям нельзя судить о сообществе в целом так и не пришло.
А, это не показатель. Ну просто условный Google возьмет 1000 стажеров со всего мира из которых условно 100 будет из России(конечно меньше, но пусть будет 100). Яндекс возьмет те же 100 человек, только они все из России будут.
Потому, что есть компиляторы, отличные от gcc и clang. Не?
Это MSVC или что-нибудь более экзотическое, где вообще совсем нет аналога __attribute__((noreturn))? Боюсь, что такая экзотика совсем замшелая и там даже C++11 нет (вот DigitalMars такой).
Без указания версии этот вопрос не имеет смысла, не? Я не знаю, что там в MSVC, но, судя по таблице https://en.cppreference.com/w/cpp/compiler_support, [[noreturn]] (именно в такой форме) там появился в 2015 году.
Еще раз - я понимаю, зачем нужны стандарты и почему стандарты - это хорошо. Но когда речь об атрибуте, который есть примерно везде и отличается только синтаксисом, его стандартность меня волнует мало.
Но [[атрибут]] _сужает_ спектр поддерживаемых платформ/компиляторов (например, мои в этот спектр не входят)..
Посредством ifdef-ов можно разделить компиляторы на те, что поддерживают __has_cpp_attribute и те, что не поддерживают. Для тех, что не поддерживают, можно (если нужно) потрахаться с compiler-specific атрибутами.
Это лучше и перспективнее, чем сразу (и только) трахаться с compiler-specific атрибутами.
Для тех, что неподдерживают, можно (если нужно) потрахаться с compiler-specific атрибутами.
Конечно. Но, если уж вынужден трахаться с ними, то уже неважно, стандартизована форма записи [[noreturn]] или нет.
Это лучше и перспективнее, чем сразу (и только) трахаться с compiler-specific атрибутами.
Есть разница между compiler-specific attribute и, как бы это сказать, compiler-specific attribute syntax. Атрибут с семантикой noreturn есть везде или почти везде, и давно, про атрибуты с какой-то другой семантикой - ХЗ.
Но разговор-то начался с того, что _семантика_ [[noreturn]] есть уже давно.
Я вмешался в этот разговор только с момента вопроса «зачем [[noreturn]] в стандарте?»
На мой взгляд, ответ очевиден.
Если ты, ссылаясь на свою дыру, в которую хрен знает когда дойдут результаты прогресса, считаешь, что [[noreturn]] в стандарте не нужен, то остается тебе только посочувствовать.
Нет, это как раз понятно. Откуда идея, что [[noreturn]] не должно быть в стандарте. Просто для протокола: то, что его стандартизовали, это хорошо, но неважно. Использовать семантику noreturn можно уже давно.
Начитался первой страницы это дискуссии и прямо захотелось выкинуть плюсы и писать на си. Всякие эти шаблоны на шаблонах и куча очень сложных фич, которые призваны добавлять синтаксический сахар, а добавляют часы чтения документации.
Есть одна проблема. Си это такое старое сложночитаемое. А писать какой-нибудь софт который работыет с пользовательским вводом где есть строки это же вообще все, приехали.
Какая разница кто где пишет код? Мой знакомый из рабочей группы по C++ пишет код в VS.
Хм, кто же это? В РГ два с Яндекса, один из Каспера. Один в свободное время сидит в Qt Creator под убунтой, второй Clang ковыряет, так что винда тоже вроде отметается. Хм-хм-хм
смысла в большинстве этих нововведений нет абсолютно
да вы что.. а хотя.. ну да, Строустрап то уже давно признал что C++ получился не таким как задумано.. а вот появление Go и других более удачных конкурентов - заставило C++ двигаться в направлении допиливания
Стандарт не читал. Вопрос задан так, как он задан.
А то вдруг окажется, что придумали свои «определения» к комбинациям из ключеых слов и пытаются дрессировать собак павлова на правильность интерпретации этих выдуманных определений ударами электрическим током. :)
Хм, кто же это? В РГ два с Яндекса, один из Каспера. Один в свободное время сидит в Qt Creator под убунтой, второй Clang ковыряет, так что винда тоже вроде отметается. Хм-хм-хм
Да не важно кто именно. Это не один случай, когда люди могут писать код под Linux в VS и для этого им не нужнен Emacs и куча магии.
что придумали свои «определения» к комбинациям из ключеых слов и пытаются дрессировать собак павлова
Есть деструкторы. Есть ключевое слово virtual. Им можно пометить деструктор. Деструкторы помеченые и не помеченые этим словом имеют свою специфику поведения(как и обычные функции, но в случае деструкторов все интереснее). Даже если в стандарте такого определения нет, то на деле они(виртуальные деструкторы) есть.