Ну функциональность, которая не работает с одним из брендов, обходится просто — данный бренд не включается в список оборудования, сертифицированного для работы с программой. :-)
Так то бывает, что проблема не находится на стадии тестирования, а всплывает только у клиента.
Типичное время переключения в горячем резерве — микросекунды.
Это да, только в часто ноды, которые в горячем резерве и падают одновременно :-). Ну а дальше начинается, что дублировать каждый сервер клиент не в состоянии финансово, поэтому есть некий кластер, с N рабочими серверами и с M резервными (N >> M). И переключение на резервный сервер уже не микросекунды занимает, и даже не миллисекунды. Да, 2N серверов, часто встречается, только в идеальном мире, да в мечтах разработчиков.
Предлагаю вернуться в правильное русло.
Вообще под студией вы и остальные понимают 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).
Я в общем к тому веду, что обсирать студию точно не стоит, вполне, да же так, ВПОЛНЕ, себе достойный коммерческий продукт для разработки. Ну а как иде обсирать её не стоит особенно.
Повторю совет: меньше читать в инете, больше пробовать самому
Нет, спасибо. Хватило адаптации кода для неё. Боль примерно та же, что и с адаптацией сайта под 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?
Вы зря спорите. Конечно, вопрос интересный. На самом деле некая совместимость между ними есть. Например, иногда можно добавить в игнор либу от дебага, и залинковаться с релизной (msvcrt.lib) или наоборот. С рантаймом для cpp там сложнее, msvcprtd.lib вместо msvcprt.lib сложнее подсунуть.
Кстати, это именно тот случай когда «два разных варианта одной библиотеки, собранные из одних и тех же сорцов и отличающихся лишь ключами компиляции».
А так как, что это 2 разные библиотеки — это не бага, как пытается jef представить, а фича! Да, если для тебя это «большая, реальная» проблема, что не хочется иметь 2 набора бинарников — не используй это. А так дебажный рантайм даёт много полезных фич нужный для отладки (на например, там при каждой деаллокации памяти куча проверяется по этому адресу, или итераторы чекаются, что они в валидном слейте. То же со строками, например, в дебаге, там даже в обычном std::string'е новые мемберы появляются, нужные для последующей фоновой валидации строк).
Если вам не нужны все эти возможности, потому что вы не можете их осились/понять/другая_надуманная_причина, то не используйте эту фичу. Собирайте свой код без оптимизации, и отлаживайтесь на нём. Тогда у вас будет только одна версия crt и cprt.
В принципе соглашусь, с небольшими исключениями.
1) Есть системы, где декларируемое время простоя может быть сильно ограничего. Например, для АТС помню, в северной америке в полиции downtime был всего 7 минут в год. Т.е. 7 минут, на все падения, переключения на failover, и т.д. И даже на установку нужных апдейтов отдельного времени не давалось. Даже если типичное время переключения на другую ноду всего 30 секунд, то это максимум 14 сбоев в год (в реальности 2-3). В больницах помню, что-то около 30 минут в год было, уже неплохо.
2) есть функциональность, которая может просто работать неправильно. Например, неправильно собираем RTP поток с удалённого устройства, или какая бага у тебя в реализации RTSP/SIP/другой протокол. И воспроизводится она только с железками такого-то бренда, если у него такие-то настройки на такой-то версии фирмваре. И тут, хоть обзапускай сервис, хоть обпереключайся между серверами, а, скажем, RTP поток ни один из сервисов, ни на одном из серверов, собрать правильно не сможет.
Я к тому, что качество кода, всё-таки это играет определённую роль.
При клики я написал в том смысле, что если за пару месяцев нашлось больше 20 свеженаписанных ворнингов 1 уровня, то инструмент будет полезен именно для инкрементального анализа.
А по логу, соглашусь с авторами, это уже не так интересно, так как даже если проверять периодически, то что-то уже будет попадать в основную ветку, тратиться время тестирования и т.д. Лично я лог рассматриваю как проверку, что никто не отключил статанализ, или не забил на него.
А вообще мы уже слишком отошли от темы.
Я что хочу заметить, PVS больше всего ошибок находит как раз в C-style коде. Так как мы уже полностью ушли от malloc/free/strcpy/strcat/printf/memcpy/ и даже от delete/new, то 2/3 диагностик к нам уже не применимо, так опечатки где-то отлавливает, или муть в условиях.
А вот вам, учитывая «Мы пишем на Си с отдельными элементами С++.» этот инструмент может оказаться гораздо более эффективным. Рекомендую, пока сотрудникам поставить триалки, пусть даже пока скрыть все ворнинги, которые уже есть на данный момент, и поработать пару месяцев на инкременталке. Если за пару месяцев триальные клики закончатся, то этот инструмент вам явно нужен.
В 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 килобайта?
Вообще ничего не понял про фрагментацию кучи. Это тут при чём?
Ну тогда ему и PVS-studio не поможет. Просто внимания обращать не будет.
Здесь вся надежда, что можно будет таких людей обязать, чтобы в коде не было новых ворнингов анализатора 1-го уровня, хотя бы.
А примерная годовая экономия времени на поиск багов какая?
Я уже написал выше, что ИМХО, это сильно зависит от человека. Тем, кто пишет быстро и грязно, а потом большую часть времени отлавливает баги, это реально может помочь. Мне вот в режиме инкременталки не часто помогает.
Чёрт, случайно комментарий послался не законченным. Продолжу.
Так вот, в стандарте C++ нет ничего, например, про strcmpi. Но есть _strcmpi. Поэтому VS честно предупредит, если вы используете этот анахронизм. И да, как вы понимаете, я не говорю не про C++98, где strcmpi — это норма. Ну что же, за 19 лет мир немного поменялся.
Собственно это повтор истории про осла. Когда IE захватил рынок, он диктовал свои стандарты. Ну и где он сейчас?
А это к чему? Компилятор от MS сейчас вролне поддерживает стандарты C++. Да есть свои extension'ы, но ИМХО, в том же gcc их уже больше :-). А так, например VS 2013 поддерживала C++11 лучше, чем скажем вышедший одновременно Intel composer 2013.
Но подумайте о том, что баги в продуктах мирософта видели все. Ни о какой надежности там речи не идет, зато ИнСат — это работа на рынке, где требуется очень высокая надежность. Это защиты АЭС, это автоматизация котла ТЭЦ (а современный котле без автоматики или тухнет ил взрывается), это автоматизация изготовления сопел ракет, это климат-контроль на производстве банковских карт., это автоматизация компрессорной магистрального газопровода, это мониторинг теплоснабжения миллионного города…
Так что уж извините, но ИнСат писать код умеет. Потому что о багах и в их продуктах я не слышал.
Я скажу так, не бывает идеальных программ без багов, так как не бывает идеальных аналитиков, которые написали бы ТЗ без противоречий, не существует идеальных системных архитектов, не бывает идеальных программистов, которые написали бы код без багов, не бывает идеальных тестеров, которые не пропустили бы ни одной баги, и т.д…
То, что баги есть — это нормально, это надо понимать. Да что там, я лично более 2-х десятков багов репортил на vs connect. А вот то, что вы не слышали не про одну багу в продуктах ИНСАТ или любой другой компании, это не значит, что их там нет. У нас вот в компании тоже половина программистов свято уверена, что у наших клиентов нет никаких проблем, типа это они круто пишут, что багов мало, а те что есть, типа все находятся тестированием. А когда периодически всплывает, что дня без клиентской проблемы не обходится, так делают круглые глаза. Я к тому, что неспособность скомпилировать свой же код в релизе — говорит о многом. Я бы не хотел работать с такими партнёрами, чтобы они для меня код писали. И да, у меня соседний департамент имеет схожую проблему, они не умеют собирать дебажные сборки. Так что о проблеме, её источнике, и т.д., я знаю не понаслышке.
Но скорее всего это очередное дурацкое ограничение у микрософта — EXE, рассчитанный на подключение dll отладочной сборки, не может подключить dll релизной сборки
Ну, если вы так изначально рассчитывали, что же потом удивляетесь?
Вот если бы не хотели такого ограничения, то написали бы сразу exe, который рассчитывает, что ему пофигу с какой dll работать — с релизной или с дебажной. :-).
А если серьёзно, то у майкрософт таких ограничений, конечно же нет, это вы придумали. Вот гляньте на ffmpeg, например. Ты собрал dll'ки, хоть в релизе, хоть в дебаге, хоть другим компилятором, например интеловским. И дальше используй хоть в релизном, хоть в дебажном exe'шнике.
Чтобы никогда не использовать VC++ мне хватает того, что они объявили POSIX obsolete и ввели свои, нестандартные вызовы. Поскольку целевой системой у нас Linux и FreeRTOS, То проще уж отлаживаться там, где POSIX не вызывает таких проблем.
Я уже писал выше, что вы всё перепутали, и майкрософт наоборот, вместо нестандартных платформозависимых POSIX функций, ввела обычные стандартные, прямо из ISO C++, функции.
Почитал. Аппаратные брекопоинты — явно недоделанные. Мало того, что их нет для Си, так ещё и вручную считать размер данных. И пересчитать адрес после перекомпиляции автоматически он сам не может.
Скажу честно. Недоделанными их можно назвать, по сравнению с тем, что, например, 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 аналоги…
А эта фигня с -Wall -Wextra (ну или иным вариантом полностью включенных варнингов и хинтов) чисто компилируется? Просто те, кто комитит фигню, часто забивают болт на предупреждения.
Конечно не чисто. Но к сожалению у нас даже на -w3 чисто в единичных случаях. Даже ворнинги w1 ещё остались. Вообще есть проекты (рабочие, не заброшенные) с больше 300 ворнингов на w3.
Но поймает ли PVS-studio что-то серьезное — непонятно. Суд по опубликованному — никаких серьезных багов он не ловит. Да, находятся вещи неприятные, но не ужас-ужас-ужас.
В принципе, находит. Т.е. это не бесполезный инструмент. Но ужас-ужас больше шансов найти при первой проверке многолетнего проекта. Так вот, чтобы в моём новом коде ужас-ужас находился на инкременталке, даже и не вспомню. Хотя, свеже-добавленые баги от коллег периодически находит, и даже ужас-ужас встречается.
А триалкой российских производителей постоянно пользоваться — не комильфо. Западных — запросто, а вот российских как-то западло мне.
Постоянно пользоваться на самом деле не хочется, а то вот меня уже Андрей Карпов в почте обвинил в том, что я пользуюсь крякнутой версией, потому что когда я рапортовал им багу про ложное срабатывание, там не было комментариев «Dear PVS...». Да и поддержать хочется российского производителя. Поэтому я и пытаюсь уже сколько времени выбить денег на коммерческую версию у руководства. Хотя чувствую, что с 330 т.р за 9 человек многовато будет, такое никто не одобрит, походу придётся и дальше на триалке сидеть :-(…
А кто ещё может брейкопйнты на изменение значений, просмотр структур с изменением их полей и так далее??? Ну 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? :)
А что вы используете как среду отладки?
Qt Creater вроде как только в utf работает. Visual Studio тоже без разницы, в локальной там или в utf'е, главное, чтобы BOM был. Если какие-то среды, которые BOM в файлах не понимают?
Сколько он может сэкономить на самом деле — непонятно.
Я вот уже несколько лет пользуюсь триалкой. И моё мнение сейчас такое, что это сильно от человека зависит. Например, мне он точно за год использования инкрементального анализа больше дня за прошлый год не съэкономил. Думаю, это у меня привычка, писать «чистый» код есть. Но вот есть чел, он периодически фигню коммитит. Вот ему бы такое неделю съэкономило бы времени. Другой человек, тоже практически говорит, что нет срабатываний на инкременталке, но он тоже сразу хороший код пишет. С другой стороны, одна «паршивая овца», может время много всем попортить, т.е. пропустит какой баг, он у тестирования вылезет, пока бюрократическая машина закрутится, не факт, что именно этот чел править будет, и т.д. Т.е. я думаю, что есть разработчики, которым если дать такой инструмент, то компании это реально полторы-две недели в год времени съэкономит. Маленьким компаниям проще, тут все навиду, обычно уровень разработчиков повыше, чем в больших монстрах, с кучей студентов. Поэтому я и говорю про среднюю неделю на разработчика, и не думаю, что в маленьких компаниях эта цифра будет больше.
Вроде очевидно, что Jef не это говорил.
Под ФОП — понимается не запрлата одного человека, а группы людей. Т.е. ФОП на 50 разработчиков ~ в 10 раз больше, чем ФОП на 5 разработчиков.
Так то бывает, что проблема не находится на стадии тестирования, а всплывает только у клиента.
Это да, только в часто ноды, которые в горячем резерве и падают одновременно :-). Ну а дальше начинается, что дублировать каждый сервер клиент не в состоянии финансово, поэтому есть некий кластер, с N рабочими серверами и с M резервными (N >> M). И переключение на резервный сервер уже не микросекунды занимает, и даже не миллисекунды. Да, 2N серверов, часто встречается, только в идеальном мире, да в мечтах разработчиков.
Предлагаю вернуться в правильное русло.
Вообще под студией вы и остальные понимают 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).
Я в общем к тому веду, что обсирать студию точно не стоит, вполне, да же так, ВПОЛНЕ, себе достойный коммерческий продукт для разработки. Ну а как иде обсирать её не стоит особенно.
Повторю совет: меньше читать в инете, больше пробовать самому
Вот прямо возникает вопрос: а вы под какую студию код адаптировали? Не под 5.0? Просто сейчас вот у нас проблема, что gcc 4.9 хуже стандарт поддерживает, чем студия. Я вот уже заколебался код «доунгрейдить», чтобы он у нас под линукс тоже собирался. Про интеловский компилятор я тоже говорил уже, не взлетел тоже в силу ущербности той версии, что была в 2013м компосере (сейчас в 2017м конечно лучше должно встать, но уже на gcc переехали под линукс).
Окно просмотра переменной можно пинить, и хоть 5, хоть 7, хоть 57 их иметь. Лучше попробуйте, множество вопросов отпадёт.
Вот видно, что так и не попробовали. Там не хит на 4к символом всплывает, а полноценное окно просмотра/редактирования переменной. Да, такое же как на моём скриншоте окна locals.
Не передёргивайте. Моё высказывание не относилось к качеству дизайна майкрософт (хотя иногда даже у МС встречается такие, что хочется эти же эпитеты к ним применить).
Вот не надо меня жалеть, что я Фортран не изучал. Это как пожалеть, что в армии 2 года не служил. И собственно ваш аргумент ни о чём. Ну пусть в Фортране есть внутренние и внешние функции. Это не значит, что он с бодуна должен вдруг начать реализовывать функции не из своего стандарта, например, из стандарта POSIX'а.
Отлично, что их много. Как много 100500 других библиотек, некоторые из котолрых реализуют так же свои стандарты. Но это не повод называть компилятор (хоть от майкрософт, хоть от интел, хоть ещё какой), плохим словом, если их рантайм не поддерживает эти левые стандарты.
Ну как бы никаких предпосылок, что он может с ним не заработать нету. А так вы вот до 2012-й студии stlport, например, использовали, крутая штука, кстати была 12 лет назад. И опять таки, к сравнению POSIX-api и WinAPI это отношения не имеет. Вообще. Берите любой компилятор (хоть gcc, хоть clang, хоть интеловский, хоть Builder, хоть VC), вам будет доступна стандартная библиотека и API операционной системы. Т.е. под gcc все WinAPI'шные функции также доступны под виндой.
Я, наверное, плохо выделил слово везде. На вики написано, что и под MCBC 3.0 доступен 4-й gcc. Не надо для этого на MCBC 5.0 переходить.
Так все думают (да, да, мы думали абсолютно так же), пока не переходят на новый компилятор, и внезапно С++11/С++14 код не начинает пролазить во все места в которые может и не может. И дело может быть даже в одной киллер-фиче, а в общем упрощении и убыстрении написания кода (при этом более безопасного и эффективного).
Вы так пишете, как будто я пытаюсь вас убедить в том, что vector<vector<vector<...>>> это круто и надо использовать только их, особенно для многомерных массивов :-). Не надо мне лишних грехов приписывать, у меня и так своих немало.
Хорошая аналогия, я бы до такой не догадался :-). Да, молоток 18-го века, вполне нормальный инструмент, сам таким пользуюсь. А вот профессионалы (по крайней мере, те, что мне ремонт делали), используют гвоздезабиватели (проще, быстрее, и безопаснее, в плане, что хрен ошибёшься).
Блин, у меня аж голова сломалась :-( Причём тут ваш печальный опыт на АЛГОЛ-60 и лямбды в C++? (Секс… ну опыт ТетяМашка-60 показал, что лучше им не заниматься, чем заниматься.). Какую связь лямбры имеют с stl-контейнерами? (это прямо мозг вынесло). Ну и как бы я сильно рад за вас, что у нас нету лишних копирований (а у кого они есть?).
Мой вопрос был, как это связано, используете вы кучу или нет, с фичами C++11/C++14?
На самом деле кухонные ножи — это не что-то абстрактно-потенциальное, а это самое частое орудие убийства.
Кстати, это именно тот случай когда «два разных варианта одной библиотеки, собранные из одних и тех же сорцов и отличающихся лишь ключами компиляции».
А так как, что это 2 разные библиотеки — это не бага, как пытается jef представить, а фича! Да, если для тебя это «большая, реальная» проблема, что не хочется иметь 2 набора бинарников — не используй это. А так дебажный рантайм даёт много полезных фич нужный для отладки (на например, там при каждой деаллокации памяти куча проверяется по этому адресу, или итераторы чекаются, что они в валидном слейте. То же со строками, например, в дебаге, там даже в обычном std::string'е новые мемберы появляются, нужные для последующей фоновой валидации строк).
Если вам не нужны все эти возможности, потому что вы не можете их осились/понять/другая_надуманная_причина, то не используйте эту фичу. Собирайте свой код без оптимизации, и отлаживайтесь на нём. Тогда у вас будет только одна версия crt и cprt.
1) Есть системы, где декларируемое время простоя может быть сильно ограничего. Например, для АТС помню, в северной америке в полиции downtime был всего 7 минут в год. Т.е. 7 минут, на все падения, переключения на failover, и т.д. И даже на установку нужных апдейтов отдельного времени не давалось. Даже если типичное время переключения на другую ноду всего 30 секунд, то это максимум 14 сбоев в год (в реальности 2-3). В больницах помню, что-то около 30 минут в год было, уже неплохо.
2) есть функциональность, которая может просто работать неправильно. Например, неправильно собираем RTP поток с удалённого устройства, или какая бага у тебя в реализации RTSP/SIP/другой протокол. И воспроизводится она только с железками такого-то бренда, если у него такие-то настройки на такой-то версии фирмваре. И тут, хоть обзапускай сервис, хоть обпереключайся между серверами, а, скажем, RTP поток ни один из сервисов, ни на одном из серверов, собрать правильно не сможет.
Я к тому, что качество кода, всё-таки это играет определённую роль.
А по логу, соглашусь с авторами, это уже не так интересно, так как даже если проверять периодически, то что-то уже будет попадать в основную ветку, тратиться время тестирования и т.д. Лично я лог рассматриваю как проверку, что никто не отключил статанализ, или не забил на него.
Я что хочу заметить, PVS больше всего ошибок находит как раз в C-style коде. Так как мы уже полностью ушли от malloc/free/strcpy/strcat/printf/memcpy/ и даже от delete/new, то 2/3 диагностик к нам уже не применимо, так опечатки где-то отлавливает, или муть в условиях.
А вот вам, учитывая «Мы пишем на Си с отдельными элементами С++.» этот инструмент может оказаться гораздо более эффективным. Рекомендую, пока сотрудникам поставить триалки, пусть даже пока скрыть все ворнинги, которые уже есть на данный момент, и поработать пару месяцев на инкременталке. Если за пару месяцев триальные клики закончатся, то этот инструмент вам явно нужен.
Аппаратный брекпоинт ставится на адрес. Обычный нативный адрес. Там хоть на ассемблере программу пиши. Бряка поставится и сработает. Рекомендую, прежде чем судить о студии, всё таки попробовать сперва её поближе, не на уровне скриншотов.
Я так и не особо понял, что вы хотите, может что-то такое?
Для ответа на вопрос, «в порядке ли данный объект», мне достаточно просто навести мышкой на переменную. А вовсе не зажимать контрол. И вовсе не добавлять каждое поле объекта в окно Watch (дикость какая).
Вы так и не сказали, что плохого в том, что компилятор C++ отказался от стандартов других языков и от стандартов для операционных систем в пользу стандарта своего языка? Я ещё раз приведу в пример strcmpi/stricmp. О нём в стандарте С99, например, тоже нет не слова. Потому что нет требований ни к одному из компиляторов эту функцию реализовывать. А вот операционная система должна реализовать такую системную функцию, иначе она не будет POSIX-системой. Т.е. здесь наоборот, переход от платформозависиой реализации к стандарту. Т.е. когда вы напишите stricmp, то это скомпилиться, заработает только на POSIX системах (на самом деле в POSIX её уже вроде как выкинули лет 15 назад, в пользу strcasecmp). Тоже самое с strdup, например. Ну нет в стандартах C и C++ этой функции. И даже более. В стандарте C написано, что функции которые начинаются с «str» зарезервированы, и их нельзя использовать. Но так как Майкрософт решила, что пусть функции можно не реализовывать, но они могут пригодиться клиентам, то она их оставила, но с именами, которые не конфликтуют со стандартом (префикс _ — это индикация, что это майкрософт-специфик). Открою ещё один секрет, gcc, например, тоже не реализовывает stricmp.
Вот я вообще не понял, для чего вы это написали. Есть стандарт для операционной системы, есть стандарты для языков, со своими стандартными библиотеками. Это разная вещь. Или вы предлагаете весь glibc запихать в ядро? А так да, каждая операционка предоставляет свой API, и вопрос какое api лучше: WinAPI или POSIX или ещё какое, к вопросу о компилятору языка отношения не имеет вообще.
Не понял про design-баг ну или багофичу. А нас это называется другими словами: кривые руки, распиздяйство, несостоятельность, и т.д. Помните, я рассказывал о соседнем департаменте с похожей проблемой? Ну так одного из них, кто нам слишком рьяно доказывал, что им это совершенно невозможно разобраться и поправить, один из нашего департамента однажды назвал жертвой аборта, но это уже слишком грубо на мой взгляд.
Рассказываю: просто наведите на переменную мышкой. Всплывёт окно (похожее на locals на скриншоте выше). Если std::vector<> заменить на std::list, то в визуализаторе ничего не поменяется, также все элементы будут видны. Новый скрин не прикладываю, так как там кроде замены vector на list ничего не поменялось. Но! Дальше я рекомендую меньше читать в инете, а больше пробовать самому. Вот попробуйте сами посмотреть как list будет показываться в отладчике.
Спасибо, но нет. Я уж лучше на плюсах, по старинке. Или уж на шарпах. Возвращаться к дельфи/билдеру желания нет.
Если верить вики по вашей ссылке, то там везде gcc 4.1 поддерживается. Не густо, конечно, но и не ужас с 2.95. Нам с Astra-linux больше повезло, gcc 4.9, код в бинарном виде сертифицируется, и потом будет ставится. А по поводу киллер-фич, то если вы незнакомы с C++11/C++14, и с тем, насколько сейчас проще и быстрее писать более безопасный код (например, сейчас даже new/delete уже не надо писать в коде), то нам не о чём дальше разговаривать.
Большая часть «киллер-фич» — языковые, они не увеличивают кол-во получаемого кода. Например, написание «auto it = » вместо «std::map<std::string, std::vector<std::string>>::const_iterator it = » ну никак не повлияет на размер кода. Тоже и с лямбдами, например, или с rvalue-ссылками.
Вообще ничего не понял про фрагментацию кучи. Это тут при чём?
Здесь вся надежда, что можно будет таких людей обязать, чтобы в коде не было новых ворнингов анализатора 1-го уровня, хотя бы.
Я уже написал выше, что ИМХО, это сильно зависит от человека. Тем, кто пишет быстро и грязно, а потом большую часть времени отлавливает баги, это реально может помочь. Мне вот в режиме инкременталки не часто помогает.
Так вот, в стандарте C++ нет ничего, например, про strcmpi. Но есть _strcmpi. Поэтому VS честно предупредит, если вы используете этот анахронизм. И да, как вы понимаете, я не говорю не про C++98, где strcmpi — это норма. Ну что же, за 19 лет мир немного поменялся.
А это к чему? Компилятор от MS сейчас вролне поддерживает стандарты C++. Да есть свои extension'ы, но ИМХО, в том же gcc их уже больше :-). А так, например VS 2013 поддерживала C++11 лучше, чем скажем вышедший одновременно Intel composer 2013.
Я скажу так, не бывает идеальных программ без багов, так как не бывает идеальных аналитиков, которые написали бы ТЗ без противоречий, не существует идеальных системных архитектов, не бывает идеальных программистов, которые написали бы код без багов, не бывает идеальных тестеров, которые не пропустили бы ни одной баги, и т.д…
То, что баги есть — это нормально, это надо понимать. Да что там, я лично более 2-х десятков багов репортил на vs connect. А вот то, что вы не слышали не про одну багу в продуктах ИНСАТ или любой другой компании, это не значит, что их там нет. У нас вот в компании тоже половина программистов свято уверена, что у наших клиентов нет никаких проблем, типа это они круто пишут, что багов мало, а те что есть, типа все находятся тестированием. А когда периодически всплывает, что дня без клиентской проблемы не обходится, так делают круглые глаза. Я к тому, что неспособность скомпилировать свой же код в релизе — говорит о многом. Я бы не хотел работать с такими партнёрами, чтобы они для меня код писали. И да, у меня соседний департамент имеет схожую проблему, они не умеют собирать дебажные сборки. Так что о проблеме, её источнике, и т.д., я знаю не понаслышке.
Ну, если вы так изначально рассчитывали, что же потом удивляетесь?
Вот если бы не хотели такого ограничения, то написали бы сразу exe, который рассчитывает, что ему пофигу с какой dll работать — с релизной или с дебажной. :-).
А если серьёзно, то у майкрософт таких ограничений, конечно же нет, это вы придумали. Вот гляньте на ffmpeg, например. Ты собрал dll'ки, хоть в релизе, хоть в дебаге, хоть другим компилятором, например интеловским. И дальше используй хоть в релизном, хоть в дебажном exe'шнике.
Я уже писал выше, что вы всё перепутали, и майкрософт наоборот, вместо нестандартных платформозависимых POSIX функций, ввела обычные стандартные, прямо из ISO C++, функции.
Скажу честно. Недоделанными их можно назвать, по сравнению с тем, что, например, Windbg умеет. Т.е. да, студия умеет следить только когда значение по некому адресу меняется (это именно то, что вы хотели). А про Си я вообще не понял.
Если вы не видите окна для просмотра структуры, то с вами пока неочём разговаривать. Смотреть и редоктировать данные можно во многих местах (Locals, Watch, да просто навести мышкой на переменную, и смотри/редактируй, сколько влезет.
Оно ещё живо? Ооо.
И что такого плохого, что компилятор стал работать согласно стандарту ISO C++, что об этом не стоит говорить? При этом не стандартные имена он так же поддерживает, но честно предупреждает, что если вы хотите, чтобы ваш код соответствовал стандарту и был кросс-платформенным, надо использовать не некие платформо-специфические функции, а их стандартные аналоги.
Ну что, поздравьте ваших коллег.
Вот вы явно со студией не работали нормально (это видно хотя бы по тому, что не знаете как переменные смотреть). Да, что-то прочитали в инете и как-то интерпретировали, что-то в курилки услышали от горе-коллег-партнёров… Поэтому от вас такой вывод странно слышать. Я как активный пользователь VS под винду и QtCreater под линукс (второе только для отладки) могу ответственно заявить, что отлаживаться в студии гораздо удобнее.
Это я пошутил так.
Я бы с этим согласился, если бы не то обстоятельство, что один из этих компиляторов даже не знает о существовании C++03, C++11, C++14. Вот сейчас всё просто. Мы когда под gcc портировали с VS2013, там уже такие мелочи оставались… В основном, замена WinAPI'шных функций на std аналоги…
Конечно не чисто. Но к сожалению у нас даже на -w3 чисто в единичных случаях. Даже ворнинги w1 ещё остались. Вообще есть проекты (рабочие, не заброшенные) с больше 300 ворнингов на w3.
В принципе, находит. Т.е. это не бесполезный инструмент. Но ужас-ужас больше шансов найти при первой проверке многолетнего проекта. Так вот, чтобы в моём новом коде ужас-ужас находился на инкременталке, даже и не вспомню. Хотя, свеже-добавленые баги от коллег периодически находит, и даже ужас-ужас встречается.
Постоянно пользоваться на самом деле не хочется, а то вот меня уже Андрей Карпов в почте обвинил в том, что я пользуюсь крякнутой версией, потому что когда я рапортовал им багу про ложное срабатывание, там не было комментариев «Dear PVS...». Да и поддержать хочется российского производителя. Поэтому я и пытаюсь уже сколько времени выбить денег на коммерческую версию у руководства. Хотя чувствую, что с 330 т.р за 9 человек многовато будет, такое никто не одобрит, походу придётся и дальше на триалке сидеть :-(…
Вы не поверите, лучшая иде всех времён и народов, ака 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? :)
Qt Creater вроде как только в utf работает. Visual Studio тоже без разницы, в локальной там или в utf'е, главное, чтобы BOM был. Если какие-то среды, которые BOM в файлах не понимают?
Я вот уже несколько лет пользуюсь триалкой. И моё мнение сейчас такое, что это сильно от человека зависит. Например, мне он точно за год использования инкрементального анализа больше дня за прошлый год не съэкономил. Думаю, это у меня привычка, писать «чистый» код есть. Но вот есть чел, он периодически фигню коммитит. Вот ему бы такое неделю съэкономило бы времени. Другой человек, тоже практически говорит, что нет срабатываний на инкременталке, но он тоже сразу хороший код пишет. С другой стороны, одна «паршивая овца», может время много всем попортить, т.е. пропустит какой баг, он у тестирования вылезет, пока бюрократическая машина закрутится, не факт, что именно этот чел править будет, и т.д. Т.е. я думаю, что есть разработчики, которым если дать такой инструмент, то компании это реально полторы-две недели в год времени съэкономит. Маленьким компаниям проще, тут все навиду, обычно уровень разработчиков повыше, чем в больших монстрах, с кучей студентов. Поэтому я и говорю про среднюю неделю на разработчика, и не думаю, что в маленьких компаниях эта цифра будет больше.
Под ФОП — понимается не запрлата одного человека, а группы людей. Т.е. ФОП на 50 разработчиков ~ в 10 раз больше, чем ФОП на 5 разработчиков.