Comments 23
Не убедили. Сказать, что синтаксический анализ стал ширпотребом можно будет только тогда, когда у вас на сайте появится цена и кнопка «добавить в корзину».
P.S. И да, я, в отличие от многих, не призываю вас это сделать «прям щаз», а то «я на вас обижусь». Как раз то, что продажа сложных продуктов, требующих внедрения начинается со «звонка оператору» — это нормально. Просто это показатель того, что «это вот — всё ещё продукт для избранных, не для всех».
P.S. И да, я, в отличие от многих, не призываю вас это сделать «прям щаз», а то «я на вас обижусь». Как раз то, что продажа сложных продуктов, требующих внедрения начинается со «звонка оператору» — это нормально. Просто это показатель того, что «это вот — всё ещё продукт для избранных, не для всех».
В новом (уже не очень новом) стандарте у меня иногда случаются проблемы при переводе старого кода на новый формат. Например, отслеживает ли PVS-Studio вот такие ситуации? (разумеется, в виде списке предупреждений, а не ошибок). У меня сейчас проблемы в работе VisualStudio, не могу PVS использовать, чтобы самому проверить.
Уже были ситуации, когда, по невнимательнсоти, писал не те скобки. Если не повезёт с типами, то даже скомпилируется…
std::vector<size_t> v1( 10, 1 ); // размер 10, инициализирован единицами
std::vector<size_t> v2{ 10, 1 }; // размер 2, заполнен числами 10 и 1
Уже были ситуации, когда, по невнимательнсоти, писал не те скобки. Если не повезёт с типами, то даже скомпилируется…
Вопрос не понятен. А что хочется детектировать? Что используется такой {} или такой () формат инициализации? Не очень хорошая идея для диагностики…
Прошу привести кратное описание желаемых диагностик с примерами.
Прошу привести кратное описание желаемых диагностик с примерами.
Выводить предупреждение минимального «уровня опасности»… Хотя… Невозможно же определить, какой из двух вариантов хотел написать программист и тогда предупреждений будет бесполезно огромное количество… Понимаю, плохая идея. Надо просто для списка инициализации всегда писать "= {...}", тогда вероятность ошибки будет минимизирована.
Насколько я понимаю проблема только в том случае, когда есть ровно два элемента в фигурных скобках.
Нужно сначала на всех доступных проектах найти такие случаи, попытавшись понять — а сколько их, собственно, вообще бывает. Дальше — прикручивать эвристику.
То есть, наверное, бывают такие случае легитимного использованя, но так как я никогда таких не видел, то даже не могу себе представить какая там может быть эвристика.
Может даже оказаться, что два элемента в списке инициализации — уже сама по себе неплохая эвристика…
Нужно сначала на всех доступных проектах найти такие случаи, попытавшись понять — а сколько их, собственно, вообще бывает. Дальше — прикручивать эвристику.
То есть, наверное, бывают такие случае легитимного использованя, но так как я никогда таких не видел, то даже не могу себе представить какая там может быть эвристика.
Может даже оказаться, что два элемента в списке инициализации — уже сама по себе неплохая эвристика…
Теоретически, если сперва был список инициализации, а потом обращение к вектору на запись значений, особенно циклом, почти со 100% вероятностью скажут про ошибку задания, что вместо круглых скобок поставили фигурные.
К счастью, этот код скомпилируется только для целых чисел и в большинстве случаев оибка обнаружится при первом же запуске. Н опридётся долбиться в глаза, тчобы различие скобочек увидеть. Переживу :)
К счастью, этот код скомпилируется только для целых чисел и в большинстве случаев оибка обнаружится при первом же запуске. Н опридётся долбиться в глаза, тчобы различие скобочек увидеть. Переживу :)
Оба кусочка кода синтаксически и семантически совершенно валидны. Допустим, после мы имеем нечто навроде:
Как вы предлагаете догадаться анализатору что на самом деле хотел сделать автор? Почему, допустим, версия с v1 должна считаться ошибкой а v2 нет или наоборот :-?
for (const auto i : v1) {
std::cout << std::dec << i << std::endl;
}
Как вы предлагаете догадаться анализатору что на самом деле хотел сделать автор? Почему, допустим, версия с v1 должна считаться ошибкой а v2 нет или наоборот :-?
Белой завистью завидую мощи инструментов! К сожалению, до мира golang нескоро подобное дойдёт. Но даже прикручивание пачки линтеров в CI даёт отличные результаты: уменьшается нагрузка на code review, появляется объективное обоснование исправления кода с ошибкой или небезопасным поведением, что важно для некоторых товарищей, легче вводить людей в проект. Вообще "всё, что может быть автоматизировано, должно быть автоматизировано".
Самый лучший способ улучшить кодовую базу проектов на C++ это перестать использовать там C++. C++ превратился в уродливого монстра, и со временем будет только еще уродливей. Давайте будем честными сами с собой — никакие, даже самые продвинутые инструменты, не превратят говнокодеров на C++ в высококласных специалистов. Есть такой замечательный язык D, который, к сожалению, не имеет и доли популярности своего предшественника, но который лишен значительной части недостатков последнего. Но ежики все так же будут продолжать жрать говно писать на C++ и плакать…
видишь тут ещё и минусы за такое ставят. Но я поддерживаю, что если синтаксис слишком запутанный и позволяет
многим ошибкам быть в валидном кодето виноват язык.
Правильно ставят. Язык — это не более, чем инструмент, а любым инструментом нужно уметь пользоваться. Выстрелить себе в ногу можно хоть на C++, хоть на D — не одним способом, так другим, голову необходимо прикладывать в любом случае. Было бы ошибкой думать ©, что можно просто взять говнокодера, кое-как тяп-ляп обученного C++, «по-быстрому» переобучить его на D, и вуаля — он больше не будет плодить говнокод. Как бы не так, это так не работает.
Да, язык это инструмент и любым инструментом нужно уметь пользоваться, вот только зачем тратить уйму времени на изучение кривого, уродливого и ненадежного инструмента когда то же самое можно сделать гораздо меньшими усилиями с помощью более простого, изящного и надежного инструмента? Скажем, template metaprogramming, compile-time programming — сложные, но полезные штуки. Пробовали когда-нибудь использовать их для чего-нибудь маломальски содержательного на С++? В D использование этих подходов ничуть не сложнее «обычного» программирования. То есть целого класса проблем просто не существует. И речь не о том что говнокодер на С++ переучится в профессионала начав кодить на D. Речь о том что большинство программистов станут более эффектво решать свои непосредственные проблемы, а не тратить свои силы, свое время и свой талант на борьбу с уродством и убогостью С++.
Ну, зато они начнут "бороться с уродством и убогостью" D, например, допиливать местный gc, без которого сейчас в D по большому счету особо не обойтись. Это вообще одно из основных больных мест D, регулярно поступают предложения сделать хотя бы ARC а-ля поздний objc/Swift, но пока воз и ныне там. Короче, серебряной пули, как обычно, не существует.
Да я и не утверждаю что D идеален. Но глупо отрицать что он на голову выше С++ по своему дизайну (и так же глупо было бы утверждать что он вообще лишен недостатков). Моя мысль сводится к тому что самое разумное для сообщества было бы ивестировать свои силы в то что можно улучшить, например в D. И бессмысленно тратить силы на то что улучшить уже нельзя. Любое «улучшение» С++ (= приделывание костылей) лишь будет сильнее затягивать его в пучину переусложненного синтаксиса и нагромождения разнородных идей, криво сшитых белыми нитками.
Моя мысль сводится к тому что самое разумное для сообщества было бы ивестировать свои силы в то что можно улучшить, например в D.Зачем?! Языков с GC — как грязи. Популярных, хороших, используемых: C#, Go, Java…
Вы же вроде про замену C++ вякали? Ну так тут GC должен отсутствовать. Пока что в этой нише один серьёзный игрок: Rust.
Его потихоньку пробуют… Но заменить C++ он пока не готов…
Любое «улучшение» С++ (= приделывание костылей) лишь будет сильнее затягивать его в пучину переусложненного синтаксиса и нагромождения разнородных идей, криво сшитых белыми нитками.Поживём — увидим. Пока что C++ успешно пережил с полдюжины попыток «замены». Часть — ушла в небытиё, часть — заняла какую-то нишу. Но вытеснить C++ никому пока не удалось…
Да, я вякал про замену С++ ) D это наиболее близкий к С++ язык из всех. Java это такое же уродливое говно как и С++, да области примениния у них разные, так что Java и С++ не конкуренты. Равно как не конкуренты С++ и Go (по крайней мере, не во всем). С#, да и вообще вся платформа .NET, это замечательная вещь, и для все будет лучше если С# вытеснит Java, но, опять же C# и С++ не конкуренты.
К сожалению, С++ действительно пережил несколько попыток замены. Только какой ценой? Тысяч человек-лет потраченных на реализацию крайне раздутого и переусложненного стандарта? А сколько человек-лет потрачено на создание сопутсвующих инструментов? Все эти усилия могли бы быть использовану с гораздо большей пользой.
К сожалению, С++ действительно пережил несколько попыток замены. Только какой ценой? Тысяч человек-лет потраченных на реализацию крайне раздутого и переусложненного стандарта? А сколько человек-лет потрачено на создание сопутсвующих инструментов? Все эти усилия могли бы быть использовану с гораздо большей пользой.
Думаю, сообщество само разберётся, без ценных указаний класса «взять все и поделить переписать», а все эти человеко-леты потрачены отнюдь не зря, чего не скажешь о человеко-летах, потраченных на несостоявшихся «убийц» C++.
То есть по существу вопроса сказать больше нечего? )
Я сам в последнее время изрядно зафанател от того же Rust, но — нельзя просто так взять и перестать использовать C++, особенно в достаточно больших проектах. Начать понемногу внедрять альтернативный язык — да (и то, взаимодействие кода на C++ с другими языками — это порой та ещё головная боль). Но не более, по крайней мере, на начальном этапе.
Sign up to leave a comment.
Статический анализ улучшит кодовую базу сложных C++ проектов