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

L>Во-первых, не "ничего не работает", а "не проходит тест А", что означает, что "алгоритм не выдает ожидаемый результат в определенных контролируемых условиях". К примеру, "ломается на граничных условиях". "Расходится при определенных валидных данных". "Падает на неправильных данных".
L>Как правило, этой информации достаточно для быстрой локализации и исправления ошибки.

По-моему — как повезёт. Может хватить, а может и нет

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

дело это вообще неблагодарное

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

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

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

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

Дьявол кроется в деталях выделенном.
Не всегда просто и нифига не быстро.
В моей практике это сложно и геморройно. И еще объемно.

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

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

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

A>>Что-то ты белаешь неправильно. Это твой проект?

__>да

Тогда ты свободен в экспериментировании. Экспериментируй!

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

__>думаю, из-за шаблонов

Я тоже так думаю, но есть инструмент, а есть умение его применять.

__>несжатых у меня собственных файлов (не включая библиотек) — 9Мб

Это очень много. Как ты их вообще в голове держишь?
У меня текста на порядок меньше и без шаблонов. Тебе действительно столько надо?

A>>Если правка в одном файле — то я просто не успеваю морнуть.

__>смотря в каком. если в cpp, который к тому же слабо связан с другими, то конечно, будет быстро

Умение писать несвязаннае файлы — отдельное колдунство. От языка не зависит.

A>>Может быть не нужны тебе эти шаблоны?
A>>Чё зря страдать-то?

__>потому что, во-первых, они убирают дублирование кода,

По таким фразам видно очень молодого программиста, который пока очень мало книг прочитал.
Где они убирают дублирование кода? Не дублируй код. Ты что, сотню типов расплодил? Не плоди типы.
Вот статья "как два программиста пекли хлеб":
https://habrahabr.ru/post/153225/

__>а во-вторых, речь жла не об этом,а о том, что с++ идет по пути все большей шаблонизации, а тут такая засада

Разумеется. Но тут уж твоя свобода воли — хочешь ты за компанию удавиться или нет.

Давай ещё пару советов дам.

1) Ну вот например шаблоны. Зачем они тебе нужны?
Шаблоны пошли в С++ мир из STL. Ты используешь именно STL?
Вот я пишу на Qt. А там — своя библиотека контейнеров.
И почему-то эти шаблоны собираются за секунды.

2) Можно писать вот так:

// главный и единственный компилируемый файл
# include <stl_all>

# include <my_first_file.cpp>
# include <my_second_file.cpp>
...

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

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

L>>Как правило, этой информации достаточно для быстрой локализации и исправления ошибки.
T>По-моему — как повезёт. Может хватить, а может и нет

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

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

__>спасибо. а что делать с
__>

__>1.h
__>class CFoo
__>{
__>public:
__> struct TFoo{}
__>};

__>2.h

__>void foo(CSubFoo::TFoo& X);
__>

1) Сделать 1.h максимально дешёвым и включать его в 2.h
2) Вынести TFoo на уровень неймспейса и предобъявлять (в том числе шаблоны — их тоже можно предобъявлять)
3) Разнести CFoo на две части, одну лёгкую с определениями зависимых имён — и включать в 2.h, вторую тяжёлую унаследовать от первой и поместить в другой хедер 1impl.h

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

T>>А можно метрики проекта? Сколько строк кода, какие библиототеки используете?
__>2Mb чистого текста в rar-формате

А сколько в строках? (в студии, в проекте, ctrl+shift+f , во всём солюшене , use regular expressions , найти конец строки, в последней строке — в результатах — будет указано количество строк )

__>cereal (вот после начала его использования, субъективно, все и начало тормозиться)
Посмотрел исходники и возник вопрос: а как там с обратной совместимостью по данным? Имя какой-нибудь сереализуемой переменной уже пробовал поменять?

Здравствуйте, Stanislav V. Zudin, Вы писали:

L>>Если вы подозреваете, что в алгоритме есть баг, просто пишете тест, воспроизводящий условия, при котором, как вы подозреваете, алгоритм ломается. Это просто и быстро. Проверяете свои подозрения. В отладчике в общем случае это сделать уже невозможно.
SVZ>Дьявол кроется в деталях выделенном.
SVZ>Не всегда просто и нифига не быстро.

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

SVZ>В моей практике это сложно и геморройно. И еще объемно.

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

SVZ>Как правило это добрая сотня строк, чтобы сварганить минимально-необходимый набор данных. И еще сотня — чтобы проверить результат. Написание одного теста занимало по полдня без перекуров. Работа алгоритма же не сводится к булевскому значению.

И это тоже индикатор

SVZ>Из полученных данных еще надо выудить нечто, что можно проверить. И в каждом тесте это "нечто" будет разным.

Это как раз не проблема

SVZ>Из-за этого у нас прижились рантайм проверки (ассерты) всего и вся и отладчик.

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

Тестами можно сделать все, что можно сделать отладчиком. Только намного быстрее и автоматизировано.
И еще много чего такого, что отладчиком сделать вообще никак нельзя.

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

A>2) Можно писать вот так:
A>

A>// главный и единственный компилируемый файл
A># include <stl_all>

A># include <my_first_file.cpp>
A># include <my_second_file.cpp>
A>...
A>

Только если заранее к этому не готовиться, то такое может совсем не просто оказаться.

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

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

Story of my life.

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

Дело в том, что это не вина человека. Просто ему не повезло быть частью команды с правильно поставленным процессом. Неведомо ему, что это есть хорошо... ой... не, мы и правда иногда напоминаем церковь свидетелей ASSERT_EQ()

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

L>Тестами можно сделать все, что можно сделать отладчиком. Только намного быстрее и автоматизировано.
L>И еще много чего такого, что отладчиком сделать вообще никак нельзя.

Не понимаю, как вообще можно сравнивать тесты и отладчик.

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

T>Не понимаю, как вообще можно сравнивать тесты и отладчик.

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

Здравствуйте, landerhigh, Вы писали:
L>Я вот не понимаю, зачем при разработке новой функциональности вообще может потребоваться отладчик.
последний раз я дебагер запускал по-моему в 2013ом. а последний раз мысль "мм, как удобно иметь дебагер, надо его запустить" была году в 2008ом где-то

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

L>>Я вот не понимаю, зачем при разработке новой функциональности вообще может потребоваться отладчик.
__>последний раз я дебагер запускал по-моему в 2013ом. а последний раз мысль "мм, как удобно иметь дебагер, надо его запустить" была году в 2008ом где-то

Простите, landerhigh и __kot2, чисто интересно:

1. Пишете ли вы код сами?
2. На каком языке программирования/платформе/IDE?

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

__>>последний раз я дебагер запускал по-моему в 2013ом. а последний раз мысль "мм, как удобно иметь дебагер, надо его запустить" была году в 2008ом где-то
D>Простите, landerhigh и __kot2, чисто интересно:

D>1. Пишете ли вы код сами?

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

D>2. На каком языке программирования/платформе/IDE?

Плюсы в основном. Под Windows, почти все юниксы, микроконтроллеры, даже vxWorks было дело. Студия, vim, gcc и прочая чертовщина.
Java еще есть под Андроид, там тоже без юнит-тестов не обходится.
Scheme опять же в качестве DSL. С юнит-тестами.

Ты думал, мы теоретики? Наоборот, прожженые циничные практики, сконвертировавшие в свою веру уже пару десятков юных падаванов

Здравствуйте, Dair, Вы писали:
D>1. Пишете ли вы код сами?
конечно, дофига

D>2. На каком языке программирования/платформе/IDE?
C++/Python/Far/mc
иногда студией пользуюсь чисто как текстовым редактором, открывая только отдельные файлы, без проекта

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

D>>1. Пишете ли вы код сами?
L>Очень много, наверное, пора даже несколько завязывать.

Знакомо

D>>2. На каком языке программирования/платформе/IDE?

L>Плюсы в основном. Под Windows, почти все юниксы, микроконтроллеры, даже vxWorks было дело. Студия, vim, gcc и прочая чертовщина.
L>Java еще есть под Андроид, там тоже без юнит-тестов не обходится.

Круто

L>Scheme опять же в качестве DSL. С юнит-тестами.

DSL?..

L>Ты думал, мы теоретики? Наоборот, прожженые циничные практики, сконвертировавшие в свою веру уже пару десятков юных падаванов
Как вступить? Где почитать скрижали, евангелие?

Я просто тут вот прямо сейчас пишу C++/JNI/Java под Android, без отладчика C++ как без рук. Причём платформенно-зависимый код, вне андроида не отладиться.
Коллега как-то умудрился настроить Visual Studio для отладки Android-C++ кода, но у меня OS X и, как следствие, Visual Studio нет.

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

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

__>>извините, но вы здесь описали вариант, когда либо готовый код правится, либо к готовому коду добавляется еще один готовый функциональный блок, и проверяется их совместимость. я нигде не увидел собственного написания.

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

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

L>Вот сходил ты в курилку и придумал, что назовешь свою функцию



L>Ты мне лучше скажи, зачем тут вообще отладчик может понадобиться?

см. ветку "дебагинг vs unit-тесты"

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

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

T>>>А можно метрики проекта? Сколько строк кода, какие библиототеки используете?
__>>2Mb чистого текста в rar-формате

BFE>А сколько в строках? (в студии, в проекте, ctrl+shift+f , во всём солюшене , use regular expressions , найти конец строки, в последней строке — в результатах — будет указано количество строк )

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

//---
if()
{
      //---
    <...>
    //---
};
//---

что увеличивает количество строк по сравнению с

if(){
  <...>
};

__>>cereal (вот после начала его использования, субъективно, все и начало тормозиться)
BFE>Посмотрел исходники и возник вопрос: а как там с обратной совместимостью по данным? Имя какой-нибудь сереализуемой переменной уже пробовал поменять?

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

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

D>Круто

Да ладно, тут гораздо более крутые люди присутствуют.

L>>Scheme опять же в качестве DSL. С юнит-тестами.
D>DSL?..

Domain-Specific language

L>>Ты думал, мы теоретики? Наоборот, прожженые циничные практики, сконвертировавшие в свою веру уже пару десятков юных падаванов
D>Как вступить? Где почитать скрижали, евангелие?

А вот ч.е.з. Существует куча книг, но мой опыт показывает, что книги сами не объясняют ничего такого, чего разработчик не знал бы сам.
Тут практика нужна. В идеале — практика в присутствии адепта церкви TDD. Если на проекте попадается фанатик вроде меня, то переход происходит относительно плавно и безболезненно, замечено на многих проектах.
Иначе придется ломать привычки, что самому, да без поддержки, намного тяжелее.

D>Я просто тут вот прямо сейчас пишу C++/JNI/Java под Android, без отладчика C++ как без рук. Причём платформенно-зависимый код, вне андроида не отладиться.
D>Коллега как-то умудрился настроить Visual Studio для отладки Android-C++ кода, но у меня OS X и, как следствие, Visual Studio нет.

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