Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>А разумный подход — каждую ситуацию, которая хоть сколько-нибудь регулярно создает проблемы, считать ошибкой, если в коде явно не указано, конкретно здесь (а не вообще везде по умолчанию) программист четко понимает, что делает (ну, или возомнил, будто понимает).
Вот это принцип очень хреновый. Он самое главное зло. В стандарте прописано что программа без ошибок не содержит UB, а если содержит то можно делать что угодно. И главное что это принцип не локален. Если UB где-то далеко, то оно может повлиять на код в котором не было UB, превратив его в не то было изначально. То есть применяются преобразования которые нарушают логику работы. Вместо того что бы предупреждать о ниоткуда ни следующих предположений обрядов, компилятор молча делает гадости. Более того стандарт предписывает использовать модели данных ничего не имеющие общего с реальным железом. Например указатель помимо числа имеет еще кучу shadow свойств, значения 8битного байта кодирую 257 величин 0..255 и еще "poison". Что помогает компилятору делать изощренные подставы в самых неожиданных места. А к этому еще следует добавить что большие программы не пишутся одним программистом, а толпой. То по определению будут UB которые компилятор обязательно не сегодня, так в будущем превратит в баги.

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

ЕМ>В компиляторах, разумеется, нужно обязательно иметь возможность понизить настороженность ключами командной строки — хоть до нуля, но ни в коем случае не втихушку. Чтоб при понижении уровня до умеренного просто выдавалось предупреждение, не бросающееся в глаза, а при полном отключении — хорошо заметное, да еще с паузой секунд в десять, чтоб неповадно было.
Надо иметь вменяемый компилятор. Почему-то разделение логики, данных и представления никого не смущают. А вот добавить в компилятор дополнительную фазу синтеза кода никому в голову не приходит. Вместо этого все ворчат на макросы и продолжают их использовать, добавляют к шаблонам концепты, вычисления времени компиляции рефлексию, короче всё месят в одну кучу. Вот спрашивается: на фига так делать. Сложность при этом перемножается как кода, так и требования к знаниям программиста, что приводит к слишком долгому обучению.

Чем хорош C — простотой. Чем плох C++ — туда наталкивают всякий мусор, не решив фундаментальных проблем, которые были заложены в самом начале.

Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>А разумный подход — каждую ситуацию, которая хоть сколько-нибудь регулярно создает проблемы, считать ошибкой, если в коде явно не указано, конкретно здесь (а не вообще везде по умолчанию) программист четко понимает, что делает (ну, или возомнил, будто понимает).
Вот это принцип очень хреновый. Он самое главное зло. В стандарте прописано что программа без ошибок не содержит UB, а если содержит то можно делать что угодно. И главное что это принцип не локален. Если UB где-то далеко, то оно может повлиять на код в котором не было UB, превратив его в не то было изначально. То есть применяются преобразования которые нарушают логику работы. Вместо того что бы предупреждать о ни откуда не следующих предположениях обрядах, компилятор молча делает гадости. Более того стандарт предписывает использовать модели данных ничего не имеющие общего с реальным железом. Например указатель помимо числа имеет еще кучу shadow свойств, значения 8битного байта кодирую 257 величин 0..255 и еще "poison". Что помогает компилятору делать изощренные подставы в самых неожиданных места. А к этому еще следует добавить что большие программы не пишутся одним программистом, а толпой. То по определению будут UB которые компилятор обязательно не сегодня, так в будущем превратит в баги.

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

ЕМ>В компиляторах, разумеется, нужно обязательно иметь возможность понизить настороженность ключами командной строки — хоть до нуля, но ни в коем случае не втихушку. Чтоб при понижении уровня до умеренного просто выдавалось предупреждение, не бросающееся в глаза, а при полном отключении — хорошо заметное, да еще с паузой секунд в десять, чтоб неповадно было.
Надо иметь вменяемый компилятор. Почему-то разделение логики, данных и представления никого не смущают. А вот добавить в компилятор дополнительную фазу синтеза кода никому в голову не приходит. Вместо этого все ворчат на макросы и продолжают их использовать, добавляют к шаблонам концепты, вычисления времени компиляции рефлексию, короче всё месят в одну кучу. Вот спрашивается: на фига так делать. Сложность при этом перемножается как кода, так и требования к знаниям программиста, что приводит к слишком долгому обучению.

Чем хорош C — простотой. Чем плох C++ — туда наталкивают всякий мусор, не решив фундаментальных проблем, которые были заложены в самом начале.