Здравствуйте, _hum_, Вы писали:

__>Разработчики языка вообще в эту сторону смотрят?

У нас один модуль полная перекомпиляция — 13 часов. В проекте около 200 модулей. Полностью перекомпилить проект уже никто не рискует как лет 5. Можно не дождаться, на пенсию выйти.

Здравствуйте, _hum_, Вы писали:

__>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) ...
__>Разработчики языка вообще в эту сторону смотрят?
Компиляция больших с++ проектов это решенная инженерная задача. Просто, никто не делится решениями.
Для интерактивной сборки разработчики используют 1-2 конфигурации. В них
а) все разбито на бинарные модули (убирает линковку всего вместе), даже если финальная сборка это 1 исполняемый файл;
б) в каждом модуле есть forward declarations где разрешен только небольшой набор типов.
в) в каждом модуле есть pch
г) автоматически мелкие cpp файлы объединяются группами (unity build), в теме был пример как это делать руками;
д) компиляция запускается на кластере из множества машин (даже если это только машины коллег это все равно дает много);
е) используется кеш с результатами компиляции (заполняется чистым билдом ночью).
...

в домашних условиях обычно никто не идет дальше первых трех пунктов и просто дозакупают железо тк "(на двухядерном 2ГГц и 4Г памяти)" бороться за время компиляции несерьезно.
Настоящие неудобства большие/сложные проекты приносят, когда надо туда заливать большие изменения а не при компиляции =)

Здравствуйте, SleepyDrago, Вы писали:

SD>Здравствуйте, _hum_, Вы писали:

__>>Не совсем понимаю, как разрабатываются большие проекты на С++? У меня он пока средний — около 2 Mb в архиве, и уже сейчас время перекомпиляции — около 20 минут (на двухядерном 2ГГц и 4Г памяти) ...
__>>Разработчики языка вообще в эту сторону смотрят?
SD>Компиляция больших с++ проектов это решенная инженерная задача. Просто, никто не делится решениями.
SD>Для интерактивной сборки разработчики используют 1-2 конфигурации. В них

	текст
	SD>а) все разбито на бинарные модули (убирает линковку всего вместе), даже если финальная сборка это 1 исполняемый файл; SD>б) в каждом модуле есть forward declarations где разрешен только небольшой набор типов. SD>в) в каждом модуле есть pch SD>г) автоматически мелкие cpp файлы объединяются группами (unity build), в теме был пример как это делать руками; SD>д) компиляция запускается на кластере из множества машин (даже если это только машины коллег это все равно дает много); SD>е) используется кеш с результатами компиляции (заполняется чистым билдом ночью). SD>...

ну так, это же "ужас-ужас-ужас" — превращать подготовку к компиляции в отдельную инженерную задачу. эдак со временем стоит ожидать появления "специалиста по предкомпиляционной подготовке с++ проекта".

SD>в домашних условиях обычно никто не идет дальше первых трех пунктов и просто дозакупают железо тк "(на двухядерном 2ГГц и 4Г памяти)" бороться за время компиляции несерьезно.

я ж вам при вел пример — в "домашних условиях" на не слишком большом проекте на перекомпиляцию тратится 20-40 минут, что при разработке — непозволительная потеря времени.

SD>Настоящие неудобства большие/сложные проекты приносят, когда надо туда заливать большие изменения а не при компиляции =)

по-моему, эти проблемы ортогональны

Здравствуйте, Мёртвый Даун, Вы писали:

МД>У нас один модуль полная перекомпиляция — 13 часов. В проекте около 200 модулей. Полностью перекомпилить проект уже никто не рискует как лет 5. Можно не дождаться, на пенсию выйти.

Боже, что вы такое пишете?

В репозитории лежат собранные бинарники?

Вот приходит новый человек — он делает клон репозитория и... что?

Здравствуйте, __kot2, Вы писали:

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

простите, так вася тестировщик или девелопер?

Здравствуйте, __kot2, Вы писали:

__>> "Сценарии покрыты на 100%"
__>>это примерно как заявить — код написан на 100% без ошибок. "ваши доказательства?"
__>ну кодом же вы как-то покрываете сценарии исполнения?

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

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

__>Вася что-то написал, приносит код, мы открываем папочку с тестами и видим
__>чяща -> чаща
__>жыр -> жир
__>несделал -> не сделал

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

__>Петя отдает код и говорит "ну и задачку же вы мне подсунули". короче, говорит, я там что-то написал, я проверил у себя на компе там, я ему тест создал, просто опечаток понараскидал, он нашел 70%. улучшить можно, но пока не знаю как.
__>вы можете выбрать какой код развивать. и какой будете — Васин, который понятно что делает или Петин, который вообще непонятно что делает?
Действительно, у Васи всё понятно: опечатка — исправление. А у Пети не пойми что, какой-то нечёткий поиск, вероятности, проценты...

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

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

Здравствуйте, B0FEE664, Вы писали:
BFE>Бывает так, что в сложных, развитых проектах некоторые части кода не вызываются никогда за время эксплуатации (даже при массовом использовании).
и этот код должен быть удален

__>>вы можете выбрать какой код развивать. и какой будете — Васин, который понятно что делает или Петин, который вообще непонятно что делает?
BFE>Действительно, у Васи всё понятно: опечатка — исправление. А у Пети не пойми что, какой-то нечёткий поиск, вероятности, проценты...
ну то есть берем код Пети?

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

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

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

Здравствуйте, __kot2, Вы писали:

BFE>>Бывает так, что в сложных, развитых проектах некоторые части кода не вызываются никогда за время эксплуатации (даже при массовом использовании).
__>и этот код должен быть удален
Нет, не должен. Это, например, может быть код обрабатывающий ошибку записи данных на диск. И этот код никогда не вызывался потому, что на всех десяти тысячах машинах этой ошибки не произошло просто потому, что эксплуатационники тщательно следят за состоянием дисков и меняют их раньше, чем начинают происходить массовые ошибки.

__>>>вы можете выбрать какой код развивать. и какой будете — Васин, который понятно что делает или Петин, который вообще непонятно что делает?
BFE>>Действительно, у Васи всё понятно: опечатка — исправление. А у Пети не пойми что, какой-то нечёткий поиск, вероятности, проценты...
__>ну то есть берем код Пети?
Может — да, а может и нет. Выбор может быть сделан по другому критерию.

BFE>>Ну, серьёзно: на практике есть классы задач, которые никак не покрываются тестами (классический пример — числа неограниченной длины) или же написание тестов превосходит по затратам написание кода на несколько порядков — это, как правило, задачи связанные с реальным миром: интерфейс, реалтайм системы, время, перегрузка входными данными от датчиков...
__>когда у вас не только Вася и Петя, а команда человек 20, вносящая хаотичные правки, то вам уже на самом деле без разницы на демагогию про что можно, а что нельзя, для вас написание юнит тестов будет единственным способом релизить проект во вменяемом состоянии. а по интересному стечению обстоятельств именно именитые говнокодеры будут ныть, что тесты писать долго и д-но будут выдавать очень запутанные невероятно гигантские тесты, которые еще и ничего не тестируют. потому что тестировать говнокод очень сложно.
Тесты, как средство управления проектом — ok, а вот как средство разработки — подходит не для всех задач.

Здравствуйте, _hum_, Вы писали:
__>>при этом, понимаете, Вася создал огромную ценность в виде минимальных некорректных примеров разных классов, а Петя просто проторчал в дебагере, выискивая какие-то опечатки, по всей видимости, еще и не все найденные. есть желание заниматься поиском его опечаток?
__>простите, так вася тестировщик или девелопер?
вообще, этот подход с тестами стал вырисовываться в начале 2000ых — пришло наверное даже их спортивного программирования, но адаптированного к реальному миру.
помню, году в 2005ом были предложения у нас по проекту так сделать, но непонятно было как наш говнокод переписывать. самые прошаренные именно тогда и стали переходить и даже тормозной микрософт, позже всех, 3 года назад перешел на эту схему.
почти все сильные программисты, с которыми я когда-то работал по разны причинах, в разные компании, свалили из России. и вот остались по всей видимости те, кто остает от общего мирового тренда в разработке, лет, уже получается, на 10. это меня, конечно, удивило очень сильно, прямо мега-открытие. когда люди в 2016ом году говорят про девелоперов и тестеров, размышляют о преимуществах дебагера или о невозможности написания тестов — это сильно! это сильная заявка в мировые аутсайдеры разработки

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, _hum_, Вы писали:
__>>>при этом, понимаете, Вася создал огромную ценность в виде минимальных некорректных примеров разных классов, а Петя просто проторчал в дебагере, выискивая какие-то опечатки, по всей видимости, еще и не все найденные. есть желание заниматься поиском его опечаток?
__>>простите, так вася тестировщик или девелопер?
__>вообще, этот подход с тестами стал вырисовываться в начале 2000ых — пришло наверное даже их спортивного программирования, но адаптированного к реальному миру.
__>помню, году в 2005ом были предложения у нас по проекту так сделать, но непонятно было как наш говнокод переписывать. самые прошаренные именно тогда и стали переходить и даже тормозной микрософт, позже всех, 3 года назад перешел на эту схему.
__>почти все сильные программисты, с которыми я когда-то работал по разны причинах, в разные компании, свалили из России. и вот остались по всей видимости те, кто остает от общего мирового тренда в разработке, лет, уже получается, на 10. это меня, конечно, удивило очень сильно, прямо мега-открытие. когда люди в 2016ом году говорят про девелоперов и тестеров, размышляют о преимуществах дебагера или о невозможности написания тестов — это сильно! это сильная заявка в мировые аутсайдеры разработки

столько текста, и только одни эмоции. вы точно профессионал ?

если все такие отсталые, зачем же до сих пор идет поддержка и усовершенствование дебагера?

ну и, в конце-концов, читаем Test-driven_development#Limitations и убеждаемся, что не все так гладко, как в песне поется.

Здравствуйте, _hum_, Вы писали:

L>>Еще раз напомню — с вопросами веры в другой форум.

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

Ээээ, ты опять не понял смысла юнит-тестирования и TDD в частности.
Юнит-тесты не являются black-box тестами и в общем случае они не верифицируют правильность алгоритма.
Юнит-тесты верифицируют, что поведение юнита соответствует ожидаемому в определенных условиях. Хорошие юнит тесты покрывают все возможные типы условий. Когда все граничные (все виды граничных) условий покрыты, а у хорошего тестируемого кода этих видов крайне мало, то верификация алгоритма может быть проведена по индукции на основании прохождения тестов на ограниченном наборе данных.
На практике это означает, что достаточно того, что написаны тесты, которые проверяют поведение вокруг всех ветвлений, переполнения и т.п., и на некоем ограниченном наборе валидных данных.

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

Здравствуйте, _hum_, Вы писали:

__>ну и, в конце-концов, читаем Test-driven_development#Limitations и убеждаемся, что не все так гладко, как в песне поется.

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

Здравствуйте, B0FEE664, Вы писали:

BFE>реалтайм системы, время, перегрузка входными данными от датчиков...

прекрасно тестируется.
Только это уже не юнит-тесты.

Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции.

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, __kot2, Вы писали:

BFE>>>Бывает так, что в сложных, развитых проектах некоторые части кода не вызываются никогда за время эксплуатации (даже при массовом использовании).
__>>и этот код должен быть удален
BFE>Нет, не должен. Это, например, может быть код обрабатывающий ошибку записи данных на диск.

Такой код может и должен быть протестирован.

BFE>Тесты, как средство управления проектом — ok, а вот как средство разработки — подходит не для всех задач.

Не подходит для крайне малого домена задач.

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, _hum_, Вы писали:

__>>ну и, в конце-концов, читаем Test-driven_development#Limitations и убеждаемся, что не все так гладко, как в песне поется.

L>Подавляющее большинство разработчиков в своей жизни столкнутся лишь с одним ограничением TDD: нежелание (неумение) вести разработку в стиле TDD сводит все его преимущества на нет и даже хуже.

Ой-ли. А

Test-driven development does not perform sufficient testing in situations where full functional tests are required to determine success or failure, due to extensive use of unit tests.[21] Examples of these are user interfaces, programs that work with databases, and some that depend on specific network configurations.

Unit tests created in a test-driven development environment are typically created by the developer who is writing the code being tested. Therefore, the tests may share blind spots with the code: if, for example, a developer does not realize that certain input parameters must be checked, most likely neither the test nor the code will verify those parameters. Another example: if the developer misinterprets the requirements for the module he is developing, the code and the unit tests he writes will both be wrong in the same way. Therefore, the tests will pass, giving a false sense of correctness.

A high number of passing unit tests may bring a false sense of security, resulting in fewer additional software testing activities, such as integration testing and compliance testing.

Ну и, наконец, из Software_testing:

Testing tools

Program testing and fault detection can be aided significantly by testing tools and debuggers. Testing/debug tools include features such as:

Program monitors, permitting full or partial monitoring of program code including:
Instruction set simulator, permitting complete instruction level monitoring and trace facilities
Hypervisor, permitting complete control of the execution of program code including:-
Program animation, permitting step-by-step execution and conditional breakpoint at source level or in machine code
Code coverage reports
Formatted dump or symbolic debugging, tools allowing inspection of program variables on error or at chosen points
Automated functional GUI testing tools are used to repeat system-level tests through the GUI
Benchmarks, allowing run-time performance comparisons to be made
Performance analysis (or profiling tools) that can help to highlight hot spots and resource usage

Some of these features may be incorporated into a single composite tool or an Integrated Development Environment (IDE).

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, _hum_, Вы писали:

L>>>Еще раз напомню — с вопросами веры в другой форум.

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

L>Ээээ, ты опять не понял смысла юнит-тестирования и TDD в частности.
L>Юнит-тесты не являются black-box тестами и в общем случае они не верифицируют правильность алгоритма.
L>Юнит-тесты верифицируют, что поведение юнита соответствует ожидаемому в определенных условиях. Хорошие юнит тесты покрывают все возможные типы условий. Когда все граничные (все виды граничных) условий покрыты, а у хорошего тестируемого кода этих видов крайне мало, то верификация алгоритма может быть проведена по индукции на основании прохождения тестов на ограниченном наборе данных.
L>На практике это означает, что достаточно того, что написаны тесты, которые проверяют поведение вокруг всех ветвлений, переполнения и т.п., и на некоем ограниченном наборе валидных данных.

L>И еще немаловажная вещь — программист должен очень хорошо понимать, что именно он делает, для того, чтобы написать хороший код и тесты к нему.

ну, раз так (если тес ты — не для поиска ошибок, а для проверки соответствия функциональным требованиям), тогда зачем же вы тут дружно с __kot2 пытаетесь нас заставить отказаться от дебагера?

Здравствуйте, _hum_, Вы писали:
__>ну, раз так (если тес ты — не для поиска ошибок, а для проверки соответствия функциональным требованиям), тогда зачем же вы тут дружно с __kot2 пытаетесь нас заставить отказаться от дебагера?
я не убеждаю отказаться. мне это зачем? мне же с вами не работать. а если бы работал, тут был бы вопрос субординации. вы бы мной командовали — уволился бы. я бы вами — просто бы заставил писать тесты.
я просто пишу, что пользоваться дебагером это извращение. да, он совершенствуется, что извращенцев, чтоли, мало разных?

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

вспоминая еще одного персонажа — как говорил Гомер Симпсон — "это противоествественно. и должно быть противозаконно!"

Здравствуйте, landerhigh, Вы писали:

BFE>>реалтайм системы, время, перегрузка входными данными от датчиков...
L>прекрасно тестируется.
L>Только это уже не юнит-тесты.
Ну как "прекрасно". Может оказаться, что для этого надо затратить труд превосходящий по времени написание приложения.

L>Время, кстати, тоже тестируется, если выбраны правильные уровни абстракции.
Не совсем понятно, как вам помогут уровни абстракции и причём они тут. Багов связанных со временем очень много, они весьма разнообразны и встречаются во всех системах. Apple, MS и Unix страдают ими перманентно. Думаете многие готовы к проблеме 2038-ого года или хотя бы задумываются/знают о ней? А ведь осталось каких-нибудь 22 года.

Здравствуйте, landerhigh, Вы писали:

BFE>>>>Бывает так, что в сложных, развитых проектах некоторые части кода не вызываются никогда за время эксплуатации (даже при массовом использовании).
__>>>и этот код должен быть удален
BFE>>Нет, не должен. Это, например, может быть код обрабатывающий ошибку записи данных на диск.
L>Такой код может и должен быть протестирован.
Может и должен. Что не отменяет того факта, что за всё время эксплуатации он никогда не будет вызван.
Кстати, можете предложить не инвазивный способ тестирования?

BFE>>Тесты, как средство управления проектом — ok, а вот как средство разработки — подходит не для всех задач.
L>Не подходит для крайне малого домена задач.
Да ладно! Есть большие классы задач, которые сложно или крайне сложно протестировать. Давайте, предложите тест для проверки отрисовки, скажем, кнопки.

Здравствуйте, _hum_, Вы писали:

L>>И еще немаловажная вещь — программист должен очень хорошо понимать, что именно он делает, для того, чтобы написать хороший код и тесты к нему.

__>ну, раз так (если тес ты — не для поиска ошибок, а для проверки соответствия функциональным требованиям), тогда зачем же вы тут дружно с __kot2 пытаетесь нас заставить отказаться от дебагера?

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