Здравствуйте, nekocoder, Вы писали:
CC>>Безусловно кастить указатель (который по определению может быть NULL) в ссылку (которая NULL быть не может) это баг.
N>Например, указатель — приватное поле, которое инициализируется в конструкторе строго в не-null.
это должно быть явно выражено.
через ссылку, или через тайпдеф:
Здравствуйте, Masterspline, Вы писали:
BFE>>>Например, в авионике это 100% покрытие кода тестами.
L>>А вне авионики давно поняли, что 100% покрытие сценариев исполнения != 100% покрытия кода. См. 737 MAX. M>Хотелось бы разъяснения столь глубокой мысли про 100% != 100%.
Глупый пример:
int calculateDistance(int a, int b) {
return a - b;
}
Тупой единственный тест обеспечит 100% покрытие кода... но все ли сценарии покрыты?
M>Насколько я знаю, в случае 737 MAX код отработал как ему полагается.
Как там говорилось.. "Компьютер сделает в точности то, что вы ему задали, но это будет отличаться от того, что вы имели в виду".
M>Там изначально было рассчитано, что код полагается на показания одного датчика из двух и код делал именно то, что и нужно, если бы датчик давал такие показания, какие получал код. M>Неприятность только была в том, что данные были неверными.
Неприятность была в том, что с точки зрения анализа отказов, вероятность отказа этого датчика, как бы помягче сказать, стремится к 100%. Соответственно, сценарий, когда датчик изначально дохлый или внезапно начинает дурить — совершенно ожидаемый.
Но этот сценарий не был протестирован.
Покрытие кода могло было 100%, но это не имеет абсолютно никакого значения.
Каким бы черезжопным не было сама идея MCAS, ее можно и нужно было реализовывать так, чтобы отказ был безопасным. Даже с одним датчиком.
M>Причем в одном случае датчик совсем отвалился и на вход шел мусор (который можно было распознать программно), а в другом случае датчик заклинило и программно никак нельзя было распознать, что данные не верные (потому что датчик заклинило в вертикальном положении и он выдавал это положение).
А это уже детали.
Кстати, использование двух датчиков в лучшем случае позволяет лишь реализовать режим отказа: если датчики не могут договориться, MCAS обязан деактивироваться. Только это не панацея, вероятность одновременного похожего отказа двух датчиков вовсе не такая маленькая, поэтому реализация MCAS обязана была учитывать и такой сценарий.
Здравствуйте, Marty, Вы писали:
M>И кроме всего прочего, непонятна тогда нужда заводить vtbl, одинаковую для всех. В плюсиках компилятор будет решать, как лучше, в сишечке — сишечник, который считает себя умнее компилятора. Причем для каждого конфига сборки — заново. гениальное решение, я щитаю
Здравствуйте, Marty, Вы писали:
Pzz>>Я заглядывал внутрь этого вашего цланга, чтобы что-то про него прояснить для себя. Прямоугольный кусок кода, одинаково плотно набитый буквами и по горизонтали, и по вертикали, ужас.
M>А гобжекты видел?
Здравствуйте, Marty, Вы писали:
M>C++ именно такой — в повседневной работе я практически не парюсь, не думаю вообще ни о чем, кроме текущей задачи. Когда пишу библиотечный код — тут — да, надо уже думать, как сделать эффективнее.
M>"Напихать в язык весь computer science — много ума не надо" — ум нужен, чтобы использовать в текущий момент только то, что нужно. Неосиляторы таким навыком не обладают
Ты в двух коротких абзацах умудряешься высказать две взаимно противоречивые мысли. Сначала ты говоришь, что C++ не требует думать о себе и не отвлекает от решения текущей задачи. Потом ты говоришь, что осилить C++ — задача нетривиальная.
Здравствуйте, Denis Ivlev, Вы писали:
DI>>>Да хорош заливать. Всегда забавно, как подростки своего возраста стесняются CC>>Ну так не стесняйся
DI>7-8 будет хайлоад, я там выступаю с докладом — приходи, попьем кофе, потрындим, посмотришь сколько мне лет.
Здравствуйте, Marty, Вы писали:
M>Торвальдс умеет в C++? Вот и ответ. M>Тащем-то, линупс дырявый, что твой дуршлаг благодаря именно твоей любимой сишечке. Вирусов под него мало, да — потому что на десктопе его исчезающе мало, и он просто не интересен вирусописателям
Зато его очень много на серверах. Разве сервера — менее привлекательный объект для атаки, чем дектоп?
S>>Там или Cи или для тулзовин используется уже более высокоуровневые ЯП, perl, python, Go etc.
M>Там есть Гобжекты, при виде которых кровь просто хлещет из глаз
А ты купи себе соленую водичку, которую пользователи контактных линз закапывают в глаза в обязательном порядке, и не забывай ее себе в глаза время от времени подливать. А то ослепнешь со временем.
Здравствуйте, Marty, Вы писали:
M>>>Думаю, компилятор C++ сложнее всех других компиляторов на порядок, если не на два НС>>Думай. M>Кроме подобных глубокомысленных комментариев по существу есть что-то?
Есть. Но сперва подобный вопрос стоило бы задать себе.
Здравствуйте, Marty, Вы писали:
НС>>>>И? Были написаны, пришлось переписать. Ровно то, о чем я и говорил. M>>>Точно пришлось? НС>>Точно. M>Можно деталей?
Деталей нельзя, потому что я процессом переписывания не занимался. Но мне об этом говорили Хейлсберг, Торгерсен и Липперт. Последний как раз компилятор и переписывал, так что оснований не доверять ему у меня нет.
Здравствуйте, CreatorCray, Вы писали:
НС>>>>Компиляторы точно на С++ писать не стоит. CC>Так стоит или не стоит? CC>По факту и на деле — видим что стОит.
В общем случае — не стоит. Конкретно для С++ — стоит.
НС>> Но не делает С++ лучшим выбором для других языков. CC>А при чём тут лучший выбор?
При том что разговор был именно об этом. Но почему то стадо С++ решило, что я сказал, что написать на С++ компилятор вообще нельзя.
Здравствуйте, Pzz, Вы писали:
Pzz>Ты в двух коротких абзацах умудряешься высказать две взаимно противоречивые мысли. Сначала ты говоришь, что C++ не требует думать о себе и не отвлекает от решения текущей задачи. Потом ты говоришь, что осилить C++ — задача нетривиальная.
Здесь нет противоречия. После достижения некоторого уровня владения C++ в привычной для тебя предметной области C++ перестает вызывать серьезные сложности. Т.е. выстрелы в ногу все еще случаются, но редко.
И проблемы, собственно, две:
* достижение этого самого "уровня владения";
* достигнутый уровень владения может оказаться недостаточным при выходе из привычной предметной области. Т.е. если пять лет подряд работаешь с сетью (т.е. колупаешься с системными вызовами, манипулируешь буферами и байтами в них), а потом сталкиваешься с задачей написать несколько повторно используемых обобщенных алгоритмов для работы с матрицами/векторами, то окажется, что знаний и опыта недостаточно.
При этом многие хейтеры C++ забывают о том, что должный уровень владения вовсе не требует знания всего стандарта C++. Как правило, большинство разработчиков довольствуются какими-то подмножествами C++. Что и обуславливает существование второй из перечисленных выше проблем.
Здравствуйте, CreatorCray, Вы писали:
CC>Эта абстракция — одно из преимуществ С++ перед С, которое позволяет писать более простой, безопасный и чистый код.
А в чем чистота, в том, что вместо стрелочки можно писать точку?
Здравствуйте, Pzz, Вы писали:
CC>>Эта абстракция — одно из преимуществ С++ перед С, которое позволяет писать более простой, безопасный и чистый код.
Pzz>А в чем чистота, в том, что вместо стрелочки можно писать точку?
Здравствуйте, so5team, Вы писали:
S>Здесь нет противоречия. После достижения некоторого уровня владения C++ в привычной для тебя предметной области C++ перестает вызывать серьезные сложности. Т.е. выстрелы в ногу все еще случаются, но редко.
Если вас трамвай задавит,
вы конечно вскрикнете,
раз задавит, два задавит,
а потом привыкнете.
S>При этом многие хейтеры C++ забывают о том, что должный уровень владения вовсе не требует знания всего стандарта C++. Как правило, большинство разработчиков довольствуются какими-то подмножествами C++. Что и обуславливает существование второй из перечисленных выше проблем.
Не обеспечивает, к сожалению, потому что любой более-менее объемный и зрелый проект на протяжении длительного времени пишется разными людьми, а у них разный бакграунд, разные подмножества, разные взгляды на вещи.
Здравствуйте, Pzz, Вы писали:
Pzz>Ты в двух коротких абзацах умудряешься высказать две взаимно противоречивые мысли. Сначала ты говоришь, что C++ не требует думать о себе и не отвлекает от решения текущей задачи. Потом ты говоришь, что осилить C++ — задача нетривиальная.
Здравствуйте, so5team, Вы писали:
S>Ну вот как в чистом C указать, что аргументы для: S>
int strcmp(const char * a, const char * b);
S>не могут быть NULL-ами?
В комментарии к функции написать. Я серьезно. Обычно этого достаточно. Проблемы вылезают в более сложных случаях, и попытка защититься от них детальным описыванием контрактов на неуклюжем языке системы типов C++ напоминает управление самолетом в презервативе, надетом на голову. Душно, неудобно, и все равно ошибаешься там, где не предусмотрел.
Ты пойми меня, пожалуйста, правильно. Я за статический анализ кода, я за то, чтобы компилятор проверил все, что возможно. Я против того, чтобы к программе прилагать еще в два раза больше кода, написанного на загадочном языке, с единственной целью — описать правила игры, по которым осуществляются проверки.
S>Или вот вы видите прототип функции: S>
S>Как вы поймете где можно передавать NULL, где нельзя? Как вы поймете, кто отвечает за удаление чего?
Никак не пойму, если в документации не написано. Чем мне станет легче, если синтаксически передавать NULL нельзя, а что в параметрах писать, мне все равно не понятно?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Pzz, Вы писали:
Pzz>>Ты в двух коротких абзацах умудряешься высказать две взаимно противоречивые мысли. Сначала ты говоришь, что C++ не требует думать о себе и не отвлекает от решения текущей задачи. Потом ты говоришь, что осилить C++ — задача нетривиальная.
НС>На самом деле все логично, если взглянуть под правильным углом.
Ну, на самом деле, если любая задача, решаемая на C++, сводится в глубине своей души к постижению дао и дзена программирования на C++, то сложность C++, конечно, не мешает решению такой задачи. Слово "C++", кстати, тут можно заменить на любое другое.
Здравствуйте, Pzz, Вы писали:
S>>Здесь нет противоречия. После достижения некоторого уровня владения C++ в привычной для тебя предметной области C++ перестает вызывать серьезные сложности. Т.е. выстрелы в ногу все еще случаются, но редко.
Pzz>
Если вас трамвай задавит,
Pzz>вы конечно вскрикнете,
Pzz>раз задавит, два задавит,
Pzz>а потом привыкнете.
Что бы это значило?
S>>При этом многие хейтеры C++ забывают о том, что должный уровень владения вовсе не требует знания всего стандарта C++. Как правило, большинство разработчиков довольствуются какими-то подмножествами C++. Что и обуславливает существование второй из перечисленных выше проблем.
Pzz>Не обеспечивает, к сожалению, потому что любой более-менее объемный и зрелый проект на протяжении длительного времени пишется разными людьми, а у них разный бакграунд, разные подмножества, разные взгляды на вещи.
Если сравнивать C++ с чистым C, то есть достаточно простой выбор:
* использовать C++, тратить время на обучение сотрудников и получать кодовую базу более-менее приемлемого размера, в которой, местами, качество и безопасность будет обеспечиваться средствами самого языка;
* использовать чистый C, тратить время на обучение сотрудников и получать гораздо более объемную кодовую базу, в которой безопасность и качество вообще ничем не обеспечивается кроме честного слова.
При этом инструменты статического и динамического анализа можно применять и там, и там.
Поэтому, когда речь заходит о коммерческих проектах, в которых сроки и бюджеты не резиновые, C++ уже много десятилетий уверенно обходит чистый C. Сдаются даже разработчики эбмедеда, которые сопротивляются вытеснению чистого С сильнее всего.
А в OpenSource чистый C продолжает жить. И мнение Торвальдса выносят на знамена, хотя вряд ли кто-то сможет перечислить коммерческие проекты Торвальдса, выполненные в рамках бюджетов, сроков и в соответствии с жестко заданными требованиями.
