Ищем ошибки в C, C++ и C# на Windows и Linux
330,66
рейтинг
30 ноября 2016 в 08:50

Разработка → Как использовать PVS-Studio бесплатно

PVS-Studio FreeМы хотим помочь миру программного обеспечения лучше познакомиться с инструментами статического анализа кода и повысить качество программного обеспечения. Мы предоставляем возможность бесплатного использования анализатора PVS-Studio студентам в учебных целях, индивидуальным разработчикам и коллективам энтузиастов.

Введение


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

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

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

Стоит пояснить нашу позицию. Впрочем, если вам не терпится, вы можете сразу перейти к разделу «Бесплатная лицензия PVS-Studio». Если же читателю интересно узнать подробности, то предлагаю продолжить чтение.

Размышления


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

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

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

Решение было найдено интуитивно. Что отличает корпоративные проекты от проектов энтузиастов? В корпоративных проектах меньше свободы и больше бюрократии. Вряд ли руководство компании Microsoft будет радо, если разработчик в коде Microsoft Office напишет, что это его персональный проект. Этим надо воспользоваться и предлагать вносить в код правки, в которых упоминается PVS-Studio. Заодно код открытых проектов будет рекламировать PVS-Studio.

Бесплатная лицензия PVS-Studio


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

Шаг 1.


Если вы используете PVS-Studio как плагин к Visual Studio, то введите следующий лицензионный ключ:

Name: PVS-Studio Free

Key: FREE-FREE-FREE-FREE

Если Вы используете PVS-Studio for Linux, то сразу переходите ко второму шагу, файл с лицензией вам не понадобится.

Шаг 2.


Внесите правки во все компилируемые файлы вашего проекта. Имеются в виду файлы с расширениями c, cc, cpp, cs и так далее. Заголовочные h-файлы менять не требуется.

Вы должны вписать в начало каждого файла две строки с комментарием. Мы предоставляем на выбор несколько вариантов. Это своего рода плата за возможность бесплатного использования анализатора PVS-Studio.

Комментарии для студентов (академическая лицензия):

// This is a personal academic project. Dear PVS-Studio, please check it.
// PVS-Studio Static Code Analyzer for C, C++ and C#: http://www.viva64.com

Комментарии для открытых бесплатных проектов:

// 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

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

// This is an independent project of an individual developer. Dear PVS-Studio, please check it.
// PVS-Studio Static Code Analyzer for C, C++ and C#: http://www.viva64.com

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

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

Автоматизация


Если в вашем проекте много файлов, то вы можете воспользоваться вспомогательной утилитой. Вы должны будете указать ей какой комментарий вставлять и каталог с кодом. Затем утилита рекурсивно обойдет все файлы в папке и вложенных папках, добавляя в файлы с исходным кодом соответствующие комментарии. Скачать утилиту (вместе с исходным кодом) можно здесь: how-to-use-pvs-studio-free.

Заключение


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

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

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

Чтобы убедить ваших коллег начать использовать анализатор кода PVS-Studio, предлагаем познакомить их со следующими разделами нашего сайта:


Спасибо за внимание. Давайте вместе сделаем программы надежнее и безопаснее.

Update


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

Вы имеете право использовать PVS-Studio бесплатно, добавив в исходный код своего проекта комментарии специального вида. Какие именно комментарии следует добавлять и как автоматизировать этот процесс описано в статье «Как использовать PVS-Studio бесплатно».

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

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

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


Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. How to use PVS-Studio for free.
Автор: @Andrey2008
PVS-Studio
рейтинг 330,66
Ищем ошибки в C, C++ и C# на Windows и Linux

Комментарии (519)

  • +14
    Отлично! Супер! Единственная просьба — разрешить не только С++ комментарии, но и Си (/* */). Проект в релиз собирается по стандарту С90, там комментарии "//" не даст вставить компилятор
    • 0
      Расскажите, пожалуйста, что за проект? C90 сейчас все-таки экзотика.
      • +3

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

      • +6
        например, в микроконтроллерах распространен.
      • +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
      Профайлер плагинов в VS2017 покажет кто где не прав! :-)
      • +1
        Боюсь что к тому времени выйдет Rider, и Студия будет постепенно уходить в забвение.
        • +1
          Придется сделать нам плагинчик для Rider.
          • +1

            А что такое Rider?

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

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

              Если один клиент готов описывать свою проблему в письме на русском языке и ожидать ответ в течении суток, то разумеется цена поддержки для него будет отличатся от цены того кто хочет получить ответ немедленно, по телефону и на чистом мандаринском.
              Не существует 2-х одинаковых крупных компаний (а на них и рассчитан данный инструмент) и процесс разработки у них поставлен по разному, при этом они хотят добавить продукт стат. анализа не изменяя данные процессы. В итоге ценник за внедрение у разных заказчиков будет разный.
              • 0
                Спасибо за адекватный комментарий.
                • 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 миллионов рублей (информация с тех времен, когда они ещё цену не скрывали)


                              • +2

                                В PVS-studio можно подавлять предупреждения комментариями.

                                • –3
                                  я чуть о групповом подавлении ложных сообщений. Именно в нем и можно(и нужно) добавлять фильтры под заказчика.
                                  • 0

                                    Тогда я вас не понимаю. Что вам не нравится-то?

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

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

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

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

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


                                          Это авторы PVS-studio считают, что нужно подтачивать их программу напильником, а не я. я всего лишь пояснил, в каких местах её, скорее всего, точат.
                                          • +3

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

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

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

        P.S. PVS-Studio без VS уже давно есть :)
        • +10

          Когда ты видишь, что SpaceX запросто указывает цены на свои ракеты-носители, понимаешь, насколько смехотворна эта «нормальная стандартная практика».

          • +6
            Если мы сейчас начнём по очереди приводить примеры товаров с ценниками и без, то ветка уйдёт в бесконечность, учитывая, что ни география, ни предметная область вопроса не ограничена.
            • +9
              Так в чём проблема продумать и построить схему ценообразования такой, что её не придётся прятать? Думаете JetBrains добился бы распространения своей IDE, если бы прятал ценник?
              • 0

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

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

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

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

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

                  А искать ваших клиентов — откровенно лень. Потому, если уж покупать продукт для статического анализа — то не у вас, а у фирм, не скрывающих сои прайсы.
                  • –1
                    а у фирм, не скрывающих сои прайсы.


                    Жаль таких фирм почти нет.
                    • +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

                                Не понимаю, почему вы решили, что я так решил.

                                • 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
              Имеется в виду замена явного намерения
              всё, что нужно, я сваяю левой ногой минут за пять

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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


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


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

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

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

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

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

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

                        А можно сравнить с Coverity, которые этого не требуют, например.

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

        Это некий компромиссc между удобством на Windows и linux. На Windows — удобнее комментарии в 1251, на линуск — в UTF-8. вот и приходится сообщать редактору о кодировке файла.
        • 0
          Может проще всегда 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, падающую при ошибке в любой части без сохранения данных, в АСУТП бы оторвали… Ну в общем что оторвали, то бы и оторвали.

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

                              А кто вам сказал, что они несовместимы?

                              • –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
                                                      Ладно, пора заканчивать кормить тролля. И так уже отъелся походу.
                                                      • 0
                                                        Самокритичненько вы. :-)
                                                  • –1
                                                    Я вот уверен, что студия умеет гораздо больше стандартного, чем любой другой 19-ти летний компилятор, и в обратном вы меня не убедите.

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

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

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


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


                                                        А так как числодробилки в моей практике пишутся не под 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
                                                • +1
                                                  Тогда попробуйте PVS, вдруг реально будет помогать!
                                                  • –2
                                                    Попробовать — попробую. Но пока чтение рекламных статей PVS-studio оставляет впечатление. что он нам не нужен. Сколько ни читал — ну ни разу не было «ой, мы за таким же багом 3 дня гонялись». Было наоборот — нифига себе, какую ерунду люди пишут.

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

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

                                                    • +2
                                                      Сколько ни читал — ну ни разу не было «ой, мы за таким же багом 3 дня гонялись».

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

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

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

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

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

                                                        Но я ещё раз обещаю, что наш код бесплатной версией проверю и статью с результатами напишу.
                                                        • +3
                                                          Вы же не стали ежедневно проверять свой код Clang, после того как он нашел у вас ошибки?

                                                          Проверяем каждый день (см. «Тестирование PVS-Studio»).
                                                          • –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 — как бы это вас спасло?

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

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


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

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

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

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

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


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

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

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

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

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

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


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


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

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

                                              • +1
                                                s[0] = 'K' читабельнее, вызывает меньше WTF и вообще.

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

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


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

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


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

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


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

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


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


                                          То есть, сделав алгоритм для 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 — всё, в один сервер не влезает. При этом валидация на более мелком датасете показала, что точности флоата-то, в общем-то, нам хватает.


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

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

                                    • +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
                                                Можете ещё и VC# от VC++ разделять…

                                                Что-то ржу

                          • 0
                            Нам с Astra-linux больше повезло, gcc 4.9

                            4.7.2 должен быть, судя по http://www.astralinux.com/osnovnye-komponenty.html

                            • 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, в конце концов, тоже разворачивается в некоторый код компилятором, который вы, внезапно, повторно используете.


                                                              А в пищеводе клапаны тоже сфинктерами называются, кстати.


                                                              И ложные аналогии — это как котята с дверцами.


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

                                                              Почему по разным? Они пространственно тесно связанные.


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


                                                              Затем, что это совсем разные сущности.

                                                              Причём тут куча? Мы же о куче изначально говорили. Я не успеваю за полётом вашей мысли.


                                                              А так — не, спасибо, один из двух моих любимых языков вообще не имеет никаких объектов, только функции и структуры данных.


                                                              Например текстового ввода-вывода.

                                                              Зачем оно мне на 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 можно просто тупо выкинуть, она и так уже на диске есть).

                                                                  • –4
                                                                    А если серьёзно, почему try/finally не технологическая операция

                                                                    По определению.

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


                                                                    Конечно, я выразил свою мысль не очень грамотно, поэтому повторю.

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

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

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

                                                                    А мне бы пару гигабайт с диска считать и распарсить побыстрее.

                                                                    Это совсем иная область.

                                                                    Куда уж быстрее memory mapped files

                                                                    Сколько процентов времени занимает загрузка страниц из файла? Если 50% — можно ускорить почти в два, ведя загрузку одной нитью (prefetch). а обработку другой.

                                                                    Ещё один финт ушами — динамическая кодогенерация под конкретную задачу. В 1993ем на году мы на этой технике достигли скорости полнотекстового поиска в 10 тысяч записей в секунду, что было лишь в полтора раз медленней скорости диска. Это под MS-DOS на I386. Второй финт был в том, что поиск велся по запакованным полям без их распаковки. Это в пару раз ускоряло чтение и сам поиск. Автором сего чуда был Антон Москаль, более известный по Паскаль-Москаль и TMT-паскаль, а я там так — прикладной код писал и баги ядра отлавливал.
                                        • 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
                                                      Это явно не Builder C++ :-)
                                                      • 0
                                                        Угу, это PDL . Слишком мало языков программирования, в которых может быть оператор «открыть выпуск». А спускаться до исходного кода — так большая простыня будет.

                                                        Ну так что, напишите с использованием RAll или будете критиковать предметную область?
                                            • 0

                                              Для начала, приведите пример как вы собрались это все делать через try/finally.

                                              • –6
                                                Мне кажется, что примеры уровня 9ого класса вы можете написать и сами. ну как бы это не уровень хабра. Но если для Вас даже это сложно — могу прислать в личку.