LINUX.ORG.RU

Ответ на: комментарий от Iron_Bug

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

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

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

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

Dudraug ★★★★★ ()
Ответ на: комментарий от deep-purple

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

Dudraug ★★★★★ ()
Ответ на: комментарий от deep-purple

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

При чем тут вообще адрес функции? 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);

}

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

Dudraug ★★★★★ ()
Ответ на: комментарий от next_time

move semantic + =delete

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

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

Dudraug ★★★★★ ()
Ответ на: комментарий от Iron_Bug

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

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

Dudraug ★★★★★ ()
Ответ на: комментарий от Iron_Bug

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

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

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

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

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

Dudraug ★★★★★ ()
Ответ на: комментарий от eao197

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

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

Dudraug ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

xpahos ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

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

KennyMinigun ★★★★★ ()
Ответ на: комментарий от KennyMinigun

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от eao197

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от Dudraug

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

eao197 ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

eao197 ★★★★★ ()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от eao197

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

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

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

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

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

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

eao197 ★★★★★ ()
Ответ на: комментарий от eao197

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

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

tailgunner ★★★★★ ()

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

anonymous ()

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

anonymous ()
Ответ на: комментарий от xpahos

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

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

zamazan4ik ★★ ()
Ответ на: комментарий от anonymous

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

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

Dudraug ★★★★★ ()
Ответ на: комментарий от Iron_Bug

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

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

PexuOne ()
Ответ на: комментарий от Dudraug

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

anonymous ()
Ответ на: комментарий от zamazan4ik

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

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

xpahos ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

Dudraug ★★★★★ ()