N>>>Это не вопрос для размышлений, это приём такой, старый и действенный.

ОК>>Нелогичность тут, однако. Как поступит компилятор с просто объявленными (но неопределенными) public и protected функциями которые нигде не вызываются?
N>Скомпилирует, при возможности. А затем линкер сообщит о проблеме. Во избежание компиляции их делают private. Двойная защита.

На счет прайвит понять можно но вот компилировать код в котором объявлены но не определены public и protected функции это уже непростительно.

N>>>Ты только что рассказывал как ты лишний код пишешь
ОК>>Вообще-то, повторюсь, я бы такие навороты не стал писать в первую очередь.
N>Значит ты используешь более бедные средства и твой код может быть небезопасен, менее расширяем и реиспользуем.

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

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

Я считаю что процентов 20 — 30 языка достаточно чтобы писать нормальный и простой код. Я концентрируюсь на бизнес задачах а не на технологиях ради технологий. Ну и разумеется стараюсь чтобы код был debuggable and maintainable.

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

ОК>>>>ненужная дополнительная complexity.
N>>>При профессиональном подходе — наоборот. Введение локальной сложности сильно упрощает систему в целом. Многократно проверено.

ОК>>Ты, видимо, мало поддерживал кода написанного другими с таким же мнением как и у тебя.
N>Не в обиду: учитывая, что ты показал недопонимание базовых конструкций? Не удивительно.

Это ненужная мелочь и плюсами я сейчас почти не занимаюсь.

Я лично никогда не писал в своем коде конвержн операторов и никогда не делал приватных копиконструкторов только потому что кто-то (О БОЖЕ!) в будущем случайно сможет попытаться создать копию объекта и из этого ничего хорошего не выйдет.

Но если ты меня так хочешь тыкнуть, то и я тебя могу тыкнуть с твоим дополнительным значением для иньюма. Первое. Ты вводишь ненужное имя в код которое потом нигде не используется. И второе. Почему ты решил что ты знаешь лучше компилятора сколько байт ему надо выделить под иньюм? Непонимание базовых вещей с твоей стороны!

N>Я много всякого кода поддерживал, в том числе занимался портированием STL и модифицировал boost. Бедный на язык код, как правило поддерживается много хуже (с С++ у меня хорошо). Сейчас вот как раз с подобным маюсь.

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

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

Каюсь, я библиотеками тоже не занимаюсь но подчеркну еще раз мысль которая до тебя не доходит. Хороший software engineer это не тот кто помнит все ньюансы языка а тот кто более просто и понятно решит насущую проблему. Пора бы уже давно вырасти из мелких деталей.