Re[13]: А С++ то схлопывается...
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.11.19 16:07
Оценка: :)
Здравствуйте, so5team, Вы писали:

Pzz>>Мы от чего защищаемся, от случайных ошибок, или от целенаправленного взлома?


S>От случайных. В сишном варианте у вас все манипуляции будут именно с var.v. И никто не защитит вас от того, что вы в var_distance.v по ошибке засунете var_weight.v.


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

Pzz>>А, ну да, у вас в команде нет индусов. Будут, это вопрос времени.


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


А теста на читалку конфига не было?

Попрошу обратить внимание, что если для измерения длительностей по всему проекту изпользуется один и тот же тип (желательно typedef'нутый, конечно, а не просто unsigned int), то ерунда туда может пролезть только на границах системы — в той же читалке конфигов, например.

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

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

S>Такая же, как и вмешивание Go в разговор про преимущества C++ перед C (или наоборот).


Я ссылаюсь на Go ради примеров, как некоторые вещи можно сделать удачно, а не ради установления исторической справедливости. Полагаю, люди, придумавшие Go, знали C++ очень хорошо.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.