OberonCore

Мусор? Однако, возможно, enum трактовался как int, у std::string есть конструктор от int-а, и тогда созданный string присвоился, а потом удалился, т. е. никакого мусора, т. к. компилятор должен был уничтожить этот временный string.

С типами здесь все хорошо, они преобразовались по всем правилам неявного преобразования типов. Проблема в дизайне std::string (если соответствующий конструктор у нее не explicit). Впрочем это далеко не единственная проблема std::string.



Под "мусором в памяти" обычно понимают неконтролируемое нарушение содержимого объекта, возникающее, в частности, в результате нарушения типизации. В данном примере ничего такого нет.

- Как себя чувствует больной?
- Очень хорошо. Он умер.


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

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



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

Конструктора от int'а у std::string нет (и это правильно). А вот operator = для символа есть. И вот это дизайнерское решение достаточно спорно, учитывая то, что к символу может быть неявно приведено много чего (в том числе и enum).

Ещё один пример "прикола" от Си: недавно писал программу, в которой нужно проверять, разный ли знак у двух значений переменных. Для скорости сделал функцию "сигнум", которая возвращала 000, 007, 070 (восьмеричные числа) в ответ на 0 + и -
Долго пытался понять, почему строка
if (a | b == 77) { }
не работает.

Оказывается, надо вот так:
if ((a | b) == 77) { }
(| - это побитовое "ИЛИ").

Вот вот. И этот спор такого вида далеко не единственный. Потому что одни хотят более строго языка, чтобы не колупаться в поисках ошибок во время выполнения (в основном из-за опечаток, которые мог бы поймать компилятор буди чуть другое дизайнерское решение в библиотеке или языке), а другие говорят что мы типа крутые программисты, глупых ошибок не допускаем и пусть все так и останется, да не нарушится наша свобода. А в итоге народ клепает подобные вещи http://www.oopweb.com/CPP/Documents/CPPRules/, призывая писать добровольно соблюдая и контролируя самостоятельно набор правил, ограничивающих даже стандарт (видел и такую разработку, ссылку щас не помню) - и суля за это большую читабельность программ и меньшую вероятность ошибок.

А нафиг мне тогда Си++? Без шаблонов как-нибудь проживу, без STL тоже. А вот наживать геморрой в поисках ошибок из-за опечаток или напрягать мозг, следуя каким-то правилам - лучше я на Обероне напишу, который такие ограничения явно вводит и сам проверяет.

Borland Pascal. "Код" мне по наследству достался. Править нельзя - "работает же"

Процедура, которая содержит этот кусок "кода" - длиной в 300 строк.
И конечно в начале процедуре есть:

Фраза из обсуждений сишниками того, хороши шаблоны или плохи. Отвлекаясь от сути вопроса, фраза сама по себе убойная:


О как! Ваш код слишком многого хочет от компилятора

Вон у меня на работе программеры наваяли шаблонов как Александреску учил, а при переходе на новую версию компилятора у них не скомпилировалось. Пришлось вернуться на старую. Так на старом и сидят...

Макросами их, макросами!!!
Шоже они так? Не видели никогда файлика аля config.h? И в STLPort есть и в gcc вроде, и по-моему у всех. Надо всего-то лишь параметризировать шаблонную реализацию макросами, чтобы хавал любой компилятор любой версии.