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

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

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

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

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

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

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

спасибо. тогда подход понятен.

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

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

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

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

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

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

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

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

только в случае, если

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

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

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

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

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

а нас учили по-другому — сперва нужно выполнить декомпозицию задачи на отдельные имеющие самостоятельное логическое значение подзадачи, и только потом оформлять их в виде функций
(иными словами, не x = муторные_преобразования(x, y, z), а x = вычислить_наименьшее_общее_кратное(x, y, z) )

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

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

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

Qt хорошо следят за модульностью. И forward declaration по максимуму используют. Так что да, не боюсь (думаю, как и nen777w).

С использованием IncrediBuild-а больше всего времени занимает линковка, а не компиляция.

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

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>Но это же твой проект...

Это называется "unity build". Некоторые системы сборки умеют это делать автоматически. Использовал когда-то с CMake — cotire.
Если правильно это дело настраивать, то можно добиться очень хорошей производительности совместно с распределёнными системами сборки.

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

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

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

__> а потому я и говорю, что размер адекватнее оценивать по архиву.
Это смотря что вы оцениваете. Скорость компиляции мало коррелирует с размером архива исходников. (К тому же с rar архивом, в котором есть уйма опций влияющих на размер архива)

__>а так 207 299
20 минут для такого проекта на не быстрой машине — это нормально.

	Скрытый текст
	__> __>/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>>Может код изменился, структура хранения поменятся, скажем раньше имя и путь файла хранились отдельно, а теперь — в одной переменной.
__>я все ранво ен понимаю. это же теоретически невозможно — чтобы сериализованные со старыми именами данные смогли загрузиться в формате, предполагающем новые.
MS Word поддерживает обратную совместимость с файлами забытого года, так что всё возможно не только теоретически, но и практически. Впрочем, не все так делают.

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

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

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

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

__>>а так 207 299
BFE>20 минут для такого проекта на не быстрой машине — это нормально.

это де-факто может быть нормально, но ненормально с точки зрения разработки программ в 21 веке (сколько времени тратится впустую)


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

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

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

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

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

SaZ>Qt хорошо следят за модульностью. И forward declaration по максимуму используют. Так что да, не боюсь (думаю, как и nen777w).

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

SaZ>С использованием IncrediBuild-а больше всего времени занимает линковка, а не компиляция.

один черт — трата времени впустую.

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

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

__>>>а так 207 299
BFE>>20 минут для такого проекта на не быстрой машине — это нормально.
__>это де-факто может быть нормально, но ненормально с точки зрения разработки программ в 21 веке (сколько времени тратится впустую)
Меня не напрягает. По сравнению с обдумыванием время компиляции занимает совсем не много.

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

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

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

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

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

__>>>>а так 207 299
BFE>>>20 минут для такого проекта на не быстрой машине — это нормально.
__>>это де-факто может быть нормально, но ненормально с точки зрения разработки программ в 21 веке (сколько времени тратится впустую)
BFE>Меня не напрягает. По сравнению с обдумыванием время компиляции занимает совсем не много.

а что насчет дебагинга — одна правка, и жди еще 20 минут?

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

вы хоть одну такую встречали?

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

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

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

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

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

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

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

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

__>>а что насчет дебагинга — одна правка, и жди еще 20 минут?
BFE>дебагинг нужен в основном для исправления ошибок в чужом коде. Для нахождения своей ошибки обычно достаточно посмотреть на поведение программы, если этого не хватает, то достаточно посмотреть на лог. А если не хватает лога, то запустить debug версию до первого ассёрта.

не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки

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

а что значит "по концептуальным соображениям"? и как вы сохраняетесь тогда?

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

__>по моим ощущениям тормозит все-таки из-за темплейтов (очень резко увеличилось врем, когда стал использовать cereal)
А не факт, что всё это из-за шаблонности (но вполне может быть что и из-за неё). Добавление такой библиотеки требует включение большого числа хедеров для каждого класса, где эта библиотека используется.
Только в cereal.hpp девять включений системных заголовков:
#include <type_traits>
#include <string>
#include <memory>
#include <unordered_map>
#include <unordered_set>
#include <vector>
#include <cstddef>
#include <cstdint>
#include <functional>

__>не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки
Ну да. Следующая проверка минут через 20, а следующий ассерт дня через 2 если писать новую функциональность.

BFE>>Нет. Впрочем, я не использую сериализацию по концептуальным соображениям, поэтому не искал библиотек подобного рода.
__>а что значит "по концептуальным соображениям"?
В данном случае это означает, что формат данных должен быть отделён и независим от формата используемых для их обработки структур.

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

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

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

__>>не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки
BFE>Ну да. Следующая проверка минут через 20, а следующий ассерт дня через 2 если писать новую функциональность.

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

BFE>>>Нет. Впрочем, я не использую сериализацию по концептуальным соображениям, поэтому не искал библиотек подобного рода.
__>>а что значит "по концептуальным соображениям"?
BFE>В данном случае это означает, что формат данных должен быть отделён и независим от формата используемых для их обработки структур.

это да, согласен. но так проще и быстрее. да и ошибок меньше.

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

аа, ну тогда да, можно и покритиковать

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

а какой вы предпочитаете?

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

__>>>не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки
BFE>>Ну да. Следующая проверка минут через 20, а следующий ассерт дня через 2 если писать новую функциональность.
__>да, но при написании новой функциональности разве не приходится править по несколькую ошибок? или вы достигли того уровня, что у вас они если и встречаются, тоне более одной на новую функциональность?
На прошлой неделе писал новую функциональность — пульт дистанционного управления. Совершил следующие ошибки:
1. перепутал поле маски с полем смещения — заметил при просмотре записанного файла — нашёл просмотром кода записи файла
2. вывод в лог одного и того же значения вместо двух разных — заметил при тестировании на некорректных входных данных — просто посмотрел в коде, что я вывожу
3. использовал unsigned вместо signed для изменения позиции слайдера — заметил при тестировании слайдера — ещё до просмотра кода знал, что скорее всего ошибка в типе (не первый раз)
4. удалял дефолтный список кнопок консоли при загрузке старого конфигурационного файла — заметил при тестировании (нет реакции на кнопки) — знал где искать, так как в логе не было вывода о сконфигурированных кнопках.
Для этих целей дебагер не потребовался ни разу.

Дебагер использовал для отладки чужого кода — код писали электронщики для микроконтроллера и там, как это обычно у них бывает и не изменилось за 20 лет, всё перемешано, имена — короткие, переменные — глобальные, функции на прерываниях, инициализация memset'ом, длины массивов не выверены, часть кода не работает, протокол не соблюдён, на переполнения переменных никто внимания не обращает и, разумеется, моя любимая не инициализированная глобальная переменная int i;.

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

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

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

__>>>>не для нахождения, а для исправления. ну вот влеетели в асерт, нашли в чем дело, исправили, и дальше 20 минут ожидания следующей проверки
BFE>>>Ну да. Следующая проверка минут через 20, а следующий ассерт дня через 2 если писать новую функциональность.
__>>да, но при написании новой функциональности разве не приходится править по несколькую ошибок? или вы достигли того уровня, что у вас они если и встречаются, тоне более одной на новую функциональность?
BFE>На прошлой неделе писал новую функциональность — пульт дистанционного управления. Совершил следующие ошибки:
BFE>1. перепутал поле маски с полем смещения — заметил при просмотре записанного файла — нашёл просмотром кода записи файла

исправили и +20 минут ожидания

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

исправили и +20 минут ожидания

BFE>3. использовал unsigned вместо signed для изменения позиции слайдера — заметил при тестировании слайдера — ещё до просмотра кода знал, что скорее всего ошибка в типе (не первый раз)

исправили и +20 минут ожидания

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

исправили и +20 минут ожидания


итого, почти полтора часа потраченного впустую времени

BFE>Для этих целей дебагер не потребовался ни разу.

дебагинг != работа под дебагером. дебагинг (по крайней мере в том смысле , что я вкладывал) — устранение ошибок.

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

__>итого, почти полтора часа потраченного впустую времени
Это много для одной недели?

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

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

__>>итого, почти полтора часа потраченного впустую времени
BFE>Это много для одной недели?

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

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

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

Вот хорошая иллюстрация использования TDD на практике: https://habrahabr.ru/post/231657/ , у меня перелом в понимании TDD (и в отношении к нему) случился после этой статьи.) Там просто на пальцах показано, как в стиле tdd пишется достаточно сложный код с нуля. Да, накидать все это без тестов получилось бы быстрее, но на отладку потом ушла бы куча времени, а здесь отладки нет совсем.)

Это стандартная ситуация с TDD: обычно проект пишется, скажем, за месяц, а потом он в состоянии "готов на 99%" отлаживается еще 3-4 месяца, с TDD — проект пишется 2 месяца вместо одного, тестов получается больше чем самого кода, многие их них кажутся бессмысленными, но вот этот период отладки отсутствует совсем.) Это надо просто попробовать самому на каком-то своем проекте, чтобы прочувствовать.)