Здравствуйте, rg45, Вы писали:

R>Кроме того, хотелось бы обратить внимание на некоторые не очень хорошие моменты в коде: неявный преобразующий конструктор, неявный оператор преобразования к сырому указателю, открытый доступ к членам-данным. Ну и совсем мелочь — стиль именования членов-данных, затрудняющий чтение кода.

это всё хорошо, но это хорошо работает когда вам платят за время а не вы платите
к тому же 100500 get'ов в коде и явные касты там где и без них можно тоже читабельности не добавляют

что читатабельнее?

a == b 
или
a.get() == (CObject *)b

Core->Manager
или
m_core.get()->get_manager()

у меня в таким стиле проекту уже 10 лет и никаких проблем о которых говорят теоретики у меня так и не возникло, например паблик мемберы никогда не создавали проблем изза своей публичности
и консты везде подряд тоже не нужны, такой стиль(перестраховка везде и всюду) нужен тока если у вас в команде индусы которые не могут понять, принять и следовать принятой идеологии

Здравствуйте, rg45, Вы писали:

R>Кроме того, хотелось бы обратить внимание на некоторые не очень хорошие моменты в коде: неявный преобразующий конструктор, неявный оператор преобразования к сырому указателю, открытый доступ к членам-данным. Ну и совсем мелочь — стиль именования членов-данных, затрудняющий чтение кода.

это всё хорошо, но это хорошо работает когда вам платят за время а не вы платите
к тому же 100500 get'ов в коде и явные касты там где и без них можно тоже читабельности не добавляют

что читатабельнее?

a == b 
или
a.get() == (CObject *)b

Core->Manager
или
m_core.get()->get_manager()

у меня в таким стиле проекту уже 10 лет и никаких проблем о которых говорят теоретики у меня так и не возникло, например паблик мемберы никогда не создавали проблем изза своей публичности
и консты везде подряд тоже не нужны, такой стиль(перестраховка везде и всюду) нужен тока если у вас в команде индусы которые не могут понять, принять и следовать принятой идеологии, и их нада как детей от всего ограждать