Диагностики GCC — это хорошо, но недостаточно

И что, в этой области есть возможность выкладывать по 6K USD в год на статический анализатор для команды до 9 человек? Это в плюс ко всем остальным расходам.

Как обычно, в зависимости от. Если люди делают mission-critical промышленное оборудование, 6к грина можно и найти. Не мне судить. Какой-нибудь Сименс, я думаю и не 6к грина найдёт, если количество ошибок уменьшится на значимую величину.

UPD: посмотрел в список, там сименс уже есть, бгы.

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

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

Плюс они делали версию для «одиночек» CppCat и она им вышла в ноль, потому от неё и отказались, что вещающих что «да, нам надо!!!!» дофига, а готовых заплатить сто баксов в год - не особо.

Ну и лозунг «Shut up and hack!» никто не отменял. CppCheck например.

Так поэтому я и говорил про Java — там проектов с деньгами больше и платить за анализаторы смогут не только конторы масштаба Siemens. А рынок C++ скукоживается и чтобы выжить нужно будет научиться и с мелочи прибыль получать. Снижение издержек, оптимизация расходов и все такое.

Coverity почему-то там и в «Multi-language», и в «C, C++».

Когда они начнут нуждаться, произойдёт то же, что всегда происходит с продуктами, которые вроде как полезные, но делаются компаниями с откровенно враждебной ценовой политикой. Ваш продукт перепишут за нефиг делать под OSS лицензией на основе, например, clang-tidy. Кстати, там уже большое количество проверок реализованно: http://clang.llvm.org/extra/clang-tidy/checks/list.html

А рынок C++ скукоживается

Наверное, поэтому делаются такие продукты как CLion, который только недавно вышел, и уже о нём все знают. Не думаю, что рынок С++ значительно скукоживается. Язык и продукты для него развиваются значительными темпами.

Диагностики GCC — это хорошо, но недостаточно

Слово «диагностика» употребляется только в единственном числе. Русский язык выучи прежде чем писать здесь.

Не думаю, что рынок С++ значительно скукоживается. Язык и продукты для него развиваются значительными темпами.

Проблема языка C++ как раз в том, что он излишне сильно развивается. И при этом сохраняется обратная совместимость. Если в С++99 есть фичи A, B, C которые признаны неудачными и в C++11 появились фичи D, E, F которые лучше, а еще позже в C++14 появились J, H, I которые еще лучше, язык по факту будет поддерживать ВСЕ ИХ т.к. уже написано много кода на A, B, C, D, E, F который никто переписывать не будет т.к. слишком дорого, а в стандарте C++17 добавят еще что-то, в итоге язык (его сложность) растет как снежный ком, и никто (даже Страуструп) не может вместить у себя в голове весь C++.

Andrey_Karpov_2009 например не хочет отдельно продавать анализатор для C по меньшей стоимости, хотя вот мне совершенно очевидно, что на поддержку диагностик только для C тратится существенно меньше время, и львинная доля времени идет именно на все эти нововведения плюсов. Си же меняется со временем довольно незначительно. Так почему те, кто хочет только анализировать чистый Си, должны платить еще и за бесполезный для них анализатор C++ и C#? (или может быть они хотя бы C# анализатор продают отдельно? Хотелось бы надеяться)

Наверное, поэтому делаются такие продукты как CLion

CLion делается для того, чтобы JB смог откусить еще один кусочек пирога на рынке IDE: для Java/Scala у них уже был продукт, для C# был, для Python-а был, для Ruby (емнип) тоже. Так почему бы и для C++ не сделать, тем более, что в обозримой перспективе C++ останется (да и значительная часть нынешних проектов на C++ — это большой и древний легаси, в котором без IDE разбираться сложно).

Не думаю, что рынок С++ значительно скукоживается.

Тем не менее, если раньше C++ «давили» в основном, со стороны managed-сред (Java, C# и иже с ними), то теперь давят и со стороны нейтива. В первую очередь это Go. А со временем и Rust подтянется.

Так что C++ никуда не денется, но для него теперь есть еще больше альтернатив. Поэтому мне думается, что для новых проектов C++ будет выбираться еще реже. А это и есть скукоживание.

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

А это и не нужно. Вполне можно обходиться относительно небольшим подмножеством языка.

Ну и, что самое важное, растущая сложность языка парадоксальным образом значительно упрощает его использование. После некоторых плюшек C++14 даже на C++11 уже сложно писать, не говоря уже про C++03.

Если в С++99 есть фичи A, B, C которые признаны неудачными и в C++11 появились фичи D, E, F которые лучше, а еще позже в C++14 появились J, H, I которые еще лучше, язык по факту будет поддерживать ВСЕ ИХ

Adopted N4086, which removes trigraphs. Yes, we removed something from C++… and something that was inherited from C! But wait, there’s more… Adopted N4190, and actually removed (not just deprecated) several archaic things from the C++ standard library, including auto_ptr, bind1st/bind2nd, ptr_fun/mem_fun/mem_fun_ref, random_shuffle, and a few more. Those are now all removed from the draft C++ 17 standard library and will not be part of future portable C++.

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

Спорно. Я встречал прямо противоположное мнение. https://youtu.be/dDm8odp8PnA?t=1682 вот например из выступления Андрея Карпова, с которым мы имеем честь тут общаться

После некоторых плюшек C++14 даже на C++11 уже сложно писать, не говоря уже про C++03.

Только уже написанный код никуда магическим образом не исчезает при появлении новых стандартов

Спорно.

Очевидно, что здесь много вкусовщины и субъективности, но доказывать это можно множеством примеров.

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

Разработчикам инструментов для C++ (вроде тех же статических анализаторов), несомненно становится сложнее. Но я говорил про обычных пользователей.

https://youtu.be/dDm8odp8PnA?t=1682 вот например из выступления Андрея Карпова, с которым мы имеем честь тут общаться

Ну, адекватность этого господина для меня лично под вопросом. Да и если заглянуть в код самой PVS-Studio, то, вероятно, говнокода там будет порядком. Как минимум, очень многое у них было гвоздями прибито под Win32 API, раз уж выпуск версии под Linux занял так много времени.

Только уже написанный код никуда магическим образом не исчезает при появлении новых стандартов

А он, в большинстве своем продолжает нормально работать. Только когда приходит время что-то в старом коде подправить, объем этого самого старого кода можно сильно сократить. Ну, например, было что-то вроде:

typedef std::map<int,string> client_id_map;
class client_name_decorator : public unary_function<
  const client_id_map::value_type &, string>
{
  const string & prefix_;
public:
  client_name_decorator(const string & prefix) : prefix_(prefix) {}
  result_type operator()(argument_type a) {
    return prefix_ + a.second;
  }
};
...
client_id_map client_ids;
vector<string> modified_names;
string nameprefix = create_name_prefix();
transform(client_ids.begin(), client_ids.end(), back_inserter(modified_names),
  client_name_decorator(nameprefix));

client_id_map client_ids;
vector<string> modified_names;
string nameprefix = create_name_prefix();
transform(client_ids.begin(), client_ids.end(), back_inserter(modified_names),
  [&nameprefix](const client_id_map::value_type & a) {
    return nameprefix + a.second;
  });

client_id_map client_ids;
vector<string> modified_names;
string nameprefix = create_name_prefix();
transform(client_ids.begin(), client_ids.end(), back_inserter(modified_names),
  [&nameprefix](const auto & a) {
    return nameprefix + a.second;
  });

А уж какие плюшки дает C++14 для обобщенного программирования - это вообще небо и земля по сравнению с C++03. Чего только стоит вот такое:

template<typename T1, typename T2> auto sum(T1 a, T2 b) { return a+b; }

Только уже написанный код никуда магическим образом не исчезает при появлении новых стандартов

Да, вот именно, что с ним все нормально и его можно постепенно переводить на новый стандарт. Говорю как человек, прошедший это на практике с несколькими проектами и компиляторами.

transform(client_ids.begin(), client_ids.end(), back_inserter(modified_names),
  [&nameprefix](const auto & a) {
    return nameprefix + a.second;
  });

KISS.

for( const auto& kv : clients_ids )
    modified_names.emplace_back( nameprefix + kv.second );

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

Если посмотреть на код GCC (который скорее C чем C++, с кучей мудреных макросов) то без кардинального переписывания никакого профита не будет

Возможно. Но какое отношение это имеет к тому, что усложнение C++ значительно упрощает разработку софта на C++?

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

Вернемся к примеру с GCC. Если изначально сишный код пытаться адаптировать (а не переписать с нуля) на плюсы, получается в итоге каша из двух языков, а для нормального modern C++ надо все это естественно переписывать. Но трудозатраты в таком случае будут сопоставимы с написанием компилятора вообще с нуля. Да и вообще, я не разделяю энтузиазма по поводу новых плюсовых стандартов. Пытаться сделать высокоуровневый язык на основе кроссплатформенного ассемблера, сохраняя при этом обратную совместимость с ним - не очень хорошая идея. С моей колокольни эти плюсы (сама идея сделать высокоуровневый язык на основе Си) выглядят примерно как попытка прикрутить к танку крылья и авиационный двигатель, чтоб он еще и летал. Да и нормальным высокоуровневым языком плюсы никогда не станут.

В коде на плюсах встречаются уязвимости, характерные для Си (выход за границу массива, всякие там use-after-free) чего нет например в Java или питоне. В плюсах нет (и скорее всего не будет) GC. В плюсах точно не будет никогда метапрограммирования(генерации нового кода) через манипуляции с AST на этапе компиляции и в рантайме(JIT). Плюсы на мой взгляд это вообще какая-то тупиковая ветвь, и чем скорее оно вымрет, тем лучше. Но как показывает практика, живучесть языка определяется еще и количеством написанного на нем кода (например программисты на Коболе до сих пор есть) и плюсы еще долго будут держаться благодаря легаси.

Ну возьмем достаточно простую задачу: допустим что надо мне считать в бигинтах, и хочу я читать формулы из stdin от пользовалетя вида x=a*c+b*c и чтоб был eval() который бы генерировал машинный код по этой формуле (без всяких стековых калькуляторов, мне надо чтоб быстро) и чтобы оптимзировало на уровне арифметических преобразований, например выражение x=a*c+b*c превращало в x=c*(a+b), выражение sqrt(a^2) становилось abs(a) и так далее, и компилировал бы чтобы в машинный код, чтобы я мог через эту формулу применить к множеству чисел. Пользователь дает таблицу
a=123, b=342, c=456;
a=777, b=333, c=666;
....
и программа должна посчитать x для каждой строки, притом сделать это быстро. Таблица может быть задана в каком-нибудь двоично-сериализованном виде, не обязательно в виде строк. Надо чтоб работало в виндовсе, линуксе, масосх, андроиде и на айпэдах всяких(на ARM). Как это сделать? Какими плюсовыми средствами предлагаете решать эту задачу? Нет таких средств, надо самому костылить какой-то JIT (тащить LLVM и куски компилятора с его кучей абстрактных представлений ради калькулятора попросту неоправданно). А какой-нибудь жаваскрипт или лисп эту проблему решает запросто, там есть eval(). Может это будет не так эффективно, как если кто-то будет городить кастомный JIT и писать опкоды в исполняемый сегмент памяти, потом оттуда что-то вызывать, зато это будет БЫСТРО и ИЗ КОРОБКИ. Разве высокоуровневый язык должен требовать таких выкрутасов? Высокоуровневость плюсов это миф. Но и низкоуровневым его назвать у меня язык не поворачивается. Язык Си еще можно с натяжкой назвать языком среднего(но ни в коем случае не низкого) уровня, а плюсы, плюсы вообще вне этих категорий. Это язык фиг-знает-какого-уровня, это сишка, которую подперли кривыми ООП-костылями, шаблонами(почти-препроцессором, который однако встроен в компилятор), constespr-ами и пр.

Усложнение C++ (нововведения в последних стандартах) не делает ненужным умение читать C++ cтарых стандартов.

С++ старых стандартов - это часть нового стандарта. Классы, шаблоны, функции и пр. никуда не делись.

В итоге получается, что программисту на плюсах надо удерживать в голове больше информации.

Чем программисту на чем?

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

Наоборот, после С++11 язык обрел вторую молодость, когда его уже собирались хоронить.

Если изначально сишный код пытаться адаптировать (а не переписать с нуля) на плюсы, получается в итоге каша из двух языков

Получается один язык - С++. Он собс-но и получил популярность за легкость перехода с С.

В коде на плюсах встречаются уязвимости, характерные для Си (выход за границу массива, всякие там use-after-free) чего нет например в Java или питоне. В плюсах нет (и скорее всего не будет) GC. В плюсах точно не будет никогда метапрограммирования(генерации нового кода) через манипуляции с AST на этапе компиляции и в рантайме(JIT). Плюсы на мой взгляд это вообще какая-то тупиковая ветвь, и чем скорее оно вымрет, тем лучше.
...
поток сознания

А, так ты наркоман. Так бы сразу и сказал. У С++ есть только один аналог - Rust. А весь свой бред про замену С++ на язык с GC, JIT и пр. оставь при себе.

С++ старых стандартов - это часть нового стандарта. Классы, шаблоны, функции и пр. никуда не делись.

Да, и что? Препроцессор тоже никуда не делся

Чем программисту на чем?

Например на Си.

Получается один язык - С++. Он собс-но и получил популярность за легкость перехода с С.

Нет. Никакой особой легкости перехода с си на современные плюсы я не наблюдаю.

А, так ты наркоман.

Нет

Так бы сразу и сказал. У С++ есть только один аналог - Rust.

А как же D, Swift, Objective-C в конце-концов?

А весь свой бред про замену С++ на язык с GC, JIT и пр. оставь при себе.

Я говорил о высокоуровневости языка. В нормальных высокоуровневых языках весь этот «бред» как раз должен быть, а месить указатели как в C и С++ там как раз не нужно.

Ужо заменили. Были кресты во все поля, стала жабка.

Усложнение C++ (нововведения в последних стандартах) не делает ненужным умение читать C++ cтарых стандартов.

Вы вообще C++ знаете или просто видели из далека? Старые стандарты практически полностью вошли в новые, что-то уберут из старого только в C++17.

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

Зачем нужно переписывать? В 99% случаев достаточно будет пересобрать код новыми компиляторами.

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

Покажите такой язык для нейтива и без GC.

Вернемся к примеру с GCC. Если изначально сишный код пытаться адаптировать (а не переписать с нуля) на плюсы, получается в итоге каша из двух языков, а для нормального modern C++ надо все это естественно переписывать

Открою вам маленький секрет: работающему коду на C++ вовсе не обязательно быть «нормальным modern C++». У вас какой-то странный максимализм: либо хардкор на шаблонах, либо не C++.

Преимущества от C++ можно получать даже программируя в стиле plain old C и местами, только там, где нужно, использовать фишки вроде enum class, auto или перегрузка оператора сравнения. Без классов, шаблонов, исключений и пр.

Ну возьмем достаточно простую задачу

Ну нифигасе простая задача. Кто вам сказал, что в C++ должны быть готовые инструменты для этого? В C++ дает вам инструменты, которые позволяют вам записать x=a*c+b*c для чисел произвольной точности именно в таком виде без потери эффективности по сравнению с тем, что пришлось бы писать в C:

bignum_assign(x, bignum_sum(bignum_mul(a, c), bignum_mul(b, c)) );

Да, и что? Препроцессор тоже никуда не делся

Да, не делся. Это мешает читать старый код на С++?

Например на Си.

Разве что. Ну и С++ это как раз С для тех, кому хочется большего. Так что странно предъявлять подобные претензии и кивать на С.

Нет. Никакой особой легкости перехода с си на современные плюсы я не наблюдаю.

Авторы GCC достаточно спокойно перешли. Ты, я думаю, ничего подобного не делал, потому и наблюдать ничего не можешь. И не надо говорить про то, что это полу-С, это именно код на мультипарадигменном С++, где ты сам выбираешь что использовать и в какой мере.

А как же D, Swift, Objective-C в конце-концов?

D без GC малоюзабелен. Swift, Objective-C - их библиотеки слишком завязаны на операционки от Apple, компиляторы есть, а открыть, например, файл в программе на Swift в линуксе - низя. И хоть для ObjC есть GNUStep, но нужно быть мазохистом, чтоб это использовать.

Вы вообще C++ знаете или просто видели из далека?

Где-то посередине. Мне доводилось иметь дело с плюсовым кодом, я там даже находил баги и репортил их. Я знаю про классы, шаблоны, наследования, constexpr, move-семантику, знаю про то, как устроена и как генерируется компилятором таблица виртуальных методов, SFINAE... но я практически НЕ ПИШУ на плюсах, мне в основном приходится читать код на плюсах. И мне не нравится то, что я читаю. Чтобы не быть голословным, могу даже привести конкретные примеры плюсового кода, которые мне категорически не нравится

Старые стандарты практически полностью вошли в новые, что-то уберут из старого только в C++17.

В том то и проблема. По-хорошему нужно вообще делать новый язык, где нет этих сишных рудиментов вроде препроцессора. А все эти новые стандарты тащат за собой старый хлам. И например если надо поддерживать старый легаси плюсовый код, эволюционировавший из Си, где еще осталось куча макросов непонятного назначения, то для сопровождения всего этого надо еще и обладать навыками разгребания этих макросов. В плюсах макросы используются намного реже, там даже константы не через #define хотят объявлять, а посредством такого http://en.cppreference.com/w/cpp/language/variable_template :

template<typename T>
constexpr T pi = T(3.1415926535897932385);

Зачем нужно переписывать? В 99% случаев достаточно будет пересобрать код новыми компиляторами.

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

Покажите такой язык для нейтива и без GC.

Да хотя б тот же D (там GC опционален) или Rust. Кстати, в D есть Mixin-ы, которые хоть и отрабатывают только на этапе компиляции, все же оказываются намного полезней, чем constexpr-ы и всякие метапрограммирования на шаблонах. https://dlang.org/template-comparison.html вот еще, по поводу шаблонов в плюсах и D.

Открою вам маленький секрет: работающему коду на C++ вовсе не обязательно быть «нормальным modern C++». У вас какой-то странный максимализм: либо хардкор на шаблонах, либо не C++.

Конечно не обязательно, вот GCC — отличный пример смешивания C++ и C, советую почитать его исходники и сделать выводы. Мне вот что-то совсем не доставляет удовольствия их читать.

Ну нифигасе простая задача.

А по-моему довольно простая. Только сами символьные вычисления (для упрощения выражений) могут вызвать некоторые затруднения, если писать это на том же жаваскрипте через eval().

Кто вам сказал, что в C++ должны быть готовые инструменты для этого?

А мне это никто и не говорил. Более того, я знаю что там ничего для этого нет.

В C++ дает вам инструменты, которые позволяют вам записать x=a*c+b*c для чисел произвольной точности именно в таком виде без потери эффективности по сравнению с тем, что пришлось бы писать в C

Это я тоже знаю, например https://gmplib.org/manual/C_002b_002b-Interface-General.html но никакой работы по упрощению выражений и JIT-у там не происходит

Да, не делся. Это мешает читать старый код на С++?

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

Чтобы не быть голословным, могу даже привести конкретные примеры плюсового кода, которые мне категорически не нравится

Покажите.

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

Это было бы неплохо. Но...

1. Текущий подход дает возможность переиспользовать без переписывания код, написанный чуть ли не 20 лет назад.

2. Это не имеет отношения к тому, что усложнение C++ делает программирование на C++ проще.

Зачем тогда новый компилятор?

Дурацкий вопрос. Как минимум, в новых компиляторах лучше оптимизаторы и еще лучше диагностика. Ключики вроде -Wall, -Wextra и -Weverything для последних версий GCC/Clang переводят продукты вроде Coverity и PVS-Studio в разряд слишком дорогой экзотики, нужной только для очень небольшого количества проектов.

Ну а если код для C++03 перекомпилировать под C++11, то можно еще и получить бенефиты за счет использования move semantic и rvalue references в STL.

Ну вот значит будет часть кода на старом стандарте, часть кода на новом, часть вообще на Си с классами, разве это является чем-то хорошим?

Не вижу в этом ничего плохого. Если есть древний код, написанный еще для C++98 в стиле C with Classes и он работает, то нет никакого смысла его переписывать. А когда приходит время в таком коде что-то подправить, то там можно, где нужно, использовать фичи из новых стандартов.

Мне вот что-то совсем не доставляет удовольствия их читать.

И в этом виноват C++11? Или C++14? Или тот факт, что разработчики GCC слишком долго слушали Столмана и тянули с переходом на C++?

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

Прекрасно. Так почему бы не взять JS? С чего вы взяли, что в C++ должны быть инструменты для этого?

хотя сам с ними не хочешь работать.

Можно поподробнее?

Подробности здесь: Диагностики GCC — это хорошо, но недостаточно (комментарий)

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

Т.е. вы сами подтверждаете, что современный C++, более сложный, чем старый C++, делает разработку на C++ проще.

Тогда к чему жалобы на усложнение C++? Вы делаете свой компилятор или статический анализатор?

Ну и зачем вы мне предложили свою PVS студию если я частное лицо и вы не хотите мне её продавать?

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

Но раз мы подбираемся к Linux, то теперь нам надо и здесь присутствовать.

вы с этим по осторожнее, а то поместят вас во одном разделе с автором одного известного антивируса :)

В старом коде на C++ может быть какая-нибудь наркомания
он этот старый код может просто-напросто не распарсить

В новом тоже. И не только на С++. Это большая отдельная тема - уметь писать простой код.

Если человек не может написать нам, то вероятность, что он станет клиентом, стремится к нулю.

Вы не понимаете кому пытаетесь продать.
Эти люди не не могут написать вам письмо с «левого» ящика, они не хотят тратить свои силы на его создание и получение ответа.
А с «рабочего» ящика они вам писать не будут. потому как вы пока неизвестно кто, может ваш сервер почты спамеры расхакали и результатам написания вам письма будет попадание тщательно скрываемого адреса в спамерские рассылки?
Не один вы гордый пользователь интернета.
Про то что я параноик можете не писать, это не я, это они, ваши потенциальные клиенты так думают.

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

Смотри как бы я тебе не написал письмо (покупать естественно ничего не буду).

А вообще если хочешь чтобы тебе писали только покупатели то опиши что и на каких условиях и за какую цену ты готов продать. А то в своё время я съел 3 часа времени Эльбрусистов только для того, чтобы узнать что их плата для меня слишком дорогая. И да, переписка с Эльбрусистами по почте состоялась и на почту ко мне и пришёл ответ. А вот опубликовали бы цену я бы им ни писать, ни звонить даже и не стал.

Лицензия стоит 5400 евро в год! наглая_рыжая_морда.jpg

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

И таки да, как видите ваша политика сокрытия цены бесполезна, всё равно кто нибудь возьмёт и расскажет.

Но программист должен хотя бы раз где-то услышать про PVS-Studio.

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

Покажите.

Например вот эта конструкция из цепочки многократно вложенных if(SUCCEEDED(hr)) https://github.com/SoftEtherVPN/SoftEtherVPN/blob/master/src/Cedar/Win32Com.c...

Дурацкие повторяющиеся куски, которые сделаны по-видимому с целью оптимизации для часто встречающихся случаев https://github.com/Z3Prover/z3/blob/8aee7129f69c8852ff1bf70dc29217d874292800/... https://github.com/Z3Prover/z3/blob/8aee7129f69c8852ff1bf70dc29217d874292800/... https://github.com/Z3Prover/z3/blob/8aee7129f69c8852ff1bf70dc29217d874292800/...

https://github.com/python/cpython/blob/1fe0fd9feb6a4472a9a1b186502eb9c0b23663... - из интерпретатора питона, вручную раскрученный двоичный поиск. Хоть это и написано на Си, я не знаю, как это сделать на плюсах лучше, чтобы можно было б например написать заготовку двоичного поиска и потом специализировать его под конкретный сценарий применения и разворачивать в нужных местах до нужных размеров. Если это можно как-нибудь сделать в плюсах - жду примера.

https://github.com/ghc/ghc/blob/e23296739fd5b9336bc1a49fe4407e8e02059ea3/incl... - из исходинка GHC, какая-то цепочка #ifdef-ов. Хоть это и написано на Си, я не знаю, как это сделать на плюсах лучше, чтобы можно было сгенерировать цепочку из #ifdef-ы через какой-нибудь макросный цикл(только такого нет, увы), или чтоб вообще не было этого рудимента - препроцессора, и это решалось более нормальными средствами. Если это можно как-нибудь сделать в плюсах - жду примера.

https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp - множественный копипаст с небольшими изменениям например тут https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L69 https://github.com/minetest/minetest/blob/master/src/content_mapblock.cpp#L796 - там почти весь код состоит из повторяющихся конструкций с небольшими изменениями, которые очевидно делались по методике копи-паст, и статический анализатор как раз вот в таких местах часто находит ошибки. Лучше такой код чем-нибудь генерировать.

И да, вот эти constexpr-ы из C++ http://habrahabr.ru/post/228181/ где их в качестве примера используют для символьных вычислений
Вообще, очень показательный пример. Предположим что уже есть некая готовая кем-то написанная обычным способом функция на С/C++(уверен что есть), делающая разбор выражений вида "(4^2-9)/8+2/3". НО использовать ее в этих constexpr нельзя, и надо заново это все переписывать с учетом ограничений (использовать можно только функционально-чистые constexpr-функции, без побочных эффектов и далее по списку. Хотя вот в C++14 там уже можно делать циклы, а не морочить голову рекурсией, уже прогресс). Так почему бы вместо того чтобы переписывать, не сделать кодогенерацию через эту функцию? Притом этот код на constexpr почти наверняка будет труднее для понимания, чем код, написанный в обычном стиле на тех же плюсах.

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

Дурацкий вопрос. Как минимум, в новых компиляторах лучше оптимизаторы и еще лучше диагностика.

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

Ну а если код для C++03 перекомпилировать под C++11, то можно еще и получить бенефиты за счет использования move semantic и rvalue references в STL.

Это да, но многим не нравится STL и все эти нововведения в стандарт. В GCC так вообще, когда они переводили исходники на плюсы, даже были предложения не использовать STL.

Не вижу в этом ничего плохого. Если есть древний код, написанный еще для C++98 в стиле C with Classes и он работает, то нет никакого смысла его переписывать.

Ну вот вы сами говорите, что С++14 более читабелен, легче сопровождается и далее по списку, так почему б его не переписать/адаптировать под новый стандарт? И не будет ли сложностей с интеграцией С++98 и C++17 например?

И в этом виноват C++11? Или C++14? Или тот факт, что разработчики GCC слишком долго слушали Столмана и тянули с переходом на C++?

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

Прекрасно. Так почему бы не взять JS?

Верно. Но только том случае, когда там есть JS (или его можно туда поставить) и не жалко ресурсов. А в случае какого-нибудь контроллера это уже может не подойти.

С чего вы взяли, что в C++ должны быть инструменты для этого?

Я ни с чего и не брал. Более того, я даже практически уверен в том, что таких инструментов там не появится в обозримом будующем (их там скорее всего вообще никогда не появится). Это я все веду к тому, что C++ не является полноценным высокоуровневым языком, и никогда им не станет скорее всего

Т.е. вы сами подтверждаете, что современный C++, более сложный, чем старый C++, делает разработку на C++ проще.

Только при условии, что будут использоваться новые фичи С++. А если есть и то и другое, надо уметь работать и с тем, и с другим.

Тогда к чему жалобы на усложнение C++?

Суть жалобы в том, что знать весь C++ на текущем этапе эволюции этого языка попросту невозможно. В разных проектах (в т.ч. опенсорсных) используются разные подмножества этого C++.Я придерживаюсь той точки зрения, что язык должен быть простым, а дополнительные абстракции должны быть реализованы не посредством введения в язык нового синтаксиса, новых конструкций (вроде лямбд, constexrp и так далее) а чтоб САМ ЯЗЫК предоставлял возможность себя программировать. Речь естественно идет о чем-то вроде лисповых макросов и гомоиконности, кодогенерации, а не колдовства с шаблонной магией. Язык темплейтов в C++, хоть и является Тьюринг-полным, на самом деле на практике бесполезен. Он не совпадает с самим C++, из этого языка нельзя пользоваться возможностями C++, и, соответственно, потенциал роста сложности абстракций оказывается ограниченным.

Это, конечно, очень круто. Говорить, что вам не нравится, как программируют на C++, а потом показывать кучу примеров на чистом C.

У меня сложилось ощущение, что вы от С++ ждете каких-то чудес. Мол, если какой-то перец перешел с C на C++, то он тут же, сразу же начинает писать просто, понятно и эффективно.

Вы ошибаетесь. Чему служит пример с if(SUCCEEDED(hr)). Этот код за счет RAII можно существенно упростить. А если там еще и перейти к использованию исключений, то и в нормальный вид привести несложно. Только вот непонятно, можно ли там исключения применять или нет.

Так что C++ не препятствует написанию говнокода (как и любой другой язык). И если человеку хочется писать вот так:

case BIND4:
   BBIND_COMMON();
   m_registers[m_oreg]   = m_app->get_arg(0);
   m_registers[m_oreg+1] = m_app->get_arg(1);
   m_registers[m_oreg+2] = m_app->get_arg(2);
   m_registers[m_oreg+3] = m_app->get_arg(3);
   m_pc = m_b->m_next;
   goto main_loop;

case BIND4:
  BBIND_COMMON();
  fill_registers_from_arg<4>(m_registers, m_oreg, m_app);
  m_pc = m_b->m_next;
  goto main_loop;

Ну и зачем вы мне предложили свою PVS студию если я частное лицо и вы не хотите мне её продавать?

Я рассказываю о PVS-Studio программистам. Как правило, программисты где-то работают. И будет здорово, если программист станет нашим «агентом влияния» и расскажет в команде о существовании статического анализатора PVS-Studio. Возможно затем он или кто-то ещё попробует, инструмент понравится и компания станет нашим клиентом. Собственно, обычно так продажи у нас и происходят. Мы входим в компании через программистов, так как только они могут оценить наш продукт.

На самом деле, мне непонятно причем здесь вообще частное лицо. Частному лицу вообще продукты для программирования не нужны. Ну разве что в рамках хобби. Но платить за хобби у программистов не в почёте :). И собственно неуспех c CppCat всё это подтверждает.

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

Кстати, что интересно, больше всего вклада в open-source вносит не одиночки энтузиасты, а группы программистах сидящие на зарплате в дорогих офисах Intel, Google, Microsoft и т.д. И совсем неплохо, если они узнают о статическом анализаторе кода PVS-Studio. Я совсем не против продать им, делают ли они Open-Source или нет.

Да, можно еще вспомнить о метапрограммировании на шаблонах. Проблем с метапрограммированием на шаблонах еще больше: если на руках есть работающий в рантайме код, то для компилтайма (если нет constexpr) надо писать код вообще по-новой, переиспользовать старый код нельзя.

Так вам об этом уже который раз говорят: C++ усложняется (тот же constexpr добавили), но это упрощает жизнь программисту. Вот и здесь так же: нет у вас constexpr и извращаетесь, а если есть, то делаете меньше работы. Как по мне, так ради этого и стоило язык усложнять.

Это да, но многим не нравится STL и все эти нововведения в стандарт.

Пусть сделают лучше. Делов-то.

В GCC так вообще, когда они переводили исходники на плюсы, даже были предложения не использовать STL.

В GCC так вообще очень долго не могли на плюсы перейти. Пока не увидели, каких успехов достиг написанный на плюсах clang. Так что не показатель.

Ну вот вы сами говорите, что С++14 более читабелен, легче сопровождается и далее по списку, так почему б его не переписать/адаптировать под новый стандарт?

Это экономически не оправдано. Достаточно уже того, что написание нового кода на C++14 оказывается дешевле и при этом старый код все так же работает. Просто офигенный плюс на практике.

И не будет ли сложностей с интеграцией С++98 и C++17 например?

Сложности будут, если вы вынуждены оглядываться на старые компиляторы. Вот мне, например, для одного из проектов приходится оглядываться на GCC 4.8. И все, некоторые фишки даже из C++11 не доступны, не говоря уже про C++14.

В таких случаях приходится использовать минимально доступное подмножество языка.

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

Да не вопрос. Только вот GCC оказалось возможным потихонечку втягивать в C++, а переписать его на каком-нибудь OCaml-е или Haskell — нет.

Это я все веду к тому, что C++ не является полноценным высокоуровневым языком, и никогда им не станет скорее всего

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

Только при условии, что будут использоваться новые фичи С++. А если есть и то и другое, надо уметь работать и с тем, и с другим.

Нет «и того и другого». Есть один и тот же язык.

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

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

Суть в том, что на данном этапе это не нужно.

В разных проектах (в т.ч. опенсорсных) используются разные подмножества этого C++.

Да это уже лет 20 как. По крайней мере как стали широкодоступны компиляторы C++ с поддержкой шаблонов и исключений, так и пошло-поехало: разные кодгайды в разных проектах и все такое.

Язык темплейтов в C++, хоть и является Тьюринг-полным, на самом деле на практике бесполезен.

Это ваша личная точка зрения.

Это, конечно, очень круто. Говорить, что вам не нравится, как программируют на C++, а потом показывать кучу примеров на чистом C.

Именно на чистом Си там всего два примера (из cython и GHC). Очень хотелось бы посмотреть на то, как тот код на чистом Си можно было бы лучше написать на С++.

Так что C++ не препятствует написанию говнокода (как и любой другой язык). И если человеку хочется писать вот так:
...
То он и будет так писать. Хотя мог бы написать хотя бы вот так:
...

Неее, надо не просто убрать

   m_registers[m_oreg]   = m_app->get_arg(0);
   m_registers[m_oreg+1] = m_app->get_arg(1);
...

case BIND2:
  BBIND_COMMON();
  fill_registers_from_arg<2>(m_registers, m_oreg, m_app);
  m_pc = m_b->m_next;
  goto main_loop;
case BIND3:
  BBIND_COMMON();
  fill_registers_from_arg<3>(m_registers, m_oreg, m_app);
  m_pc = m_b->m_next;
  goto main_loop;
case BIND4:
  BBIND_COMMON();
  fill_registers_from_arg<4>(m_registers, m_oreg, m_app);
  m_pc = m_b->m_next;
  goto main_loop;

А с «рабочего» ящика они вам писать не будут. потому как вы пока неизвестно кто, может ваш сервер почты спамеры расхакали и результатам написания вам письма будет попадание тщательно скрываемого адреса в спамерские рассылки?

Facepalm. Тяжело такое комментировать. В крайнем случае, никто и не требует, чтобы такой человек писал письмо. Мы может начать общаться с Team Lead этой команды или менеджером проекта. У них нет таких заморочек и общение идёт конструктивно.

Вообще не понятно, зачем проецировать свою пареною на окружающих. Я же знаю, что нам нормально пишут, мы общаемся, продаём, поддерживаем. Какая-то выдуманная проблема, чтобы завуалировать простой факт - анализатор Вам или такому абстрактному персонажу в принципе не нужен.

что тоже нехорошо

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

А вообще если хочешь чтобы тебе писали только покупатели то опиши что и на каких условиях и за какую цену ты готов продать. А то в своё время я съел 3 часа времени Эльбрусистов только для того, чтобы узнать что их плата для меня слишком дорогая. И да, переписка с Эльбрусистами по почте состоялась и на почту ко мне и пришёл ответ. А вот опубликовали бы цену я бы им ни писать, ни звонить даже и не стал.

А причем здесь Вы? Вы что хотели Эльбрус себе домой? Он или нужен компании, в которой Вы работаете, или нет. И решать дорого он стоит или нет, должно решить Ваше руководство. B2B.

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

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

Поправка. Вы не узнали о цене. Вы нашли какое-то число на просторах интернатах, в обсуждении бородатой давности.

Да, вот именно, что с ним все нормально и его можно постепенно переводить на новый стандарт. Говорю как человек, прошедший это на практике с несколькими проектами и компиляторами.

Как-то я на практике не сталкиваюсь с такими проектами, которые планируется рефакторить с целью подновления. Это нерационально. Так и лежат миллионы строк кода так, как написаны. В результате проект напоминает дерево с кольцами этапов развития C++.

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