Developing.ru

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

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

Romeo писал(а):Ну похожи они только тем, что расположены вне тела конструктора.

Эти два синтаксиса вообще не имеют различий. Там и расположение вызова вне тела, и разделение вызовов запятыми, и двоеточие перед всем списком. Всё перечисленное совпадает. Различие же в самом тексте только в имени пере круглыми скобками, при вызове конструктора предка это имя класса, а при инициализации - имя поля. Ну семантически различаются, да. В нюансе: вызов конструктора поля, или конструктора всего объекта. Но там и там вызов конструктора.

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

Либо ты очень медленно писал проект, так что за 2 года выдал на гора не более нескольких сотен строк, либо говоришь неправду о сроках переделки. Более-менее крупные проекты состоят по крайней мере из десятков тысяч строк кода, и без продуманной архитектуре в них можно быстро утонуть. Тем более, если они написаны в процедурном стиле, что для меня само по себя является шоком.

Сионист писал(а): Эти два синтаксиса вообще не имеют различий. Там и расположение вызова вне тела, и разделение вызовов запятыми, и двоеточие перед всем списком. Всё перечисленное совпадает. Различие же в самом тексте только в имени пере круглыми скобками, при вызове конструктора предка это имя класса, а при инициализации - имя поля. Ну семантически различаются, да. В нюансе: вызов конструктора поля, или конструктора всего объекта. Но там и там вызов конструктора.

Ты всё верно пишешь, но я так до сих пор и не понял, в чём состоит сложность использования этого синтаксиса, что ты его не только не используешь, но даже не помнишь.

Либо ты очень медленно писал проект, так что за 2 года выдал на гора не более нескольких сотен строк, либо говоришь неправду о сроках переделки.

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

Более-менее крупные проекты состоят по крайней мере из десятков тысяч строк кода,

Не так. Отборная мелочь не превышает пяти миллионов строк.

Тем более, если они написаны в процедурном стиле, что для меня само по себя является шоком.

Хуже. В смешанном. Процедурный код вперемешку с объектно-ориентированным.

У «традиционных» перечислений в С++ есть некоторые недостатки: они экспортируют свои значения в окружающую область видимости (что может привести к конфликту имен), они неявно преобразовываются в целый тип и не могут иметь определенный пользователем тип.

Эти проблемы устранены в С++11 с введением новой категории перечислений, названных strongly-typed enums. Они определяются ключевым словом enum class. Они больше не экспортируют свои перечисляемые значения в окружающую область видимости, больше не преобразуются неявно в целый тип и могут иметь определенный пользователем тип (эта опция так же добавлена и для «традиционных» перечислений").

enum class Options {None, One, All};
Options o = Options::All;

. Синтаксис не описан.

Сионист писал(а):Синтаксис не описан.

В принципе, этих двух строчек и кратких объяснений достаточно, чтобы понять, что такое strongly-typed enum, если ты знаешь, что такое классический enum. Если же не знаешь, то дела обстоят хуже. Может ты всё-таки прочтёшь какую-нибудь книгу по С++? Всё-таки 15 лет на этом языке уже пишешь...

В принципе, этих двух строчек и кратких объяснений достаточно, чтобы понять, что такое strongly-typed enum, если ты знаешь, что такое классический enum. Если же не знаешь, то дела обстоят хуже. Может ты всё-таки прочтёшь какую-нибудь книгу по С++? Всё-таки 15 лет на этом языке уже пишешь...

Ни краткостью, ни объяснениями там не пахнет. Хорошо, что ещё нашёл это.

Да уж. Искать умеешь, в этом тебе не откажешь... Вообще-то это C++/CLI. Иными словами, С++ -подобный компилятор .NET платформы... Господи, какой же ты беспомощный.

Однако дефолтный конструктор всё же нужен, я в этом соглашусь. Правда во всех случаях, когда проверка на нулевой Owner у тебя может стрельнуть, у тебя делается проверка на нулевой Pointer, и стреляет именно она. Так что проверку на Owner всё равно можно убирать. Ну, либо, я не весь код вижу...

Ага. Вы не видите код обработки исключений с выводом разных сообщений.

Romeo писал(а):Да уж. Искать умеешь, в этом тебе не откажешь... Вообще-то это C++/CLI. Иными словами, С++ -подобный компилятор .NET платформы... Господи, какой же ты беспомощный.

Вот только к "сбору" мусора текст не относится, а подобие языков часто полезно для понимания. Например, паскалевый if then я не учил по книге Вирта, а использовал факт подобия бейсику, который уже знал. А после прочтения я протестировал enum class на том компиляторе, который использую.