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

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

A>>

A>># include <stl_all>

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

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

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

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

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

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

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

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

__>>да

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

чем и занимаюсь

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

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

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

потому и спрашиваю у тех, кто умеет

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

A>Это очень много. Как ты их вообще в голове держишь?

держусь из последних сил

A>У меня текста на порядок меньше и без шаблонов. Тебе действительно столько надо?

да, так выходит (это типа gui для сапра + движок самого объекта управления для возможности проведения эумляции)

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

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

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

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

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

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

A>По таким фразам видно очень молодого программиста, который пока очень мало книг прочитал.

(с с++ я уже 14 лет знаком и время от времени на нем пишу)

A>Где они убирают дублирование кода? Не дублируй код. Ты что, сотню типов расплодил? Не плоди типы.

stl + boost + cereal как минимум


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

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

я просто не думал, что все так плохо... (до этого времени ен приходилось сталкиваться с такого объема проектами)

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

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

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

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

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

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

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

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

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

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

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

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

__>>2.h

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

К>1) Сделать 1.h максимально дешёвым и включать его в 2.h

но он логически не соответствует 2.h (в них лежат отдельные классы объектов)

К>2) Вынести TFoo на уровень неймспейса и предобъявлять (в том числе шаблоны — их тоже можно предобъявлять)

в смысле, можно писать NsFoo::TFoo; где NsFoo — namespace?

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

тоже техническое решение

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

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

да, но и проблем с ними уйма (искать баги работы из-за неперекомпилированного кода — еще та радость)

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

B>>Должны прилично ускорить сборку в случае массового использования больших хидеров, иногда даже в несколько раз.
__>да, но и проблем с ними уйма (искать баги работы из-за неперекомпилированного кода — еще та радость)

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

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

К>>1) Сделать 1.h максимально дешёвым и включать его в 2.h
__>но он логически не соответствует 2.h (в них лежат отдельные классы объектов)

Как же он не соответствует, если 2.h использует объявления из 1.h ?

К>>2) Вынести TFoo на уровень неймспейса и предобъявлять (в том числе шаблоны — их тоже можно предобъявлять)
__>в смысле, можно писать NsFoo::TFoo; где NsFoo — namespace?

Ну, или на уровень неймспейса ::
Главное, что глобальные имена можно предобъявлять сами по себе, а зависимые — только в определении класса. А частичных классов в С++ нет.
Кстати, на всякий случай. Внутри класса можно делать предобъявления — на этом строится и идиома пимпл

///// публичный хедер
class Foo {
  class Impl;
  some_ptr<Impl> impl_;
     // если std::unique_ptr, то все конструкторы и деструктор Foo надо перенести в файл с объявлением Foo::Impl
     // если std::shared_ptr - то лишь код, инициализирующий этот указатель
  .....
};
///// частный файл с реализацией
class Foo::Impl { ..... };

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

Частичные классы для бедных

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

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

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

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

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

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

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

Была же недавно подобная тема. Первое, что начнут втирать, так это установка SSD для ускорения перекомпиляции, именно пере, а не компиляции. На что я могу сказать, что прежде чем втыкать SSD не мешало бы купить быстрый компьютер с высокоскоростными портами к которым он будет подключен, а для опытов можно вообще ничего не покупать, а создать RAM диск, то есть диск в оперативной памяти. Далее должна быть включена многопоточная компиляция (количество логических ядер + 1), иначе толку с ядер не будет, и лучше чтобы при одинаковой общей производительности была более высокая производительность на ядро.

__>Из тех мер, что предлагается, самая естественная — forward declaration, но, во-первых, она работает только с классами верхнего уровня (сделать что-то наподoбие class CFoo::CSubFoo; уже нельзя), а во-вторых, и там есть подводные камни: Google C++ Style Guide/Forward_Declarations.

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

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

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

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

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

А что для тестов и моков используете? Свой велосипед/gtest/boost/...?

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

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

m2l>А что для тестов и моков используете? Свой велосипед/gtest/boost/...?

Больше гуглевым, конечно.
Но это вопрос привычки больше.

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

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

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

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

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

/cereal/serialization_archives
Out of order loading

The default behavior for all archives is to sequentially load data in the order in which it appears. XML (and JSON) archives support out of order loading, meaning that you can utilize name-value pairs to load data in an order different to that in which it appears in the XML file.

When cereal detects that you are using an NVP to load data from an XML archive, it checks to see if the name matches the next expected (in order) name. If they don't match, cereal will search for the provided name within the current level of nodes. If the name isn't found an exception will be thrown. Once cereal finds and loads the name, it will proceed sequentially from that location until forced to search for another name via an NVP.

...

Important! cereal's default behavior is to load in the order data is presented in an archive. If you use an NVP to load something out of order, cereal will immediately revert to this behavior starting at the node you caused it to jump to.

__>>а зачем менять имя? ясно же, что если она не найдет нужной метки, то будет ругаться.
BFE>Может код изменился, структура хранения поменятся, скажем раньше имя и путь файла хранились отдельно, а теперь — в одной переменной.

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

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

см. выше.

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

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

К>>>1) Сделать 1.h максимально дешёвым и включать его в 2.h
__>>но он логически не соответствует 2.h (в них лежат отдельные классы объектов)

К>Как же он не соответствует, если 2.h использует объявления из 1.h ?

использует и соответствует — разные вещи (это как использовать ключ от квартиры — он соответствует квартире, а не тому, кто им пользуется)

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

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

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

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

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

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

	code
	L> L> Matrix transpose(const Matrix& original); L> L>Налил кофе и написал следующие три теста L> L> TEST(transposeMatrix, transposeNegative) L> { L> // this is more a border case test L> ASSERT_TRUE(transpose(emptyMatrix).empty()); // Also checks that we don't crash if matrix is empty L> } L> TEST(transposeMatrix, transposePositiveSymmetrical) L> { L> Matrix symmetricalMatrix = ...; // Initialize L> Matrix expected = ...; // Manually transposed matrix L> ASSERT_EQ(expected, transpose(symmetricalMatrix)); L> ASSERT_EQ(symmetricalMatrix, transpose(transpose(symmetricalMatrix))); L> } L> TEST(transposeMatrix, transposePositiveAsymmetrical) L> { L> Matrix asymmetricalMatrix = ...; // Initialize L> Matrix expected = ...; // Manually transposed matrix L> ASSERT_EQ(expected, transpose(asymmetricalMatrix )); L> ASSERT_EQ(asymmetricalMatrix , transpose(transpose(asymmetricalMatrix ))); L> } L>

L>Потом написал собственно код транспонирования.

L>Запустил тест. На все-про-все 5 минут времени и у тебя гораздо более полное покрытие, нежели ты может добиться ручными проверками в отладчике.

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

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

ну, например, в коде вы сделали описку — вместо resulted[i][j] = original[j][i] написали resulted[i][j] = original[i][j]Э, или у вас эксепш при вызове функции вылетает (вы неправильно рассчитали размерность транспонированной матрицы)


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

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

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

Эээ... путем нажатия на соответствующие клавиши на клавиатуре в редакторе кода, как же еще?
Я серьезно не понимаю, в чем вопрос.

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

__>ну, например, в коде вы сделали описку — вместо resulted[i][j] = original[j][i] написали resulted[i][j] = original[i][j]Э, или у вас эксепш при вызове функции вылетает (вы неправильно рассчитали размерность транспонированной матрицы)

Соответствующий юнит-тест на это укажет:

TEST(transpose, matrixDimensions)
{
    // это вообще можно сделать в цикле, чтобы проверить все возможные варианты.
    // но обычно не надо, т.к. правильность алгоритма можно индукцией
    Matrix transposed = transpose(getMatrix(1,10));
    ASSERT_EQ(matrix::dimension(10,1), transposed);
}

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

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

Когда кажется, нужно (и далее по тексту).

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

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

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

L>Эээ... путем нажатия на соответствующие клавиши на клавиатуре в редакторе кода, как же еще?
L>Я серьезно не понимаю, в чем вопрос.

а как найдете место, в который нужно поставить курсор, чтобы потом "нажать клавиши на клавиатуре в редакторе кода"?

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

__>>ну, например, в коде вы сделали описку — вместо resulted[i][j] = original[j][i] написали resulted[i][j] = original[i][j]Э, или у вас эксепш при вызове функции вылетает (вы неправильно рассчитали размерность транспонированной матрицы)

L>Соответствующий юнит-тест на это укажет:
L>

L>TEST(transpose, matrixDimensions)
L>{
L>    // это вообще можно сделать в цикле, чтобы проверить все возможные варианты.
L>    // но обычно не надо, т.к. правильность алгоритма можно индукцией
L>    Matrix transposed = transpose(getMatrix(1,10));
L>    ASSERT_EQ(matrix::dimension(10,1), transposed);
L>}
L>

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

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

если у вас тесты на каждые пару строк кода, то согласен (но это нереально).

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

L>Когда кажется, нужно (и далее по тексту).

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

кстати, а что с эксепшенами? вот вылетает у вас он в куске кода — как вы тестируете?

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

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

Монетку кину, как же еще?

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

__>во-первых, в вашем первоначальнмо варианте этого теста не было, а во-вторых, он покажет, что транспонирования не поисходит, но в каком месте кода ошибка — нет.

Ну и что, что не было? добавить его дело 30 секунд. Вообще не стоит обсуждения.
А уж указывать, в каком месте тестируемого ошибка? А ключ от квартиры, где деньги лежат, не нужен? Голова прогаммисту для чего?

L>>Если тест ломается, то это практически прямое указание, что именно и где нужно править.
__>если у вас тесты на каждые пару строк кода, то согласен (но это нереально).

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

L>>Когда кажется, нужно (и далее по тексту).
__>ладно, тогда так — я практически уверен, что вы только пользуетесь стандартными написанными кем-то штуками (ну, либо пишете код такой сложности, что его легко и без дебагера проверить)


Мы все пользуемся стандартными написанными кем-то компиляторами. И да, я не пишу код, в котором без пол-литры отладчика не разобраться. Я пишу крайне простой код, делающий весьма сложные вещи.
Код же, в котором без отладчика не разобраться, не разобраться и с отладчиком. Но в нем и не следует разбираться. Его нужно выбрасывать. Это всегда говнокод. Без исключений.

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


__>кстати, а что с эксепшенами? вот вылетает у вас он в куске кода — как вы тестируете?

Ммм, в чем вопрос? Что "тестируете"? Сценарии, в которых тестируемый код обязан бросить исключение? Во всех фреймворках нынче есть ASSERT_THROW. Или когда исключение не ожидается? тогда это означает провал теста и необходимость исправить код (или тест).

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

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


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

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

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

когда к вам приходит багрепорт, вы не тыкаете с полчаса, его репродюся, а сразу пишете юнит-тест, который дает баг (например, числа сортируются в лексикографическом порядке вместо нормального, сразу пишете тест equal( order("2") < order("12"), true ), сразу запускаете, он сразу падает, сразу правите код сортировки, запускаете тесты, проверяете, что теперь все работает и ничего старого не поломалось, все, можно релизить

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

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

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

Совершенно верно.

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

Совершенно верно.

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

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

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

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

А вот это уже пример так называемого вранья.

Есть такое правило — If it worth doing, it worth testing. If it not worth testing, why bother doing it in the first place?

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