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

Sergey Кстати, можете ещё раз пояснить почему внутри класса создавать Алиас на указатель на данный класс - не хорошо ?

ну это просто имеет мало смысла...

Ничего себе память, однако)
Да, почему нет. Элиас станет зависимым именем и потребует определения инкапсулирующего класса в местах, где понадобится его использование. А т.к. суть указателей в определенных контекстах как раз сводится к возможности forward declaration'ов - такой подход оказывается весьма противоречивым.
Edit: Иными словами, нижеследующий пример.

/* PtrTy.hpp */
template < typename Ty >
using Ptr = Ty*;

/* StructA.hpp */
struct StructA
{ typedef StructA* Ptr; };

/* Smthng.hpp */
#include <PtrTy.hpp>

/* fwd declaration */
struct StructA;

/* ok */
auto subA ( StructA* )
-> /* ... */;
/* ok */
auto subB ( Ptr<StructA> )
-> /* ... */;
/* ill-formed, definition of 'StructA' required */
auto subC ( StructA::Ptr )
-> /* ... */;

Как можно видеть, первым двум примерам достаточно forward declaration'а, что полностью соответствует концепции легковесных заголовков (второму при этом нужен еще и сам шаблон элиаса). А вот третий потребует подтянуть именно определение StructA, поскольку Ptr - nested identifier в нем.
В принципе, я бы вполне себе рекомендовал использование вербозных врапперов над указателями и ссылками в больших проектах, поскольку это позволит их произвольным пейлоадом обременить при желании (например в рамках какой-нибудь условной отладочной компиляции с кастомными санитайзерами какими-нибудь).

Не существует способа более простого, чем
((double) 1) / ((double) 2) для деления двух целых с получением в итоге double?
Без перегрузки

как в этом случае отработает auto?

1. / 2.

а если переменная?

то нет

Или не кастить, а умножить на 1.0

@H1LIASSS, с биткойнами в другой чат

Затрудняюсь ответить, если честно.

Но, не зря же его придумали и все чаще используют в ядре, как минимум

"Не зря" - не ответ :)

Ну окей, залочить на уровне корня - это более затратно, чем создать окно для писателя относительно читателлей на уровне корня, разве нет?

Да, но писателю придется копировать всё дерево или по крайней мере поддерево, и это нехилый оверхед по сравнению с локом на вставку 1 указателя

Лок на вставку указателя можно делать атомарно без лока в принципе

Лок на вставку указателя в мапу/список/вектор?))

Эээм