Микроменеджмент синоним слова производительность? Если уж взялись за рассмотрение «собственной производительности», то посмотрите в сторону статической типизации, ведь синтаксис lambda в С++ является прямым развитием этой идеи — избавление от ошибок на этапе компиляции. В частности, от ошибок которые могут быть спровоцированы использованием переменной(по ошибке), которая не должна быть использована в lambda. С++ минимизирует подобные ошибки посредством строгого контроля над тем, что попадает в closure и как оно туда попадает.
Из Ваших слов можно сделать только один вывод: Вы не знаете(или не понимаете), что такое shared_ptr и как его использовать. Ровно как и имеете неправильное представлении о C++. Если Вы уверены в своей правоте, тогда, пожалуйста, приведите пример потери контроля в C++.
Потомучто для этого пришлось бы наследовать класс Node от std::enable_shared_from_this и добавлять метод для получения этого самого shared_ptr. Я не знаю почему Герб не стал так делать; возможно, чтобы не усложнять пример. К тому же тут это явно избыточно, потомок не может существовать без родителя, а значит указатель всегда валиден или nullptr
При разработке языка нужно думать как студентов учить или как сделать язык подходящим под современные требования и стандарты? С++ это язык с исключениями и подобные нововведения просто жизненно необходимы были в нём.
Тип указателей один, все то, что Вы перечисли является лишь обертками. Для человека пишущего на C++ «схватывание» подобной концепции не должно вызвать проблемы, т.к. никакой сложности они не представляют.
Нужен объект, который может быть скопирован во время исполнения и его копия будет использоваться как полноценный объект? shared_ptr
Нужен объект, который не будет скопирован? unique_ptr
Нужна копия объекта для реализации опроса его состояния на все время его жизни или вы столкнулись с проблемой циклических ссылок? weak_ptr
Когда использовать голые указатели? Никогда.
Более подробный ответ: Когда вы вынуждены. К примеру, в Qt, придется использовать голые указатели в parent/child отношениях. Если среда не вынуждает вас использовать голые указатели всегда используйте «умные обертки»
Те же, что С++98. Если вообще можно сказать, что язык «несет риски»
Проблемы статического и динамического линкования со старым кодом С++98
Какие тут могут быть проблемы, если линкуются библиотеки/объектники собранные одним компилятором?
Сравнения скорости компиляции, скорости работы, потребления памяти старого и переписанного на C++11 кода.
Подобные метрики слишком проектозависмые. Можно предположить, что код, который активно использует STL будет исполняться в сотни, а то и тысячи раз быстрее, за счет move semantics. Потребление памяти не уменьшится посредством самого стандарта, т.к. все, итак, контролируется программистом. Тут все в руках писателей компиляторов и библиотек. На данный момент нет ни одного компилятора поддерживающего хотя бы 90% стандарта.
Ну мы же тут говорим о хороших практиках :) Я тоже много всякого повидал, но писать то можно более безопасно и красиво. Тем более, в С++, безопасность и красота кода идут рука об руку
Я с Вами солидарен; для разных людей, разные способы подходят. Но я, естественно, выражаю свое мнение. Т.е. я бы убрал, Вы бы нет. Поэтому я считаю, что нормальное образование, это образование позволяющее варьировать предметы в пределах курса самостоятельно. Т.к. пытаются всех под одну программу подвести, а в результате — «не вашим, не нашим».
Именно поэтому Microsoft делает ставку на C++, Microsoft верит в мифы. И лишь только бравые комментаторы хаобра знают истину.
Нужен объект, который может быть скопирован во время исполнения и его копия будет использоваться как полноценный объект? shared_ptr
Нужен объект, который не будет скопирован? unique_ptr
Нужна копия объекта для реализации опроса его состояния на все время его жизни или вы столкнулись с проблемой циклических ссылок? weak_ptr
Когда использовать голые указатели? Никогда.
Более подробный ответ: Когда вы вынуждены. К примеру, в Qt, придется использовать голые указатели в parent/child отношениях. Если среда не вынуждает вас использовать голые указатели всегда используйте «умные обертки»
Те же, что С++98. Если вообще можно сказать, что язык «несет риски»
Какие тут могут быть проблемы, если линкуются библиотеки/объектники собранные одним компилятором?
Подобные метрики слишком проектозависмые. Можно предположить, что код, который активно использует STL будет исполняться в сотни, а то и тысячи раз быстрее, за счет move semantics. Потребление памяти не уменьшится посредством самого стандарта, т.к. все, итак, контролируется программистом. Тут все в руках писателей компиляторов и библиотек. На данный момент нет ни одного компилятора поддерживающего хотя бы 90% стандарта.