PVS-Studio corporate blog
C++
C#
Development for Linux
Development for Windows
Comments 669
+14
Отлично! Супер! Единственная просьба — разрешить не только С++ комментарии, но и Си (/* */). Проект в релиз собирается по стандарту С90, там комментарии "//" не даст вставить компилятор
+3

Если честно, Си вообще в принципе почти экзотика для энтерпрайза)
Подозреваю, что примерно про мой проект в статье и написано: Winter Novel. Подробнее о реализации тут
С90 и остальные "зверские" опции компилятора сейчас использую почти вместо PVS-Studio — они заставляют писать чище, потом меньше времени на отладку.

+1

Я сталкивался с подобным наследством в медицинской области, где некоторые файлы были еще старше (там был сильнозапущеный принцип "работает — не трожь", помноженый на медицинскую специфику что любой код или либа по умолчанию считаются опасной и глючной). И проблем там была куча из-за этого, тот же кланг вообще не смог проанализировать или собрать проект из-за отсутствия -fpermissive и присутсвия в коде кнострукций void a(){ return 1;}

+10
Да, такая возможность есть. Вы можете написать:

/* This is an open source non-commercial project. Dear PVS-Studio, please check it.
 * PVS-Studio Static Code Analyzer for C, C++ and C#: http://www.viva64.com
 */

Замечу, утилита для вставки комментариев так не умеет. Поэтому надо либо вставить комментарии вручную, либо доработать утилиту (на github доступен её исходный код).
+13
Отличная новость и интересная реализация, надеюсь она принесёт вам профит.

+22

Однозначно разумный и честный подход! Моё глубокое вам уважение!

+3
Попытки редактировать поля Registration и Serial в настройках PVS Studio намертво убивают Visual Studio :( (Upd: оказывается не намертво, но где-то полминуты Студия висела.)
+1
Боюсь что к тому времени выйдет Rider, и Студия будет постепенно уходить в забвение.
0
Боюсь, что Rider для enterprise — это далекое будущее… А значит студия еще поживет…
+10
Уже два раза пытался внедрить ваш продукт на производстве, но есть проблема. Ищешь ты удобного случая, подходишь к начальству говоришь: «Тут есть такая классная штука .....». А тебе в ответ: «Прайс покажи», ну ты мнешься немного, говоришь ну вот полгода назад мне в письме отвечали столько-то. На тебя смотрят сквозь густую бровь: «Ты что на китайском рынке, где ценник на товар не указывают». И ты снова идешь пишешь письмо, и когда этот удобный случай настанет снова…
-16
Казалось бы, возьми да напиши на support@viva64.com и не надо ждать удобного случая.
+53
Казалось бы, возьми да повесь прайс прямо на сайте, и не надо никакие письма писать…
+2
Сколько можно пережевывать одно и то же. Корпоративные продукты и их внедрение имеют свою специфику и «прайс по запросу» — одна из них.

Это, собственно, очень хороший первичный тест: если ваше начальство не знает о том, что «прайс по запросу» — это типичный способ продажи корпоративного софта и его практикуют, в частности, такие «мелкие китайские лавочки» как IBM или SAP, а также и конкуренты обсуждаемого здесь продукта, то, в общем, вам стоит сначала об этом с начальством поговорить, а не учить весь мир — как ему следует жить?
+6
То, что так делает IBM (а ещё тьма тьмущая производителей и поставщиков железа), не значит, что это хорошо. Я не понимаю зачем так делать? Чтобы каждому клиенту разные ценники выставлять? Чтобы от налогов уклоняться?
+8
Я не понимаю зачем так делать? Чтобы каждому клиенту разные ценники выставлять?
Именно. Я читал, что такое практикуется в Китае в ресторанчиках, куда захаживает, как местное население, так и туристы. Фиксированной цены в меню нет. Цена зависит от прикидки «на глазок» платежеспособности клиента. Более «продвинутые» китайцы делают два меню:
Некоторые рестораны (особенно часто мы это наблюдали в городе Санья, остров Хайнань) имеют меню на русском или английском языках. Такое меню ориентировано на иностранных гостей, но цены в нем завышены. Причем иногда в два раза. Заметив такое «кидалово», мой супруг, прищурившись, смотрит на официанта и просит «другое» меню.
+9
Чтобы каждому клиенту разные ценники выставлять?

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

Честные — это плата за рабочие места, за объем проверяемого кода, за дополнительные возможности программы, за скорость поддержки. Честные — описываются в прайсе.

А нечестные — это когда прайса нет, а есть оценка платежеспособности клиента.

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

Но у вас-то хотят узнать цены на коробочное решение. Ну если оно у вас есть, конечно.

Потому как из-за отсутствия прайса — впечатление хреновое. То ли обдерут как липку, то ли у людей нету продукта, а есть полузаказные (исследовательские) варианты программы.
0
то ли у людей нету продукта


Зайдите в раздел Downloads и скачайте. Сможете понять, продукт это или не продукт.
-2
Ну батенька, ну Брукса почитайте. Или вы утверждаете что у вас комплексный программный (коробочный) продукт или у вас программа, которая при внедрении подтачивается напильником под клиента.

Если внедрение требует усилий от вас(и только от вас) — это не продукт.
+1
Мир не такой чёрно-белый. Наличие дистрибутива и кнопки «выполнить анализ», не гарантирует что всё у всех получится, и вот здесь и нужна поддержка. И дело не в том, что мы криворуки. Статический анализатор — это сложный продукт. И как следствие есть масса нюансов, которые невозможно учесть. Сталкиваемся с ними не только мы, но и, например, старшие коллеги из Coverity. В свою очередь предлагаю прочитать их статью: "A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World". В ней как раз рассказывается, что не всё так просто в этом самом Real World.
0
Давайте не путать отсутствие продукта и цену поддержки. На поддержку вполне возможен отдельный прайс. В пределе как в 1С-Бухгалтерии. 1С — вполне себе продукт, но без настройки непригоден для использования. Отличие в том, что настройку делают сторонние фирмы.

А у вас, я так понимаю, приходится подпиливать код под заказчика. Что и означает, что программа у вас есть, а комплексного программного продукта нет.

Видели компилятор, который подпиливается под заказчика? Такой компилятор — не продукт, а решение. И прайс на него зависит от времени на допилку. Но большинство компиляторов — коробочные продукты. И подпиливания под заказчика не требуют.

P.S. Интересно, вы вспомните хоть один пример компилятора, подпиливаемого под заказчика?
0
P.S. Интересно, вы вспомните хоть один пример компилятора, подпиливаемого под заказчика
Легко. ICC, SCC. Cygnus Solutions на этом специализировались (и да, скачать с сайта у них можно было весьма небольшую часть того, что можно было купить). Со временем, правда, компиляторы стали более «коробочными» — я знаю что пять лет назад они ещё вовсю пилились под конкретных заказчиков, но не знаю — пилятся ли всё ещё сейчас…
0
я то имел ввиду компилятор Алгол-68, который команда Терехова за месяца раскручивала на новую архитектуру процессора. Кто делал компилятор под NeuroMatrix не помню, но там тоже только кодогенератор писали.

Но, повторюсь, это не продукты, а решения. Чуть иная категория.
0
Прочитал все ваши диалоги и не могу сдержаться спросить: вы точно не путаете настройку программ, разработку и поддержку? Просто выглядит так, будто в программе есть гибкие настройки, но от нечего делать разработчики переписывают код каждый раз, когда им пишут на почту.
-7
Это вопрос ко мне? Если ко мне, то я бы сказал так, что их программа не является комплексным программным продуктом и не может корректно обрабатывать результаты препроцессирования любых #define. Поэтому они затачивают вручную программу на конкретный набор используемых макроопределений.

При этом убрать ложные часть ложных срабатываний они могут конфигурированием, а часть — требует дописывания (расширения) конфигурирования.

Ну как пример, что мы используем
#define CCASSERT(predicate) _x_CCASSERT_LINE(predicate, __LINE__)
#define _x_CCASSERT_LINE(predicate, line) _x_CCASSERT_LINE_CAT(predicate,line)
// cppcheck-suppress variableScope
#define _x_CCASSERT_LINE_CAT(predicate, line) \
typedef char constraint_violated_on_line_##line [2*((predicate)!=0)-1];


Это assert, работающий в compile-time. И подавление диагностики от cppcheck там не спроста. Но если вместо настройки макроопредений под систему статического анализа они пытаются сделать наоборот (настроить систему статанализа под используемые макро) регулярное добавление ручек в в конфиг является неизбежным…

Мой совет — спросите их напрямую, может быть расскажут… я лично сужу по куче признаков, начиная с конской цены в 25 миллионов рублей (информация с тех времен, когда они ещё цену не скрывали). Ну и см выше об отдельной цене для каждого заказчика.
0
я лично сужу по куче признаков, начиная с конской цены в 25 миллионов рублей (информация с тех времен, когда они ещё цену не скрывали)


-3
Мне не нравится, когда цену назначают исходя из толщины моего кошелька. я не против сегментации, когда есть явный прайс с вариантами подешевле и получше.
0

Нет, это вам в другой ветке не нравится. Тут вы говорили про подавление предупреждений.

-6
Перечитайте, пожалуйста ветку. Или объясните, к какому именно посту вопрос. А то похоже, что я туплю… Может вы придрались к этому ??

Ну тогда почитайте, что пишут авторы PVS-Studio. Собственно я всего лишь попытался конкретизировать их слова

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


Это авторы PVS-studio считают, что нужно подтачивать их программу напильником, а не я. я всего лишь пояснил, в каких местах её, скорее всего, точат.
0
Видимо туплю. Объясните тогда (лучше в личке) против каких слов вы возражаете.
+7
Да знаем, хлебали этого говна. Начинаешь изучать, какие продукты на нужную тему вообще есть на рынке. Находишь три варианта, цена от компании X и от компании Y отличается в разы, а у компании Z на сайте цены вообще нет, один только маркетинговый буллшит и вот это вот «возьмите да напишите». При этом ни о какой кастомизации и аццкой интеграции вопрос не стоит. Вообще не стоит, не может стоять, в силу специфики продукта. Вот нахуа?? Зачастую «возьмите да напишите» означает совершенно антигуманные цены, но и это не всегда. Пишу, высылают прайс, явно стандартный какой-то. Всё то же самое, как если бы просто цену на сайте указали, только ещё дополнительно надо прыгнуть через горящее кольцо и подождать ответа от нескольких часов до нескольких дней. По-приколу люблю таким писать с личного мусорного гмайл-аккаунта, всё равно отвечают, высылают тот же самый прайс :)
+1
Ладно если так, а то иногда для запроса цены надо анкету заполнить в которой разве что результатов твоих анализов нет.
0
Главное, чтобы как Интел не сделали, чтобы анкету надо было заполнять только чтобы скачать триалку новой версии.
Или как постоянные посетители бара «Голубая устрица» компания Оракл — чтобы скачать что-то надо сперва зарегистрироваться на сайте, при попытке регистрации должно сперва письмо придти для окончания регистрации, а письмо-то и не приходит…
+7
NVidia тоже не отстаёт — для каждой ихней библиотечки надо подавать заявление на очередную «девелоперскую программу», в процессе чего заполнить анкету, а кто ты, да что ты, да как ты собираешься использовать, после чего они тебя рассмотрят на пленуме ЦК и зааппрувят, а может быть и нет. При этом аппрув, хоть и занимает порой несколько дней, похоже, автоматический — я как-то раз написал в ответ на вопрос «зачем хотите это использовать?» что для пост-обработки детской порнографии, деньги от которой планирую направить на наркоторговлю, работорговлю и поддержку международного терроризма — таки всё равно зааппрувили.
+3
Странно, на самом деле. Сплошь и рядом такое (к сожалению), и не только в России. Недавно 2 недели MaximIntegrated мурижил, чтоб выставили счёт на одну отладочную платку, ну никак не хотели продавать.

зы: хочу PVC studio для эмбеда (БЕЗ Visual Studio)
-4
Это нормальная стандартная практика.

P.S. PVS-Studio без VS уже давно есть :)
+6
Если мы сейчас начнём по очереди приводить примеры товаров с ценниками и без, то ветка уйдёт в бесконечность, учитывая, что ни география, ни предметная область вопроса не ограничена.
+9
Так в чём проблема продумать и построить схему ценообразования такой, что её не придётся прятать? Думаете JetBrains добился бы распространения своей IDE, если бы прятал ценник?
0

Стоит дополнительно заметить, что ещё у JetBrains есть бесплатная версия с открытым исходным кодом. Первая доза — бесплатно. А ещё — студенческие лицензии. Подсадить их смолоду!

0
Студенческие лицензии которые, кстати, можно использовать на производстве пока ты студент. Был сильно удивлён когда на мой вопрос в поддержку «А можно ли?» мне ответили прямым текстом «Да» без каких-либо условий.

Вот уж действительно, подсадили на иглу смолоду.
+1
И тоже дают с неё скидку при покупке через sales@jetbrains.com или реселлеров.
+3
Потому что NASA, если сильно упростить, покупает примерно так:
— Хотим вот эту позицию (тычет пальцем в прайс), плюс вот это, это и это. И чтобы ещё всё застраховано было по максимальному тарифу. Ах да, и ещё хотим контролировать каждый ваш чих в момент предоставления услуги.
— Не вопрос. Тогда цена будет вот такая.
— По рукам.
+1
NASA не страхует пуски как государственная компания. Она вкладывает дополнительные деньги в дополнительные проверки.
+1
Вот вы ведете себя как очень прогрессивная компания, готовая искать новые каналы сбыта и рекламы. Чего только стоит этот топик.
Так может попробуете «сломать систему» еще разок и сформировать подход при котором потенциальный клиент может заранее оценить затраты на внедрение?
0
Я ничего не понял. Прошу сформулировтаь предложение как-то иначе.
0
Стандартная практика — не публиковать прайсы и не раздавать бесплатных лицензий за комментарии в коде.
От второго вы смогли отойти, попробуйте отойти и от первого.
0
В день когда на viva64.com появится прайс, миллионы россиян вздохнут спокойно… А собственно почему? Вот лично Вам какое дело до наличия цен на сайте?

Если у Вас есть интерес к PVS-Studio, то напишите с корпоративной почты и узнаете цены, секрета в них нет. А если интереса нет, то какая разница, указаны они на сайте или нет.
+1
я знаю цену, которую вы заломите для нашей компании. А чтобы узнать реальную цену на ваш продукт — нужно писать не вам, а выискать 5-10 ваших клиентов и у них узнавать, по какой цене они купили.

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

А искать ваших клиентов — откровенно лень. Потому, если уж покупать продукт для статического анализа — то не у вас, а у фирм, не скрывающих сои прайсы.
+1
Да ноль проблем; 1C, ИнСат, Embarcadero
… ну в общем все, у кого есть продуктовое решение, не требующее подтачивания напильником под клиента.
0
Ну и покупайте статический анализ у 1С и ИнСат.

Сразу видно теоретика. Вам просто не нужно, вот и все.
+1
Статический анализ нам полезен. CppCheck я использую. Но судя по косвенным признакам — ваши цены не для нас. 200 тысяч строк кода — не тот размер, где миллионы на PVS-studio окупятся.

Поэтому работаем по-старинке — код периодически компилируется дюжиной компиляторов под полудюжину операционок.

Ну и опять-таки, отпугивает необходимость адаптировать код PVS-studio под каждый проект.
0

cppcheck — это несерьёзно, на самом деле.


Coverity скорее попробуйте или даже clang static analyzer. И вообще, я на днях таки допилю статью на тему недосравнения всех трёх (мне, наконец, ответили из Coverity с решением моей проблемы по запуску их анализатора в моей конфигурации, что дало возможность потестить этот анализатор и в очередной раз затянуло статью), там можно делать выводы.

0
Не понимаю, почему вы решили, что clang static analyzer продукт более высокого уровня, чем coverity.
0
Coverity скорее попробуйте или даже clang static analyzer.

вот это даже мне и не понравилось
0

О, прекрасные человеческие языки с их неоднозначностями.


В общем, оно там в другую сторону, считайте.

-1
Но в целом вы правы, нам ваш продукт не выгоден. Сколько он может сэкономить времени в год? Ну скажем 2 недели на поиски ошибок. Вот половину этого (неделя ФОП программиста) и должна стоит лицензия на рабочее место. Тогда внедрение выгодно. А при тайных ценах — даже экономический расчет не получится сделать.
-1

Т.е. по вашему и покупателям IntelliJ CLion анализ не нужен, коли ваш продукт не покупают? Я конечно им не пользовался (на c/c++ не пишу), но сомневаюсь, что в этом продукте JetBrains отступились от своей практики внедрения он-лайн статического анализа с быстрыми проверками и возможностью более полного статического анализа по запросу…
с ним только одна проблема — это побочный клиент-сайд функционал

+1

Кстати, непонятно, почему вас минусуют. У CLion анализ находит любопытные и пахнущие места, некоторые из которых не находит тот же PVS или clang.

0
А ведь раньше был там прайс. Хотя уже подозрение иногда, что могло и присниться. Помню, что на команду в 9 человек что-то около 110 т.р. выходило. Если сейчас цена приблизительно такая же, то это очень не плохо.
+2

Прочитал статью на сайте обрадовался! Попытаюсь с ней разобраться. Спасибо за замечательный инструмент.

+1
Я что-то не понял, вот, допустим, я очень корпоративный разработчик — кроме мук моей воспалённой совести мне что-то помешает держать ваши комментарии только в моей рабочей копии и автоматически удалять перед каждым коммитом?
+5
В очень корпорации иногда приходит очень внезапно проверка. И очень внезапно обнаруживает у вас нелицензионный софт на компе. В конце концов, для очень корпорации это не такие уж и деньги.
+1
Возможно. Но зачем тогда требовать какой-то дополнительный комментарий в начале каждого файла?
+3
Очевидно чтобы они работали как реклама? Да, какой-то «Злобный Буратино» может настроить в своём личном проекте всё так, как вы сказали — ну так он и без того платить не будет.

А для корпорации сам факт того, что подобный «обработанный файл» может случайно попасть в репозиторий и потом всплыть где-нибудь в суде — хороший повод так не играться.
+19
Ничто не помешает. А раз Ваше рабочее время стоит так дешево, чтобы заниматься на работе фигнёй, то значит компания где Вы работаете не является нашим потенциальным клиентом. :)
+3
Вот я и думаю: по-замыслу, вроде как, вы пытаетесь создать мне достаточно неудобств, чтобы побудить не заниматься на работе фигнёй и купить уже лицензию. А по-факту, скрипт, который добавляет-удаляет всё, что нужно, я сваяю левой ногой минут за пять, а потом повешу pre-commit hook-ом (или как там оно называется), и мне даже хоткей никакой нажимать не придётся. Уж всяко меньше я с таким подходом потрачу времени на «фигню», чем пытаясь пробить покупку вашего софта по корпоративным каналам (это даже без учёта времени на написание вам письма и ожидание ответа :)
+13
Делайте. Я же поставлю свечку, чтобы однажды скрипт сглючил и комментарии попали в систему контроля версий. За что кого-то накажут. :)

А если серьезно, то мы отлично понимаем, что систему можно обойти. Более того, её легко было обойти и раньше. Вся идея в том, что тот, кто готов заниматься подобным не является нашим клиентом. Есть компании, которые умеют ценить время и понимают, что приобретают не только программу, но и сопровождение, что крайне важно в больших и сложных проектах. На них мы и ориентируемся.
0
Делайте. Я же поставлю свечку, чтобы однажды скрипт сглючил и комментарии попали в систему контроля версий. За что кого-то накажут. :)


Какой вы злой и мстительный… :)
+6

Не накажут. Бог дал нам гит и возможность переписать историю :).

+3
3aicheg, для приличия хоть, добавить бы, сослагательное наклонение
0
Имеется в виду замена явного намерения
всё, что нужно, я сваяю левой ногой минут за пять

на что-то гипотетическое, типа
всё, что нужно, я сваял бы левой ногой минут за пять

для смягчения эффекта.
0
А по-факту, скрипт, который добавляет-удаляет всё, что нужно, я сваяю левой ногой минут за пять, а потом повешу pre-commit hook-ом (или как там оно называется), и мне даже хоткей никакой нажимать не придётся.

Не забудьте на гитхаб выложить и опубликовать ссылку! :)
+2

Знаете, написать приложеньку для такого трюка стоит по времени гораздо дешевле, чем стоимость годовой лицензии на человека (в составе команды из 10 человек). Впрочем, в моей, например, компании, даже и в git это можно было бы залить без проблем. Но совесть. Поэтому сидим без лицензии (один год попользовались, профит меньше ожидаемого, продлевать не стали).
По-моему, вашу — действительно очень здравую и хорошую — задумку с бесплатным использованием лучше продвигать и обсуждать в терминах совести, а не игры в кошки-мышки.

0
>Знаете, написать приложеньку для такого трюка стоит по времени гораздо дешевле, чем стоимость годовой лицензии на человека

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

Казалось бы, если продукт содержит логические бомбы и с ним нельзя работать без постоянной поддержки, то его качество вызывает большие сомнения и покупать его себе дороже.
При этом мой небольшой опыт работы с PVS Studio говорит, что это вполне нормальный подукт, которым можно пользоваться без посторонней помощи. Отсюда вопрос — что именно входит в ту поддержку, без которой не обойтись, какие операции, какая помощь? Может, я пропустил какие-то важные ее возможности, с которыми от студии был бы гораздо больший профит?

0
Вверху кликните по ссылке на «блог компании» и отмотайте в прошлое где-то на пол-годика, у них там есть пост, как их триальные ограничения, на самом деле, благо для юзера, ибо стимулируют писать им в техподдержку, а без неё никак. На мой взгляд, не особо убедительно, но, может, вас сильнее убедит.
+2

Спасибо, прочел. Не лишено смысла, но пара ссылок на документацию — это явно не та поддержка. которая требуется годами. В целом, аргументация "почему у нас подписочная модель оплаты" у PVS очень слабая (поддержка, добавление новых правил, ...) и искусственная, призванная заменить настоящую мотивацию "нам надо больше денег". Поэтому дальше обсуждать ее, наверное, бесполезно.

0
Очень правильная философия. Искренне желаю вашему проекту расти и процветать.
+1

Да ну ладно вам. Я от мира С очень далёк, но я напишу такой скрипт, ну, скажем, за два часа. Это сколько-то тысяч рублей. На этом я сэкономлю компании все деньги на покупку вашего продукта. Я это даже чисто из любви к компании могу сделать, в свободное время, просто потому что для меня это интересный челлендж. И цена моего времени вообще ни при чём тут.

0
Для мелких компаний — возможно, а в особом мире корпоративного маразма дело не в деньгах, и эффективные менеджеры вряд ли одобрят подобную экономию, а ещё меньше того её одобрит юридический отдел. Зачастую вообще боятся бесплатного ПО (да, именно бесплатного, безо всяких ограничений) из соображений «а вот как бы чего не вышло», типа у них на душе неспокойно, пока за него денег кому-то не занесли (чтобы недалеко ходить за примерами, вспомним хоть российский маразм несколько лет назад, когда приходит проверка лицензионности ПО и требует предъявить платёжки за Линукс). Так что с этой стороны как раз идея нормальная… ну или, как минимум, прикольная.

С другой же стороны, эффективные менеджеры слыхом не слыхивали ни про какое PVS-Studio, а ещё меньше того про него слышал юридический отдел. Надо переговорить с начальником, замначальника, начальником начальника, представителем юридического отдела, написать заявление от руки в пяти экземплярах, подписать, пере-подписать, размножить, подшить, отксерить, похерить, вот это вот всё, уйдут годы на эту деятельность, которой нормальный разработчик вряд ли желает заниматься. Даже в лучшем случае, когда просто говоришь своему менеджеру, чего ты хочешь, это ждать, ждать, ждать, пока он ответит (если ещё не забудет). Вот с этой стороны да — несложное техническое решение, и сразу играйся с цацкой.
0
Я работаю в мире большого корпоративного софта, я всякое видел :) И я знаю что когда я тимлид — у меня есть возможность в своём отделе сделать так как мне хочется мимо всякого начальства на худой конец ))
0
Зачастую вообще боятся бесплатного ПО (да, именно бесплатного, безо всяких ограничений) из соображений «а вот как бы чего не вышло», типа у них на душе неспокойно, пока за него денег кому-то не занесли


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

Кстати, в связи с этим и процветают конторы типа Red Hat и т.д.
0
Возможно, для какого-то ПО это и так, но какой важный процесс остановит баг в статическом анализаторе? И зачем тогда так извращаются герои статьи, если все, кто могут заплатить, и так заплатят?
0
Вы рассуждаете, как типичный ИТ-шник, что нормально.
К счастью, или к сожалению, за операционные риски отвечает чувак, как правило, далекий от ИТ. Этот умный чувак пишет правила. Задача всех прочих, в том числе ИТ-шников, эти правила соблюдать. Написали: все ПО должно быть с поддержкой, это значит все (все) ПО должны быть с поддержкой.

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

Есть один отдел — он считает риски. И с его точки зрения продукт (тем более бесплатный) от фирмы-однодневки — страшный риск.

Есть другой отдел — он отвечает за закупки. И старается закупать, разумеется, подешевше (а как иначе?). Может и бесплатную версию за'approve'ить, если фирма уже первым отделом одобрена.

А у PVS'ников задача — пройти их все и получить денег, однако…
+1
Попробуемс))
Для небольших групп можно сделать как у Unreal Engine, типо в проектах с прибылью до скольки то там, юзай бесплатно, как превысил — отчисляй пенни.
+1
Это сложно и непонятно как отслеживать. Плюс это не решает вопроса с большой компанией, продукт которой бесплатен, но по факту косвенно приносит прибыль.
+1

Unity требует покупки Pro лицензий, если годовой доход организации превышает $200k. Не знаю, как они проверяют и проверяют ли вообще, но смысл в том, что им не важно, чем занимается контора.


Контора может


  • делать продукты на Unity и продавать;
  • раздавать их даром, зарабатывая на рекламе или поддержке;
  • использовать Unity для каких-то внутренних целей (обучение сотрудников, хз);
  • жить пожертвования пользователей или получать деньги из гос. бюджета.

Вообще не важно, откуда берутся деньги, но если откуда-то всё-таки берутся, изволь купить лицензии.

+6
Мне кажется если кто и ведет взвешенную и разумную политику по продвижению своего продукта так это вы ребята, приятно видеть столь логичные шаги в сторону сообщества, очень надеюсь что через некоторое время год-два это действительно приведет к ожидаемому профиту.
+4
Отличная идея.
Меня, как независимого разработчика под лин, это устраивает почти на 100%.
А с заказчиками по поводу «лишних строк в начале файла» договориться не сложно: внести допусловие в стандартный договори и/или озвучить цену того, чтоб этих строк не было. :)

Единственная просьба, разрешите, чтоб эти сроки были не первые в файле, просто в пределах «шапки», в пределах ~20 строк, например. Все же, информация о разработчике и владельце прав на код важнее, имхо.
+3
Если информация о разработчике и владельце прав на код важнее, то предлагаем рассмотреть вариант приобретения платной лицензии. А так, извините, нет.
0
Воля Ваша.
Тогда давайте проясним один момент. Допустимо ли, с Вашей точки зрения, удаление «шапки» после окончания разработки?
0
Это случай, когда продукт на 100% соответствует требованиям технического задания.
Еще одним примером является момент запуска продукта в серию.
+1
Ну а потом его все, сразу на кладбище?

Вот у PVS-Studio окончание разработки — это когда продукт на кладбище окажется, как мне кажется. А у вас как?
+3
Вот, допустим, человек разрабатывал-разрабатывал код, честно ставил в начале каждого файла ваш комментарий. Заказчик видит, говорит: «Убери.» Должен ли он сказать в ответ твёрдое и решительное «Нетъ!», или же допустимо убрать комментарий, но перестать пользоваться бесплатной версией PVS-Studio для этого проекта? А когда интенсивная фаза разработки, в целом, закончена, и код выкинут на кладбище передан заказчику, который вообще не слышал ни о каком PVS-Studio — этот заказчик имеет право убрать комментарий? А если заказчик что-то ещё сам дописал и хочет от изначального разработчика неких доработок — должен ли тот добавить комментарий обратно?
+4
Ответ прост: если возникают сложности с бесплатной лицензией, значит лицензия не подходит для данного проекта.
+1
Стоит ли это понимать, как:
«Пользуетесь PVS-Studio — вставляйте комментарии. Перестали пользоваться — можно удалить.»?
+4
Вообще не ответ, а вольные фантазии в духе гоголевской Коробочки:
— Право, я боюсь на первых-то порах, чтобы как-нибудь не понести убытку. Может быть, ты, отец мой, меня обманываешь, а они того… они больше как-нибудь стоят.

Понятна вполне ваша боязнь понести убытку, но ответить-то можно на поставленный конкретный ответ, а не изворачиваться, как аскариды в прямой кишке?
+4
А можно просто поблагодарить разработчиков крутого продукта за предоставление его широким массам, а не вести себя как нехороший человек, выискивая неточности в формулировках и доставая авторов?
+2
А продукт Боженька разрабатывает, что даже спросить ничего нельзя, а можно только «славатебегосподи»?
0
Не вижу смысла обсуждать абстрактные «а что если». Но Святослав рядом правильно написал.
0
Конечно. На кладбище. Кладбище ПО — т.е. в архив.
Проекты они разные бывают. Бывают, внезапно, и со статическим и полным ТЗ. ТЗ выполнил — работа окончена, код изменениям более не подвергается.
0
У нас первой строкой обычно идет что-то вроде
/* -*- mode: c++; coding: windows-1251-dos; fill-column:160 -*- */

Это некий компромиссc между удобством на Windows и linux. На Windows — удобнее комментарии в 1251, на линуск — в UTF-8. вот и приходится сообщать редактору о кодировке файла.
0
Среда отладки на Windows не позволяет. Про MS-DOS уже не говорю. А основная отладка — в Windows.
0
А что вы используете как среду отладки?
Qt Creater вроде как только в utf работает. Visual Studio тоже без разницы, в локальной там или в utf'е, главное, чтобы BOM был. Если какие-то среды, которые BOM в файлах не понимают?
0
Лучшую среду всех времен и народов — <a href=«https://ru.wikipedia.org/wiki/Borland_C++>Borland C++ 3.1 :). Это для MS-DOS. Для windows — Borland C++ Builder 5.0.

А кто ещё может брейкопйнты на изменение значений, просмотр структур с изменением их полей и так далее??? Ну Qt Creator советуют посмотреть, а кого ещё?

Работает-то оно под linux в основном. А отладка комфортнее на винде.
0
А кто ещё может брейкопйнты на изменение значений, просмотр структур с изменением их полей и так далее??? Ну Qt Creator советуют посмотреть, а кого ещё?

Вы не поверите, лучшая иде всех времён и народов, ака Visual Studio, это всё умеет уже лет как N'дцать. Qt creater в плане удобства отладки, даже рядом не валялся.
Кстати, советую, ещё https://blogs.msdn.microsoft.com/vcblog/2016/07/11/debugging-tips-and-tricks-for-c-in-visual-studio/ прочитать/посмотреть, может там что заинтересует ещё, а вот например Parallel Stacks так для себя открыл, уже пару раз реально помогло.

P.S. Примите соболезнования по поводу необходимости работать в иде и с компилятором 2000-го года выпуска. Может вам стоит совершить сумасбродство, и перейти на C++ Builder 6.0? :)
-2
Вы не поверите, лучшая иде всех времён и народов, ака Visual Studio, это всё умеет уже лет как N'дцать

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

Окна для изменения данных в структуре — просто нет. И даже не вижу окна для просмотра структуры с разворачиваем и сворачиваем её подструктур…

Окна регистров FPU тоже не вижу. Не говорю уже о том, что для VS++ POSIX — это оbsolete. Короче, отказать. Глючный и очень неудобный.

У коллег в VS++ только debug-сборка работает. В релизе у них просто не собирается… Ну в общем VS++ — для тех, кто не видел возможности удобных отладчиков.

Примите соболезнования по поводу необходимости работать в иде и с компилятором 2000-го года выпуска.

Вообще-то, BC++ 3.1 — 1992ого года. А что вас так удивляет? Новое дороже и тормозней, но с чего вы взяли, что оно удобней? Не говоря уже о том, что вряд ли вы найдете компилятор под MS-DOS новее 1995ого года.

Может вам стоит совершить сумасбродство, и перейти на C++ Builder 6.0? :)

Зачем? Назовите хоть один важный для меня плюс. А важных минусов — много.
Главный минус — Kylix, то есть CLX. Это потребовало перетряски VCL, в итоге что Delphi 6, что C++ Builder 6 — основано на прилично забагованной библиотеке.
В семерке стало получше, но вмешалась кадровая ошибка. В ядро VCL пустили человека, плохо понимающего работу в многопоточной среде. Итогом стало несколько неприятных ошибок.

Мы купили 10.1 Berlin, но я пока его не смотрел. Из очевидных минусов — gcc в качестве компилятора. А чем больше разных компиляторов — тем проще с портируемостью.
0
У коллег в VS++ только debug-сборка работает. В релизе у них просто не собирается…

Самая глупая отмазка из тех которые я видел. Если кто-то перемудрил с директивами условной компиляции — это не является недостатком ни IDE, ни компилятора.


Ошибки компиляции надо взять и исправить.

-3
Вы знаете, если у "одной из ведущих российских компаний" на рынке SCADA один из их флагманских продуктов так себя ведет, то явно не все так просто.

Ошибки компиляции надо взять и исправить.

Ну-ну… Скачайте и разберитесь.

я понимаю, вы не занимаетесь АСУТП. Но подумайте о том, что баги в продуктах мирософта видели все. Ни о какой надежности там речи не идет, зато ИнСат — это работа на рынке, где требуется очень высокая надежность. Это защиты АЭС, это автоматизация котла ТЭЦ (а современный котле без автоматики или тухнет ил взрывается), это автоматизация изготовления сопел ракет, это климат-контроль на производстве банковских карт., это автоматизация компрессорной магистрального газопровода, это мониторинг теплоснабжения миллионного города…

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

Может быть, вы круче их и сумеете решить эту проблему. Но скорее всего это очередное дурацкое ограничение у микрософта — EXE, рассчитанный на подключение dll отладочной сборки, не может подключить dll релизной сборки. Хотя в других системах это проблем не вызывает.

Чтобы никогда не использовать VC++ мне хватает того, что они объявили POSIX obsolete и ввели свои, нестандартные вызовы. Поскольку целевой системой у нас Linux и FreeRTOS, То проще уж отлаживаться там, где POSIX не вызывает таких проблем.

Собственно это повтор истории про осла. Когда IE захватил рынок, он диктовал свои стандарты. Ну и где он сейчас?
image

0
Может быть, вы круче их и сумеете решить эту проблему. Но скорее всего это очередное дурацкое ограничение у микрософта — EXE, рассчитанный на подключение dll отладочной сборки, не может подключить dll релизной сборки. Хотя в других системах это проблем не вызывает.

Это не "дурацкое ограничение", а конфликт зависимостей. До тех пор, пока отладочный рантайм и релизный рантайм — это две разных библиотеки, проблема будет существовать.


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

0
Но скорее всего это очередное дурацкое ограничение у микрософта — EXE, рассчитанный на подключение dll отладочной сборки, не может подключить dll релизной сборки

Ну, если вы так изначально рассчитывали, что же потом удивляетесь?
Вот если бы не хотели такого ограничения, то написали бы сразу exe, который рассчитывает, что ему пофигу с какой dll работать — с релизной или с дебажной. :-).
А если серьёзно, то у майкрософт таких ограничений, конечно же нет, это вы придумали. Вот гляньте на ffmpeg, например. Ты собрал dll'ки, хоть в релизе, хоть в дебаге, хоть другим компилятором, например интеловским. И дальше используй хоть в релизном, хоть в дебажном exe'шнике.

Чтобы никогда не использовать VC++ мне хватает того, что они объявили POSIX obsolete и ввели свои, нестандартные вызовы. Поскольку целевой системой у нас Linux и FreeRTOS, То проще уж отлаживаться там, где POSIX не вызывает таких проблем.

Я уже писал выше, что вы всё перепутали, и майкрософт наоборот, вместо нестандартных платформозависимых POSIX функций, ввела обычные стандартные, прямо из ISO C++, функции.
+1
Чёрт, случайно комментарий послался не законченным. Продолжу.

Так вот, в стандарте C++ нет ничего, например, про strcmpi. Но есть _strcmpi. Поэтому VS честно предупредит, если вы используете этот анахронизм. И да, как вы понимаете, я не говорю не про C++98, где strcmpi — это норма. Ну что же, за 19 лет мир немного поменялся.

Собственно это повтор истории про осла. Когда IE захватил рынок, он диктовал свои стандарты. Ну и где он сейчас?

А это к чему? Компилятор от MS сейчас вролне поддерживает стандарты C++. Да есть свои extension'ы, но ИМХО, в том же gcc их уже больше :-). А так, например VS 2013 поддерживала C++11 лучше, чем скажем вышедший одновременно Intel composer 2013.

Но подумайте о том, что баги в продуктах мирософта видели все. Ни о какой надежности там речи не идет, зато ИнСат — это работа на рынке, где требуется очень высокая надежность. Это защиты АЭС, это автоматизация котла ТЭЦ (а современный котле без автоматики или тухнет ил взрывается), это автоматизация изготовления сопел ракет, это климат-контроль на производстве банковских карт., это автоматизация компрессорной магистрального газопровода, это мониторинг теплоснабжения миллионного города…

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

Я скажу так, не бывает идеальных программ без багов, так как не бывает идеальных аналитиков, которые написали бы ТЗ без противоречий, не существует идеальных системных архитектов, не бывает идеальных программистов, которые написали бы код без багов, не бывает идеальных тестеров, которые не пропустили бы ни одной баги, и т.д…
То, что баги есть — это нормально, это надо понимать. Да что там, я лично более 2-х десятков багов репортил на vs connect. А вот то, что вы не слышали не про одну багу в продуктах ИНСАТ или любой другой компании, это не значит, что их там нет. У нас вот в компании тоже половина программистов свято уверена, что у наших клиентов нет никаких проблем, типа это они круто пишут, что багов мало, а те что есть, типа все находятся тестированием. А когда периодически всплывает, что дня без клиентской проблемы не обходится, так делают круглые глаза. Я к тому, что неспособность скомпилировать свой же код в релизе — говорит о многом. Я бы не хотел работать с такими партнёрами, чтобы они для меня код писали. И да, у меня соседний департамент имеет схожую проблему, они не умеют собирать дебажные сборки. Так что о проблеме, её источнике, и т.д., я знаю не понаслышке.
-1
Вы немного промахнулись при ответе. Если вам нужен ответ, то я его, конечно дам. Но лучше подождите, пока я напишу статью про систему, работающую 14лет 365*24 без видимых сбоев.

Мир АСУТП и embeded -это несколько иной мир, чем мир visual studio. За программу типа Word, падающую при ошибке в любой части без сохранения данных, в АСУТП бы оторвали… Ну в общем что оторвали, то бы и оторвали.

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


Всё остальное — спор о терминах. я в нем участвовать не хочу.
0

Отладочный рантайм и релизный рантайм — это две разных совместимых библиотеки

-4
Давайте не спорить о терминах.Разные — означает несовместимые. По багам, по таймингу… Исходя из ваших слов — по зависимостям.

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

Для доказательства несовместимости — достаточно одной ситуации, где библиотеки не взаимозаменяемы. Искомая ситуация описана выше. Если программа, собранная для одного из рантаймов не может вызвать dll с другим рантаймом — значит они несовместимы. Были бы совместмы -легко бы совмещались в одном проекте.

+3
Вы зря спорите. Конечно, вопрос интересный. На самом деле некая совместимость между ними есть. Например, иногда можно добавить в игнор либу от дебага, и залинковаться с релизной (msvcrt.lib) или наоборот. С рантаймом для cpp там сложнее, msvcprtd.lib вместо msvcprt.lib сложнее подсунуть.
Кстати, это именно тот случай когда «два разных варианта одной библиотеки, собранные из одних и тех же сорцов и отличающихся лишь ключами компиляции».
А так как, что это 2 разные библиотеки — это не бага, как пытается jef представить, а фича! Да, если для тебя это «большая, реальная» проблема, что не хочется иметь 2 набора бинарников — не используй это. А так дебажный рантайм даёт много полезных фич нужный для отладки (на например, там при каждой деаллокации памяти куча проверяется по этому адресу, или итераторы чекаются, что они в валидном слейте. То же со строками, например, в дебаге, там даже в обычном std::string'е новые мемберы появляются, нужные для последующей фоновой валидации строк).
Если вам не нужны все эти возможности, потому что вы не можете их осились/понять/другая_надуманная_причина, то не используйте эту фичу. Собирайте свой код без оптимизации, и отлаживайтесь на нём. Тогда у вас будет только одна версия crt и cprt.
0
  1. Кстати, это именно тот случай когда «два разных варианта одной библиотеки, собранные из одних и тех же сорцов и отличающихся лишь ключами компиляции».

  2. А так дебажный рантайм даёт много полезных фич нужный для отладки (на например, там при каждой деаллокации памяти куча проверяется по этому адресу, или итераторы чекаются, что они в валидном слейте. То же со строками, например, в дебаге, там даже в обычном std::string'е новые мемберы появляются, нужные для последующей фоновой валидации строк).


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

скорее всего там много #ifdef, то есть сорцы одни, но отличия — совсем не только в ключах компиляции, а ещё и в дефайнах сборки
0
А что — где-то по другому? Вы тут Borland C++ 3.1 упоминали — так в нём, о ужас, аж шесть рантаймов!
-3
Да, обычно иначе. gcc, clang, С++ builder… В BC++ рантайм зависел вовсе не от наличия отладки, а от модели памяти. В gcc и clang мы можем выбирать рантайм на этапе сборки компилятора… То есть проблема, что при отладке иной рантайм, чем при выполнении — это проблема VC++. Вполне возможно, что она решается отладкой на релизном ранйтайме. Но уже понятно, что у VC++ на одну проблему больше.

0
Я уже говорил — это не проблема — это фича. Можете, как все отлаживаться. А можете кучу бенефитов получить. Это дополнительная возможность.
-2
Увы, наоборот. Или как все (one microsoft way debug+relize ) или куча геморроя для получения того, что мне нужно. При этом в варианте «как все» часто вижу стон «в релизе не пашет, в дебаг все хорошо». Уж на что я далек от форумов по VC++, но даже до меня этот стон долетал.

Ну и регулярно вижу споры «эта фича не нужна, потому что студия её не умеет». Не, я лучше буду там, где умеют все, что нужно.

При этом вполне допускаю, что в иных задачах — VC++ лучше всех. Ну скажем драйвер windows я бы на нём писал, несмотря на все его неудобства.
+2
При этом в варианте «как все» часто вижу стон «в релизе не пашет, в дебаг все хорошо». Уж на что я далек от форумов по VC++, но даже до меня этот стон долетал.

Ещё раз повторю свой совет: меньше случать горе-партнёров-коллег, интернет и бабок у подъезда. Лучше сперва попробовать самому и сформировать своё личное мнение.

«в релизе не пашет, в дебаг все хорошо»

Этот стон, если и раздаётся, то на порядки реже, чем стон «у меня на компе работает, а у тестеров нет» или «у нас в лабе работает, а у клиента нет». При этом если стонет человек адекватный, и он понимает, что тестеры тестирует на 20 ядерном ксеоне, а он на 4-х ядерном проце, то он просто идёт и начинает искать, например, race condition.

Ну и регулярно вижу споры «эта фича не нужна, потому что студия её не умеет». Не, я лучше буду там, где умеют все, что нужно.

Я вот уверен, что студия умеет гораздо больше стандартного, чем любой другой 19-ти летний компилятор, и в обратном вы меня не убедите. Ваши споршики видимо мало отличаются от ваших партнёров (может это они же?) :-)

При этом вполне допускаю, что в иных задачах — VC++ лучше всех. Ну скажем драйвер windows я бы на нём писал, несмотря на все его неудобства.

Ну хоть на этом спасибо :-).
-1
Лучше сперва попробовать самому и сформировать своё личное мнение.

Увы, по правилам хабра мат запрещен. А без обсценной лексики личное мнение о VС++ не излагается :-) Увы, пробовал я эту поделку…

«у нас в лабе работает, а у клиента нет».

Ну чтобы понять, что делает клиент, надо зело великую фантазию иметь… я когда был главным альфатестером T-Mail такого навидался… Ну вроде FIDO не совсем для чайников, но корректно описывают баги единицы.

«у меня на компе работает, а у тестеров нет»

А это качество работы тестеров. Пример. Тыкаю мышкой — баг 100%. Тыкает мышкой второй тестер (@yole) — 50%баг. Тыкает мышкой автор — нету бага. Оказалось, что для бага надо было в однопиксельную полоску попасть.

Я вот уверен, что студия умеет гораздо больше стандартного,

я сказал нужного. А то, что мои задачи нестандартные — это факт.
0
Ладно, пора заканчивать кормить тролля. И так уже отъелся походу.
-1
Я вот уверен, что студия умеет гораздо больше стандартного, чем любой другой 19-ти летний компилятор, и в обратном вы меня не убедите.

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

0
Вам уже расписывали, что компиляторная часть в ней вполне хорошая. Если Хотите, перефразирую так:
«Я вот уверен, что студийный компилятор умеет гораздо больше стандартного, чем любой другой 19-ти летний компилятор, и в обратном вы меня не убедите.»
0

Ну, это расписывали не мне тогда.


Бекенд, может, там действительно хороший и оптимизирующий, но фронтенд &mdash; совсем другой разговор.


А так как числодробилки в моей практике пишутся не под Windows, то все теоретические преимущества бекенда немножко разбиваются о некроссплатформенность cl.exe.

0
Ой, точно не вам :-)
Думал, что это Джеф опять ругает компилятор :-)
И не соглашусь с вами по поводу некроссплатформенности cl.exe. Нормальный он сейчас, если код кроссплатформенный, и не полностью на C++14, то cl.exe его нормально может.
0

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


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

+2
При этом в варианте «как все» часто вижу стон «в релизе не пашет, в дебаг все хорошо»
Это вы что-то с чем-то путаете. Можете писать код в gcc и запускать его только с -O0, а потом попытаться оптимизации включить. Скажите «ССЗБ»? И будете правы. Только почему-то в случае с GCC это [справедливо] считается проблмой кривых рук программиста, а в случае с Visual Studio — это, типа, проблема компилятора. Проблемой «другого рантайма» это является в лучшем случае в одном случае из 100.

Ещё раз: попробуйте поработать с Visual Studio — а уже потом сказки рассказывать.
-2
Не знаю, возможно дело в том, что ярые сторонники VC++ утверждают, что с включением оптимизаций ничего не меняется. И вообще мол надо отлаживаться в дебаге, а после отладки — выдавать релиз без всяких лишних проверок.

Со студией я немного работал, мнение нецензурное.
+2
выдавать релиз без всяких лишних проверок.

Без тестирования, ага. А ещё у меня есть коллега джавист, так он говорит, что после него код вообще тестировать не надо, если он закоммител, то сразу можно клиенту ставить. Только причём тут C++, VC++ и т.д. если проблема в мозгах?

Ладно, извиняюсь, на сегодня хватит бреда.
-1
угу, тестировать дебаг, а отдавать релиз. Это очень давний холивар.
0
Не рассказывайте сказок. Если и есть такой холивар у вас, то он никак к студии не относится. А так предложений лично я слышал множество, как надо деплоить, начиная с «ху@к, ху@к, и в продакшен». И некоторые даже так и работают. Но это на их совести. И это не связано ни с VC++, ни с самим C++, ни, даже, с написание кода.
-3
Да это, увы, не сказки, а реальность. Деток так в институтиках учат — debug для отладки, релиз для работы. :-( Некоторые потом даже не понимают, что можно отлаживаться на тот же коде, что пойдет в production. Любуйтесь
Проекты Visual Studio имеют отдельные конфигурации выпуска и отладки для вашей программы. Как следует из самих названий, производится построение отладочной версии для отладки и версии выпуска для окончательного выпуска программы.

Как думаете откуда эта кривь? А это из MSDN. Ну да, строго формально это связано не с самой студией, а с её документацией микрософтом. И дальше эта кривь копируется большинством учебников по VC++.
0
И где кривь то? Отлаживаем/разрабатываем на дебаге, тестируем/деплоим релиз. Нигде в документации не написано, что надо деплоить дебажную версию, как делают детки-партнёры, или что тестировать надо не ту версию что в итоге в продакшен уйдёт.
-3
И где кривь то? Отлаживаем/разрабатываем на дебаге, тестируем/деплоим релиз.

Это и есть кривь. Если фирма большая, есть отдельный отдел тестирования, то есть и некоторая культура программирования. А если фирма мелкая, то тестирование совмещено с отладкой. И получается кривь: тестируем и отлаживаемся на debug. а в деплоим релиз.

Вы поспрашивайте джуниоров — многие ли отличают тестирование от отладки?

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

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

Более того, делается удаленное управление, чтобы не ехать за пару тысяч километров, а из конторы (или из дома) залезть в сбоящий прибор, посмотреть, что там происходит и подправить конфигурацию. А в конфигурации — некоторое количество ручек, делающих плавную деградацию. И возможность дистанционного обновления прошивки.

Вся беда в том, что у тестеров нету собственного завода, ТЭЦ, лефортовского тунеля, корабля, близости к Сирии… у тестеров — имитаторы. А основной этап тестирования называется опытная эксплуатация и делается у заказчика.

Мой коллега (переманилии!!!) — создатель одного из фоторадаров. Так вот, он хвалится, что потребность поехать и дернуть питания была всего лишь один раз на несколько тысяч установок. И то, сам виноват, ошибся и загасил установку при ребуте. И даже в этом случае справились местными силами.

И ещё раз дисклеймер. Это У НАС так. У настоящих программистов — иначе. Там, где для тестирования не нужен завод, корабль, локомотив, туннель — там можно и дебаг/релиз применять.

Байка от того же коллеги. Опытная эксплуатация, Лефортовский туннель. Фоторадар показывает 320 километров в час, программер судорожно думает, где же он посадил багу в коде. Сообщение от гайцев: не ищите багу, козел реально с такой скоростью летел. :-) Ну кто из тестеров додумается, что лихач может разогнаться быстрее истребителя на взлете? Так что опытная эксплуатация — главный этап и тестирования и отладки. Все, что до него — это лишь цветочки.
+2
Это и есть кривь.

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

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

-6
Да посмотрите вы на реальный мир! Возможность комплексность комплексного тестирования и комплексной отладки — это чудо. Никто не даст вам завод или корабль на месяц тестирования. На несколько часов — максимум. А потом — опытная эксплуатация.

Полноценное тестирование есть только там, где нету реального мира. А есть искусственный цифровой мир. Который можно скопировать для целей тестирования.

И опять, в дебаге функциональность отлаживать проще

Пьяный мужик что-то ищет под фонарем. Тут к нему под ходит милиционер и
спрашивает: «Что вы тут делаете?» Мужик отвечает: «Ключи от квартиры
ищу». «А где потерял?». «В парке». «А зачем здесь ищешь?».
«А здесь светлее ».

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

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

Так все-таки тестеры у вас работают с дебаг-версией? Или тестирует сам программист? Короче, кто находит проблемы в дебуг-версии?

Да и вообще не верю я в разработку с /O2. Поэтому схема дебуг-релиз производит более надежные приложения.

Только потому, что вы не верите? Мне очень грустно за вас стало…

Один департамент в одной схеме работает, второй в другой (они не умеют дебаг собирать). Очень хорошо разницу видно.

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

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

Скажу честно. Недоделанными их можно назвать, по сравнению с тем, что, например, Windbg умеет. Т.е. да, студия умеет следить только когда значение по некому адресу меняется (это именно то, что вы хотели). А про Си я вообще не понял.

Окна для изменения данных в структуре — просто нет. И даже не вижу окна для просмотра структуры с разворачиваем и сворачиваем её подструктур…

Если вы не видите окна для просмотра структуры, то с вами пока неочём разговаривать. Смотреть и редоктировать данные можно во многих местах (Locals, Watch, да просто навести мышкой на переменную, и смотри/редактируй, сколько влезет.

Окна регистров FPU тоже не вижу.

Оно ещё живо? Ооо.

Не говорю уже о том, что для VS++ POSIX — это оbsolete.

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

У коллег в VS++ только debug-сборка работает. В релизе у них просто не собирается…

Ну что, поздравьте ваших коллег.

Ну в общем VS++ — для тех, кто не видел возможности удобных отладчиков.

Вот вы явно со студией не работали нормально (это видно хотя бы по тому, что не знаете как переменные смотреть). Да, что-то прочитали в инете и как-то интерпретировали, что-то в курилки услышали от горе-коллег-партнёров… Поэтому от вас такой вывод странно слышать. Я как активный пользователь VS под винду и QtCreater под линукс (второе только для отладки) могу ответственно заявить, что отлаживаться в студии гораздо удобнее.

Может вам стоит совершить сумасбродство, и перейти на C++ Builder 6.0? :)
Зачем? Назовите хоть один важный для меня плюс...

Это я пошутил так.

А чем больше разных компиляторов — тем проще с портируемостью.

Я бы с этим согласился, если бы не то обстоятельство, что один из этих компиляторов даже не знает о существовании C++03, C++11, C++14. Вот сейчас всё просто. Мы когда под gcc портировали с VS2013, там уже такие мелочи оставались… В основном, замена WinAPI'шных функций на std аналоги…
-4
А про Си я вообще не понял.

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

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

Так покажите мне инспектор структур. Или ссылкой на MSDN или скриншотом. Судя по тому, что вы не понимаете, что это такое — такого окна в VC++ нет.

Почитайте про отладчик Delphi.

Ну или на скриншот посмотрите
image

Кардинальное отличие инспектора, что он показывает имена полей структуры, а для класса-ещё и имена методов и свойств. Для ответа на вопрос, «в порядке ли данный объект», мне достаточно сделать один клик мышкой с зажатым контролом. А вовсе не добавлять каждое поле объекта в окно Watch.

И что такого плохого, что компилятор стал работать согласно стандарту ISO C++, что об этом не стоит говорить?

Что плохого, что компилятор отказался от международных стандартов ANSI C и POSIX?! Да пусть отказывается, только мы такой компилятор использовать не хотим. Так, по мелочи, плагины написать. На большее он не годится.

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

Вот ровно для этого и придуман POSIX. Это универсальный язык общения с OS. И большая беда Windows, что POSIX подсистема в ней была не развита. В итоге в Win10 пришлось добавлять ядро линукс в режиме виртуальной машины.

Ну что, поздравьте ваших коллег.

Уже написали, что это design-баг. Ну или багофича.

Вот вы явно со студией не работали нормально (это видно хотя бы по тому, что не знаете как переменные смотреть

Как переменные смотреть, я знаю… А вот как смотреть поля структуры или элементы связанного списка — нет. Рассказывайте. А что я мало работал со студией — это факт. я стараюсь работать с удобными продуктами. Поработай с Delphi — поймете, что такое удобный отладчик.

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

А зачем нам они? Где в них киллер-фичи, которые заставят нас отказатьсяот потенциальных военных заказов? А военный заказ — это МСВС 3.0 с gcc 2.95.4. И полный запрет на установку и запуск любых программ, кроме собранных на МСВС из собственных исходных кодов.

Ну ладно, откажемся мы от военных заказов. От embeded нам тоже отказаться? Какие из ваших киллер-фичей влезут в 64 килобайта ПЗУ? А в такое же количество ОЗУ?

Мы пишем на Си с отдельными элементами С++. Сейчас я отлаживаюсь на довольно мощной машинке, у которой 192 килобайта ОЗУ и 512 ПЗУ. При этом у меня 8 килобайт кучи. Какие киллер-фичи новых версий С++ не вызовут фрагментации при 10 килобайтах кучи, из которых после начального захвата свободно 2 килобайта?

Если вы такие киллер-фичи знаете, то рассказывайте. В исходном С++ такой фичей были классы, ссылки и комментарии через //. А что полезного для нас добавили в новых версиях?
+4
В MSDN написано, что аппаратные брейкпоинты только для С++, а не для чистого Си. Ну и по сравнению с тем, что я использую сейчас, они недоделанные.

Аппаратный брекпоинт ставится на адрес. Обычный нативный адрес. Там хоть на ассемблере программу пиши. Бряка поставится и сработает. Рекомендую, прежде чем судить о студии, всё таки попробовать сперва её поближе, не на уровне скриншотов.

Так покажите мне инспектор структур. Или ссылкой на MSDN или скриншотом. Судя по тому, что вы не понимаете, что это такое — такого окна в VC++ нет.

Я так и не особо понял, что вы хотите, может что-то такое?

Для ответа на вопрос, «в порядке ли данный объект», мне достаточно просто навести мышкой на переменную. А вовсе не зажимать контрол. И вовсе не добавлять каждое поле объекта в окно Watch (дикость какая).

Что плохого, что компилятор отказался от международных стандартов ANSI C и POSIX?! Да пусть отказывается, только мы такой компилятор использовать не хотим. Так, по мелочи, плагины написать. На большее он не годится.

Вы так и не сказали, что плохого в том, что компилятор C++ отказался от стандартов других языков и от стандартов для операционных систем в пользу стандарта своего языка? Я ещё раз приведу в пример strcmpi/stricmp. О нём в стандарте С99, например, тоже нет не слова. Потому что нет требований ни к одному из компиляторов эту функцию реализовывать. А вот операционная система должна реализовать такую системную функцию, иначе она не будет POSIX-системой. Т.е. здесь наоборот, переход от платформозависиой реализации к стандарту. Т.е. когда вы напишите stricmp, то это скомпилиться, заработает только на POSIX системах (на самом деле в POSIX её уже вроде как выкинули лет 15 назад, в пользу strcasecmp). Тоже самое с strdup, например. Ну нет в стандартах C и C++ этой функции. И даже более. В стандарте C написано, что функции которые начинаются с «str» зарезервированы, и их нельзя использовать. Но так как Майкрософт решила, что пусть функции можно не реализовывать, но они могут пригодиться клиентам, то она их оставила, но с именами, которые не конфликтуют со стандартом (префикс _ — это индикация, что это майкрософт-специфик). Открою ещё один секрет, gcc, например, тоже не реализовывает stricmp.

Вот ровно для этого и придуман POSIX. Это универсальный язык общения с OS. И большая беда Windows, что POSIX подсистема в ней была не развита. В итоге в Win10 пришлось добавлять ядро линукс в режиме виртуальной машины.

Вот я вообще не понял, для чего вы это написали. Есть стандарт для операционной системы, есть стандарты для языков, со своими стандартными библиотеками. Это разная вещь. Или вы предлагаете весь glibc запихать в ядро? А так да, каждая операционка предоставляет свой API, и вопрос какое api лучше: WinAPI или POSIX или ещё какое, к вопросу о компилятору языка отношения не имеет вообще.

Ну что, поздравьте ваших коллег.

Уже написали, что это design-баг. Ну или багофича.

Не понял про design-баг ну или багофичу. А нас это называется другими словами: кривые руки, распиздяйство, несостоятельность, и т.д. Помните, я рассказывал о соседнем департаменте с похожей проблемой? Ну так одного из них, кто нам слишком рьяно доказывал, что им это совершенно невозможно разобраться и поправить, один из нашего департамента однажды назвал жертвой аборта, но это уже слишком грубо на мой взгляд.

Как переменные смотреть, я знаю… А вот как смотреть поля структуры или элементы связанного списка — нет. Рассказывайте.

Рассказываю: просто наведите на переменную мышкой. Всплывёт окно (похожее на locals на скриншоте выше). Если std::vector<> заменить на std::list, то в визуализаторе ничего не поменяется, также все элементы будут видны. Новый скрин не прикладываю, так как там кроде замены vector на list ничего не поменялось. Но! Дальше я рекомендую меньше читать в инете, а больше пробовать самому. Вот попробуйте сами посмотреть как list будет показываться в отладчике.

Поработай с Delphi — поймете, что такое удобный отладчик.

Спасибо, но нет. Я уж лучше на плюсах, по старинке. Или уж на шарпах. Возвращаться к дельфи/билдеру желания нет.

А зачем нам они? Где в них киллер-фичи, которые заставят нас отказатьсяот потенциальных военных заказов? А военный заказ — это МСВС 3.0 с gcc 2.95.4. И полный запрет на установку и запуск любых программ, кроме собранных на МСВС из собственных исходных кодов.

Если верить вики по вашей ссылке, то там везде gcc 4.1 поддерживается. Не густо, конечно, но и не ужас с 2.95. Нам с Astra-linux больше повезло, gcc 4.9, код в бинарном виде сертифицируется, и потом будет ставится. А по поводу киллер-фич, то если вы незнакомы с C++11/C++14, и с тем, насколько сейчас проще и быстрее писать более безопасный код (например, сейчас даже new/delete уже не надо писать в коде), то нам не о чём дальше разговаривать.

Какие из ваших киллер-фичей влезут в 64 килобайта ПЗУ? А в такое же количество ОЗУ?

Большая часть «киллер-фич» — языковые, они не увеличивают кол-во получаемого кода. Например, написание «auto it = » вместо «std::map<std::string, std::vector<std::string>>::const_iterator it = » ну никак не повлияет на размер кода. Тоже и с лямбдами, например, или с rvalue-ссылками.

Мы пишем на Си с отдельными элементами С++. Сейчас я отлаживаюсь на довольно мощной машинке, у которой 192 килобайта ОЗУ и 512 ПЗУ. При этом у меня 8 килобайт кучи. Какие киллер-фичи новых версий С++ не вызовут фрагментации при 10 килобайтах кучи, из которых после начального захвата свободно 2 килобайта?

Вообще ничего не понял про фрагментацию кучи. Это тут при чём?
-1
Аппаратный брекпоинт ставится на адрес. Обычный нативный адрес. Там хоть на ассемблере программу пиши.

Тем страннее ограничение MSDN.

Рекомендую, прежде чем судить о студии, всё таки попробовать сперва её поближе,

Нет, спасибо. Хватило адаптации кода для неё. Боль примерно та же, что и с адаптацией сайта под IE. При этом со всеми остальными компиляторами и операционками — проблем было мало. Даже с WIN32 на linux перешли с меньшей болью, чем при адаптации к VC++

Я так и не особо понял, что вы хотите, может что-то такое?

Уже похоже. А VC++ может иметь 5-7 окон инспектора на экране одновременно (а не рассованные по разным вкладкам)? Иногда есть необходимость сразу несколько структур раскрывать.

Для ответа на вопрос, «в порядке ли данный объект», мне достаточно просто навести мышкой на переменную

я не настолько крут и разобраться в хите длиннее 1024 символов не могу. :-) Особенно, если первые 4К не несут важной информации. :-) Всплывающие подсказки хороши для простых типов, а не для объектов.

А так да, каждая операционка предоставляет свой API

Да нет… Все современные операционки предоставляют POSIX. И только windows — WinAPI. Чтобы выйти за пределы POSIX нужно уж совсем в дебри залезать. Более того, часть POSIX Уже перешла в стандарт языка Си.

Не понял про design-баг ну или багофичу. А нас это называется другими словами: кривые руки, распиздяйство, несостоятельность, и т.д.

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

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

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

Жалко, что вы не изучали язык FORTRAN. В фортране было разделение между стандартными внутренними функциями, которые могли реализовываться компилятором, и стандартными внешними функциями, которые реализовывались библиотекой.
Так вот, всякие asin никогда компилятором не реализуются. Компилятор может реализовать sqrt или fabs, потому что в сопроцессоре могут быть соответствующие машинные команды.

Открою ещё один секрет, gcc, например, тоже не реализовывает stricmp.

Согласитесь, что кровать — это не холодильник, а библиотека — не компилятор.? Так что открою вам другой секрет — gcc не реализует и strcpy — это делает библиотека. А POSIX-совместимых библиотек весьма много (мы используем glibc, uClibc, Newlib). И все они кроссплатформенные и реализуются на любой нормальной ОС (и даже на части ненормальных. например есть на винде, просто не от микрософта).

и вопрос какое api лучше: WinAPI или POSIX или ещё какое, к вопросу о компилятору языка отношения не имеет вообще.

к нормальному компилятору — да, не имеет. Но вы видели, чтобы VC++ работал не с микрософтовским clibc? Если вы знаете альтернативу — дайте ссылку. Вы же не на пустом месте спутали компилятор с библиотекой. У VC++ библиотека — часть компилятора. Увы, не заменяемая.

Если верить вики по вашей ссылке, то там везде gcc 4.1 поддерживается.

А если почитать внимательно — там gcc 2.95.4. Сертификация идет на конкретную версию МСВС и стоит миллионы. Сертифицировано МСВС 3.0 — или платите миллионы за сертификацию МСВС 5.0 или живите на gcc 2.95.4

то если вы незнакомы с C++11/C++14, и с тем, насколько сейчас проще и быстрее писать более безопасный код (

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

Например, написание «auto it = » вместо «std::map<std::string, std::vector<std::string>>::const_iterator it = » ну никак не повлияет на размер кода.

я же писал, что на SOC обычно не используют кучу. Так что std::vector нам вообще не нужен. И даже там, где куча есть,, лучше использовать специальные библиотеки для многомерных матриц, чем возиться с std::vector<std::vector<std::vector<std::vector><std::vector>>>> Неужели вы не понимаете, что std::vector придумали для совсем других целей, а не для многомерных массивов. Посмотрите, насколько уродлив код с std::vector<std::vector>> и насколько он красив с eigen. Впрочем eigen — это чуть иной проект

я согласен, если микроскопом забивать гвозди, он потребует многих улучшений. А если молотком… ну так молоток 18ого века — вполне нормальный инструмент.

Лямбды… ну опыт АЛГОЛ-60 показал, что лучше их не использовать, чем использовать. Опять-таки, не актуально в связи с отсутствием у нас контейнеровв STL.

rvalue-ссылки… ну нету у нас лишних копирований. Просто нету. И потребности в этой семантике нету. Фишка полезная. но не для нас.

Вообще ничего не понял про фрагментацию кучи. Это тут при чём?

При том, что из-за опасности фрагментации (отказ программ в малопредсказуемый момент) мы не используем кучу совсем. Для того, чтобы в проекте можно было бы использовать кучу нужна или виртуальная память + swap или памяти должно быть процентов на 60 больше необходимого.

А вот возможность ценой не очень больших усилий отказаться от С++ и в части модулей перейти на Си — это киллер-фича.
0
Тем страннее ограничение MSDN.

Повторю совет: меньше читать в инете, больше пробовать самому

Нет, спасибо. Хватило адаптации кода для неё. Боль примерно та же, что и с адаптацией сайта под IE. При этом со всеми остальными компиляторами и операционками — проблем было мало. Даже с WIN32 на linux перешли с меньшей болью, чем при адаптации к VC++

Вот прямо возникает вопрос: а вы под какую студию код адаптировали? Не под 5.0? Просто сейчас вот у нас проблема, что gcc 4.9 хуже стандарт поддерживает, чем студия. Я вот уже заколебался код «доунгрейдить», чтобы он у нас под линукс тоже собирался. Про интеловский компилятор я тоже говорил уже, не взлетел тоже в силу ущербности той версии, что была в 2013м компосере (сейчас в 2017м конечно лучше должно встать, но уже на gcc переехали под линукс).

Уже похоже. А VC++ может иметь 5-7 окон инспектора на экране одновременно (а не рассованные по разным вкладкам)? Иногда есть необходимость сразу несколько структур раскрывать.

Окно просмотра переменной можно пинить, и хоть 5, хоть 7, хоть 57 их иметь. Лучше попробуйте, множество вопросов отпадёт.

я не настолько крут и разобраться в хите длиннее 1024 символов не могу. :-) Особенно, если первые 4К не несут важной информации. :-) Всплывающие подсказки хороши для простых типов, а не для объектов

Вот видно, что так и не попробовали. Там не хит на 4к символом всплывает, а полноценное окно просмотра/редактирования переменной. Да, такое же как на моём скриншоте окна locals.

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

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

Потому что нет требований ни к одному из компиляторов эту функцию реализовывать.
Жалко, что вы не изучали язык FORTRAN. В фортране было разделение между стандартными внутренними функциями, которые могли реализовываться компилятором, и стандартными внешними функциями, которые реализовывались библиотекой.
Так вот, всякие asin никогда компилятором не реализуются. Компилятор может реализовать sqrt или fabs, потому что в сопроцессоре могут быть соответствующие машинные команды.

Вот не надо меня жалеть, что я Фортран не изучал. Это как пожалеть, что в армии 2 года не служил. И собственно ваш аргумент ни о чём. Ну пусть в Фортране есть внутренние и внешние функции. Это не значит, что он с бодуна должен вдруг начать реализовывать функции не из своего стандарта, например, из стандарта POSIX'а.

А POSIX-совместимых библиотек весьма много (мы используем glibc, uClibc, Newlib). И все они кроссплатформенные и реализуются на любой нормальной ОС (и даже на части ненормальных. например есть на винде, просто не от микрософта).

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

и вопрос какое api лучше: WinAPI или POSIX или ещё какое, к вопросу о компилятору языка отношения не имеет вообще.
к нормальному компилятору — да, не имеет. Но вы видели, чтобы VC++ работал не с микрософтовским clibc? Если вы знаете альтернативу — дайте ссылку. Вы же не на пустом месте спутали компилятор с библиотекой. У VC++ библиотека — часть компилятора. Увы, не заменяемая.

Ну как бы никаких предпосылок, что он может с ним не заработать нету. А так вы вот до 2012-й студии stlport, например, использовали, крутая штука, кстати была 12 лет назад. И опять таки, к сравнению POSIX-api и WinAPI это отношения не имеет. Вообще. Берите любой компилятор (хоть gcc, хоть clang, хоть интеловский, хоть Builder, хоть VC), вам будет доступна стандартная библиотека и API операционной системы. Т.е. под gcc все WinAPI'шные функции также доступны под виндой.

А если почитать внимательно — там gcc 2.95.4. Сертификация идет на конкретную версию МСВС и стоит миллионы. Сертифицировано МСВС 3.0 — или платите миллионы за сертификацию МСВС 5.0 или живите на gcc 2.95.4

Я, наверное, плохо выделил слово везде. На вики написано, что и под MCBC 3.0 доступен 4-й gcc. Не надо для этого на MCBC 5.0 переходить.

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

Так все думают (да, да, мы думали абсолютно так же), пока не переходят на новый компилятор, и внезапно С++11/С++14 код не начинает пролазить во все места в которые может и не может. И дело может быть даже в одной киллер-фиче, а в общем упрощении и убыстрении написания кода (при этом более безопасного и эффективного).

И даже там, где куча есть,, лучше использовать специальные библиотеки для многомерных матриц, чем возиться с std::vector<std::vector<std::vector<std::vector><std::vector>>>> Неужели вы не понимаете, что std::vector придумали для совсем других целей, а не для многомерных массивов.

Вы так пишете, как будто я пытаюсь вас убедить в том, что vector<vector<vector<...>>> это круто и надо использовать только их, особенно для многомерных массивов :-). Не надо мне лишних грехов приписывать, у меня и так своих немало.

я согласен, если микроскопом забивать гвозди, он потребует многих улучшений. А если молотком… ну так молоток 18ого века — вполне нормальный инструмент.

Хорошая аналогия, я бы до такой не догадался :-). Да, молоток 18-го века, вполне нормальный инструмент, сам таким пользуюсь. А вот профессионалы (по крайней мере, те, что мне ремонт делали), используют гвоздезабиватели (проще, быстрее, и безопаснее, в плане, что хрен ошибёшься).

Лямбды… ну опыт АЛГОЛ-60 показал, что лучше их не использовать, чем использовать. Опять-таки, не актуально в связи с отсутствием у нас контейнеровв STL.

rvalue-ссылки… ну нету у нас лишних копирований. Просто нету. И потребности в этой семантике нету. Фишка полезная. но не для нас.

Блин, у меня аж голова сломалась :-( Причём тут ваш печальный опыт на АЛГОЛ-60 и лямбды в C++? (Секс… ну опыт ТетяМашка-60 показал, что лучше им не заниматься, чем заниматься.). Какую связь лямбры имеют с stl-контейнерами? (это прямо мозг вынесло). Ну и как бы я сильно рад за вас, что у нас нету лишних копирований (а у кого они есть?).

При том, что из-за опасности фрагментации (отказ программ в малопредсказуемый момент) мы не используем кучу совсем.

Мой вопрос был, как это связано, используете вы кучу или нет, с фичами C++11/C++14?
-2
Честно говорю — эта дискуссия отнимает слишком много сил от работы.

Повторю совет: меньше читать в инете, больше пробовать самому

Напробовался. Цензурных слов нет, очень тянет блевать. я понимаю, у вас логика наркомана: да как ты можешь судить о героине, если ты 5 лет не кололся?!

а вы под какую студию код адаптировали? Не под 5.0?

2012ая вроде.

«Там не хит на 4к символом всплывает, а полноценное окно просмотра/редактирования переменной.»

То есть случайно мышку оставил над переменной, а потом окно закрывать? Ну очередной минус VC++.

Ну пусть в Фортране есть внутренние и внешние функции.

Они есть во всех языках, только стандарт фортрана их выделил явно. Внутренние — это те, про которые компилятор знает. А внешние — про которые не знает.

Но это не повод называть компилятор (хоть от майкрософт, хоть от интел, хоть ещё какой), плохим словом, если их рантайм не поддерживает эти левые стандарты.

Угу, типичное мнение любителя микрософт. я выбираю инструменты под свои задачи. И говорю, что данный инструмент плох для наших задач. А мне начинают втюхивать, что задачи у нас неправильные, код не тот, операционные системы не те, железки не такие… Ну в общем нужно все бросить, фирму закрыть и идти путем one microsoft way. Вам самому не грустно?

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

Ну-ну, попробуйте для начала. Даже gcc не позволяет, чтобы проект, скомпилированный для glibc, запустился с uClibc. Компилятор вызывает много служебных процедур, которые в разных библиотеках разные.

Я, наверное, плохо выделил слово везде. На вики написано, что и под MCBC 3.0 доступен 4-й gcc.

Что за бред? Вы хоть раз с МСВС работали? Ещё раз: сертификация идет на конкретную версию и редакцию МСВС по конкретному процессору. Никакой софт, кроме самописного ставить туда нельзя. Новая редакция с новым gcc — повезло. Старая редакция — платите миллионы за новую сертификацию или пользуйтесь тем, что есть. Мой вам совет — поработайте с МСВС, а потом судите. Не вот, увы, пришлось. Повезло. Кто-то подсуетился вовремя и оплатил сертификацию более нового варианта на тот же sparc МЦСТ R500. Но адаптировать я ядру 2.4 и gcc 2.95.4 все равно пришлось.

и внезапно С++11/С++14 код не начинает пролазить во все места в которые может и не может.

Упаси нас боже от этого ужаса. Лучше уж вернуться на голый Си.

А вот профессионалы (по крайней мере, те, что мне ремонт делали), используют гвоздезабиватели

Там, где нужна надежность — никогда не используется ничего нового. Все детали — только реально проработавшие 10-20 лет. С известной опытным путем (а не теоретически) наработкой на отказ. Все технологии — старые, с известными проблемами и способами их решениях. Любая операционка — после третьего сервис-пака (одна из причин, почему в банкоматах до сих пор Windows XP). Нужна была бы вашим «профессионалам» надежность — использовали бы молотки. Просто потому, что ремонт гвоздезабивателя в поле — то ещё приключение.

Причём тут ваш печальный опыт на АЛГОЛ-60 и лямбды в C++?

я вам ссылку дал — почитайте внимательно. АЛГОЛ-60 использовал лямбды в виде передачи параметров по наименованию. Выражение, переданное, как параметр запроцедуривалось, и исполнялось в точке обращения. Это приводило к возможности вызывать самые разные побочные эффекты и к красивым трюкам. Через 10-20 лет общее мнение пришло к тому, что это был design-баг и лучше передачу по наименованию не использовать.

Какую связь лямбры имеют с stl-контейнерами?

А где они ещё нужны? Типовой пример из вики
std::vector<int> someList;
int total = 0;
std::for_each(someList.begin(), someList.end(), [&total](int x) {
  total += x;
});
std::cout << total;

Да, это действительно наглядней и удобней. Но без STL — просто не нужно.

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

У тех, кто выдает объект как результат функции. Например часто результатом функции бывает std::string. Вот тут экономия огромная.

Мой вопрос был, как это связано, используете вы кучу или нет, с фичами C++11/C++14?

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


Мы не используем кучу. Следовательно, мы не используем STL. Мы вообще пишем на Си с некоторыми элементами С++. Вот и подумайте, какие элементы С++14 будут полезны в Си? что-нибудь равно по силе использованию ссылок вместо указателей. Есть такое? Ах нету? Ну вот то-то, что нету. :-)
+1
Но без STL — просто не нужно.

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


Какие ещё киллер-фичи — автоматический вывод типов, вариадики, constexpr, да мало ли.


Я на этом C++14 символьное взятие производных в компил-тайме написал, что сильно облегчило поддержку и разработку кода для одного моего вычислительного эксперимента. Никакой кучи, никаких new в рантайме.


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


В ещё одном проекте есть обощённая и красиво декомпозированная очередь заданий с пулом, адекватной обработкой ошибок на уровне типов (Either, монадки, вот это всё), композабельные асинхронные примитивы (тоже монадки, если подумать), обобщённые примитивы для применения вызывабельных объектов (это как функторы, но мне после хаскеля не хочется использовать слово «функтор» в плюсовом смысле) (о, и лямбды можно!) поверх этого всего счастья (монадки же, аппликативные функторы, все дела).

-3
Возможность сформировать анонимную функцию вот прям здеся в точке вызова — она, ну, удобная и полезная не только в STL.

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

автоматический вывод типов

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

std::string str= "ворона";
auto s = str;
auto k = 'k';
s = k;

И вы долго будете искать вашу корону…

вариадики

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

constexpr

Ещё одна костыльная недофича. Хорошая недофича, конечно. Но пока вы не сможете в compile-time создавать новые операторы — это все будет недофичей. Ну вот не нравится вам, что #elif есть, а elif нету — ну взяли и написали сами, как это делается в FORTH. Думаю, ч то лет за 50 С++ продвинется в этом направлении. constexpr — это шаг в нужную сторону. Но это все-таки костыль, по сравнению с прямой кодогенерацией в compile-time в FORTH.

да мало ли.

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

Я на этом C++14
у меня есть
мне после хаскеля

Ну у вас и компы не на 18мегагерц работают. И памяти — не 64килобайта. И отладка без паяльника и осциллографа идет. И ещё много-много чего не так.

Давай не путать — мы ненастоящие программисты. У нас многое не так.
+2
Но абсолютно бесполезная для нас. Нету у на временных функций, нужных только в точке вызова.

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


То есть убрать возможность проверки? Это само по себе является источником ляпов.

И как вам указание типа сильно поможет? Особенно с учётом приведений, опять же.


А вкупе с системой приведения типов — невообразимым источником разных глюков.

Ну, тут я согласен. Преобразование типов — зло.


И вы долго будете искать вашу корону…

А что ваш пример призван показать? В s будет символ k, длина строки равна единице. Что не так?


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

Темплейты (и вообще статический полиморфизм) — это механизм, позволяющий абстрагировать и переиспользовать код. Причём тут библиотеки?


Но пока вы не сможете в compile-time создавать новые операторы — это все будет недофичей.

Почему это? Вообще какие-то ортогональные вещи, как по мне.


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

А С вам зачем? Что там есть такое, что принципиально невыразимо на ассемблере?


Ну у вас и компы не на 18мегагерц работают. И памяти — не 64килобайта. И отладка без паяльника и осциллографа идет. И ещё много-много чего не так.

На C++ под attiny какой-то, где мегагерц ещё меньше, а памяти в окрестности килобайта, я писал. С шаблонами и вот этим всем. Не на C++11, правда, он тогда C++0x ещё назывался и поддерживался не очень, год был где-то 2008-й.

-4
А что ваш пример призван показать? В s будет символ k, длина строки равна единице. Что не так?

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

И как вам указание типа сильно поможет? Особенно с учётом приведений, опять же

Была очень веселая история в 1998 ногу. Тестирую, вижу баг, пишу @yole — мол у тебя вещественный тип вместо денежного. Он в ответ — у меня все норм. На четвертый раз дал ему тестовый пример, он убедился. Через четыре часаЧертова Венгерская нотация.!!!!/ Мало назвать переменную так, как читает верным микрософт, надо ещё и на самом деле дать ей нужный тип.

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

Возможность их легко и дёшево создавать меняет мышление.

Героин — тоже. А из дешевого — можно бензин нюхать. :-) Аналогия прямая — все трое приводят к глюкам.

Темплейты (и вообще статический полиморфизм) — это механизм, позволяющий абстрагировать и переиспользовать код. Причём тут библиотеки?

Да по определению "Библиоте́ка (от англ. library) в программировании — сборник подпрограмм или объектов, используемых для разработки программного обеспечения (ПО)". Впрочем, я соглашусь, что молодое поколение имеет право не знать изначальный смысл этого слова.

Но мне все это «переиспользование» напоминает смешную историю 1998ого года. Тогда тот же yole нашел настройку, позволяющую менять количество часов в сутках. Ну вдруг у кого-то 25 часов или 18… :-) За очень редкими исключениями, алгоритмы не инвариантны относительно типов. То есть, сделав алгоритм для double — не надо его расширять на float или int64. Да, есть синтаксический сахар в том, чтобы дать алгоритму сильную типизацию, то есть не просто double, а отдельно TWieight(масса), а отдельно — TVolume(объем).

Но все эти красоты — увы, не перевешивают проблем с отладкой темплейтов.

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

А С вам зачем? Что там есть такое, что принципиально невыразимо на ассемблере?

А Си как раз и писался, как универсальный ассеблер (сначала PDP-8, потом PDP-11). *dst++ = *src++; — это одна машинная команды MOV (R3)++, (R2)++.

На C++ под attiny какой-то, где мегагерц ещё меньше, а памяти в окрестности килобайта, я писал.

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

— Я духов вызывать могу из бездны
— И я могу и каждый это может.
— Вопрос лишь, явятся ль они на зов.
0
Желание программиста. Явно имелось ввиду не то, что написано.

Я так и не понял, кто что желал. Судя по коду, программист явно желал, чтобы строка s == «k», что и исполнено. В чём проблема?
-3
Хотелось что-то вроде *s = 'K'. То есть ворону в корону превратить. :-)
+2
Ну это было не явно из вашего кода. У вас какое-то особое мнение.
-4
Знаете в нашей профессии столько неявного. Ошибка в одной букве и Word превращает «персональный» в анального перса. :-) Ситуации, когда описка в одном знаке влечет не выявляемую компилятором ошибку- опасныеситуации. Если вы используете такие конструкции, то статический анализатор становится обязательным.
0

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

-2
int &k=1; не прокатит. Достаточно? Или вам нужно в любом контексте? Тогда что-то типа /bin/sh, где для обращения к значению переменной нужно явно делать операцию разыменования, то есть $I
-2
Попробовать — попробую. Но пока чтение рекламных статей PVS-studio оставляет впечатление. что он нам не нужен. Сколько ни читал — ну ни разу не было «ой, мы за таким же багом 3 дня гонялись». Было наоборот — нифига себе, какую ерунду люди пишут.

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

Но я потестируюсь, как время будет. И отчет напишу. Вполне возможно, что я ошибаюсь кардинально.

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

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

Оно замечательно работала на x86 потом что сопроцессор работает с 80битными long double, А вот на ARM, увы, только double длиной 64 бита. В итоге вместо на 2**31 выдавало на единичку меньше.

Ещё была смешная история про проверку пустоты строки через strlen. Оно работало, но настолько неэффективно… строки там по 4К были…

Общее впечатление от ваших статей — ну вот как у вас от проверки Clang. Вы же не стали ежедневно проверять свой код Clang, после того как он нашел у вас ошибки?

Но я ещё раз обещаю, что наш код бесплатной версией проверю и статью с результатами напишу.
-5
Ткните меня носом в нужную строчку, пожалуйста. Вижу "мы дополнительно используем компилятор Clang для проверки C++ кода." Но компилятор Clang и Clang Static Analyzer все-таки не одно и то же.

Если считать их одним и тем же, так мы тогда тоже Clang используем. С практически нулевым результатом.
+5
Ну написано в статье неудачно. Хватит уже всех троллить, придираясь к словам и фразам.
-5
Да не троллю я и не придираюсь. Мышление формальное. Как написано, так и читается. Исключения — только когда на саппорте работаю. Вот там любое слово может любое понятие изображать.

знаете историю про налево?
Дама у трех вокзалов садится в такси.
Машет рукой вправо:
— поворачивайте налево, налево!!!
Водитель поворачивает налево.
— Куда же вы? У нас в Расее куды кажут, там и лево!
+1

Я бы такой код на ревью не пропустил хоть со си-строками, хоть с чем хотите. s[0] = 'K' читабельнее, вызывает меньше WTF и вообще.


И, кстати, работает как ожидается с std::string.

-4
Увы, у std::string есть перегрузка оператора присваивания от сhar
string& operator= (char c);


А код — да, кривой, не спорю. В хорошем коде — лучше без auto. Ну разве что в темплейтах — там может так сложиться, что без него не обойтись.
0

А причём тут auto? Написали бы вы где надо std::string, где надо char &mdash; как бы это вас спасло?

0
Да, ляп был бы понятней и нашелся бы мной при чтении кода. А с auto — его пропустить проще.
+6
нашелся бы мной

Ну сказали бы, что код без аннотаций типов вы читать не можете. Так нет, auto виноват.


Я в упор не понимаю, как этот ляп с auto пропустить проще, серьёзно.

-5
Знаете, тоже в упор не понимаю, как можно вместо 1<<N написать pow(2,N). Но выяснилось, что можно. Правда авто бага — математик, а не программер. Все-таки программер обычно понимает кодогенерацию, а не рассчитывает, что оптимизатор выручит.

Ну сказали бы, что код без аннотаций типов вы читать не можете

я читаю код даже на тех языках, которых не знаю. И даже какие-то баги нахожу. :-) Но одно дело — найти какие-то ошибки, а другое дело — найти все. Наличие auto понижает шансы на нахождение ошибки. Хотя и делает код более (а не менее) читабельным.
+4
Все-таки программер обычно понимает кодогенерацию, а не рассчитывает, что оптимизатор выручит.

Обычно достаточно понимать семантику языка.


Наличие auto понижает шансы на нахождение ошибки.

Для вас, опять же.

-6
2**N и 2<<N обладают одинаковой семантикой. pow(2,N) тоже по семантике не отличается от 2**N. Но рассчитывать, что компилятор превратит pow(2,N) в 2<<N нельзя — кодогенерация совсем разная.

Хотя — тут многое зависит от определений слов, потому я прошу привести, где в вашем толковании проходит граница.

Что касается auto, то почти 60 лет истории языков программирования вполне доказали, что языки, требующие явного указания типа — более надежны, чем языки с неявной типизацией. Мне как-то казалось, что споры о этом утихли примерно к 1975ому году вместе со спорами о GOTO. Но видимо развитие идет по спирали и молодняк просто не в курсе.
+4
2**N и 2<<N обладают одинаковой семантикой. pow(2,N) тоже по семантике не отличается от 2**N. Но рассчитывать, что компилятор превратит pow(2,N) в 2<<N нельзя — кодогенерация совсем разная.

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


pow(2,N) очевидно надёжнее, не надо заморачиваться с правилами битовых сдвигов в C.


Что касается auto, то почти 60 лет истории языков программирования вполне доказали, что языки, требующие явного указания типа — более надежны, чем языки с неявной типизацией.

Во-первых, адекватному выводу типов хорошо если 30 лет — того же Хиндли-Милнера допилили примерно в 80-х. В плюсах, конечно, не он, но мы ведь говорим здесь о языках в общем, не так ли?
Во-вторых, где это они доказали? Можно почитать? А то молодняк действительно не в курсе.

-6
pow(2,N) очевидно надёжнее, не надо заморачиваться с правилами битовых сдвигов в C.

Вы математик что ли?! Или только на x86 работали? На АРМ 2**31 дал результат на единицу меньше. И вместо нужного бита в битовой маске установились все биты кроме нужного. Искали это полтора года, нашли вычиткой текста.
И это как раз тот баг, ради поимки которого не жалко денег на статический анализатор.

Скажите, а strlen(str) > 0 тоже для вас лучше *str != 0? А на строках размером 4килобайта? Семантика одинаковая. зато кодогенерация разная…

Во-первых, адекватному выводу типов хорошо если 30 лет

Багоусточивый вывод типов — это миф.
auto x = 1;
auto y = 2;
double xy = x / y;

И получаем 0 вместо 0.5. Написали бы double вместо auto — все хорошо бы было.

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

Это все было задолго до интернета. Поищите дискуссию про implict none (запрет автоматического определения типа по имени переменной в FORTAN). Ну как бы общее место Поэтому запомните правило: ставить implicit none всегда, а затем корректно обрабатывать вылезающие ошибки. Иначе рано или поздно нарветесь на проблемы. Но сам implict noneпоявился в фортране с большими боями. Слишком уж удобно было, что I. J, K — целые, а X, Y, Z — вещественные.

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

Тут есть другой момент. Кроме того, что в Fotran и BASIC использовалась неявная типизация, там ещё и использовалось неявное описание имен переменных. И критика этих разных сущностей сливалась вместе.

В целом, есть хорошая обзорная статья о плюс и минусах разных систем типизации.

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

А идея простая. Любая избыточность в тексте программы дает компилятору (и статанализатору) больше информации для проверки. Взамен — замедляется написание кода. Поэтому короткие программы удобнее писать на BASIC, а длинные и надежные — на чем-то алголоподобном (Си, Pascal...)

0
Вы математик что ли?! Или только на x86 работали? На АРМ 2**31 дал результат на единицу меньше. И вместо нужного бита в битовой маске установились все биты кроме нужного.

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


Скажите, а strlen(str) > 0 тоже для вас лучше *str != 0? А на строках размером 4килобайта?

В читабельности и правилах приведения разницы особо нет. Разве что, второй вариант даже немного лучше &mdash; не надо вспоминать, как там себя strlen ведёт на нулевых указателях, из кода сразу всё видно.


Семантика одинаковая. зато кодогенерация разная…

Что самое смешное, кодогенерация тоже одинаковая. Можете проверить, gcc и clang, проверенные мной, генерируют одинаковый код для обоих веток:


#include <cstring>

int main (int argc, char **argv)
{
#if 1
  return *(argv[1]) != 0;
#else
  return std::strlen(argv[1]) > 0;
#endif
}

Компиляторы нынче умные, заразы.


И получаем 0 вместо 0.5. Написали бы double вместо auto — все хорошо бы было.

Написали бы 1.0 вместо 1 &mdash; тоже было бы хорошо.


Адекватным решением здесь являются не явные аннотации типов, а более адекватная система типов, где операнды для оператора / должны быть вещественного типа. Ну, как в хаскеле, опять же.


Поищите дискуссию про implict none (запрет автоматического определения типа по имени переменной в FORTAN).

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


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

Вы ведь понимаете, что сам факт попадания чего-либо в требования не может быть доказательством ненадёжности? Доказательством могло бы быть присовокуплённое обоснование ненадёжности от авторов пропозала в Аду, например.


В целом, есть хорошая обзорная статья о плюс и минусах разных систем типизации.

Ну да, с явной типизацией программисту сразу виднее.


Поэтому короткие программы удобнее писать на BASIC, а длинные и надежные — на чем-то алголоподобном (Си, Pascal...)

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

+3
> Скажите, а strlen(str) > 0 тоже для вас лучше *str != 0? А на строках размером 4килобайта?

В читабельности и правилах приведения разницы особо нет. Разве что, второй вариант даже немного лучше — не надо вспоминать, как там себя strlen ведёт на нулевых указателях, из кода сразу всё видно.

Сразу видно что будет ub, если что?

-2

Я встречал не самых необразованных людей, которые думают, что strlen на нулевых указателях &mdash; это норма, например.

0
Я встречал не самых необразованных людей, которые думают, что strlen на нулевых указателях — это норма, например.

Это уже implementation defined, может быть ub, а может и не быть. По крайней мере strlen(3) не говорит ничего о поведении при передаче NULL. Естественно, логично предполагать, что в общем случае будет ub, но в частном просто SIGSEGV. На glibc это справедливо.


Кстати, clang выдает предупреждение, если в strlen отдать NULL, но дальше этого не заходит.

+4
Это уже implementation defined, может быть ub, а может и не быть.
Это что ещё за разговоры? Implementation defined and Undefined Behaivior — это вообще «из разных опер». Undefined Behavior — это требования, налагаемые не на компилятор, а на программу. Их в программе быть не должно, точка.

По крайней мере strlen(3) не говорит ничего о поведении при передаче NULL.
Именно. Что это значит? Правильно: всё описывают «правила использования библиотечных функций» (раздел 7.1.4 в C99/C11). А там — английским по белому написано: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.

Кстати, clang выдает предупреждение, если в strlen отдать NULL, но дальше этого не заходит.
А вот GCC — заходит:
int foo(char *p) {
  int x = strlen(p);
  if (!p) return 42;
  return x;
}

Даёт:
foo(char*):
        sub     rsp, 8
        call    strlen
        add     rsp, 8
        ret

Неплохая такая оптимизация, да? Всё в рамках стандарта, между прочим. Можете сходить на Compiler Explorer сходить, проверить…
0
Это что ещё за разговоры? Implementation defined and Undefined Behaivior — это вообще «из разных опер». Undefined Behavior — это требования, налагаемые не на компилятор, а на программу. Их в программе быть не должно, точка.

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


Моё утверждение базировалось на том, что для strlen это не специфицировано и libc вполне может иметь guard вида if(!str) return 0;.

0
Моё утверждение базировалось на том, что для strlen это не специфицировано и libc вполне может иметь guard вида if(!str) return 0;
Вы путаете C и C++ — это в C++ подобные вещи бывают (скажем в std::operator delete можно nullptr передавать). Но в C — другие законы. По умолчанию — нельзя. Должно быть явно описано, если можно.

В частности std::operator delete так и устроен — проверка на nullptr + вызов free.

Естественно, логично предполагать, что в общем случае будет ub, но в частном просто SIGSEGV.
Собственно это — большой-большой хинт. Если у вас случается SIGSEGV, то у вас в программе с вероятностью 99% процентов UB…
0
Собственно это — большой-большой хинт. Если у вас случается SIGSEGV, то у вас в программе с вероятностью 99% процентов UB…

Да, вполне хороший указатель. Гораздо приятнее тихой порчи данных ,)

-4
Значит, вам так повезло в данном конкретном случае, что комбинация размеров типов и поведения оператора сдвига дала нужный вам результат. Сами понимаете, что такой код не очень портируемый и не очень поддерживаемый.

Когда тролите — тролльте потоньше, пожалуйста. Сдвиг столь же переносим, как операция сложения и намного более, чем вещественная арифметика. Впрочем, вы вполне способны и сложение объявить непереносимым. Действительно, может быть переполнение и результат будет неопределенным. :-) Пока (N >=0) && (N < (WORD_BIT-1)) все работает на любой архитектуре. А в реальном использовании все чуть сложнее:

#ifdef USE_GALILEO
typedef uint64_t TSatMask;
#else // USE_GALILEO
typedef uint32_t TSatMask;
#endif // USE_GALILEO
#define ONE_SATT_MASK TSatMask(1)
TSatMask mask = ONE_SATT_MASK << N;


Зато uint32_t mask = pow(2,N); работает непредсказуемо. То есть зависит от архитектуры процессора, софтверной или аппаратной плавающей точки, ключей компилятора, конкретных алгоритмов в софтверной реализации. Если для 2**2 вы получите 4.00000000001 — это не страшно, а вот если будет 3.99999999999999 то при преобразовании в целое у вас получится 3.

Что самое смешное, кодогенерация тоже одинаковая. Можете проверить, gcc и clang, проверенные мной, генерируют одинаковый код для обоих веток:

Проверил на gcc под corrtex-M7, код разный. Жду от вас версию и название библиотеки. Версия компилятора скорее всего не причем, просто std::strlen объявлен inline. ну или вообще через #define или template. Ну и жду от вас теста с нормальным strlen.

Чуть ужатый пруф на кодогенерацию
1876:../Pobase3/ugol-2a.cpp **** bool test1(const char *str) {return *str != 0;}
1529 0000 0078 ldrb r0, [r0] @ zero_extendqisi2
1531 0002 0030 adds r0, r0, #0
1532 0004 18BF it ne
1533 0006 0120 movne r0, #1
1534 0008 7047 bx lr
1877:../Pobase3/ugol-2a.cpp **** bool test2(const char *str) {return strlen(str) > 0;}
1551 0000 08B5 push {r3, lr}
1556 0002 FFF7FEFF bl strlen
1558 0006 0030 adds r0, r0, #0
1559 0008 18BF it ne
1560 000a 0120 movne r0, #1
1561 000c 08BD pop {r3, pc}
1878:../Pobase3/ugol-2a.cpp **** #include 1879:../Pobase3/ugol-2a.cpp **** bool test3(const char *str) {return std::strlen(str) > 0;}
1578 0000 08B5 push {r3, lr}
1583 0002 FFF7FEFF bl strlen
1585 0006 0030 adds r0, r0, #0
1586 0008 18BF it ne
1587 000a 0120 movne r0, #1
1588 000c 08BD pop {r3, pc}



Написали бы 1.0 вместо 1 — тоже было бы хорошо.

Конечно. Но это значит, что нужно иметь двойной набор констант. Например SECS_PER_DAY — количество часов в сутках (86400), а для поддержки auto потребуется SECS_PER_DAY_FLOAT со значение 86400.0. Увы, неудобно и ненадежно.

Так что пусть auto лет 5-10 отлаживается на подопытных свинках. ну в смысле на всяких настоящих програмистах из хайлоада. А когда наберется опыт, что надежно, а что нет, тогда и в АСУТП можно будет применить.

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

Ну в паскале как раз достаточно сильная система типов. Своя операция деления для целых (DIV) и запрет на неявное преобразование вещественных в целые. Так что он как раз подходит. А ещё лучше Delhi, ибо дает много преимуществ.

С остальным более-менее согласен.
+1
Зато uint32_t mask = pow(2,N); работает непредсказуемо. То есть зависит от архитектуры процессора, софтверной или аппаратной плавающей точки, ключей компилятора, конкретных алгоритмов в софтверной реализации.

Ну, если у вас IEEE754-совместимая система, то всё вполне предсказуемо. Впрочем, да, различие в семантике есть, я забыл, что нет перегрузок pow для целочисленных аргументов.


Если для 2**2 вы получите 4.00000000001 — это не страшно, а вот если будет 3.99999999999999 то при преобразовании в целое у вас получится 3.

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


Проверил на gcc под corrtex-M7, код разный. Жду от вас версию и название библиотеки.

Вы хотя бы -O1 добавили?


А какая библиотека &mdash; фиг знает, что там на gcc.godbolt.org. Кстати, проверил только что там же, код снова эквивалентен.


Например SECS_PER_DAY — количество часов в сутках (86400), а для поддержки auto потребуется SECS_PER_DAY_FLOAT со значение 86400.0.

Вас auto заставляют писать либо везде, либо нигде, что ли? Напомню (а то сам подзабыл уже, в конце концов), что изначально дискуссия началась со споров о нужности auto вообще.


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

Там ещё не зря было «выразительная».

-4
Ну, если у вас IEEE754-совместимая система, то всё вполне предсказуемо.

Увы, нет. Оно почти предсказуемо. На х86 сопроцессор выполняет вычисления в long double. А записываем мы временные результаты в double. Убрал компилятор при оптимизации временную переменную — получили капельку иной результат. я уж не говорю о том, что на других архитектурах long double иного размера — не 80, а 96 или 64 бита. Включили -Ofast, он включил -ffast-math и вот вам ещё отличия от IEEE.

Вы хотя бы -O1 добавили?
А какая библиотека — фиг знает, что там на gcc.godbolt.org.

У нас -O2, но дело именно в библиотеке. Можете проверить, при -O0 оно тоже инлайнится. У нас NewLib, а у вас — glibc.

любуйтеь на # define strlen(str)
/* Return the length of S.  */
# define _HAVE_STRING_ARCH_strlen 1
# define strlen(str) \
  (__extension__ (__builtin_constant_p (str)				      \
		  ? __builtin_strlen (str)				      \
		  : __strlen_g (str)))
__STRING_INLINE size_t __strlen_g (const char *__str);

__STRING_INLINE size_t
__strlen_g (const char *__str)
{
  register char __dummy;
  register const char *__tmp = __str;
  __asm__ __volatile__
    ("1:\n\t"
     "movb	(%0),%b1\n\t"
     "leal	1(%0),%0\n\t"
     "testb	%b1,%b1\n\t"
     "jne	1b"
     : "=r" (__tmp), "=&q" (__dummy)
     : "0" (__str),
       "m" ( *(struct { char __x[0xfffffff]; } *)__str)
     : "cc" );
  return __tmp - __str - 1;
}



изначально дискуссия началась со споров о нужности auto вообще.

Так вот нам, в нашем коде он более вреден, чем полезен. А у вас — другие задачи и другой код.

Там ещё не зря было «выразительная».

Прошу точнее определить термин, возможно мы его по-разному понимаем. В паскале есть диапазонные типы множества (то есть битовые маски). Так что его система типов — более выразительная, чем в С++. Ещё одно достоинство Delphi (object pascal) — это интерфейсы, как в java.Это некий аналог множественного наследования, но без присущих множественному наследованию проблем.
+1
Включили -Ofast, он включил -ffast-math и вот вам ещё отличия от IEEE.

Ну так что вы удивляетесь с -ffast-math, это вообще несовместимый режим.


И я с ним ловил очень классные глюки в своё время, когда сортировал массив флоатов, и там были -NaN'ы.


Прошу точнее определить термин, возможно мы его по-разному понимаем.

Ну это как в хаскеле, короче, а ещё лучше — как в Idris каком.

-3
Ну это как в хаскеле, короче, а ещё лучше — как в Idris каком.

Ещё раз прошу пояснить термин «выразительная система типов».
+2

Это когда я средствами компилятора и тайпчекера могу отследить, что мутабельные данные или хендлы не убежали за пределы некоторого контекста выполнения (см. rank-2 polymorphism и existential types).


Это когда я могу выразить больше ограничений системой типов, когда пишу тот же компилятор (см. GADT и functional dependencies, к примеру).


Это когда я могу проверить соответствие размерностей перемножаемых матриц на уровне системы типов, даже если их размерности известны лишь на этапе выполнения (см. dependent types).


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

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

Ещё сложнее вам будет доказать, что эти возможности реально увеличивают надежность.

Реальная задача такова. Есть фиксированное ТЗ с объемом работы. Есть требуемый уровень надежности. Какой язык позволит достигнуть результата за меньшую стоимость и время? Сомневаюсь, что это будет haskel. Высокая оплата разработчиков на haskel вряд ли окупается во столько раз возросшей производительностью и надежность. В лучшем случае, заплатив в 2 раза больше — мы увеличим надежность в корень из двух раз.

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

я очень рекомендую сравнить 50 страничек стандарта паскаля (порядка 70 у дельфи) с более тысячей страниц стандарта С++.

А как размер стандарта хаскел со всеми нужными вами расширениями?
+5
Ещё сложнее вам будет доказать, что эти возможности реально увеличивают надежность.

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


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

Что-то мне не кажется, что разработчикам на Haskell платят статистически значимо больше, чем аналогичным по уровню разработчикам на тех же плюсах.


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

Тоже вариант. Примерно поэтому Google сделал простой как пробку язык Go &mdash; вроде как даже они это не особо скрывали.


А как размер стандарта хаскел со всеми нужными вами расширениями?

От 60 до 100 страниц на core language, ещё страниц 200 описания стандартной библиотеки (API и семантика). Полезные мне расширения, которые не относятся к синтаксическому сахару &mdash; existential types, GADTs, functional dependencies, type families. Есть ссылки на соответствующие научные работы, обосновывающие эти расширения, можно оценить. Заодно учесть, что все эти описания содержат в себе соответствующие доказательства их свойств.

-4
Больше возможностей отвергнуть некорректные программы.

я не о возможностях. Возможность стать президентом России у вас есть.А шансов — нету. :-)

typeded int Metr;
typeded int MetrSquare;
Metr l, w, sWrong;
MetrSquare sRight;
sWrong = l * w; 
sRight= l * w; 


Сумеете ваша система типов ругнуться на sWrong = l * w? Если нет — её возможности несколько не в той области.
+2
Сумеете ваша система типов ругнуться на sWrong = l * w? Если нет — её возможности несколько не в той области.

Если в С++ объявить Metr и MetrSquare как классы и перегрузить операторы умножения, то ругнётся по-моему.

0
Покажите, пожалуйста, переопределение pow(x.y) на пригодной для физики метода размерностей системе классов.

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


Ну как минимум систему СИ (или СГС) поддержать сможете?

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

-4
А пока мы это не сделаем в compile-time говорить о надежной системе типов бесполезно. И статанализ такие ошибки не выявит.
+1

Если вы хотите полноценный метод размерностей с pow(x, y), где y &mdash; переменная времени выполнения, то вам в зависимые типы.

-3
А что, они такое поддерживают в compile-time? А можно ссылочку на популярное и понятное описание?
0

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

-7
Знаете, чем выше квалификация программиста — тем более читаемый его код. Чем выше квалификация ученого — тем проще он объясняет свою область. Можете для сравнения Фейнмана почитать. Если ваш Пирс не читаем — то, наверное, не стоит его читать. Но ссылочку дайте. Можно и на Пирса, если есть хороший перевод.

+2
Можете для сравнения Фейнмана почитать.

Я читал, и ФЛФ, и прочие замечательные вещи. При этом я не уверен, что книжечку Фейнмана по КЭД, например, средний человек вот прям так осилит влёт и поймёт.


Если ваш Пирс не читаем — то, наверное, не стоит его читать.

По мне — читаем, мне очень понравилось в своё время.


Скачать русский перевод можно на здесь. Но всё-таки в долгосрочной перспективе лучше и полезнее освоить английский.

-4
При этом я не уверен, что книжечку Фейнмана по КЭД, например, средний человек вот прям так осилит влёт и поймёт.

Ну она на уровне шестиклассника написана. То есть очень понятна.

За ссылочку спасибо, гляну.
+2
Сумеете ваша система типов ругнуться на sWrong = l * w?

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


struct Metr(u32);
struct MetrSquare(u32);

//let err: Metr = Metr(1) * Metr(2);
let val = Metr(1) * Metr(2);
println!("{:?}", val); // MetrSquare(2)
-4
я не об этом. Вы переопределили операцию умножения. И вам придется переопределять каждую операцию. А это неинтересно, слишком много писать кода, причем писать для каждого типа. Интереснее когда в описании типа MetrSquare я могу сказать, что его размерность равна квадрату от Metr. И компилятор сам это проверит по всем операциям.

я же прямо написал, сумеет ваша система типов ругнуться. Сама система описаний типов, а не дополнительный код.
+2

В хаскеле:


{-# LANGUAGE MultiParamTypeClasses, TypeFamilies, FlexibleInstances #-}
{-# LANGUAGE DataKinds, KindSignatures, TypeOperators #-}

-- Чтобы не писать натуральные числа времени компиляции самому
import GHC.Types
import GHC.TypeLits

-- Описываем тайпкласс для нашего извращённого умножения
class DimMult a b where
    type Result a b
    (|*|) :: a -> b -> Result a b
    infixl 6 |*|

-- Описываем структуру данных, которая будет реализовывать тайпкласс,
-- и тип которой параметризован натуральным числом.
data SI a (d :: GHC.Types.Nat) = SI { val1 :: a } deriving (Eq, Show)

-- Реализуем для неё наш класс типов.
instance Num a => DimMult (SI a d1) (SI a d2) where
    type Result (SI a d1) (SI a d2) = SI a (d1 + d2)
    (SI val1) |*| (SI val2) = SI $ val1 * val2

-- Пара функций для удобства, чтобы создавать экземпляры размерности 1
linear :: Double -> SI Double 1
linear = SI

-- и размерности два
squared :: Double -> SI Double 2
squared = SI

Попробуем заведомую лажу:


*Main> squared 100 == linear 100

<interactive>:59:16: error:
    • Couldn't match type ‘1’ with ‘2’
      Expected type: SI Double 2
        Actual type: SI Double 1
    • In the second argument of ‘(==)’, namely ‘linear 100’
      In the expression: squared 100 == linear 100
      In an equation for ‘it’: it = squared 100 == linear 100

Ошибка типов, как и ожидалось.


А теперь перемножим два элемента размерности один и сравним с элементом размерности один:


*Main> linear 10 |*| linear 10 == linear 100

<interactive>:60:1: error:
    • Couldn't match type ‘2’ with ‘1’
      Expected type: SI Double 1
        Actual type: Result (SI Double 1) (SI Double 1)
    • In the first argument of ‘(==)’, namely ‘linear 10 |*| linear 10’
      In the expression: linear 10 |*| linear 10 == linear 100
      In an equation for ‘it’: it = linear 10 |*| linear 10 == linear 100

Не получилося. И хорошо.


А вот тут всё работает:


*Main> linear 10 |*| linear 10 == squared 100
True
*Main> linear 10 |*| linear 10 == squared 101
False
-4
Ну и сколько вам потребуется дописать для сложения? я правильно понимаю, что нужен будет аналог DimMult и аналог Num?
+1

Нет. Num тут упоминается только для того, чтобы делегировать непосредственное умножение величин нижележащему типу, эти величины представляющему (ну там, Double, Float, Int, Complex, мало ли). Для сложения достаточно просто добавить соответствующий оператор в DimMult, например.

-3
Все равно, немного не то, что хочется… Но взять на заметку можно…
-1

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

+2
я же прямо написал, сумеет ваша система типов ругнуться.

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


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

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

Хочется несколько иное — язык, на котором достаточно сказать, что MetSquare — это Metr во второй степени. А весь контроль типов — встроенный.

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

Ну если вспомогательные определения занимают 5%, то может и стоит. Но боюсь, то в реальности они будут занимать 80% кода.
0

Дык, отсутствие неявных преобразований уже повышает надёжность.
Опять же, если этот "вспомогательный код" написан, оттестирован и используется по всему проекту (а может даже не в одном проекте), то сомневаюсь, что дефекты будут частыми.


На язык в котором "достаточно сказать, что MetSquare — это Metr во второй степени" взглянуть было бы интересно, но есть некоторые сомнения, что такие указания были бы достаточно гибкими для всех случаев. Иначе это уже не язык общего назначения.


С 80% явно перебор, мы ведь не о игрушечном примере говорим, а о проекте не самого маленького размера?

-3
Дык, отсутствие неявных преобразований уже повышает надёжность.

Ну это не про С++. В нем неявных преобразований много. В 93ем году экспериментировали с системой преобразований — и выяснили, что лучше её не использовать, а все преобразования писать явно.

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

Что будет в ином языке — нужно будет проверять.

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

Сомнения и у меня есть. Но в реальном мире мы же используем размерности? Значит такую систему типизации создать можно. Проблем пока вижу две:

  1. градусы, радианы, полуциклы для углов. ну или футы, дюймы, метры для длин.
  2. сложение уток с курицами дает птицы, а куриц с коровами — живность. То есть без наследования не обойтись.


С 80% явно перебор, мы ведь не о игрушечном примере говорим, а о проекте не самого маленького размера?

Открываю стандарт RTCM 3.2 — 457 типов полей. При обычном программировании — нужен просто множитель для приведения к метрам или герцам. А при строгой типизации? А на все возможные операции? Боюсь, что на переводе из RTCM 3.2 в RINEX можно и 95% вспомогательного кода получить. И да, проект точно будет не самого маленького размера.

Но вполне возможно, что в каких-то областях такой подход будет реально удобней.
+1
Хочется несколько иное — язык, на котором достаточно сказать, что MetSquare — это Metr во второй степени.

А с кубами вы как будете работать? Мне просто интересно, как вы предлагаете такие вещи выражать.


Пример на хаскеле выше работает с произвольными размерностями (включая обратные метры и прочие замечательные вещи).

-3
А ровно так же. Какая отдельная проблема с кубами? Не названный отдельным именем тип — это все равно тип.
0

Сумеет. Я бы даже сказал, что подобные вещи &mdash; это классический пример, и в этом случае нет ничего сложного.


Правда, вместо значка умножения нужно будет использовать другой значок. Умножение &mdash; это всё-таки операция на поле в него же.

-6
С другим значком — не интересно, это почти на любом языке можно. Интереснее всего — это чтобы pow(x, 2.0) давало квадратные метры, а pow(x, 3.0) — кубические. И чтобы система на этапе компиляции понимала, что pow(x1,2.5) / pow(x2, 1.5) — это просто метры.

Сумеет такое хаскель? Нет? Ну если нет — значит не сильно он поднимет надежность на наших задачах.
+1

В хаскеле, в принципе, и с тем же значком можете. Правда, тогда штатные функции из тайпкласса Num прятать придётся.


Сумеет такое хаскель? Нет? Ну если нет — значит не сильно он поднимет надежность на наших задачах.

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

-6
В вики я без вас полез. Мне бы описание языка языка на русском или хоть кратное введение. По idris нашел.

Но уже понятно, что ваш уровень таков, что вам кажется, что вики хватает. :-(
+3

Тут могла бы быть колкость об уровне программистов, которые английского не знают, но я просто сошлюсь на здравый смысл: откуда взяться подробным материалам на русском о сравнительно новых и не мейнстримовых языках? А на википедии есть ссылка, в том числе, на официальный сайт с мануалами.

-5
Встречаются в Лондоне два англичанина
— whitch watch?
— six cloch.
— such match?
— match such!
— What which?
— a for whom how.
— MGIMO fisnihed?
— ack!

Так что одно дело читать datasheetы, а другое дело — полный разговорный язык.

А вот то, что на разработанный в 1973ем году язык ML нету хорошего русского описания — скорее всего показывает, что этот язык никому не нужен. Не все, что не вылезло в мейнстрим — не заслуживает потраченного на него времени. Но тем менее — это хороший критерий, на что тратить время, а на что нет. Не так уж долго жить на этом свете осталось, чтобы тратить время на ерунду.
-6
грустно, когда любознательность растрачивается на ерунду. А ещё более грустно, когда взрослый человек не хочет (или не может) отличать одно от другого.

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

А ваш ML известен в 1969ого года. И за 45 лет — так ни во что путное не развился. Да, в отдельных нишах что-то используется. Как используется и COBOL, и PROLOG и LISP и FORTH… Но вот глобального переворота — даже в программировании не вижу. В быту — тем более.

А вот то, что вы не умеете отличать одно от другого — это грустно.
+2
грустно, когда любознательность растрачивается на ерунду.

Осталось определить, что такое ерунда. Вот желание читать Пирса &mdash; ерунда? А книгу по алгебраической топологии (никогда в программировании не пригодится)?


А ваш ML известен в 1969ого года. И за 45 лет — так ни во что путное не развился. Да, в отдельных нишах что-то используется.

ocaml, F#, Scala, Haskell тот же.


А так вообще всё программирование &mdash; одна большая ниша.

-3
Глянул Пирса. Для его изучения требуется знать один из ML-подобных языков. Так что все тот же вопрос в третий раз — дайте, пожалуйста, хорошее и понятное описание ML или чего-то ML-подобного.

ерунда — расстрачивание сил на то, что в жизни не пригодится.
+2
Но уже понятно, что ваш уровень таков, что вам кажется, что вики хватает. :-(

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

-5
Часто, но далеко не всегда. В нашей области — процентов на 60, не более…
+2
С другим значком — не интересно, это почти на любом языке можно. Интереснее всего — это чтобы pow(x, 2.0) давало квадратные метры, а pow(x, 3.0) — кубические. И чтобы система на этапе компиляции понимала, что pow(x1,2.5) / pow(x2, 1.5) — это просто метры.

Вы говорите про метод размерностей и несёте лютую пургу тут же. Это ошибка, за которую любой школьник или студент 1 курса тут же получает линейкой по рукам. Возведение в действительную степень (а равно, скажем, лонарифм или экспонента) определено только для безразмерных величин.


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


Конечно IEEE754'шные числа являются действительными с некоторой натяжкой, но чтобы трактовать их как рациональные необходимо использовать gmp ,)

-5
Возведение в действительную степень (а равно, скажем, лонарифм или экспонента) определено только для безразмерных величин.

s = a *t**2 / 2;
t = sqrt(2*s)/sqrt(a) = pow(2*s, 0.5) / pow (a, 0.5)

Неужели вы такого в школе не проходили? А номер школы, где равноускоренное движение не проходят, можно? :-)
+2

Там вам товарищ про рациональные степени чуть ниже написал.


Конечно, корректнее было бы сказать, что возведение в степень x \in \mathbf{R} \ \mathbf{Q} не имеет особого смысла, но это настолько ясно из контекста, ИМХО, что даже я со всем своим занудством, если бы спорил с grossws, к этому бы не придрался — просто в голову бы не пришло.

+3

Если вам так интересен номер моей школы, то ФМШ №18. И, к вашему сожалению, я отличаю натуральные, целые, рациональные и действительные числа.


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


Также вам стоило бы понять ещё в школе, что операция возведения в натуральную степень, в целую степень, в рациональную степень и в действительную степень над полем действительных чисел — разные операции, иногда дающие один результат, т. к. для более широкого множества чисел операция строится таким образом, чтобы она обычно давала одинаковый результат для, скажем, натурального числа 2 и целого числа 2.


Но бывают случаи когда это не так: например, операция возведения в целую степень определена для -2 (\in Z), но операция возведения отрицательного числа в рациональную степень не определено над полем действительных чисел, но определена над полем комплексных.

-4
Ну привет из ФМЛ 239. Математикой я перестал заниматься почти 40 лет назад, и что там в строгой математике — это неинтересно (ну или интересно только математикам). Поэтому о математике я с вами спорить не буду, а расскажу, что на самом деле.

Логарифм определен только для безразмерных? Ха-ха-ха, неужели в школе не говорили про децибелы? логарифмируем 1 киловатт — получаем 3 BW (3 бела") или 30 dBW или 60 dBm. Да, это очень не строго. Но в технике — так. А главное — так в ГОСТах откуда берутся формулы. Ну вот вам ГОСТ 24204-80 и формула абсолютного уровня мощности оттуда:
image
Логарифмируем милливатты и получаем dBm.

Ещё смешнее — с arcsin, Берем arcsin(0.5) и получаем… радианы, градусы, полуциклы, реже -грады и обороты (циклы) — все, что угодно, но не безразмерную величину. Может её стоит называть псевдоразмерной, но уж безразмерной она не является.

pow(x1,2.5) / pow(x2, 1.5) на который вы ополчились — это как раз рациональные, а не действительные числа. Но…

Беда в том, что на компе вообще-то нету действительных чисел. То, что дает IEEE 754 это представление действительных чисел с помощью двоичных дробей. То есть фактически, в обычной плавающей арифметике — все числа рациональные. Причем их не так много. Тип float — это чуть меньше 4 миллиардов значений. То есть ещё у нас далеко не любое число представимо.

Далее, ещё смешнее. pow(x,2.5) мы можем представить как х*х*sqrt(x). И если x — это квадратные метры, то размерность будем m**5; Но… бывают ошибки округления. И 2.4999999999999999 мы должны рассматривать как 2.5.

Бывает ещё смешнее. Синус больше единицы в математике быть не может. Но… синус, подсчитанный через векторное произведение — получился больше 1. Не сильно больше — на 10**-12, но больше. Пришлось вставлять условия — если больше 1, то брать строго 1. А уж потом — arcsin.

Так что жалко, что вас не научили отличию физики от математики, а техники от физики. А что там в математике — извините, не интересно. у меня — техника.
+3
Логарифм определен только для безразмерных? Ха-ха-ха, неужели в школе не говорили про децибелы? логарифмируем 1 киловатт — получаем 3 BW (3 бела") или 30 dBW или 60 dBm. Да, это очень не строго. Но в технике — так. А главное — так в ГОСТах откуда берутся формулы. Ну вот вам ГОСТ 24204-80 и формула абсолютного уровня мощности оттуда:

Логарифмируем милливатты и получаем dBm.

Если вы сами не заметили, то под логарифмом искусственно убирается размерность (выполняется переход к безразмерным величинам) посредством нормализации на 1 Вт/1 мВт. И логарифмируете вы не 1 кВт, а 1 кВт/1 Вт. Если вы этого не понимаете, то лучше бы и не заикались про размерности. Точно такая же ситуация, например, в диффурах, во всяких вещах типа магнитуд (где под логарифмом может быть приведённая к безразмерной энергия, максимальное отклонение в мкм и т. п.)


Ещё смешнее — с arcsin, Берем arcsin(0.5) и получаем… радианы, градусы, полуциклы, реже -грады и обороты (циклы) — все, что угодно, но не безразмерную величину. Может её стоит называть псевдоразмерной, но уж безразмерной она не является.

И получаете радианы, как естественную единицу угла, которая, напомню, отношение длины дуги к радиусу, т. к. безразмерная величина. То, что вы потом её перемасштабируете — к делу не относится.


pow(x1,2.5) / pow(x2, 1.5) на который вы ополчились — это как раз рациональные, а не действительные числа. Но…

Беда в том, что на компе вообще-то нету действительных чисел. То, что дает IEEE 754 это представление действительных чисел с помощью двоичных дробей. То есть фактически, в обычной плавающей арифметике — все числа рациональные. Причем их не так много. Тип float — это чуть меньше 4 миллиардов значений. То есть ещё у нас далеко не любое число представимо.

Как я уже сказал выше, для восприятия чисел типа IEEE754 как рациональных нужно брать gmp или аналогичную библиотеку для работы с generic multiprecision numbers. Вы, естественно, не удосужились прочитать соответствующий абзац. Как известно из ненавистной вам математики любое периодическое действительное число представимо в виде рационального. Но большого смысла в размерности m^{123896721987/999999999999} нет.


Бывает ещё смешнее. Синус больше единицы в математике быть не может. Но… синус, подсчитанный через векторное произведение — получился больше 1. Не сильно больше — на 10**-12, но больше. Пришлось вставлять условия — если больше 1, то брать строго 1. А уж потом — arcsin.

Запросто, sin(1+1i) = 1.298 + 0.635i, и действительная часть, и модуль > 1. Ну или sin(1.571+1.317i) = 2.000, если хочется действительного результата.


Так что жалко, что вас не научили отличию физики от математики, а техники от физики. А что там в математике — извините, не интересно. у меня — техника.

Тут тоже не угадали, я физик. Ну и чтобы не вставать лишний раз — и с технической стороной образования проблем у меня нет, и в АСУТП поработать успел. И повидать программ написанных "инженерами" в которых ни они сами баги нормально выловить не могли, ни просто разобраться. Зато минимально написание повторно используемого кода, почти полное отсутствие форматирования, до 8 стейтментов на одной строке в коде на Си… Вы, кстати тоже код какого-нибудь ПИД-регулятора или фильтра копируете в несколько мест, чтобы потом независимо баги вносить?


И софт от всяких товарищей типа Carel, TAC/SE и Necos/Danfoss не сильно далеко от этого ушел.

-4
Если вы сами не заметили, то под логарифмом искусственно убирается размерность

Это называется абстракция. Странно, что математик не видит их. В технике законодательно (на уровне ГОСТ) принята абстракция, что логарифм от мощности выдает белы. А что под капотом — не важно. Под капотом у умножения — вообще-то сдвиги и сложения. А у взятия квадратного корня — подсчет ряда. И что происходит с размерностью при подсчете ряда — вопрос для меня темный. Да и как сдвиги и сложения меняют размерность — тоже не понятно. Но абстракция такова, что некий ряд делает из квадратных метров метры, а некая последовательность сложений и сдвигов метров с метрами — дает квадратные метры.

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

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

Естественная где? На плоскости? Вы хоть на одной карте видели радианы? Земля вообще-то круглая. :-) Поэтому естественная единица в геодезии — градус. Видели хоть на одной карте радианы? :-) А самая естественная единица угла — это оборот и доли оборота. Все остальное (градусы, грады, полуциклы) — пляшет от оборота. Так что для техники абстракция плоскости не всегда применима. И в языке для техники нужны и градусы и полуциклы.

Как известно из ненавистной вам математики любое периодическое действительное число представимо в виде рационального

Мне известно про то, что иррациональных чисел — не меньше рациональных. :-)

Как я уже сказал выше, для восприятия чисел типа IEEE754 как рациональных нужно брать gmp или аналогичную библиотеку для работы с generic multiprecision numbers.

Мда… На физфаке СПбГУ тоже так думали. И потеряли все значащие цифры при подсчете сходящегося ряда. :-) Не все абстракции математики выполняются в программировании. Ассоциативный закон сложения — увы, выполняется не всегда.

Тут тоже не угадали, я физик.

Ну тогда все понятно. Видел я, как программируют физики. Картинка с натуры (Программист — П, Физик — Ф, место действия физфак СПбГУ, 1983 год):
Ф — программа что-то не работает
П — у вас деление на ноль
Ф — физически эта переменная не может быть нолем. А можно обойти ошибку?
П — могу не делить, если ноль. Сделал.
Ф — ура! Ошибка исправлена!

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

Вы, кстати тоже код какого-нибудь ПИД-регулятора или фильтра копируете в несколько мест, чтобы потом независимо баги вносить?


Ну вот вам пример ПИД-регулятора, а вот — экспоненциальный фильтр:
      result = result * (1. - k) + value * k;


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

Но… у нас система оплаты чуть иная. Нам платят не за количество строк, а за работоспособность. Поэтому прежде чем выносить код в библиотеку — думаем, а насколько нам нужна модицифруемость, а насколько повторная используемость. А прежде, чем использовать чужой библиотечный код — сравниваем время на изучение и время на написание и отладку собственного кода. Ну и все остальные характеристики тоже смотрим.

Потому мы и не настоящие программисты, что мы думаем, а не слепо следуем правилам моде. Есть очень хорошая статья про Hype Driven Developmen. А вот рассказ про очень модный стиль примерно lдесятилетней давности, заглавие говорит само за себя "Микросервисы: пожалуйста, не нужно".

Ну в общем любой технологией нужно пользоваться обдуманно, а слепое следование правилам применимо только для ГОСТ.

почти полное отсутствие форматирования,

Это действительно плохо, но математики так пишут. Почему-то математикам форматирование не нужно для понимания смысла кода.

до 8 стейтментов на одной строке в коде на Си…

В отдельных случаях — это правильно. Много операторов на одной строке писали, чтобы уменьшить количество перфокарт в колоде. А один оператор на строке — дань вычисления производительности программиста исходя из числа строк. Вы как цикл for запишите?
for (int i=0;
      i < N;
      i++)

или нормально, как for (int i=0; i < N; i++)? Вот аналогичные конструкции (прежде всего инициализацию) и принято писать в одной строке. Вам не кажется, что в этом примере однострочная иницализация явно читаемей была бы?

/*     MACHINE CONSTANTS FOR THE BURROUGHS 1700 SYSTEM. */
/*
   imach[1] = 2;
   imach[2] = 33;
   imach[3] = 8589934591;
   imach[4] = 2;
   imach[5] = 24;
   imach[6] = -256;
   imach[7] = 255;
   imach[8] = 60;
   imach[9] = -256;
   imach[10] = 255;
*/

Но увы, это переписано с фортрана «1 в 1». :-) Недостатки общепринятого библиотечного кода, между прочим.

-1
Математикой я перестал заниматься почти 40 лет назад, и что там в строгой математике — это неинтересно (ну или интересно только математикам).

А что там в математике — извините, не интересно.

А зря. Во-первых, это просто красиво. Во-вторых, ум в порядок приводит и вот это всё.


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

-3
А жизни много красивого: горы, самолеты, атомные ледоколы, педагогика, театр… Просто после того, как достиг вершины — уже неинтересно. я в свое время прыгнул через голову и стал призером Питера по математике (диплом 1ой степени, 2ое место в личном зачете). Вот только разница с Игорем Жуковым — не одно место в таблице, а примерно на голову. Поэтому Игорь стал призером мира, а я математикой заниматься перестал.

Для меня всегда был важен вопрос, чтобы меня помнили после моей смерти. Кого вы знаете из ныне живущих математиков? я Гришу Перельмана, Матиясевича, Башмакова… И то, лишь потому что лично знаком.

Зато по всей России стоит тысяча зданий, просчитанных на прочность программой «Ладога», документацию к которой я правил в 17 лет. И это намного важнее любой математики.
+1
s[0] = 'K' читабельнее, вызывает меньше WTF и вообще.

Я бы на ревью такой код без комментария, что это сделано специально для какой-то адовой оптимизации тоже не пропустил бы. Да и с коментарием тоже подумал бы ещё. Обычно, если не нужна больше ворона, и хочешь корону, пиши полностью, s = «корона»;
+4
Желание программиста. Явно имелось ввиду не то, что написано.

Про это вам уже написали. Отвечаю на это, чтобы выразить своё согласие с написанным nikolaynnov.


Была очень веселая история в 1998 ногу. Тестирую, вижу баг, пишу yole — мол у тебя вещественный тип вместо денежного. Он в ответ — у меня все норм.

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


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

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


Да по определению «Библиоте́ка (от англ. library) в программировании — сборник подпрограмм или объектов, используемых для разработки программного обеспечения (ПО)». Впрочем, я соглашусь, что молодое поколение имеет право не знать изначальный смысл этого слова.

Старое поколение, очевидно, имеет право пропустить слово «сборник». Хотя вы, конечно, можете сказать, что множество из одного элемента &mdash; тоже множество, и даже пустое множество &mdash; всё равно множество.


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


То есть, сделав алгоритм для double — не надо его расширять на float или int64.

Почему на флоат не надо?


Почти все вычислительные алгоритмы, которые я писал, имело смысл по крайней мере протестировать что с float, что с double, что провалидировать с типами из boost.multiprecision на мелком датасете.


Но все эти красоты — увы, не перевешивают проблем с отладкой темплейтов.

Какие там особые проблемы по сравнению с обычным кодом?


А Си как раз и писался, как универсальный ассеблер (сначала PDP-8, потом PDP-11).

Так тем более, почему не ассемблер?


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

Работает, работает.


Правда, причём это к тому, влезают плюсы в мелкие микроконтроллеры или нет?

-3
Увольте его, пожалуйста, язык тут ни при чём.

Виновата венгерская нотация, усиленно насаждаемая микрософтом. Пока имя переменной в ладу с тмипом — она помогает. Но если сменили тип и забыли поменять имя — наступает локальный песец. Примерно та же фишка и с auto. Так что применять его надо крайне ограничено. А ещё лучше — не применять.

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

Будет ссылочка — почитаю.

Старое поколение, очевидно, имеет право пропустить слово «сборник».

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

Но смысл-то на самом деле в том, что разработчики библиотек не обязаны разрабатывать и клиентский код

А тестироваться на чем? Так что обязаны, увы.

Почему на флоат не надо?

Большинство FPU использует double или long double. Да и по стандарту Си любой float при операциях сразу преобразуется в double. Так что преобразования — несколько замедлят ваш код. А там, где используется FPU — обычно памяти хватает. А у нас просто по точности ничего не влезет во float. Расстояние до спутников — 20 тысяч км от центра земли, точность измерений — СКО 5 миллиметров. Так что 11 значащих цифр — это минимум.

Какие там особые проблемы по сравнению с обычным кодом?

Конечно! Примерно та же гадость, что и с инлайнами. «суслика видишь? Нет? А он есть».

Так тем более, почему не ассемблер?

Потому что каждый инструмент выгоден в своей области. Там, где надо — там ассемблер. Где важнее универсальность — там Си.

Правда, причём это к тому, влезают плюсы в мелкие микроконтроллеры или нет?

Ну в некотором смысле мы тоже на плюсах пишем. :-)
0
Виновата венгерская нотация, усиленно насаждаемая микрософтом. Пока имя переменной в ладу с тмипом — она помогает.

Суть венгерской нотации в том, чтобы указывать семантику переменной.


Если у вас есть переменная, отвечающая разнице, не знаю, ширин ваших любимых клапанов, то вы её назовёте не iDiff или fDiff, а wDiff. Потому что width.


Будет ссылочка — почитаю.

Например. А правильной ссылкой была бы ссылка на Бенджамина Пирса, Types and programming languages.


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

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


А тестироваться на чем? Так что обязаны, увы.

Смогите, пожалуйста, прочитать то, что в скобках после процитированной фразы.


Большинство FPU использует double или long double. Да и по стандарту Си любой float при операциях сразу преобразуется в double. Так что преобразования — несколько замедлят ваш код.

Но если я упираюсь в шину памяти, а не в FPU, то нет. А это бывает не так уж редко. Современные процессоры в 2017 году достаточно мощные, память не поспевает.


А там, где используется FPU — обычно памяти хватает.

Или нет. У меня был проект, где жралось гигов под 200 памяти. Заменить float на double — всё, в один сервер не влезает. При этом валидация на более мелком датасете показала, что точности флоата-то, в общем-то, нам хватает.


Конечно! Примерно та же гадость, что и с инлайнами. «суслика видишь? Нет? А он есть».

Очень по существу, спасибо.

-4
Суть венгерской нотации в том, чтобы указывать семантику переменной.

Это лишь побочное использование. Сошлюсь на Линуса «Вписывание типа переменной в её имя (так называемая венгерская нотация) ущербно — компилятор и так знает типы и может проверить их, и это запутывает программиста. Не удивительно, что MicroSoft делает забагованные программы. (Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged — the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs.)»

Например. А правильной ссылкой была бы ссылка на Бенджамина Пирса, Types and programming languages.
Меня интересовала ссылка на описание языка ML.

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

Это самообман. Посчитайте время, потраченное на реюзабельность и какое количество кода на самом деле повторно используется.

А самая главная проблема это, когда объясняешь любителю повторно используемого кода, что алгоритм долджен работать несколько иначе, а он говорит, что не может этого сделать, ибо код используется ещё в паре мест, где нужно именно существующее поведение. В результате повторно используемый код оборачивается cut & paste, что мне нравится ещё меньше.

Инженер должен уметь предвидеть, какой код стоит сделать повторно используемым, а какой не стоит.

Но если я упираюсь в шину памяти, а не в FPU, то нет.

Согласен. У нас не бывает больших вещественных массивов, область не та.

Очень по существу, спасибо.

я имел ввиду, что для отладки полезно видеть исходный код. А макроопределения, инлайны и темплейты это не позволяют. То есть мы видим мета-код, а как он инплементировался — не видно. Вот и получается, как с тем сусликом. А вкупе с «одаренными» программистами, наворачивающими пять уровней темплейтов друг на друге получается фигня. То есть красиво, но — не отлаживается.
+3
Это лишь побочное использование. Сошлюсь на Линуса

Отсылка к авторитету, люблю такое.


А если серьёзно, венгерская нотация, опять же &mdash; она не обязательно про типы, это лишь один из возможных вариантов, пусть и самый распространённый (см. также карго-культ).


Меня интересовала ссылка на описание языка ML.

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


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


Это самообман. Посчитайте время, потраченное на реюзабельность и какое количество кода на самом деле повторно используется.

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


я имел ввиду, что для отладки полезно видеть исходный код. А макроопределения, инлайны и темплейты это не позволяют. То есть мы видим мета-код, а как он инплементировался — не видно.

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

0
А если серьёзно, венгерская нотация, опять же — она не обязательно про типы, это лишь один из возможных вариантов, пусть и самый распространённый

Вы за деревьями не видите леса. если бы добавляете префикс w для ширины, то тем самым выделяете некий (под)тип width. Это удобно для языков, не позволяющих объявлять свои типы. Ну как пример. В Си нету множеств, потому когда мы используем целую переменную как битовую маску — её разумно выделить префиксом. Это же касается и интервальных типов вроде wifth.

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

Вам интересен вывод типов, а мне — устройство языков программирования. Есть возражения?

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

А теперь — добро пожаловать в реальный мир. О его прелестях — можно почитать в блоге daata.ru. Ну и вот эпическое — Заблуждения программистов об именах. Это вот очень похоже на наши будни…

Так что на первый план в прикладном коде выходят совсем иные характеристики. Те самые, которые вы не называли. Прежде всего — модифируемость. Даже если вы используете overengineering всегда возникают новые условия, которые не вписываются в контракты вашего кода.

Ну как пример. У вас в базе есть ключ идентифицирующий человека. Ну скажем ФИО + дата рождения + место рождения. А потом возникает повесть о несчастной Королеве, которая в половине документов Королёва. Вы бы и рады внести изменения в повторно используемый код, но беда в том. что в одной области в одном раойне у вас есть и Новосёлово и Новоселово.

Ещё пример. Вроде все части ключа должны быть обязательно не пустыми. И тут вдруг суд признает человека без фамилии.

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

Потому что у любителей повторного использования любой ценой — частая проблема, «ой, я не могу это изменить, этот код используется ещё в 10 местах».

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

Да, для понимания. Мы не знаем, с какими приемниками GPS мы будем работать через 5 лет. И какие из инвариантов в них разрушатся. Проблема не в анализе исходной задачи, а в перемене условий.

А мелкие универсальные кусочки — они и у нас повторно используемые. И сидят в отдельном библиотечном репозитарии.

Только не воспринимайте это как защиту cut'n'paste — его у нас тоже нет.

То же самое можно сказать и про функции, и вообще про любые методы абстракции.

Вы не правы, Код функции я вижу и вполне могу по нему ходить, ставить точки останова и так далее. Более того, я вижу дерево вызовов.
0
Вы за деревьями не видите леса. если бы добавляете префикс w для ширины, то тем самым выделяете некий (под)тип width. Это удобно для языков, не позволяющих объявлять свои типы.

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


Вам интересен вывод типов, а мне — устройство языков программирования. Есть возражения?

Для того, чтобы понять некоторые причины дизайна языка, надо понять вывод типов. Чтобы понять абсолютно формальный и не особо привязанный к языку (но привязанный к системе типов) алгоритм вывода типов, дизайн некоего конкретного языка понимать не обязательно.


Ну как пример. У вас в базе есть ключ идентифицирующий человека. Ну скажем ФИО + дата рождения + место рождения. А потом возникает повесть о несчастной Королеве, которая в половине документов Королёва. Вы бы и рады внести изменения в повторно используемый код, но беда в том. что в одной области в одном раойне у вас есть и Новосёлово и Новоселово.

Не, не рад. Нормализация имён — ответственность слоя выше. Это его задача — определять, какая форма имени является каноничной, и отдавать её мне.


Ещё пример. Вроде все части ключа должны быть обязательно не пустыми. И тут вдруг суд признает человека без фамилии.

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


Так что повторное использование — лишь там, где контракт точно не будет сильно меняться.

Самое забавное, что нет. У меня было много-много-много случаев, когда существенно менялась бизнес-логика и бизнес-требования. Грамотная декомпозиция помогала с этим справляться минимальной кровью.


Потому что у любителей повторного использования любой ценой — частая проблема, «ой, я не могу это изменить, этот код используется ещё в 10 местах».

Да ёлки-палки, вы к этому моменту уже забыли вами же процитированный кусок, на который вы отвечали?


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


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

А код темплейтов не видите, что ли?
А код внешних функций и библиотек видите?

-4
Нормализация имён — ответственность слоя выше.

Отлично! Вы уже признаете, что в разных слоях — разные требования. А нижние слои — и у нас библиотечны и повторно используемые.

Грамотная декомпозиция помогала с этим справляться минимальной кровью.

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

Есть повторное использование ради более грамотного дизайна системы,

Зависит от. Если вы тратите на 20% больше времени и получаете хороший дизайн — это отлично. А если вы пишете на 400% больше кода, а потом выясняется, что ваша абстракция не годится для реальных данных — это песец (полярная лисица такая). я за первый вариант, но обычно любители повторного использования выдают второй. Классы — чудо, все операции есть, а проект не работает. Все рабочее время ушло на грамотный дизайн да повторное использование.

А код темплейтов не видите, что ли?
А код внешних функций и библиотек видите?

Макросов и инйланов — не вижу. Темплейт виден, если не заинлайнился. Внешних библиотеки — могу увидеть, если соберу с сорцами.
+2
Отлично! Вы уже признаете, что в разных слоях — разные требования.

Во-первых, речь идёт не о разных требованиях, а о разных задачах и разных ответственностях.
Во-вторых, я изначально про это говорил.


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

Это не значит, что любая декомпозиция плоха, и теперь не надо декомпозировать.


я за первый вариант, но обычно любители повторного использования выдают второй.

Это в вашей субъективной практике, или есть какие другие данные?


Макросов и инйланов — не вижу. Темплейт виден, если не заинлайнился. Внешних библиотеки — могу увидеть, если соберу с сорцами.

А, вы объектный код/асм имеете в виду? Так там вообще никаких отличий темплейтов от прочих функций нет (кроме того, что у темплейтов выше шанс заинлайниться в виду доступности определения в точке использования в подавляющем большинстве случаев).

-3
Во-первых, речь идёт не о разных требованиях

Да нет, именно о разных требованиях. Одно дело — самый нижний слой библиотечных процедур. Ради скорости их можно на ассемблере написать, как тот же #define strlen в glibc.А другое дело — слой прикладной логики, есть модифицируемость намного важнее скорости исполнения.

Это не значит, что любая декомпозиция плоха, и теперь не надо декомпозировать.

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

А то некоторые из-за универсальности пишут в 6 раз больше кода, причем 2/3 этого кода просто не вызывается, 1/6 полезна при отладке и только 1/6 рабочий код. При этом уровень вылизанности — везде одинаков. :-)

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

И если бы разработчик не погнался бы за универсальностью. и повторным использованием — он бы уложился в бюджет из сделал бы работающую систему. А так… Когда проект перешел ко мне, пришлось выкидывать 2/3 неиспользуемого и отлаживать остальное. В итоге отладил, конечно. но матерился сильно.

Это в вашей субъективной практике, или есть какие другие данные?

Это в практике. Из литературы — почитайте у Брукса про эффект второй системы. И вообще вам совет — читайте Брукса. Сразу по иному на процесс разработки начнете смотреть.

А, вы объектный код/асм имеете в виду?

Соответствие бинарного кода исходному. Возможность поставить точку останова, например.
+3
Да нет, именно о разных требованиях.

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


А то некоторые из-за универсальности пишут в 6 раз больше кода, причем 2/3 этого кода просто не вызывается, 1/6 полезна при отладке и только 1/6 рабочий код.

Некоторые. Это ключевое слово. Любую технику можно испоганить при особом желании или таланте.


Это в практике. Из литературы — почитайте у Брукса про эффект второй системы.

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


Соответствие бинарного кода исходному. Возможность поставить точку останова, например.

У меня почему-то таких проблем даже с шаблонными функциями в дебаг-сборках особо не было. В релизных &mdash; там компилятор вообще код хорошенько так переколбашивает, там весело.


К слову о доказательстве большей надёжности всяких хаскелей &mdash; сейчас поймал себя на мысли о том, что не пользуюсь там дебаггером. Если программа скомпилировалась, то либо она работает, либо я накосячил в самой логике, и тогда достаточно медитации над кодом и дёшево создаваемых тестов (вроде hspec того же).

-4
Некоторые. Это ключевое слово. Любую технику можно испоганить при особом желании или таланте.

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

Любители повторно используемого кода неразрывно связаны с написанием второй версии системы?

Не важно по какой причине выбирается более универсальное решение, чем нужно. Важно — что это ведет к лишним трудозатратам, разбуханию кода и меньшей надежности действительно используемого кода. Отлаживается=то все, а не только нужные 20% кода.

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

Специальная дебажная сборка — это для нас экзотика. Код или работает (98%) или уж такой тонкий баг, что в дебажной сборке его не поймать.
+5
Если отладочная сборка для вас экзотика, то у вас нет и не может быть статистики о том, насколько такая сборка упрощает нахождение ошибок.
-6
Слышал уже такое: «Да вы же не колитесь! Ну откуда вы знаете, что героин вреден!» :-)

Деление на отладочную и релизную сборку — характерно только для Visual Studio. У нас скорее отладочные и релизные исполнения приложения.

Черты отладочной сборки:
  • Включена 10уровневая система логирования. Уровень логирования переключается динамически, стартовый уровень задается в параметра запуска.
  • Выдается полный map (а на FreeRTOS ещё и листинги)
  • Там, где есть — полный комплект символов для отладчика
  • Есть отладочная консоль
  • Если есть специальные отладочные функции — они скомпилированы и их вызов может быть включен из командной строки или отладочной консоли.
  • Есть выдача довольно полной информации по командам с отладочной консоли или из приложения оператора
  • Есть система записи бинарных данных (там, где есть файловая система)


Черты релизной сборки
  • Включение оптимизации (-O2 или -Os)
  • Сборка под конкретный SoC


Архитектуры: I386, ARM, SPARC, 8086(16бит)
OS: Linux, FreeRTOS, Windows, QNX, FreeBSD, MS-DOS
Компиляторы: gcc, С++ Builder, clang, lcc, Borland C++, MSVC

Варианты отладки (в порядке частоты использований):
  • I386, Windows, С Builder, работа по записанным файлам данных
  • Включение высоких уровней логгирования + динамическое наблюдение
  • Анализ рапортов (отчетов о состоянии) и логов от заказчика
  • Вставка дополнительной отладочной печати
  • ARM, Linux, gcc, работа по записанным файлам данных
  • Отладка отладчиком на целевой системе


Код делится на общую, ОС-зависимую и платформо-зависимую части. Аналогично, ошибки бывают общие, ОС=зависимые, платформо-зависимыеи компиляторо-зависимые.

Специфика работы состоит в том, что если мы работаем по реальным данным и встали на точку останова, то до следующего входа в режим (фиксации RTK быстрой статикой) может пройти и 5 минут. Иными слова — у нас мягкое реальное время.

Основная отладка — по записанным данным в среде разработки. А вот то, что нужно копать отладчиком… там или вылет (и есть адреса в коде) или порча памяти или нехватка стека или гонка или неиниализированные переменные…

Шансы, что при сьборке с ниыми параметрами ошибка перестанет проявляться или будет проявляться иными симптомамии — процентов 80.

Так что не обязательно колоться, чтобы понять, что лично мне не не нужен героин. Не обязательно 10 раз нарваться на то, что «в debug работает в reliase сбоит», чтобы понять, что эта система для нас не подходит.

Ну а любители debug-release с моей точки зрения должны отключать тормоза на своих автомобилях после получения. прав. :-)

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

Ну настолько, что интернет полон воплями «в debug работает, а reliase падает».

P.S. Запрет пользоваться чужим опытом — это логика наркомана
+5
Деление на отладочную и релизную сборку — характерно только для Visual Studio.

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


Промотайте до главы "Running and debugging" и убедитесь сами: https://community.embarcadero.com/blogs/entry/learn-to-program-with-c-builder-2-building-and-debugging


Таким образом, ваше утверждение о том, что деление на отладочную и релизную сборки присуще только Visual Studio — ложно.


А вот то, что нужно копать отладчиком… там… или неиниализированные переменные

У вас, профессионала, умеющего выделять ключевые слова в комментариях полужирным шрифтом, случаются неинициализированные переменные в релизном коде?
Это все современные компиляторы отлавливать умеют, даже без помощи PVS-Studio. И позволяют трактовать неинициализированные переменные как ошибки компиляции, что и следует делать.


Шансы, что при сьборке с ниыми параметрами ошибка перестанет проявляться или будет проявляться иными симптомамии — процентов 80.

Столь высокий процент плавающих ошибок — не повод ли поразмыслить о качестве кода?


P.S. Запрет пользоваться чужим опытом — это логика наркомана

Я уже заметил, что эта тема — частый гость в ваших комментариях.

-6
Промотайте до главы «Running and debugging» и убедитесь сами:

Рекомендую использовать Google Translate, Как минимум не потеряете смысл.
These are Run Without Debugging and Run [implied, this means Run With Debugging]. это не кнопки запуска отдельных версий. Это запуск одного и того же исполняемого кода под отладчиком или напрямую.

случаются неинициализированные переменные в релизном коде?
Это все современные компиляторы отлавливать умеют, даже без помощи PVS-Studio.

Ох уж эти сказочники… Последняя история. Пишу в battery RAM (чайники зовут его CMOS), читаю — нули. В итоге выясняет — забыл на него тактирование подать. Ну вот вам даже не неинициаизированная переменная, а целая неиницаилизированная память. :-)

Ну и что тут компилятор отловит? Откуда он знает, какой у меня SoC, и как там что инициализируется?

И вообще, инициализация в одном модуле, переменная — в другом, пишем из третьего, читаем из четвертого. Вы думаете в PVS-Studio (не говоря уж о компиляторах) есть межмодульный анализ?

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

Столь высокий процент плавающих ошибок — не повод ли поразмыслить о качестве кода?

Ну конечно, хочется, что 99% багов, за которыми полез в отладчик, были бы сложными и плавающими. Но никто не идеален, процентов 20 — можно было найти и без отладчика, просто аккуратным чтением кода и спецификаций. А так — 99.5% ошибок находятся без залезания в отладчик на целевой системе. То есть воспроизводятся по записанным файлам и не на приборе, а в среде разработки, под windows.

случаются неинициализированные переменные в релизном коде?

я не знаю, что вы имеете ввиду под релизным кодом. Деления на дебаг и релиз у нас нет. Если вы имеете ввиду код, поставленный в прибор, отправленный заказчику, то там пример 1 баг на 2-3 года. Если вы имеете ввиду экспериментальный код, залитый в прибор на стенде — ну зависит от степени экспериментов. Сейчас вот переходил на FreeRTOS (то есть практически работаем на голом железе), ну так вплоть до 5 багов в час находилось. Ну так под линуксом у нас мегабайта 3-4 памяти потреблялось, а тут ужались до 300 килобайт. Само собой, что баги полезли.

Я уже заметил, что эта тема — частый гость в ваших комментариях.

Ну не хочется уж совсем нецензур прямым текстом выражаться. Потому и применяться аналогии. А нарком ламеров безграмотного народу тут и впрямь очень много.
+2
Беда в том, что люди с желаниями писать универсальный код там, где он не нужен, обычно выбирают С++.

Нравятся мне эти ваши «обычно».


Важно — что это ведет к лишним трудозатратам

Напоминает фигак-фигак-продакшен-дривен девелопмент.


разбуханию кода

Бинарного или исходного?


меньшей надежности действительно используемого кода

Это из той же серии, ИМХО, что и про обычность выбора C++.


Отлаживается=то все, а не только нужные 20% кода.

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


Специальная дебажная сборка — это для нас экзотика. Код или работает (98%) или уж такой тонкий баг, что в дебажной сборке его не поймать.

При этом не вы ли сидели с дебаггером чуть ранее по треду?

-6
Напоминает фигак-фигак-продакшен-дривен девелопмент.

Увы, это часто бывает у любителей С++. У них отличный код, только данные из реального мира для него не годятся.

Бинарного или исходного?

Исходного. А если наворочено на темплейтах — то иногда и бинарного.

Только, во-первых, отлаживать проще.

За счет чего?

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

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

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

С точки зрения любого АСУТП-шика — это идиотизм. С точки зрения любителя С++ — нормальный ход. позволяющий втиснуть в схему RAll то, что ресурсом не является.

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

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

Грамотные абстракции в мире АСУТП — это те, что отражают поведение железа. Чем больше вы делаете свой код повторно используемым — тем хуже вы отражаете конкретное поведение в конкретной ситуации.

Инженерный подход — он в том, чтобы сначала понять, что будет повторно использоваться, а что не будет. Потом — понять, что будет общим при разных повторно использовании, а что нужно параметризовать. А уж потом — писать нужное…

А любители С++… Выдрали первую пришедшую в голову абстракцию, написали кучу ненужного кода, а потом жалуются, что данные кривые. Вот и получается у них фигак-фигак-продакшен. Для сферической лошади в вакууме — работает, для реального ишака в упряжи — сбоит.

Разумеется, там, где речь не идет о реальном мире все проще. И когда вы код для цифровой реальности, то и шансы на повторное использование у вас выше и абстракции ваши будут более походи на реальность. А в нашей области у вас вечно будет фиг знает как называется, штука такая с одной торчащей палкой. И у других любителей С++ — тоже.

При этом не вы ли сидели с дебаггером чуть ранее по треду?

У нас довольно много разных проектов (и в разных местах я говорил про разные проекты, каюсь). Но специальных дебажных сборок нигде нет. Есть нечто среднее.
+1
Исходного.

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


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


За счет чего?

За счёт разделения ответственности, изоляции, меньшего объёма общего состояния и прочих подобных замечательных вещей.


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

Фиг знает, какой смысл вы вкладываете в слово «инженер». У меня вон в должности стоит [Senior] C++ Engineer/Researcher, скажем, я стал инженером?

-6
Если это обеспечивает большую изоляцию, то это оправдано.

Иногда. Если эта изоляция действительно нужна для дела. а не для галочки.

А то так можно, знаете, и функциями на 5 тысяч строк наслаждаться.

Можно. И очень редко — это будет оправдано. Первое, что пришло в голову — так проще при кодогенерации. То есть кормите программу алгоритмом, она выдает код на том же Си, его реализующий. И тут проще сделать все одним куском, чем учить кодогенератор разбивать на процедуры. Если не путаю — так сделан синтаксический анализатор в алголе-68. Кодогенератор кормят формализованной грамматикой, а он генерит огромную процедуру парсера на том же алголе-68.

Ещё раз. Для инженера главное — адекватность решения задаче. А не какие-то формальные критерии хорошо-плохо.

Фиг знает, какой смысл вы вкладываете в слово «инженер»

Ну если вы не видите абстракции «два крана» и называете "штука такая с одной торчащей палкой," — вы не инженер и никогда им не станете.

Инженер — это тот, кто понимает, какие требования к коду. И делает код под требования. А вы — математик. Поэтому сферическая лошадь в вакууме вам милее каурой. И брыкается, и срет и ржет…

В своей области — вы можете быть адекватны своим задачам. В нашей — фи… полное непонимание основ. И нежелание их понимать.
+1
Иногда. Если эта изоляция действительно нужна для дела. а не для галочки.

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


Можно. И очень редко — это будет оправдано. Первое, что пришло в голову — так проще при кодогенерации.

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


Ну если вы не видите абстракции «два крана» и называете «штука такая с одной торчащей палкой,» — вы не инженер и никогда им не станете.

Я описываю внешний интерфейс. А как оно там на самом деле называется, меня не очень волнует, всё равно ремонтировать это будет специально обученный человек.


Инженер — это тот, кто понимает, какие требования к коду. И делает код под требования. А вы — математик.

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

-4
Разделение ответственностей и прочие умные слова редко когда нужны для галочки.

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

То есть на первом месте — работоспособность, на втором — затребованные характеристики (модифицируемость, устойчивость, надежность...), а лишь на третьем — всякая изолированность, повторное использование и так далее.

А когда любители С++ ставят несущественные характеристики на первое место — получается плохо. Код — конфетка, классы, темплейты, все повторно использованное. Но — не работает. И работать не может. Изменить поведение классов «нельзя» — они повторно используемые. Сделать наследника тоже «нельзя» — изоляция не позволяет. «Нельзя» — в смысле автор против. :-) Ну и как водится кода больше в 10 раз, чем нужно.

И это, увы, типично. Ну как пример — ради изоляции в Windows NT 3.1 видеоподсистема (GDI) была вне ядра. Изоляция — отличная, но… производительности не хватило. В итоге — в 4.0 её >с помпой внесли в ядро. :-)

Так что изолированность — это третьестепенная характеристика, которой обычно можно пожертвовать ради более важных вещей. Думаю, что даже вы делаете нити, а не процессы. Хотя изолированность процессов — намного больше. А вот там, где изоляция важнее производительности — там делаются отдельные процессы. Самый известный пример — Chrome.

Я описываю внешний интерфейс. А как оно там на самом деле называется, меня не очень волнует, всё равно ремонтировать это будет специально обученный человек.

Да такое впечатление, что вы и пользуется «специально обученный человек». Там простая абстракция — две задвижки. Оси управления задвижками перпендикулярны и направлены под 45 градусов (вправо-вверх и влево-вверх). Если мы переходим к прямым осям, то вверх ось суммы, а вбок — ось разности.

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

Ещё раз. Очень редко — это будет оправдано. Ничего не могу сказать, не зная задачи и требований к коду. Вообще, деление на подпрограммы — не елинственный способ выделения. Например, в OMRON Ladder подпрограммы есть. Но… обычно не используются. Программа делиться на блоки, блоки — на нетворки, нетворки — на цепи. Но в принципе — это единый огромный кусок кода с общими глобальными переменными.

Если программу с Lаdder переписывать на другой язык, то скорее вредно оформлять нетворки как подпрограммы. Порядок исполнения нетворков важен, а при подпрограммном оформлении он более подвержен искажениям.

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

Тогда непонятно, почему в нашем разговоре вы их не понимаете. Вроде не сильно сложные вещи объясняю.
+1
Давай не путать — мы ненастоящие программисты. У нас многое не так.

На этом надо, наверное, заканчивать дисскусию.
+1
Напробовался. Цензурных слов нет, очень тянет блевать. я понимаю, у вас логика наркомана: да как ты можешь судить о героине, если ты 5 лет не кололся?!

Чушь. Вы так говорите, как будто за все эти годы студия не менялась. Видимо это из-за у вас такое мнение, что за 17 лет Builder C++ 5.0 не поменялся ни на грамм.

То есть случайно мышку оставил над переменной, а потом окно закрывать? Ну очередной минус VC++.

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

Они есть во всех языках, только стандарт фортрана их выделил явно.

Куда вас всё несёт? Причём тут фортран. Мы про C++ говорим.

Угу, типичное мнение любителя микрософт. я выбираю инструменты под свои задачи. И говорю, что данный инструмент плох для наших задач. А мне начинают втюхивать, что задачи у нас неправильные, код не тот, операционные системы не те, железки не такие… Ну в общем нужно все бросить, фирму закрыть и идти путем one microsoft way. Вам самому не грустно?

Я вам про одно, вы про другое. Повторю (надеюсь, всё таки смогу свою мысль донести), при решении задачи надо выбирать правильный инструмент, которым эту задачи надо решать. Но, если вы для своей задачи забивания шурупов выбрали навороченный микроскоп с функцией затягивания болтов, то это не повод называть молотки отстоем. Да у молотков есть своя область применения, и если она вам не подходит (надо не гвозди забивать, а шурупы, в данном примере), используйте другой инструмент. Но это не значит, что все другие инструменты, без так необходимой вам нестандартной функции забивания шурупов — отстой.

Упаси нас боже от этого ужаса. Лучше уж вернуться на голый Си.

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

Там, где нужна надежность — никогда не используется ничего нового.

Никогда слишком громное слово. Скорее всего вы хотели сказать, что лично вы никогда не используете ничего нового, когда нужна надёжность. И что для вас новое — это что-то моложе 10-20 лет. Просто у других людей всё может быть по другому, например, попробовал раз в одной проекте, не требующем 100% надёжности, в следующий раз можно уже и в таком проекте использовать, без необходимости дожидаться 10летней безотказной отработки этого первого продукта.

Какую связь лямбры имеют с stl-контейнерами?

А где они ещё нужны?


Опять таки, вы просто показали, что лямбды ничего не знаете, что нам было уже и так понятно.
Вот вам переписанный пример из вики (хотя пример притянутый за уши) не для контейнеров, а для С-массива:
int someList[100] = ...;
int total = 0;
std::for_each(begin(someList), begin(someList), [&total](int x) {
  total += x;
});

В общем люмбды, можно использовать как без контейнеров, так и без stl вообще.

У тех, кто выдает объект как результат функции. Например часто результатом функции бывает std::string. Вот тут экономия огромная.

«Больной, не делайте так».

Мы не используем кучу. Следовательно, мы не используем STL. Мы вообще пишем на Си с некоторыми элементами С++.

Я очень раз за вас лично. Можете и дальше так делать. Только просьба никому не доказывать, что это круто, и что все должны делать как вы.
-5
Вы так говорите, как будто за все эти годы студия не менялась.

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

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

я ровно об этом и говорю. VC++ не подходит для решения наших задач. Ещё раз и громко — НАШИХ задач. Если вам она годится — это ваши проблемы.

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

Ещё раз и громче. Студия не подходит для решения НАШИХ ЗАДАЧ.. НАШИХ ЗАДАЧ.. НАШИХ ЗАДАЧ.. НАШИХ ЗАДАЧ..

А то, что вы на пустом месте фантазируете про иные задачи — это уже ваши проблемы с пониманием смысла текста.

А если вы 20 лет поваритесь в АСТУП и embebded — вы оцените, что для наших областей наш подход верный. А для highload — верен ваш подход, не спорю. Там в чести самые свежие версии с самыми свежими багами.

Вот вам переписанный пример из вики (хотя пример притянутый за уши) не для контейнеров, а для С-массива:

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

В общем люмбды, можно использовать как без контейнеров, так и без stl вообще.

я вам страшную тайну открою, std::for_each — это STL

«Больной, не делайте так».

Увы, это стандарт С++ такой. string operator+ (const string& lhs, const string& rhs);, et cetera, et cetera… Костыль на костыле и костылем погоняет.

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

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

я в своей отрасли сам удивляюсь. Знаете, какой GPS приемник летает на современных самолетах? Характеристики уровня 1990ого года, элементная база — примерно 1975ого года. Пару лет назад сменили, теперь характеристики года 1995ого. Если интересно — могу ссылки покидать на разную технику, будете сильно удивлены. ну вот вам процессоры для затравки — это примерно Pentium II. По нашим меркам — весьма современные. Через 2 года самые слабые из них снимут с производства. А те, что помощнее — ещё лет 10 будут производиться.
+4
Да вы во своими задачами уже достали всех. Вы что реально не понимаете, что если что не подходит для ВАШИХ задач, ВАШИХ ЗАДАЧ, ВАШИХ ЗАДАЧ, то это не значит, что мы можете обсирать инструменты, которые подходят для других задач? На вашаих задачах свет клином не сошёлся.

Господи, какая кривь!!!

Не пытайтесь уйти от темы. Вам доказали что вы были неправы, надо просто написать, «да был дураком, не знал о чём писал, буду умнее. прочитаю RTFM.». А вот уводить разговор в сторону не надо. И так всем (может кроме вас, конечно) очевидно, что пример притянут за уши, и в реальности такой код никто не напишет. Это была просто иллюстрация, что лямбы не связаны с stl-контейнерами, как вы утверждали.

я вам страшную тайну открою, std::for_each — это STL

Мы уже поняли, что вы застряли в 2000-м году на C98. Неужели вы реально могли подумать, что вы кому-то открыли тайну?

Увы, это стандарт С++ такой.

Ни в одном стандарте С++ не написано. что вы обязаны делать 5 вызовов этой функции на 100 строчек кода.

я хочу сказать, что использование нового запрещено на уровне стандартов отрасли.

Раскройте тайну, как у вас появляется эта наработка на отказ, если ничего нового использовать нельзя? И даже более интересный вопрос: почему ваше железо покупают, пока оно где 10 лет безотказно не проработает. Т.е. по вашей логике, написали вы новый код. Он должен где 10 лет покрутится, иначе стандарты отрасли (слово то какой пафосное) запрещают его ставить в эксплуатацию.
-3
Ну что ж, вы скатились до ad hominem и тем самым подтвердили, что аргументов у вас нет.

В отличие от вас, я прекрасно понимаю, что любое языковое средство делается для решения своих задач. Есть области где оно годится, есть — где не годится, есть — где выглядит уродливым костылем. И только любители микрософта считают, что все должны идти строем по one microsoft way..

Раскройте тайну, как у вас появляется эта наработка на отказ, если ничего нового использовать нельзя?

В бытовых применениях испытывается. (с) Ваш К.О.
+3
Блин, опять отходим от темы в никуда.

Предлагаю вернуться в правильное русло.
Вообще под студией вы и остальные понимают 3 вещи:
— иде
— компилятор С++
— стандартная библиотека

1) Если говорить про иде, (а изначально разговор вроде про неё шёл?), то вполне себе нормальная иде, которая позволяет легко писать код, (притом любой код, хоть java; с лёгкой навигацией, с нормальным редактором, с поддержкой рефакторинга, с фичами типа IntelliSense, поддержкой VCS, моделированием, плагинной системой (можно читать как интеграций во всё, что только можно) и множества других), легко отлаживаться (по крайней мере удобно. не весь функционал windbg доступен, ну чтож, зато не перегружен и интуитивно понятен основной интерфейс. + фичи типа IntelliTrace и т.д.), позволяет подключить любой компилятор (интел сам тулсетом встаёт, clang' сами майкрософтцы допили под винду, можно этот тулсет использовать из коробки, для mingw тулсет вроде как народные умельцы сделали, использовать можно). В общем есть всё, что можно ожидать от нормально IDE и даже множко сверху. Уверен, что, иде, скажу мягко, не хуже, чем любая другая иде 17-ти летней давности.

2) компилятор: его можно тоже по нескольким параметрам рассматривать. например, поддержку стандарта, надежность (чтобы сам компилятор не падал), качество генерируемого кода в плане скорости, качество генерируемого кода и отладночной информации, чтобы потом можно было дампы с клиентов разбирать и т.д.
Так вот по этим показателям, это вполне себе современный компилятор. Я уже писал, что стандарт поддерживает даже лучше интеловского, по надёжности лучше чем gcc (возьмём для определённости) 4.9, в котором я уже начал уставать от internal complier errors. Качество генерируемого кода сейчас тоже не плохо, помню ещё vs2012 практически догнал интеловский, сейчас уже не уверен, что разница найдётся. ну и как плюс есть много нового, что ещё только на стадии включения в стандарт. Те же модули или await'ы, например.

3) здесь похожие критерии: соответствие стандарту, эффективность реализации, отладочные фишки, и т.д.
Так вот, здесь всё тоже неплохо. МС довольно сильно помешано на стандарте, правят все найденные несоответствия со стандартом довольно быстро. (на самом деле она смотрят всегда на последний драфт, ну это не важно). Все стандартные функции реализованы очень эффективно (пример, внутри memset/memcpy/и_т_д есть реализация на AVX, помимо реализации на SSE2 и помимо реализации на MMX).

Я в общем к тому веду, что обсирать студию точно не стоит, вполне, да же так, ВПОЛНЕ, себе достойный коммерческий продукт для разработки. Ну а как иде обсирать её не стоит особенно.
-1
И сразу видно, что четвертой части — системы быстрого создания GUI-прототипов просто нет. В результате я за день пишу и отлаживаю новую форму, на которую в VC++ нужно не меньше недели.

В итоге получается, что я на привычном мне билдере выигрываю от 2 до 7 раз и на написании кода и на его отладке и на изучении чужого кода. Выигрываю у тех, кто давно работает в VC++.

Личные впечатления от переноса кода под VC++ — отвратительные. Впечатления от отладки в нем — ужасные. Да, чуть-чуть не допили, ну совсем чуть-чуть, но это чуть-чуть дает скорость и удобство от отладки.

Ну представьте, что после мерседеса вы пересели на запорожец? Вроде и руль есть и тормоза и передачи переключать можно… Но явно машина не того класса…

Так что я не вижу смысла бесплодно терять время на изучение VC++. Надо именно в нем — значит скомпилюсь и отлажусь именно в нем.
+2
Пока вы за день пишите и отлаживаете новую форму в билдере, кто-то их по 5 штук за это время на Qt в студии лабает. И в ус не дует.

И да, я верю, что вы можете работать в 2-7 раза быстрее тех кто «давно работает в VC++», притом давно — это лет 17, и всё также на MSVS 6.0 с тех давних времён.

То, что вы просто похоже не знаете, как происходит разработка в студии, и при этом так о ней судите не даёт вам плюс в карму. Вот когда поработаете с ней немного, тогда ваше мнение можно будет послушать.
0
Пока вы за день пишите и отлаживаете новую форму в билдере, кто-то их по 5 штук за это время на Qt в студии лабает. И в ус не дует.

Забыл добавить: При этом, пока вы за день делаете непереносимую фигню на VCL, разработчик в студии делает кроссплатформенную фигню на Qt.
-1
Qt я не смотрел, вполне возможно, что продукты удобный. Насчет ускорения в 5 раз — не верю, пока вы не расскажите за счет чего оно достигается. Скорее всего, вы просто никогда не работали с дельфи.

Кроссплатформенность в GUI нам пока не нужна. А будет нужна — в том же дельфи можно компилировать для «Windows, Android, iOS, OS X». Так что вы просто не разбираетесь.

Но вообще я бы предпочел на мобильники и планшеты делать своё приложение, а не портировать виндовое. И задачи несколько разные и приемы работы иные и размер экрана несколько не тот… Потому на мобильники — простые экраны с 1-2 функциями, а на виндоус — сложный экран с кучей данных. Смотреть-то на мобильник будут с расстояния порядка метра (если не 2-3), как на навигатор.

Вот когда поработаете с ней немного,

Немного, это сколько? 20 лет работы и миллион строк кода? у нас два проекта на VС++, по 10-20 тысяч строк кода каждый. И ещё тысяч 30-40 строк кода адаптировано под студию. И да, это в последний раз это было VC++ 2015 (или 2013) — лень сейчас брать ключ и смотреть. Впечатление от студии — омерзительные и нецензурные.
-1
Опять вас утянуло в сторону. Ну причёт тут Делфи, когда разговор идёт про ИДЕ для разработки на C++? Вам нечего сказать по теме, поэтому всё время пытаетесь в сторону уйти?

Немного, это когда перестанете явный бред нести про неё. Я даже верю, что у вас есть пару проектов на VC, но подозреваю, что там не лично вы ими занимаются…
-5
Учите матчасть. Delphi это не только язык, но и IDE. Уже 10 лет (начиная с Delphi 2006 ) поддерживает С# и С++.

Ну да, если 20 лет есть дерьмо полной ложкой, то желание критиковать утихнет. Увы, пришлось самому с VC++ работать. Пока не работал — относился нейтрально, как поработал — так блевать потянуло так стал резким противником.
0
Вы не путаете Делфи и Developer Studio 4.0, а потом и RAD Studio?
В Develop Studio да, была поддержка разных языков в одном IDE.

А про дерьмо, вы тут уже за 3 дня довели до ситуации, когда тянет блевать.
-3
Не путаю, почитайте Фактически это одно и то же + маркетинговая путаница в названиях., Впрочем, если вам хочется их разделять — разделяйте. Можете ещё и VC# от VC++ разделять…
0
В комплекте, да, но можно поставить gcc 4.9, компилить этой версией, и потом магией сделать, чтобы он запускался на том glibc, который с 4.7.
-2
Если на систему можно принести бинарники или объектники — это система не для серьезных задач. Увы, в серьезные системы можно приносить только собственные исходники.
0
Ну, конечно, вы лучше военных всё знаете, что и как им делать. Или у них дерьмо хайлоад, а серьёзные системы только в АСУТП?
0
я просто немножко знаю, что делается в околовоенных областях (системы двойного назначения). Полный запрет на принесения всего, кроме своих сорцов.

-1

Мне нравится ваша пассивная агрессивность про ненастоящих программистов в сочетании с проскакивающими перлами вот типа этого про серьёзные задачи.

-2
В очередной раз ругаетесь, что реальный мир не соответствует ваших представлениям о нем? :-) Лично вы можете делать с МСВС все, что угодно, Хоть ядро пересобрать. Но только после этого пропадет сертификация. А единственное, что можно сделать без лишения сертификации — это собрать свой собственный код из сорцов.
0
В очередной раз ругаетесь, что реальный мир не соответствует ваших представлениям о нем? :-)

Вы точно со мной разговариваете?


Лично вы можете делать с МСВС все, что угодно

Спасибо! Предпочту с ней не касаться даже восемнадцатиметровой палкой.

+2
А вообще мы уже слишком отошли от темы.
Я что хочу заметить, PVS больше всего ошибок находит как раз в C-style коде. Так как мы уже полностью ушли от malloc/free/strcpy/strcat/printf/memcpy/ и даже от delete/new, то 2/3 диагностик к нам уже не применимо, так опечатки где-то отлавливает, или муть в условиях.
А вот вам, учитывая «Мы пишем на Си с отдельными элементами С++.» этот инструмент может оказаться гораздо более эффективным. Рекомендую, пока сотрудникам поставить триалки, пусть даже пока скрыть все ворнинги, которые уже есть на данный момент, и поработать пару месяцев на инкременталке. Если за пару месяцев триальные клики закончатся, то этот инструмент вам явно нужен.
0
А зачем вообще нужны клики? есть лог, по нему ошибки и анализируются.
0
При клики я написал в том смысле, что если за пару месяцев нашлось больше 20 свеженаписанных ворнингов 1 уровня, то инструмент будет полезен именно для инкрементального анализа.
А по логу, соглашусь с авторами, это уже не так интересно, так как даже если проверять периодически, то что-то уже будет попадать в основную ветку, тратиться время тестирования и т.д. Лично я лог рассматриваю как проверку, что никто не отключил статанализ, или не забил на него.
0
В этом смысле согласен. 10 найденных ошибок в месяц — достаточно полезно.
А проверка по логу простая. Лог предупреждений должен быть пустым. Если он не пуст — надо исправлять код. Иногда — отменой предупреждения, но исправлять.
0
И ещё. Надежность программы и количество ошибок — это не одно и то же. В некий момент стоит просто признать, что ошибки в программе есть и будут, но работать она должна независимо от наличия ошибок. И вот тогда приходит понимание, как из ненадежных элементов делаются надежные системы.
+1
В принципе соглашусь, с небольшими исключениями.
1) Есть системы, где декларируемое время простоя может быть сильно ограничего. Например, для АТС помню, в северной америке в полиции downtime был всего 7 минут в год. Т.е. 7 минут, на все падения, переключения на failover, и т.д. И даже на установку нужных апдейтов отдельного времени не давалось. Даже если типичное время переключения на другую ноду всего 30 секунд, то это максимум 14 сбоев в год (в реальности 2-3). В больницах помню, что-то около 30 минут в год было, уже неплохо.
2) есть функциональность, которая может просто работать неправильно. Например, неправильно собираем RTP поток с удалённого устройства, или какая бага у тебя в реализации RTSP/SIP/другой протокол. И воспроизводится она только с железками такого-то бренда, если у него такие-то настройки на такой-то версии фирмваре. И тут, хоть обзапускай сервис, хоть обпереключайся между серверами, а, скажем, RTP поток ни один из сервисов, ни на одном из серверов, собрать правильно не сможет.
Я к тому, что качество кода, всё-таки это играет определённую роль.
0
Ну функциональность, которая не работает с одним из брендов, обходится просто — данный бренд не включается в список оборудования, сертифицированного для работы с программой. :-) Особенность мира АСУТП — программеры могут диктовать, какое оборудование закупать для их системы

И даже на установку нужных апдейтов отдельного времени не давалось.

А зачем оно? Ставим апдейт на ноду теплого резерва, потом выводим её в горячий резерв, а из ноду горячего — в теплый.

Даже если типичное время переключения на другую ноду всего 30 секунд

Типичное время переключения в горячем резерве — микросекунды. Ну как предельный пример — четырехпроцессорный Simatic для АЭС. Два процессора через два модуля ввода-вывода получают одни и те же сигналы. При рассогласовании процессоров (аппаратная проверка каждый так) идет переключение на вторую пару. В софте подобные подходы спасают не всегда, но довольно часто.

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

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

Типичное время переключения в горячем резерве — микросекунды.

Это да, только в часто ноды, которые в горячем резерве и падают одновременно :-). Ну а дальше начинается, что дублировать каждый сервер клиент не в состоянии финансово, поэтому есть некий кластер, с N рабочими серверами и с M резервными (N >> M). И переключение на резервный сервер уже не микросекунды занимает, и даже не миллисекунды. Да, 2N серверов, часто встречается, только в идеальном мире, да в мечтах разработчиков.
0
Так то бывает, что проблема не находится на стадии тестирования, а всплывает только у клиента.

В АСУТП?! Проект делается под клиента и его оборудование. Коробочные продукты — это только полуфабрикаты. После комплексной отладки у клиента ещё идет стадия опытной эксплуатации, потом опытно-промышленной. НеЮ бывает, что сразу в опытно-промышленную эксплуатацию проект ставится. Но это некий высший пилотаж.

Да, 2N серверов, часто встречается, только в идеальном мире, да в мечтах разработчиков.

ну и в АСУТП. Там даже люди часто дублируются. Ибо что делать, если у дежурного острый аппендицит прямо на смене? Значит нужна горячая замена.

Это да, только в часто ноды, которые в горячем резерве и падают одновременно :-)

А вот это уже задница очень плохо. По хорошему вводится деградация с отключением неработоспособной части, но я понимаю, что совсем везде её не сделать
+1
АСУТП тоже всякий бывает. Одно дело АЭС какая по производству электроэнергии, а другое дело подвальный конвейер по производству зубных щёток. Да и мир софта АСУТПом не ограничивается. Так что этот подход (пусть хоть куча говнокода, у нас же резервирование 3 этапное) применим только в сравнительно небольшой области. Что, конечно же, не отменяет факта, что само резервирование делать нужно, т.е. по крайней мере возможность такая быть должна для клиентов, которым это важно.
-3
А это у вас опять вредное влияние VC++. Нету в VC++ конструкция try...finaly — значит обеспечивать надежность можно делать только на уровне компов. Не может микрофсот уже 25 лет сделать, чтобы Word не вылетал с потерей набранного текста — значит нужно всем запретить писать надежно. ну или обозвать надежное написание гавнокодом.

Надежное написание требует примерно 30% от стоимости проекта. Дело не в гавнокоде, а в том, что когда период обнаружени я ошбок больше месяца — это не означает, что ошибок в системе нет. Есть! И довольно много: 1-2 на тысячу строк кода. Просто выискивать их все займет десятки лет.
+2
А это у вас опять вредное влияние VC++. Нету в VC++ конструкция try...finaly — значит обеспечивать надежность можно делать только на уровне компов.

Кто только что возмущался (предъявлял это студии) на тему использования не стандартных, не переносимых конструкций? Ну нету finaly в стандарте. И не найдёте вы её, не в gcc, ни в clang'e, ни в icl.
А если серьёзно, то в студии есть поддержка виндовых SEH'ов, в том числе и __try/__catch/__finally.
А если ещё более серьёзно, то уже давно (видно 19 лет назад об этом не знали, но вот 18 назад уже точно было :-) ) люди додумались до RAII. Так что проблема с отсутствием finaly в стандарте C++ сильно преувеличена (именно поэтому и отклонили внесение finaly в стандарт).

Не может микрофсот уже 25 лет сделать, чтобы Word не вылетал с потерей набранного текста

Чёрт, у меня Word на работе последние 5 лет не вылетал ни разу (при том обычно открыто 5-10 документов), в отличие от OpenOffice дома. ЧЯДНТ?

Надежное написание требует примерно 30% от стоимости проекта. Дело не в гавнокоде, а в том, что когда период обнаружени я ошбок больше месяца — это не означает, что ошибок в системе нет. Есть! И довольно много: 1-2 на тысячу строк кода. Просто выискивать их все займет десятки лет.

Вот это адекватная фраза, с ней сложно не согласится.
-4
Ну нету finaly в стандарте.

Есть-есть… Просто это не С++, а Objective C.. ну или java или delphi.
люди додумались до RAII.

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

Чёрт, у меня Word на работе последние 5 лет не вылетал ни разу

я видел человека, не перезагружавшего Win95 месяцами при дюжине постоянно запущенных программ. Будете на основе этого превозносить Win95 как безглючную систему?
0
Есть-есть… Просто это не С++, а Objective C… ну или java или delphi.

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

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

Вообще не понял, причём тут LIFO. У всех годиться, а тут видите ли нет.

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

Ну вот видите, а вы всё майкрософт ругаете. Видно же, что вы неправы :-)
-1
Вообще не понял, причём тут LIFO. У всех годиться, а тут видите ли нет.

RAll придумали для захвата ресурсов. Чтобы избежать deadlock используется LIFO. Это все абсолютно разумно для многопоточных приложений. И неразумно в жизни, где LIFO не соблюдается.

Если на школьном уровне — «Захватили ложку, захватили вилку, отдали вилку, отдали ложку» ложиться на RAll. А вот наоборот («Захватили вилку, захватили ложку, отдали вилку, отдали ложку) — это уже не RAll, Потому что для RAll области действия объектов должны быть вложенными. А тут они пересекаются, но ни одна из них не вложена в другую. На этом уровне понятно?

Ну вот видите, а вы всё майкрософт ругаете.

Люди настолько хорошо дрессируемы, что приспосабливаются не только к микрософту.

62 килобайта оперативной памяти, машина М-6000 в режиме разделения времени. 5 терминалов, за которыми отлаживаются программисты. диспетчера памяти нет, защита памяти — только 2килобайт загрузчика, и то — прибиваемая. Каждый новый сотрудник приводил к нестабильности системы (3-4 перезагрузки в день) на срок 2 недели. А через 2 недели — опять как утром загрузились так до вечера работаем.

Кстати, если вы читали Ли Вон Яна, то оно, похоже, как раз там писалось. Конечно не мной, а моим шефом.
+1
Если на школьном уровне — «Захватили ложку, захватили вилку, отдали вилку, отдали ложку» ложиться на RAll. А вот наоборот («Захватили вилку, захватили ложку, отдали вилку, отдали ложку) — это уже не RAll, Потому что для RAll области действия объектов должны быть вложенными. А тут они пересекаются, но ни одна из них не вложена в другую. На этом уровне понятно?
На этом уровне понятно — непонятно с чего вы решили, что try… finally вас спасёт. Он точно также предназначен для вложенных действий над объектами. Причём в отличие то RAII (где отход то простого LIFO у вас всегда очевиден и нагляден, так как одному объекту приходится управлять несколькими сущностями с хитро вложенными временами жизни) в случае с try… finally конструкции с вложенными временами жизни и конструкция с обычным LIFO и хитрыми вариантами с впуском-выпуском выглядят одинаково (люди ленивы, а 10-вложенные try… finally «некрасиво выглядят») и вопросы типа «а что делать если во время подготовительных операций к закрытию выпуска произошло исключение — впуск-то закрывать или нет?» внимания не привлекают.
-6
По опыту — спасает. Причем с сохранением наглядности и компактности кода. 10 вложенных try в одной процедуре не помню, 5-6 бывает. Дело в том, что на каждый try...finally ещё пишется try..except. А ленивые — это не к АСУТП, это ко всяким процессорам со 128ядрами… В АСТУТП ленивым не место.

В любом случае, RAll предназначен для захвата ресурсов. А для всех остальных целей — это костыль. Предназначение try — работа с исключениями.

Если мы ради RAll разнесли единую технологическую операцию по трем разным кускам кода о какой читаемости можно говорить?!
0
Если на школьном уровне — «Захватили ложку, захватили вилку, отдали вилку, отдали ложку» ложиться на RAll. А вот наоборот («Захватили вилку, захватили ложку, отдали вилку, отдали ложку) — это уже не RAll, Потому что для RAll области действия объектов должны быть вложенными.

move-ните объект, описывающий ресурс, из внутреннего скоупа во внешний, тоже мне проблема.


А, у вас же C++11 нинужно, какая ещё move-семантика, действительно, это ж только чтобы строчки двигать и копирования избегать надо.

-3
Вы хотите сказать, что увидев семантику move, компилятор просчитает, при каких условиях она выполняется, и в этих случаях вызовет деструктор в другом месте? :-) гм, ну скорее грустно, чем смешно. На самом деле, вы видимо хотите приделать .RAll объекту кроме деструктора и конструктора ещё и флаг — выполнять ли действия в деструкторе. Таким образом, вместо RAll у вас будут два одинаковых объекта (отличе лишь во флагге), только в одном из них выполняется конструктор, а в другом деструктор.

Ну в общем костыль на костыле и костылем погоняет. Как многое и многое в современном С++.

Хороший пример цепочки костылей
  • Костыль «объекты живут не только в куче»
  • Раз не только в куче — пришлось делаььб костыль выдачи объектов как результата функции
  • Выдача происходит плохо — ввели костыль семантики копирования
  • Опять хреново — сделали семантику перемещения.


А если бы объекты жили только в куче — все было бы проще. И функции могли бы выдавать только ссылки на объекты.

Но увы, мне это тоже было не очевидно в 1990ом году.

Это одна из причин, почему мы пишем на Си с элементами С++. А не на С++.
+1

Ну почитайте, как unique_ptr работает. Или *stream. Они все movable, но не copyable. Да, внутри будет флаг, проверяемый в деструкторе, или идемпотентное закрытие состояния (хотя не уверен, что оно существует для закрытия клапана), или мало ли.


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


А если бы объекты жили только в куче — все было бы проще.

Только куча медленная, стек быстрый, а escape analysis — штука ненадёжная, и не с плюсовой системой типов.


Это одна из причин, почему мы пишем на Си с элементами С++. А не на С++.

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


Но это такое.

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

Чушь собачья! Полное непонимание нашей предметной области! Код в деструкторе — одноразовый, применим только для данной технологической операции… В этом отличие реального мира от абстрактных сущностей (ресурсов). Сильных отличий два:
  • часть освобождения (finally, деструктора) уникальна для каждой операции
  • часть захвата (конструктора, try) не атомарна и тоже уникальна

В итоге RAll — это багоопасный костыль. Код из одной процедуры расплывается по 2-3 местам. Ну поймите вы, что реальный мир и математические абстракции вроде ресурсов — разные вещи. Мы не захватываем дверь — мы её открываем или закрываем.

Да, внутри будет флаг, проверяемый в деструкторе

И это ещё один костыль.

Только куча медленная, стек быстрый, а escape analysis — штука ненадёжная, и не с плюсовой системой типов.

Поэтому структура с методами и объект — должны быть несколько разными вещами.

Опыт показывает, что у говорящих так людей основная причина неписания на плюсах — отношение к плюсам как к С с классами

я не утверждаю., что С++ плохой язык. Но он очень не походит к нашей области. Не верите — попробуйте сами. У нас есть задачи, которые мы готовы дать на аутсоринг. Но готовьтесь к тому, что большая часть плюсовой библиотеки просто не влезет в ПЗУ.
0
Чушь собачья! Полное непонимание нашей предметной области!

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


Код в деструкторе — одноразовый, применим только для данной технологической операции…

Разделите код, отвечающий за перемещение RAII-объекта, от самого RAII.


Код из одной процедуры расплывается по 2-3 местам.

Тесно связанные, при этом.


Поэтому структура с методами и объект — должны быть несколько разными вещами.

Зачем? У нас же всё, вообще всё на куче живёт согласно вашему предложению, разве нет?


Но готовьтесь к тому, что большая часть плюсовой библиотеки просто не влезет в ПЗУ.

Плюсовой библиотеки чего?


Не, под attiny я тоже код собирал с -fno-exceptions -fno-rtti, но упомянутые мной вещи того не требуют.

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

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

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

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

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

А все остальные задвижки — в совсем других местах. У вас всего один анус с клапаном. И процедура управления анусом — совсем не то, что управление уретрой. Хотя вроде и там и там — задвижка. Ну то есть сфинктер. А в пищеводе — оно совсем иначе. И вообщем-то там даже и не сфинктеры.

Вот так и на заводе. Зачем заводу два ануса? У него один. А все прочие трубы — имеют другое назначение. Все технологические операции до и после закрытия задвижки уникальны: транспарант зажечь, проверить наличие рабочих в опасной зоне, давление стравить, масло проверить. Было бы все однотипно — вы могли есть через анус и испражняться через рот. Ну вот и подумайте, почему вы этого не можете. И завод тоже не может.

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

Так, на аналогиях, понятней стало? Если нет — то просто запомните, что голова — это не ягодица, хотя и очень похожа по форме.

Тесно связанные, при этом.

Угу. :-( Это дополнительно ухудшает и написание и модернизацию. Технологические операции нужно один куском писать. Причем так, чтобы логика была понятна технологу. А хотите багов — распихивайте тесно-связанные куски по разным местам кода. Рано или поздно рванет, гарантирую.

Зачем? У нас же всё, вообще всё на куче живёт согласно вашему предложению, разве нет?

Затем, что это совсем разные сущности. Есть записи — это строки СУБД или записи на перфокартах или магнитной ленте… Добавление к ним методов не меняет их сути. А есть объекты. Это такая умная штука со скрытыми потрохами. У объекта есть несколько интерфейсов (пропертей, методов), но все самое важное — под капотом.

А вообще почитайте описания. Я вам собственно основы delphi излагаю.

Плюсовой библиотеки чего?

Например текстового ввода-вывода. Никогда не думали, сколько стоит std::cout << «Hello, world!\n»?

+1
Нету повторно используемого кода в технологических операциях. Нету… А там, где есть похоже оборудование — повторно используются технологические операции целиком. Ну вот как руки у вас более-менее одинаковые, а суставы — разные.

Есть. try/finally, в конце концов, тоже разворачивается в некоторый код компилятором, который вы, внезапно, повторно используете.


А в пищеводе клапаны тоже сфинктерами называются, кстати.


И ложные аналогии &mdash; это как котята с дверцами.


Угу. :-( Это дополнительно ухудшает и написание и модернизацию. Технологические операции нужно один куском писать. Причем так, чтобы логика была понятна технологу. А хотите багов — распихивайте тесно-связанные куски по разным местам кода.

Почему по разным? Они пространственно тесно связанные.


Ну, как вы в shared_ptr можете передать новый указатель и функцию для его удаления прямо рядом, на подряд идущих строчках. Да, сущности разные, но очень рядом, и поддерживать просто, ничего не размазывается.


Затем, что это совсем разные сущности.

Причём тут куча? Мы же о куче изначально говорили. Я не успеваю за полётом вашей мысли.


А так &mdash; не, спасибо, один из двух моих любимых языков вообще не имеет никаких объектов, только функции и структуры данных.


Например текстового ввода-вывода.

Зачем оно мне на attiny?


Никогда не думали, сколько стоит std::cout << «Hello, world!\n»?

Думал. И сколько стоит std::cin/ifstream, тоже думал. Оказывается, кстати, что чуть меньше, чем fscanf, но не суть. Когда мне нужна производительность и оптимизация работы с памятью, я беру mmap и boost::string_view, и получаю, благодаря реюзабельности кода, ориентированного на строки только для чтения… ой, да не, это ж шаблоны, это всё нинужно опять.

-4
Есть. try/finally, в конце концов, тоже разворачивается в некоторый код компилятором, который вы, внезапно, повторно используете.

Уровень вашего понимания понятен. try finally -это не технологическая операция. Если вы не можете отличать операции реального мира от операций с программными объектами — мне вас очень жаль.

Почему по разным? Они пространственно тесно связанные.

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

Думал. И сколько стоит std::cin/ifstream, тоже думал. Оказывается, кстати, что чуть меньше, чем fscanf

Ого, как много! мы даже printf в мелком embeded используем свой, на сотню строчек. А не системного монстра.

Когда мне нужна производительность и оптимизация работы с памятью, я беру mmap и boost::string_view

А когда она нужна мне, я придумываю свой велосипед, который ускоряет от 10 до 1000 раз. И не заморачиваюсь на копеечных оптимизациях.
+1
Уровень вашего понимания понятен. try finally -это не технологическая операция. Если вы не можете отличать операции реального мира от операций с программными объектами — мне вас очень жаль.

Я вообще солипсист и не знаю, что за реальный мир такой.


А если серьёзно, почему try/finally не технологическая операция, а BOOST_SCOPE_EXIT и подобные вещи — внезапно технологическая? Там очевидный изоморфизм вообще-то.


Сотня-две строк технологической операции, и вне её — деструктор с вызовом закрытия задвижки.

Деструктор с вызовом переданного функтора. А функтор и где-то поближе к инициализации ресурса операции можно запихнуть.


Ну в самом-то деле.


Ого, как много! мы даже printf в мелком embeded используем свой, на сотню строчек. А не системного монстра.

Рад за вас. А мне бы пару гигабайт с диска считать и распарсить побыстрее.


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

Куда уж быстрее memory mapped files и отсутствия копирования из кернелспейса в юзерспейс вообще, ленивой подгрузки данных, когда надо, и эффективного пейджаута (память на хипе надо сбросить в своп сначала, память из mmap можно просто тупо выкинуть, она и так уже на диске есть).

-5
А если серьёзно, почему try/finally не технологическая операция

По определению.

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


Конечно, я выразил свою мысль не очень грамотно, поэтому повторю.

Сами технологические операции (завинтить винт, закрыть задвижку, зажечь транспарант) — вполне стандартны и обычно исполняются готовыми функциональными блоками (объектами или процедурами).

А вот техпроцесс записывается без повторно используемого кода. Если оборудование одинаковое — использует техпроцесс целиком, просто с привязкой к другим входам и выходам.

Но записываем мы техпроцесс только так, как его нам дал технолог. Потому что любая отсебятина с повторным использованием — чревата проблемами. Включая, в том числе и аварии с человеческими жертвами. Технолог — может сгруппировать технологические операции в комплексную технологическую операцию. А программист на это права не имеет.

А мне бы пару гигабайт с диска считать и распарсить побыстрее.

Это совсем иная область.

Куда уж быстрее memory mapped files

Сколько процентов времени занимает загрузка страниц из файла? Если 50% — можно ускорить почти в два, ведя загрузку одной нитью (prefetch). а обработку другой.

Ещё один финт ушами — динамическая кодогенерация под конкретную задачу. В 1993ем на году мы на этой технике достигли скорости полнотекстового поиска в 10 тысяч записей в секунду, что было лишь в полтора раз медленней скорости диска. Это под MS-DOS на I386. Второй финт был в том, что поиск велся по запакованным полям без их распаковки. Это в пару раз ускоряло чтение и сам поиск. Автором сего чуда был Антон Москаль, более известный по Паскаль-Москаль и TMT-паскаль, а я там так — прикладной код писал и баги ядра отлавливал.
+1
По определению.

Вы бы лучше на вопрос отвечали, а не на выдранный из него кусок.


А самый главный вопрос, впрочем, устраивает ли вас такое изоморфное преобразование try/finally в что-то RAII-подобное, или нет.


Сколько процентов времени занимает загрузка страниц из файла? Если 50% — можно ускорить почти в два, ведя загрузку одной нитью (prefetch). а обработку другой.

Нет, на синхронизацию больше времени убьёте, если обработка достаточно дешёвая.


Да и readahead в ядре при последовательном чтении очень неплохо справляется.

-4
А самый главный вопрос, впрочем, устраивает ли вас такое изоморфное преобразование try/finally в что-то RAII-подобное, или нет.

В исходном коде — нет. Преобразованиями должен заниматься компилятор. А человек — писать так, как ему понятней. Понятней написание технологического процесса сверху вниз. Вы пример попробуйте записать. Вместо чтения 1-2-3-4 у вас получится что-то 3-1-4-2.
Нет, на синхронизацию больше времени убьёте, если обработка достаточно дешёвая.

Синхронизация там простейшая — первый тред атомарно пишет текущий адрес, второй его читает. Видимо под синхронизацией вы имели ввиду переключение контекстов между тредами. Чтобы не терять на нёе время — запустите prefetch на другом ядре.
Да и readahead в ядре при последовательном чтении очень неплохо справляется.

Ну если у вас linux и никуда переносить не надо — то вы правы. А если нужен перенос? Кроме того, сомневаюсь, что linux закачает вам кэши L2 и L3, не говоря уже об L1. На некоторых алгоритмах, линейно идущих по файлу, можете выиграть очень прилично, вплоть до половины отношения времени загрузки из памяти к времени загрузки из кэша.
0
В исходном коде — нет. Преобразованиями должен заниматься компилятор.

Это уже другой вопрос. Главное &mdash; придти к согласию, что такое преобразование по крайней мере корректно.


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

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


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

Нет.


Чтобы не терять на нёе время — запустите prefetch на другом ядре.

Кэшу поплохеет, по опыту.


Ну если у вас linux и никуда переносить не надо — то вы правы. А если нужен перенос?

Если будет нужен &mdash; буду смотреть на конкретную целевую систему и думать, как там сделать быстрее.


Вот самое забавное в свете всей дискуссии &mdash; сейчас вы предлагаете обобщённое решение в том месте и в том контексте, который обобщить, скажем так, весьма трудно.


Кроме того, сомневаюсь, что linux закачает вам кэши L2 и L3, не говоря уже об L1.

Префетчер в процессоре сам всё закачает, ядру достаточно просто класть прочитанные страницы, ну, как есть, постранично, оно по определению будет последовательным.

-3
Главное — придти к согласию, что такое преобразование по крайней мере корректно.

Преобразование вообще-то в обе стороны работает. А чтобы понять, что важнее — глянем в код. Вызовы деструкторов компилятор генерирует? Значит есть часть finally.

А дальше мы имеем смешную ситуацию. Для лямбды вы видите удобство в написании кода в точке вызова. А для try..finally — вы почему-то за обратное, за вынесение кода вверх, выше try. Будьте уж логичны, не нравится написание кода в точке выполнения — объявите тогда лямбды злом. :-)

Ситуация одинаковая — и лямбды и try-finally удобнее для одноразового кода. А для повторного использования — RAll и обычные классы с operator().

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

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

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

Что??? Первый тред занимается обработкой. И работает независимо от других тредов (в том числе и в их отсутствие). Текущий обрабатываемый адрес записывается в глобальную переменную atomic_t. Второй тред читает данные на некотором смещении от этого адреса и тем самым заносит их в кэши L2 и L3. Возможен и третий тред, делающий загрузку отмапленных страниц в память. Где тут потери на синхронизацию?!

Префетчер в процессоре сам всё закачает,

Можно ссылочку на технологию префетчинга данных? Ну и на каких процессорах она есть.

Если будет нужен — буду смотреть на конкретную целевую систему и думать, как там сделать быстрее.

Разумно. Это как раз инженерное решение. Жалко, что в иных местах вы его отвергаете.

+2
А дальше мы имеем смешную ситуацию. Для лямбды вы видите удобство в написании кода в точке вызова. А для try..finally — вы почему-то за обратное, за вынесение кода вверх, выше try. Будьте уж логичны, не нравится написание кода в точке выполнения — объявите тогда лямбды злом. :-)

Нет никакой конкретной точки вызова, любой стейтмент внутри блока теоретически может быть точкой вызова (если исключение кинет, например). Я пишу код подчистки в начале блока, вы — в конце, вот и вся разница.


И да, изоморфизм — он, внезапно, в обе стороны. Не понимаю, почему «вообще-то».


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

Так, подождите. Вот у вас есть два треда, один файл читает, другой, для простоты, идёт по замапленному и делает всем найденным строкам-похожим-на-числа atoi и складывает их в массив. Что тут кто куда атомарно писать будет?


Можно ссылочку на технологию префетчинга данных? Ну и на каких процессорах она есть.

Во-первых, когда вы читаете следующую порцию данных, вы зачитываете все 64 байта в кешлайн.
Во-вторых, если вы читаете в цикле, то ближе к концу той итерации, что идёт по последнему элементу в текущем кешлайне, бранч предиктор при спекулятивном выполнении следующей итерации вполне может подгрузить следующие 64 байта. Это согласовывалось с результатами профайлинга и с тем, что _mm_prefetch (или как её там, из SSE) особо ни на что не влияла.


Это всё на этом моём тяжёлом и горячем, но горячо любимом x86.

-4
Нет никакой конкретной точки вызова, любой стейтмент внутри блока теоретически может быть точкой вызова

Теоретически и крокодилы летают. Только низенько-низенько. Практически у нас будет goto к точке finally и вызов деструкторов только в ней. Можете сами убедиться. Размотка стека — по вкусу, или до goto или в finally.

А тут ещё один момент. я люблю писать код, который слабо нуждается в оптимизации. То есть у меня -O1 от -O2 отличается на проценты, а -O3 часто хуже -O2. А у вас в коде без оптимизации скорость падает в разы. Опять-таки, это старая школа — раньше советовалось не рассчитывать на оптимизатор, а писать эффективно.

Так, подождите. Вот у вас есть два треда, один файл читает, другой, для простоты, идёт по замапленному и делает всем найденным строкам-похожим-на-числа atoi и складывает их в массив. Что тут кто куда атомарно писать будет?

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

Это всё на этом моём тяжёлом и горячем, но горячо любимом x86.

А у нас прибор в рубке стоит. И при шторме — на него может пара кубометров воды вылиться. Или полкуба льда из снежно-ледового заряда. Так что герметичен — до упора. В итоге используются только холодные процессоры, то бишь прежде всего ARM. В outdoor-исполнении иногда всякие наследники 80186 используют. Из более современного — только Intel Atom или Geode. Так что горячие процессоры — это не к нам.
+3
Практически у нас будет goto к точке finally и вызов деструкторов только в ней. Можете сами убедиться.

Вы определитесь, вы про написание кода в точке вызова или про то, что там компилятор сгенерирует?


А тут ещё один момент. я люблю писать код, который слабо нуждается в оптимизации. То есть у меня -O1 от -O2 отличается на проценты, а -O3 часто хуже -O2.

Но зачем?


Опять-таки, это старая школа — раньше советовалось не рассчитывать на оптимизатор, а писать эффективно.

Потратив на 400% больше времени (цифры взяты из вашего соседнего комментария).


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


Тред, идущий по замапленному давайте назовем основным. Он кладет обрабатываемый адрес в переменную.

Расшаренную между тредами? Поздравляю, у вас уже затраты на синхронизацию кешей. ЕМНИП в современных i7 только L3 общий для всех, L2 уже нет.


Треды мапинга и выборки в кэш этот адрес читают и работают с адресами несколько больше указанного.

И тут внезапно тред маппинга затормозил (ну, с IO проблемы какие, или БД, крутящаяся на этой же машине на этом же диске, весь IO заняла, да мало ли). Как основной тред узнает, что дальше лежит мусор, потому что тред маппинга не успел?


Так что горячие процессоры — это не к нам.

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

-4
Вы определитесь, вы про написание кода в точке вызова или про то, что там компилятор сгенерирует?

Про кодогенерацию, конечно.

Я предпочитаю писать человекопонятно, а потом прогнать профайлером

Как правило, читаемый код весьма эффективен. Лишнее наворачивание уровней абстракции как раз ухудшает читаемость.

Но зачем?

Затем, что я руками могу написать алгоритм, который эффективней в разы, иногда в 1000 раз. А надежда на оптимизатор дает лишь проценты. Да и не на всех платформах есть хорошая оптимизация. Как думаете, кто-нибудь сделал оптимизацию на NeuroMatrix? :-)

Как основной тред узнает, что дальше лежит мусор, потому что тред маппинга не успел?

А зачем? Не успел — значит будет загрузка страницы при первом обращении к ней. Это быстрее, чем ожидать треда маппинга, который делает то же самое.

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

Не, вы только свои методы разработки нам навязываете. Увы, вы не понимаете, что цифровой мир и мир реального железа — это разные миры. В том же мире бизнес-логики — повторно используемый код намного более полезен, чем в мире embded и АСУТП. И шансы на повторное использование там сильно выше. И цена универсальности ниже.
+2
Про кодогенерацию, конечно.

Но в случае лямбд-то речь о написании кода, а не о кодогенерации!


Как правило, читаемый код весьма эффективен. Лишнее наворачивание уровней абстракции как раз ухудшает читаемость.

В моей практике это правило по какой-то причине не выполняется. Видимо, действительно сильно разными вещами занимаемся.


Затем, что я руками могу написать алгоритм, который эффективней в разы, иногда в 1000 раз.

Оптимальный алгоритм &mdash; это одно. Оптимальное представление этого алгоритма в виде исходного кода &mdash; совсем другое.


А зачем? Не успел — значит будет загрузка страницы при первом обращении к ней. Это быстрее, чем ожидать треда маппинга, который делает то же самое.

Во-первых, как это вы из режима пользователя будете управлять такими атрибутами страницы?


Во-вторых, ещё немного, и вы переизобретёте readahead, который уже есть в линуксе.


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

Вовсе нет. Что именно я делаю, я уже писал где-то в этом треде.

-3
В моей практике это правило по какой-то причине не выполняется. Видимо, действительно сильно разными вещами занимаемся.

Возьмите человека из своей области, зарабатывающего больше вас в несколько раз. И сравните читаемость кода. Чем более код читаем — тем выше уровень программиста и выше оплата.

Оптимальное представление этого алгоритма в виде исходного кода — совсем другое.

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

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

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

Во-первых, как это вы из режима пользователя будете управлять такими атрибутами страницы?

В чем проблема? Как загрузить страницу в память? В linux — mlock, в Windows — VirtualLock, Когда не нужна — разрешить выгрузку из памяти.

Во-вторых, ещё немного, и вы переизобретёте readahead, который уже есть в линуксе.

Ну вообще-то не везде есть linux, :-) На машинку с 300 к памяти его не запихнешь. :-) Да и не только linux есть на свете, бывает ещё freeBSD, QNX, даже MS-DOS…

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

Но бывает и наоборот, см. известную историю с OS/360 и VM/370. VM/370 управляла подкачкой настолько хорошо, что OS/360 лучше работала под ней, чем на голом железе.
+1
Возьмите человека из своей области, зарабатывающего больше вас в несколько раз. И сравните читаемость кода. Чем более код читаем — тем выше уровень программиста и выше оплата.

Вы не поверите, но там те же абстракции, темплейты и прочее счастье.


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


Зависит от критериев оптимальности.

Мы обсуждали эффективность реализации с точки зрения производительности, разве нет?


В чем проблема? Как загрузить страницу в память?

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


Ну я уже говорил, что вы readahead изобретаете.


Ну вообще-то не везде есть linux, :-) На машинку с 300 к памяти его не запихнешь. :-)

Но там мне и гигабайтные файлы читать не надо, как правило.


бывает ещё freeBSD

И там readahead тоже есть, ЕМНИП.


QNX

Скорее всего, это никогда не нужно портировать на QNX.


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

Зато можно оценить, насколько вы близки к наиболее эффективному решению задачи. Если, условно, вам нужно просмотреть почти каждый байт, файл имеет размер 4 гигабайта, а скорость до диска &mdash; 100 мегабайт в секунду, то решение, делающее работу за 45 секунд, почти достигает теоретической границы в 40 секунд.

-3
Вы не поверите, но там те же абстракции, темплейты и прочее счастье.

Угу, а ещё и ровно те же буквы и цифры. :-) Те же, но не такие же. Код намного читабельней. Сравните код eigen c кодом из STL — увидите разницу в классе. Код eigen — адекватен задаче. Код STL — нет. Или задача у его авторов совсем иная была или писать хорошо они не могут.

Мы обсуждали эффективность реализации с точки зрения производительности, разве нет?

Нет. У нас RealTime. Производительность бывает трех видов: недостаточная, достаточная и избыточная. В идеале — избыточная. От ускорения на 20 (или даже 50) процентов ситуация не меняется.

Ну какая разница процессор занят 6 или 4 процента времени? Все равно на пике хватит. А если процессор занят 90% времени, то нам не поможет ускорение на 50%, все равно процессор будет занят 60% времени и на пике этого не хватит.

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

А от кодирования нам важнее не скорость, а совсем иные характеристики. Например — поведение при отказах, читаемость, адаптируемость.

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

Ровно так же, как и раньше — это дело ОС.

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

я рад, что у вас наконец-то проснулось инженерное мышление. :-) Да, свой собственный readahead хорош тем, что мы можем портировать его куда угодно. И у нас есть шансы портироваться на всякие странные архитектуры. И заточка на конкретный linux для нас хуже, чем универсальное решение. А ваш код — действительно никуда переноситься не будет и универсальность вам не нужна.

Если, условно, вам нужно просмотреть почти каждый байт, файл имеет размер 4 гигабайта, а скорость до диска — 100 мегабайт в секунду

Мама!!! Вы уверены, что скорость "до диска" это и есть скорость диска? Мда… инженерная культура у вас....:-(
0
Не рассказывайте сказок, а? try...finally — это костыль. Плохая замена для RAII. Используйте оригинал — и будет вам щастя.

А насчёт «падающего ворда» — покажите альтернативу со сравнивыми возможностями и не падающую — будет о чём говорить. То что вложения в надёжность не окупаются в случае в Word'ом не значит, что Microsoft не умеет надёжный код писать. В конце-концов сама Windows уже давно не падает если железо не глючит, а она, как бы, не сильно проще Word'а.
-2
RAll — это даже не костыль. Это такая подушка. На которой удобно спать, которой при нужде можно придушить заказчика, на худой конце можно налить туда воду и ехать на ней в субботу. Но для забивания гвоздей RAll подушка не пригодна.

Открыть выпуск.
разные операции
Открыть впуск.
перекачка и все прочеее
подготовительные операции к закрытию выпуска
Закрыть выпуск.

ещё всякие операции
подготовительные операции к закрытию впуска
Закрыть впуск.



я не про то, что единая технологическая операция расползается по трем местам кода. Это неудобно, провоцирует ошибки, но это плата за RAll.

И не о том, что придется создавать объекты, у которых смысл только в конструкторе и деструкторе, а никакой физической сущности нету. Это тоже плата за RAll,

И не о том, что на один и тот же выпуск придется пяток разных объектов, Это тоже плата за RAll

Но вы на область действия посмотрите! Видно же, что в реальном мире «неправильные пчелы и они делают неправильный мед». (с) я понимаю, вы захотите сменить технолога, потом завод, потому страну, потом будете искать другой глобус, но не откажитесь от RAll,. Мне проще — я просто выбираю язык под задачу.

Давайте уж оставим RAll для того, для чего его придумали — для управления ресурсами в дисциплине LIFO. А в реальной мире — не ресурсы и скорее FFO.

Кстати, с моей зрения автоматический вызов деструкторов локальных переменных — это костыль. Или уж не вызвать ничего автоматически (это надежнее) или уж автоматически вызывать деструкторы и для объектов в куче (как в COM). Потому что такое половинчатое решение вызвала другие костыли, например "владеющие указатели"… И так один костыль наворачивается на другой и всё это вместе называется современным С++.

Только давайте не будем спорить о языках программирования. Мне не интересны такие холивары…
0
Я извиняюсь, может из-за того, что сейчас уже глубокая ночь, но написанное кажется бредом. "владеющие указатели" особенно порадовали/
Обещаю завтра ещё раз прочитать, вдруг смысл написаного дойдёт.
-1
А вы попробуйте пример сделать при помощи RAll. Жирным шрифтом — то, что надо бы поместить в конструкторы и деструкторы. Ну и покажите результат, если вам это удастся сделать.
0
Не понял вашего примеры. Напишите на своих finally, я вам перепишу код на RAII.
-5
Ловлю на слове. Ибо уверен, что ничего вы не напишите, а только будете критиковать предметную область.

Try
   Try
      Try
          Try
               Открыть выпуск.
               разные операции
               Открыть впуск.
               перекачка и все прочеее
          Except
               Eabort : Raise;
               Else     Выдача собщений; Raise EAbort
          End 
       Finally
          подготовительные операции к закрытию выпуска
          Закрыть выпуск.
       End
       ещё всякие операции
    Except
        Eabort : Raise;
        Else     Выдача собщений; Raise EAbort
    End
Finally
    подготовительные операции к закрытию впуска
    Закрыть впуск.
End
0
Угу, это PDL . Слишком мало языков программирования, в которых может быть оператор «открыть выпуск». А спускаться до исходного кода — так большая простыня будет.

Ну так что, напишите с использованием RAll или будете критиковать предметную область?
0

Для начала, приведите пример как вы собрались это все делать через try/finally.

-6
Мне кажется, что примеры уровня 9ого класса вы можете написать и сами. ну как бы это не уровень хабра. Но если для Вас даже это сложно — могу прислать в личку.
0

Я не собираюсь отвечать на оскорбления в личке. На этом со своей стороны считаю дискуссию законченной. Можете не утруждать себя ответом на этот комментарий.

-6
ОК. Для всех — в личку был отправлен искомый исходный код уровня восьмого класса.
-1
Забыл на вторую часть ответить. Любое приложение, написанное на основе VCL падать не будет из-за дизайна VCL. Примеров много, из общеизвестных — сам Delphi, С++ Builder, Skype… Ошибка в реакции на любое действие пользователя изолируется. То есть у вас может быть access violation при использовании любого пункта меню или нажатию на кнопочку. Но к закрытию всего приложения и потере данных он не приведет.

я бы сказал, что не окупается использование MFC вместо VCL. Ну и сама парадигма «по одной ошибке считаем, что сломали вообще все» тоже не окупается. А вот парадигма «Баг в функциональности — это только баг в функциональности» вполне окупается.
-1
Любое приложение, написанное на основе VCL падать не будет из-за дизайна VCL.

Так можно про 100500 вещей сказать. «Любое приложение, написаное на основе XXX падать не будет из-за дизайна XXX», я с ходу 5 страшных и не очень слов уже придумал, что можно вместо XXX подставить.

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

И это плюс? Молча ловить и глотать системные SEH'и? И ваш любимый MFC и Qt правда тоже самое делают, правда и там и там это легко правится.

я бы сказал, что не окупается использование MFC вместо VCL.

Так, откуда тут MFC появисля? Был Qt. Что за фигня, верните Qt.
А если серьёзно, то на MFC тоже много коммерческого софта написано. И если бы не 2 его недостатка (коннектить сигналы можно только при компиляции, а не динамически, как в Qt) и на поддержка из коробки лейаутов и растяжения форм, то вообще нормальная библиотека была бы.
-1
я с ходу 5 страшных и не очень слов уже придумал, что можно вместо XXX подставить.

Мало придумать. Вы докажите, что вы правы.

И это плюс? Молча ловить и глотать системные SEH'и?

Плюс. Потому что молча — это на вас опыт VC++ влияет. А на самом деле выдается сообщение, если надо — идет логгирование… Статистика примерно такая:
  • 0.5% — ошибка фатальная, лавинный отказ, программа закрывается с потерей данных
  • 2% — дятел (постоянная выдача собщений об ошибке). При быстрой работе мышкой обычно удается закрыть с сохранением данных.
  • 97.5% — отказ одной функциональности


Что за фигня, верните Qt.

А не работал я с Qt. Потому и судить о нём не буду. По слухам — отладчик лучше VC++. Надо бы попробовать, но времени нету.
0
Плюс. Потому что молча — это на вас опыт VC++ влияет. А на самом деле выдается сообщение, если надо — идет логгирование

Логирование тоже в VCL встроено? Не верю. А если писать логирование вручную — то какая разница какое там поведение при ошибках по умолчанию? Все равно же по-своему переделывать.

-2
Вам опыт общения с продуктами микрософт мешает. :-) Разумеется, в VCL встроено много событий, позволяющих переопределить поведение без переделки библиотеки. Соответствующее событие зовется OnException и имеет тип (для старых версий С++)
typedef void __fastcall (__closure *TExceptionEvent)(System::TObject* Sender, Sysutils::Exception* E);

ну или (для новых)
(Sender: TObject; E: Exception) ( TExceptionEvent)()

Более того, есть специальный объект для трансляции таких событий в объект формы.

То есть в разных окнах можно сделать разное логгирование.

__closure это киллер-фича, возможность переддать указатель не просто на функцию, а на метод конкретного объекта. Иными словами __closure это два указателя — и на объект и на его метод. Крайне удобно для событийной организации программ потому что позволяет делегировать обработку другому объекту.
+3
__closure это киллер-фича, возможность переддать указатель не просто на функцию, а на метод конкретного объекта. Иными словами __closure это два указателя — и на объект и на его метод. Крайне удобно для событийной организации программ потому что позволяет делегировать обработку другому объекту.

Но лямбды при этом не нужны.


А лямбды в сочетании с auto template types из C++17 позволяют делать это прозрачно и одним указателем. Надо бы про это тоже статейку наваять.

-5
Костыль + костыль + костыль = ура, работает. И зачем это другие обходтся без костылей? Дураки, видимо. :-)
+1

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

-3
А вы поработайте на FORTH. я понимаю, что вам будет сложно. Но прямая генерация помежуточного кода из compile-time программы — это прямое и логичное решение. А в С++ городят костыль на костыль, но ещё очень дали от мощи FORTH.

Ну как пример foreach. Куча языков имеют его как языковую конструкцию. И С++ тянется к тому. Но вместо того, чтобы программно реализовать новое ключевое слово, используютяс костыли ввиде темплейтов и лямбд.
А на том же форте — ноль проблем. Нужен foreach — взяли и написали. Через несколько часов у вас в языке новый оператор foreach.

С++ давно идет к этому. Собственно начиная с возможности переопределения семантики оператора присваивания — это всё шаги именно в направлении написания собственных операторов. Даже больше. Движение в этом правлении началось ещё с дефайнов Си. Но пока что шаги костыльные.

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

А прежде чем судить костыль или нет — напишите парочку своих операторов на любом языке, который это позволяет. И уж потом — судите.
+2
А вы поработайте на FORTH. я понимаю, что вам будет сложно. Но прямая генерация помежуточного кода из compile-time программы — это прямое и логичное решение. А в С++ городят костыль на костыль, но ещё очень дали от мощи FORTH.

Самое правильное из встреченных мной решений &mdash; кодогенерация уровня Template Haskell. Можно взять хаскелевский код и выполнять его как обычно, в рантайме, а можно в компил-тайме. Хотя чаще всего TH не нужно, и достаточно хаскелевских дженериков, которые лишь формализуют изоморфизм между произвольной структурой данных и, если упрощать, комбинацией типов-сумм и произведений.


Ну как пример foreach. Куча языков имеют его как языковую конструкцию. И С++ тянется к тому. Но вместо того, чтобы программно реализовать новое ключевое слово, используютяс костыли ввиде темплейтов и лямбд.

Вообще-то уже шесть лет как дотянулся. Вы вообще знаете предмет вашей критики или по-прежнему в 98-м году?


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

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


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

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

-3
Вообще-то уже шесть лет как дотянулся.

Тогда зачем вы дает пример лямбд с std::for_each? Мест, где они реально нужны, не нашлось?

Если немножко подумать, то станет очевидно, что на самом-то деле оператор не отличается от функции вообще ничем.

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

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

void external(void)
{
   int ext1, exxt2;
   voi intA(void) {,...ext2=ext1;...};
   voi intB(void) {,...ext2=ext1;...intA();...};
   intA();
   intB();
}

Пока мы из вызываем IntB из external — все ещё хорошо. Но когда из IntB мы мы вызвали IntA — у неё огромная проблема, как найти в стеке адрес переменных ext2 и ext1. Поэтому лямды не могут вызвать друг друга или рекурсивно самих себя. Да и вообще, обращаются к переменным процедуры очень ограничено.

А вот в операторе этих проблем нету. Оператор не функция — из иного места не вызовется.

Впрочем, наверное, это все слишком сложно для вас. :-(

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

Да и так понятно, что опыта нет. Компилятор не писали, кодогенерацию не чувствуете… Напишите свой первый компилятор — совсем по-другому на язык взгляните.

а на FORTH взгляните. Там вообще вся кодогенерация в руках программиста. И даже компиляция — написана на том же форте. Занимает форт-система 14 килобайт (вместе с редактором и системой хранения на диске) и живет без ОС. Наверняка в детстве с форт-системами играли.

Вот вам одна из самых популярных. Кроме форта - туда ничего не лезло
image
+2
Тогда зачем вы дает пример лямбд с std::for_each? Мест, где они реально нужны, не нашлось?

Значит, не знаете предмета критики. Ну, окей, бывает. Хотя лучше, конечно, хотя б страничку в википедии осилить до конца перед тем, как критиковать.


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


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

А вы что оператором называете? А то у меня чувство, что вы то ли не хотите вылезать из контекста какого-то данного конкретного языка, то ли троллите.


Что там с пространством имён? Что за проблемы с переменными? Что с кодогенерацией, в конце концов?


Знаете, почему лямбды — это не полноценные функции? В Алголе 60 попытались…

Можно я просто не буду читать дальше? Причём тут, #!@%^, алгол-60?


Но я всё-таки прочитаю.


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

В C++ есть:


int ext1, exx2;
std::unique_lock<std::mutex> lock;
auto lambda1 = [ext1, &exx2] {};
auto iWannaCaptureEverything = [&] { ... };
auto yayMoveIntoLambda = [lock = std::move (lock)] { ... };

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


В языках с GC (или с адекватной системой типов вроде Rust, хотя я его тыкал очень мало) есть ещё лучше. Во, смотрите, в хаскеле:


filterNonEqual n xs = filter (\x -> x /= n) xs

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


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

В плюсах могут относительно спокойно (правда, придётся пожертвовать auto в силу особенностей семантики языка, но это не принципиальная проблема):


std::function<int (int)> fac = [&fac] (int n) { return n ? n * fac (n - 1) : 1; };

Впрочем, надо отметить, что если вам такую лямбду надо куда-то вернуть, то становится весело.


А в хаскеле-то сам Карри велел:


let f = \x -> if x == 0 then 1 else x * f (x - 1)

Можно возвращать что хотите куда хотите.


А вот в операторе этих проблем нету. Оператор не функция — из иного места не вызовется.

Из какого иного? Почему? Кто сказал? Что вы называете оператором?


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


Prelude> "foo" `elem` ["bar", "foo", "baz"]
True
Prelude> (+) 3 2
5

Впрочем, наверное, это все слишком сложно для вас. :-(

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


Да и так понятно, что опыта нет. Компилятор не писали, кодогенерацию не чувствуете… Напишите свой первый компилятор — совсем по-другому на язык взгляните.

Вот в том и забава, что писал. За рекурсивный спуск поговорим? А за методы избавления от левой рекурсии? А за преобразования и упрощения AST? А за стейтмашины с неявными состояниями, тупо в виде суперпозиции соответствующих семантических действий? А за SSA form и three address code?


У меня, к счастью, теория идёт рука об руку с практикой (на Пирса я уже ссылался), поэтому я могу всё это дело писать и осознавать не на уровне полуэврестических отсылок к полуразложившимся языкам, а, ну, чуть более вдумчиво. Местами немножко более вдумчиво, чем в Dragon Book (их тайпчекинг — это несерьёзно совсем, в самом деле).

-6
Пример показывает, как этим делом пользоваться, и как лямбды упрощают код по сравнению с в остальном таким же примером.

Так о том и речь, что мы не используем «в остальном такие же примеры». :-)
Замечания такие:

  • Упрощение только синтаксическое, на уровне эффективности кода упрощения не вижу.
  • Лямбды — это костыль по сравнению с нормальными вложенными функциями.
  • Лямбды столь же неэфективны, как и обычные вложенные функции

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

Можно я просто не буду читать дальше? Причём тут, #!@%^, алгол-60?

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

В C++ есть:

Милый человек, синтаксически оно и в алголе-60 есть. Причем нормально, без костылей типа [ext1, &exx2]. А что с кодогенерацией? Какой способ обращения будет эффективен, если мы можем вызвать вложенную функцию IntA не только напрямую из внешней, но и через IntB? А если мы вызываем через рекурсивную функцию?
Какая разница, что и где есть синтаксически? Вы мне про кодогенерацию расскажите.

В плюсах могут относительно спокойно (правда, придётся пожертвовать auto в силу особенностей семантики языка, но это не принципиальная проблема):

А с кодогенерацией-то что???? Размотка стека вызовов при каждом входе в лямбду? А если рекурсия там тысячу вызовов накрутила?

А вы что оператором называете?

Да я предпочитаю не спорить о терминах. Давайте возьмем определение из вики:.
Инстру́кция или опера́тор (англ. statement) — наименьшая автономная часть языка программирования; команда. Программа обычно представляет собой последовательность инструкций.


Что там с пространством имён? Что за проблемы с переменными? Что с кодогенерацией, в конце концов?

Честно говоря не очень понимаю на каком уровне вести ликбез. Если уровень слишком сложен — то скажите, объясню на школьном уровне. есть такая вещь — stack frame.

В вики для него есть отличная картинка.
image

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

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

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

Понятно, что для инлайновых функций таких проблем нету, но инлайновые функции — это собственно такой макрос. Чисто синт