Здравствуйте, smeeld, Вы писали:

S>>а не разобраться в достоинствах и недостатках C++.

S>Разобрался

Да, ваши заключения о полезности фич C++ тут уже все желающие могли прочитать. Очевидное доказательство того, что вы "разобрались".

S>лет десять как, вооружившись спекой C++-ного стандарта, реализациями используемого компилятора, отладчиками и трайсерами.

Разбираться с достоинствами C++ по стандарту языка? Да вы еще больший оригинал, чем кажетесь.

Здравствуйте, so5team, Вы писали:

S>Разбираться с достоинствами C++ по стандарту языка? Да вы еще больший оригинал, чем кажетесь.

Разбираться в тонкостях ЯП, основываясь на сочинениях сказочников вроде Майерса? Ясно, понятно. Желаю и дальше неходится в неведении очень интересных вещей, характерных для програм, написанных на современном C++.

Здравствуйте, so5team, Вы писали:

S>Даже больше: нужны убедительные доводы для того, чтобы отказываться по каким-то причинам от C++17.

"Лично мне С++17 абсолютно не нравится, по сравнению с С++98" — убедительный довод?
И не надо про осиливание С++: я работал с разными технологиями, да и изучал науки посложнее программирования, пускай и в качестве хобби. Кое-что по С++17 читал, например книгу Майерса(тот еще фанатик), немного статей в интернете. Детали С++17, которые можно освоить только практикой, я не знаю, и мне не интересно этот опыт получать. Чтобы сформировать мнение "не нравится", достаточно иметь общее представление об этих фичах, знать зачем они нужны и как работают.
И кстати я приводил свои аргументы, в том числе в этом топике, ты же отвечаешь одними лозунгами. Впрочем, если хочешь, пиши конечно на С++17. Только не надо абсолютизировать С++17 на хайпе С++.

Здравствуйте, smeeld, Вы писали:

S>>Разбираться с достоинствами C++ по стандарту языка? Да вы еще больший оригинал, чем кажетесь.

S>Разбираться в тонкостях ЯП

Не в тонкостях. Не в тонкостях. А в достоинствах языка.

Тонкость -- это, например, особенности выбора перегрузки или шаблонной функции. Или детали того, что прячется за structured binding.

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

Может таки отважитесь и назовете имя компании? Ну чтобы вот вообще никак не пересечься.

Здравствуйте, lpd, Вы писали:

S>>Даже больше: нужны убедительные доводы для того, чтобы отказываться по каким-то причинам от C++17.

lpd>"Лично мне С++17 абсолютно не нравится, по сравнению с С++98" — убедительный довод?

Нет.

lpd>Чтобы сформировать мнение "не нравится", достаточно иметь общее представление об этих фичах, знать зачем они нужны и как работают.

Это ошибочный постулат.

lpd>И кстати я приводил свои аргументы, в том числе в этом топике, ты же отвечаешь одними лозунгами.

Позволю себе процитировать эти самые "лозунги":

Это сложно назвать объяснением того, чем вас современный C++ обидел. Скорее это список того, чего вы бы хотели видеть в некотором гипотетическом языке. Из чего можно сделать вывод о том, что C++ вас обидел именно тем, что не стал таким гипотетическим языком. Ну так уж повернулась история, здесь ничего не поделать.

Ну и да, пустозвонство местных плюсохейтеров уже просто надоело. Где же, блин, конкретные примеры, которые от вас просишь снова и снова?

Вот Pzz разорялся-разорялся образными выражениями, вроде "презерватива на голове", а как начался с ним разговор про конкретные примеры, так и выяснилось "я все лучше вручную сделаю", "напишу тучу однотипного кода" и прискорбный факт, что человек судит о языке, про который мало что знает.

Покажите же, в конце-концов, пример того, как в современном C++ все сложно, а в C или C++98 просто и понятно.

Здравствуйте, Pzz, Вы писали:

IID>>То ли дело в чистом си! Нужна копия сокета при accept — выделим память и алга в нее memcpy. В результате CVE-2017-8890, чудесная дырочка, через которую буханки трескались как орешки. С success rate выше 98% (сорян, но выиграть две гонки с 100% рейтом это уже фантастика).

Pzz>Ну давайте теперь будем каждый байт через конструктуры с проверками копировать.

Ну что вы, конечно не проверяйте.
Активных (непофикшенных) крешей, с авто воспроизведением, найденных syzcaller'ом, всего то 3000 (три тысячи) штук. Среднее время фикса полгода.

Т.е. даже особо стараться не надо. Старых багов навалом, постоянно новые вносятся.

А начнете проверять (не дай б-г) — наступит грусть и печаль.

Pzz>У Пентиума мегагерцев много, на всех хватит.

О! Уже пентиум! Нехилый прогресс после VT-100.

Здравствуйте, IID, Вы писали:

IID>Ну что вы, конечно не проверяйте.
IID>Активных (непофикшенных) крешей, с авто воспроизведением, найденных syzcaller'ом, всего то 3000 (три тысячи) штук. Среднее время фикса полгода.

Вопрос про эффективность ведь не я поднял. Тут кто-то рассказал, что в C++ достигается недостижимое: совмещается типа-безопасность языков высокого уровня с эффективностью кода, практически как в Си. Вот я и поинтересовался.

Здравствуйте, Basil2, Вы писали:

Благодарю за шикарную тему.
Такого количества каминг-аутов не было, имхо, со времён Синтаксического Оверхеда или Линукс против Всех.

Здравствуйте, smeeld, Вы писали:

S>линукс вытестнил винду из сегмента серверов уровня предприятия,

Не вытеснил, а слегка потеснил.

Здравствуйте, lpd, Вы писали:

lpd>Я бы предпочел опциональную сборку мусорам возне с умными указателями(циклические ссылки, выбор shared_ptr/weak_ptr).

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

lpd>С недостатками неавтоматического освобождения спорить сложно. Однако
lpd>— вместо неявного освобождения unique_ptr<>, лично я предпочту вручную явно вызвать delete. Хотя да, это вопрос вкуса, спорить наверное бесполезно.
lpd>— если время жизни объекта неизвестно, то в этом случае shared_ptr может помочь. Но на мой взгляд опциональный сборщик мусора был бы удобнее, чтобы не заботиться о круговых ссылках.

Это вообще, с точки зрения эффективности, злобный антипаттерн. Программы на C++, активно использующие всякое там автоматическое освобождение, имеют тенденцию создавать в куче объекты с очень коротким временем жизни, и сразу же их освобождать. Это ОЧЕНЬ медленно, медленнее, например, чем автоматическое управление памятью в языках со сборкой мусора, типа какого-нибудь даже яваскрипта.

Здравствуйте, Pzz, Вы писали:

lpd>>— вместо неявного освобождения unique_ptr<>, лично я предпочту вручную явно вызвать delete. Хотя да, это вопрос вкуса, спорить наверное бесполезно.
lpd>>— если время жизни объекта неизвестно, то в этом случае shared_ptr может помочь. Но на мой взгляд опциональный сборщик мусора был бы удобнее, чтобы не заботиться о круговых ссылках.

Pzz>Это вообще, с точки зрения эффективности, злобный антипаттерн. Программы на C++, активно использующие всякое там автоматическое освобождение, имеют тенденцию создавать в куче объекты с очень коротким временем жизни, и сразу же их освобождать. Это ОЧЕНЬ медленно, медленнее, например, чем автоматическое управление памятью в языках со сборкой мусора, типа какого-нибудь даже яваскрипта.

Ну, без статистики такое утверждение очень спорно. Я бы сказал так: "Программы на C++, активно использующие всякое там автоматическое освобождение, имеют тенденцию корректно работать с исключениями." Вот это утверждение верно безо всякой статистики, потому что деструктор объекта вызывается автоматически, в отличие от ручного delete, которое может и не быть вызвано. При этом тот же unique_ptr почти не вызывает оверхеда. Но если он есть, например в паттерне pimpl, можно обойтись и без него — как раз на последней cppconf был отличный доклад Антона Полухина.

Здравствуйте, Marty, Вы писали:

_>>Просто из-за скорости изменения. А подходит только что-то типа STMStudio, в которой строится график значения, который можно сравнивать с параллельным ему графиком другой переменной — по сути такой софтверный осциллограф.
M>А, так для этого есть FreeMaster

Ну да, это того же типа продукт. Кстати, а он с st-link работает?

_>>Советую глянуть на такую штуку, как jlink (его кстати можно прошить даже в обычный st-link с Али). Там очень много вкусностей. И в том числе идёт RTT.
M>А в чем его плюс по сравнению с ST-Link'ом?

Ну для начала он банально намного быстрее. Т.е. понятно что это вообще не принципиальный параметр, но всё равно как сильно приятнее с ним. Ну и потом там есть множество мелких удобство. Одно из которых как раз "свой printf" (причём поделённый на каналы и в отдельном удобном приложение).

Кстати, а как раз с jlink FreeMaster точно работает — помню что видел это, хотя и не использовал сам продукт.

Здравствуйте, so5team, Вы писали:

S>Ну и да, пустозвонство местных плюсохейтеров уже просто надоело. Где же, блин, конкретные примеры, которые от вас просишь снова и снова?

S>Вот Pzz разорялся-разорялся образными выражениями, вроде "презерватива на голове", а как начался с ним разговор про конкретные примеры, так и выяснилось "я все лучше вручную сделаю", "напишу тучу однотипного кода" и прискорбный факт, что человек судит о языке, про который мало что знает.

S>Покажите же, в конце-концов, пример того, как в современном C++ все сложно, а в C или C++98 просто и понятно.

Ну, допустим, я тебе ни раз приводил доводы почему современный C++ не торт. Допустим, у тебя есть взвод индусов, как из анекдота, которые булевое значение со строкой сравнивают, а продукт делать надо. И ты понимаешь, что используя C++ ты его ну никак не сделаешь. Вот вообще, никак, а с индусоустойчивым инструментом ты завершить продукт в срок и с ожидаемым качеством. Надо осмысленно инструмент подбирать, и, кстати, Си-с-классами куда более приемлемый язык для совсем уж бездарностей от программирования. А вообще, в идеале, надо брать Go

Здравствуйте, lpd, Вы писали:

_>>Если же говорить о конкретных технических моментах, то тут есть целый ряд нюансов. Во-первых статический полиморфизм гарантирует корректность кода, т.к. всё проверяется компилятором на стадии сборки и не может случиться ситуация с неверно переданным указателем.
lpd>Странно звучат "все проверяется", и "гарантирует корректность кода", т.к. в реальных программах основную сложность составляют проблемы вовсе не те, что пытаются решать создатели современного С++ своими дополнительными проверками корректности типов или raii, либо этих мер все равно недостаточно. Получается, что этот современный С++ только запутывает реализации и без того сложных алгоритмов на ровном месте.
lpd>Кому-то лес из скобочек нравится, кому-то нет, поэтому С++ перестал быть универсальным языком.

Т.е. вот сейчас серьёзно заявляешь, что такой код:

class AbstractCustomizer{
public:
    virtual bool Customize(int v)=0;
    virtual ~Customize() {}
};

void DoJob(Data data, AbstractCustomizer* customizer);

class MyCustomizer: public AbstractCustomizer{
    int param;
public:
    MyCustomizer(int p): param(p) {}
    virtual bool Customize(int v) override {return v<param;}
};

void Test(){
    ...
    MyCustomizer customizer(param);
    DoJob(data, &customizer);
}

проще такого:

template<class F> void DoJob(Data data, F customizer);//кстати, можно записать и без шаблона, через function<bool(int)>, но тогда потеряем инлайн

void Test(){
    ...
    DoJob(data, [&](int v) {return v<param;});
}

???

_>>Во-вторых естественно вопрос производительности. Статический полиморфизм очевидно на порядки эффективнее, т.к. вызов не просто идёт напрямую (а не косвенно, как в случае виртуальной функции), но и практически гарантированно инлайнится.
lpd>Ну это уже совсем экономия на спичках. В отдельных критических участках кода может такой выигрыш в скорости и имел бы смысл, но и в таких случаях обычно нужны simd-инструкции, а не шаблоны. А оптимизация каждой функции только вредит проекту усложнением кода. Использовать везде шаблоны это все равно как раньше писали все полностью на ассемблере ради некой скорости.

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

P.S. Упоминать про SIMD вычисления в подобной теме (которые ей абсолютно ортогональны) — это вообще уже какая-то детский сад.

Здравствуйте, lpd, Вы писали:

lpd>Чем лучше архитектура и проще код, тем легче в программе искать ошибки, легче добавлять новые функции, и легче оптимизировать по скорости. Современный С++ же код значительно усложняет, особенно мув-семантика, умные указатели(по сравнению с GC), сложные шаблоны. Причем все это сделано вроде как для скорости, оправданность чего и вызывает сомнения.

Что-то у тебя какая-то дикая каша в сообщениях. То говоришь про простоту C, то про простоту GC — как это вообще сочетается? Ты вообще что сказать то хочешь? И вообще с каким языком ты проводишь сравнение C++?

Потому как если сравнивать с C++ скажем Java и Python, то в каждом таком сравнение появятся свои плюсы и минусы. И соответственно для каждой конкретной задачи можно выбрать один из этих трёх языков. А вот скажем если сравнивать с современным C++ язык C или же C++98 (тут у нас похоже и такие любители водятся), то я считаю что плюсов у них не будет в принципе, а минусов множество.

Здравствуйте, kaa.python, Вы писали:

KP>Вот вообще, никак, а с индусоустойчивым инструментом ты завершить продукт в срок и с ожидаемым качеством. Надо осмысленно инструмент подбирать, и, кстати, Си-с-классами куда более приемлемый язык для совсем уж бездарностей от программирования.

Тут мы переходим от решения технических проблем к решению социально-организационных. И даже тут, если сравнивать C++ и C, то у C++ преимуществ все-таки больше.

KP>А вообще, в идеале, надо брать Go

Да, когда качество персонала обеспечить нельзя, то Go, Java или Rust будут лучшим выбором, чем любой из вариантов C++. Но с этим я вроде бы и не спорил.

Здравствуйте, Pzz, Вы писали:

_>>Если же говорить о конкретных технических моментах, то тут есть целый ряд нюансов. Во-первых статический полиморфизм гарантирует корректность кода, т.к. всё проверяется компилятором на стадии сборки и не может случиться ситуация с неверно переданным указателем. Во-вторых естественно вопрос производительности. Статический полиморфизм очевидно на порядки эффективнее, т.к. вызов не просто идёт напрямую (а не косвенно, как в случае виртуальной функции), но и практически гарантированно инлайнится.
Pzz>Представляю, во что превратится код программы, если в гуйне каждая кнопка поинлайнится.

Ну и во что превратися? Расскажи... )

Кстати, та же самая Qt (которая родом из 90-ых и насквозь динамическая) уже давно научилась использовать лямбды в качестве слотов, чем я активно пользуюсь. Конечно ни к какой оптимизации это не приводит (да и не нужна она в GUI), т.к. внутри там всё равно динамика, причём даже ещё хуже чем обычные виртуальные функции C++. Но это без разницы, т.к. лямбды мне здесь нужны исключительно для удобства и простоты кода.

Здравствуйте, Nuzhny, Вы писали:

N>Ну, без статистики такое утверждение очень спорно. Я бы сказал так: "Программы на C++, активно использующие всякое там автоматическое освобождение, имеют тенденцию корректно работать с исключениями." Вот это утверждение верно безо всякой статистики, потому что деструктор объекта вызывается автоматически, в отличие от ручного delete, которое может и не быть вызвано. При этом тот же unique_ptr почти не вызывает оверхеда. Но если он есть, например в паттерне pimpl, можно обойтись и без него — как раз на последней cppconf был отличный доклад Антона Полухина.

unique_ptr почти не вызывает оверхеда. А вот постоянные мелкие аллокации/освобождения на куче очень даже вызывают.

Здравствуйте, alex_public, Вы писали:

Pzz>>Представляю, во что превратится код программы, если в гуйне каждая кнопка поинлайнится.

_>Ну и во что превратися? Расскажи... )

В очень много повторов практически одинакового кода.

_>Кстати, та же самая Qt (которая родом из 90-ых и насквозь динамическая) уже давно научилась использовать лямбды в качестве слотов, чем я активно пользуюсь. Конечно ни к какой оптимизации это не приводит (да и не нужна она в GUI), т.к. внутри там всё равно динамика, причём даже ещё хуже чем обычные виртуальные функции C++. Но это без разницы, т.к. лямбды мне здесь нужны исключительно для удобства и простоты кода.

Лямбды и не нужны для оптимизации. Лямбды нужны именно что для читаемости кода.

Здравствуйте, lpd, Вы писали:

lpd>И кстати я приводил свои аргументы, в том числе в этом топике, ты же отвечаешь одними лозунгами.

О, а этот "шедевр" я как-то пропустил... ) Сейчас отвечу по пунктам... )))

lpd>Я бы предпочел опциональную сборку мусорам возне с умными указателями(циклические ссылки, выбор shared_ptr/weak_ptr).

Сборку мусора (во всяком случае эффективную, например как в JVM) невозможно просто опциональной прикрутить к системному языку — потребуется его весь переделывать. И именно, потребуется полностью изменить подход в размещение объектов в памяти — появятся ненужные скрытые поля. Из-за которых язык получит те самые тормоза и пожирание памяти, характерные для управляемых языков. Правда как бонус появится рантаймовая интроспекция (рефлексия), но это совсем не то, что требуется для языка, нацеливающегося на нашу C++.

lpd>Еще большим злом считаю добавление в C++ move-семантики и rvalue-ссылок. Они только усложняют язык. В 98% случаях копирование объектов незначительно замедляет программу.


Семантика перемещения нужна в первую очередь совсем не для оптимизации (в конце концов в текущем коде она редко срабатывает автоматически, т.к. чаще перед ней срабатывает RVO), а как раз для возможности создания автоматического управления памятью (ну и кстати не только памятью, но и любыми другими ресурсами). Потому что без семантики перемещения ты просто физически не сможешь написать безопасный unique_ptr. Т.к. или у тебя будет разрешён оператор копирования (но тогда о каком "владение" можно будет говорить?) или же ты почти ничего не сможешь делать с таким указателем (ни в контейнер положить, ни в лямбду передать, вообще ничего). И кстати по тому же принципу работает множество сущностей стандартной библиотеки (потоки, мьютексы и т.п.), которые заявляют владение и соответственно не могут быть скопированы.

lpd>Ну процессоры сейчас в 100 раз быстрее чем в 90х, поэтому эффекты скорости от move-семантики, шаблонов, и прочей экономии на спичках, про которую тут часто говорят, уже не так полезны, как 30 лет назад.

Действительно стали быстрее и даже более чем в 100 раз. Только вот есть интересный нюанс — через 10 лет они уже точно не станут быстрее в 100 раз. Да и собственно последние лет 5 тоже никаких ускорений по сути нет. А вот усложнение ПО почему-то не собирается останавливаться...

lpd>вместо неявного освобождения unique_ptr<>, лично я предпочту вручную явно вызвать delete. Хотя да, это вопрос вкуса, спорить наверное бесполезно.

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

lpd>Ну потому, что С++-98 и C++-17 — это совсем разные языки. Общее у них только имя, да частично легаси-синтаксис. И появись фичи C++-17 в каком-нибудь редком языке, а не С++, массовым бы этот редкий язык они не сделали.

Совершенно верно. Более того, по сути как раз таким "редким" языком и является Rust. Только вот он вполне успешно пытается стать массовым (и в перспективе заменить C++ во всех его нишах).

lpd>Впрочем, если хочешь, пиши конечно на С++17. Только не надо абсолютизировать С++17 на хайпе С++.

Конечно! C++17 это действительно совсем торт. Вот C++20...