Опрос: Три-пять лучших фич C++

Вот табличка, если без неё не понятно:

        +---------------------+        
        |                     |        
        |    С А Р К А З М    |        
        |                     |        
        +---------------------+        

Соболезную. Если долго писать на Qt

Все в порядке. После этого я писал и на «правильном» С++, и на С с классами, и на других удобных и не очень языках. Этот этап моей карьеры остался далеко позади.

Чтобы классами можно было пользоваться для создания любых программ

Возможно мы с вами очень по разному понимаем функциональность, которой должны обладать классы. Дискуссия о том «что такое класс» может растянуться на целую вечность и даже в этом случае мы можем остатся без консенсуса.

Я знаю, что вы очень опытный разработчик на С++. Без шуток. И мне бы не хотелось уходить в дебри определений, но услышать вашу точку зрения на проблему.

Например, вы можете попробовать привести примеры функциональности классов, которая будет потеряна вместе с исключениями и конструкторами.

Или можно попробовать пойти от противного.

Давайте предположим, что у нас есть гипотетический язык Ц++.

Пусть этот язык обладает всеми «фичами» C++, кроме исключений и конструкторов.

Пусть в этом языка есть вменяемая реализация Optional и статические фабричные методы используются для конструирования объектов. При этом создатель метода в праве выбирать в качестве возвращаемого значения как Optional, так и экземпляр объекта.

Давайте оставим за скобками стандартную библиотеку. Стандартная библиотека C++ была написана с оглядкой на существующий функционал. Для гипотетического Ц++ ее придется написать с нуля.

Расскажите, какие проблемы вы видите в этом языке? Будет ли при этом неминуемо утрачена какая-то ещё функциональность из C++, помимо конктруторов и исключений? Какие проблемы вы видите у этого языка?

Заранее благодарен за содержательный ответ.

В Rust решили, что если программа не может выделить память, то она падает в панику.

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

В Javascript есть <...> this.

this имеет примерно никакое отношение к классам javascript. this указывает на контекст в котором выполняется функция. Именно оттуда все проблемы с использованием this в замыканяих внутри методов.

Если долго писать на Qt, особенно если с этого начинать, может сложиться впечатление, что всеми способами избегать конструкторов в Си++ это нормально.

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

Смешно или нет, но данный рейтинг косвенно подтверждается количеством вакансий.

Так этот дебил, который комментарии не сделал для json. Сказочный дол**е6. Ну конечно он за ошибки в рантайме вместо компалтайма. js головного мозга.
Это кстати иллюстрация причины, по которой в стандарты попадают те или иные технологии: решает не самый талантливый или умный, а самый громкий

Самый громкий? Где ты вообще слышал про Крокфорда до треда на LOR? Справедливости ради, я сам первый раз узнал про него там. В штатной поставке JS долгое время был только XML, JSON туда добавили вследствие популярности среди индусских масс, примерно как фичи из тех же jQuery и Underscore. До своей известности Крокфорду удалось добавить только пару фич в ES5, это уже в ES6 он половину стандарта написал, из-за чего в ближайшие годы тебя ожидает тотальный JS, на фронте и на бэке.

Что это за рандомный аноним и почему ты считаешь что его мнение имеет вес?

Просто чтобы не пояснять самому то же. что Крокфорд может пояснить за меня. Хотя, я был наивен так считать, потому что к Крокфорду ЛОР прохладен, судя по всему.

Корутины удобно использовать при написании серверов, большая часть работы которых сводится к обращению к внешним ресурсам (диск, сеть). Без них тоже можно «наколхозить», но с ними получается выразительнее

Я ж всеми руками за, я даже упомянул Go, который является эталонным инструментом для написания подобных прокладок. Но если серьезно подходить к вопросу, то я советовал бы спросить себя «почему мне приходится снова и снова писать прокладки, которые почти ничего не делают?».

Сложность, к сожалению, тоже растет (и не факт что пропорционально)

И я о том же. Если у тебя сложность разработки-поддержки одной новой фичи не растет хотя бы как O(logN), не говоря уже про O(1), то это повод задуматься. Это и есть основная проблема распределенных систем, и я вообще не вижу. как корутины или горутины помогают с этой сложностью.

Где ты вообще слышал про Крокфорда до треда на LOR

Так я раньше читал про него. Просто имени не помнил.

из-за чего в ближайшие годы тебя ожидает тотальный JS, на фронте и на бэке

Ванга подъехала. Предсказания интересно послушать. Но мы на это посмотрим. А пока посмотрим на статистику используемых языков программирования на бэкэнде вэба:

https://w3techs.com/technologies/history_overview/programming_language/ms/y

https://w3techs.com/technologies/overview/programming_language

Сразу видно: JS прямо лидер :-)

Тем не менее, каждый раз при работе с сишным кодом снова и снова всплывает мысль «блин, как же здесь не фатает крестов».

В текущем проекте я выбрал чистый Си за его непревзойдённое среди языков высокого уровня время обработки данных (наименьшее из возможных). Ради этого даже функции обработки строк мне пришлось написать самостоятельно - всё в угоду наименьшему времени отклика.

В целом, удобство написания программы вряд ли имеет какое-либо значение, где требуется получить максимально возможный результат. А если в проекте время обработки данных не измеряется миллисекундами, то лучше взять Джаву за её превосходные средства отладки и не парить себе мозг всякими мэйкфайлами, указателями и убогим, ремесленным подходом управления зависимостями сборки.

Стоит ли учить «Кресты» в 2022 году? - Не думаю, так как начинать новые проекты на «Крестах» разумный разработчик вряд ли уже станет из-за отсталых средств разработки, отладки и сборки, а плескание в лужах старого «крестового» говна удовольствия вряд ли кому-то принесёт даже за относительно большие деньги. Лучше учить Си да Джаву с Джаваскриптом - новые проекты начинаются на них.

Так было до тех пор, пока выполнялся закон Мура. На наших глазах происходит разворот обратно. Индустрия уже начинает ощущать нехватку процессорных мощностей на самых разных уровнях. И вопрос не удается решить просто потратив больше денег на железо. Физика - она дама бессердечная. Совершить этот разворот за 2-3 года конечно же не удастся, но я готов спорить на бутылку хорошего виски или коньяка, что через 10 лет результаты этого разворота будут видны всем

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

А пока посмотрим на статистику используемых языков программирования на бэкэнде вэба

Очень советую поинтересоваться, как эту статистику собирали. К сожалению, большинство сайтов не светит инфу о том, на каких языках они написаны.

PS: поэтому советую равняться на статистику бэкэндов из опроса stackoverflow, а не w3c.

Лучше учить Си да Джаву с Джаваскриптом

удваиваю.

а вот и пятница )

Очень советую поинтересоваться, как эту статистику собирали. К сожалению, большинство сайтов не светит инфу о том, на каких языках они написаны.

PS: поэтому советую равняться на статистику бэкэндов из опроса stackoverflow, а не w3c.

Конечно к stackoverflow вопросов у тебя никаких, да?

Конечно к stackoverflow вопросов у тебя никаких, да?

Лучше статистики просто не существует.

Слепая вера. Добро пожаловать в клуб…

Например, вы можете попробовать привести примеры функциональности классов, которая будет потеряна вместе с исключениями и конструкторами.

Будет потеряна возможность снижения показателя «WTFs per minute». Два самых неприятных бага, которые я правил в последнее время, можно было предотвратить, если использовать Си++ нормально. Но в той кодовой базе используется Си++ без исключений, поэтому там нет атомарности инициализации объектов, что привело к ошибке по недосмотру. Кстати, ошибку в кодовую базу внёс один из основных авторов кода. Десятилетия опыта в индустрии вообще и много-много лет опыта с конкретной кодовой базой не спасли.

Очевидно, вопрос был задан специально в такой форме, с подвохом. Если затребовать ответ на него прямо, то ответ будет «никакая». Просто потому что классы без исключений и конструкторов можно организовать в Си, а на Си можно написать всё.

Пусть в этом языка есть вменяемая реализация Optional

Опять подвох. Что значит «вменяемая»?

При этом создатель метода в праве выбирать в качестве возвращаемого значения как Optional, так и экземпляр объекта.

То есть язык требует возвращать объекты по значению? Или он будет требовать все объекты выделять исключительно на куче?

Стандартная библиотека C++ была написана с оглядкой на существующий функционал. Для гипотетического Ц++ ее придется написать с нуля.

Я недавно попробовал написать что-то такое, но не осилил. Не было цели вообще всех осчастливить. Только очень ограниченная функциональность, которая нужна для небольшой утилиты. Поэтому очень хочу посмотреть на такую библиотеку. Не для гипотетичекого Ц++, а для существующего C++, но без исключений. Желательно, чтобы её можно было линковать статически, и только те части, что нужны.

какие проблемы

У меня сомнения в упомянутом Optional и способе возврата объектов из фабричных методов. Там получится инициализировать объект на стеке? А в заранее выделенном блоке памяти? Что произойдёт, если не получится выделить память? Как будет выглядеть обработка ошибок инициализации, скажем, десятка объектов в одной функции?

Конструкторы это вообще зло хотя бы потому, что при наследовании их надо все дублировать.

Можешь развернуть мысль? Что подразумевается под «дублировать»?

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

А методы при наследовании не надо «дублировать»? Опять-таки, что подразумевается под «дублировать»?

Можешь развернуть мысль? Что подразумевается под «дублировать»?

https://git.haiku-os.org/haiku/tree/src/kits/interface/Button.cpp#n38

Три дубликата конструктора. Бывает больше.

А методы при наследовании не надо «дублировать»?

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

Три дубликата конструктора. Бывает больше.

Ты не заметил, что у них разные параметры?

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

То есть ты хочешь сказать, что если класс B наследован от класса A, то конструктор B не может вызвать конструктор A? Я правильно тебя понял?

Erlang не прижился )

Ой и не говори. Недели летят... Работа, работа, работа...

Ты не заметил, что у них разные параметры?

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

Получается дублирующий паттерн вроде

Derived(): Base() {}
Derived(int a): Base(a) {}
Derived(int a, int b): Base(a, b) {}
Derived(int a, int b, int c): Base(a, b, c) {}

То есть ты хочешь сказать, что если класс B наследован от класса A, то конструктор B не может вызвать конструктор A? Я правильно тебя понял?

Нельзя указать, чтобы наследовались конкретные (или все, но с возможностью добавлять новые) конструкторы без писанины вроде Derived(int a, int b, int c): Base(a, b, c) {}.

И с методами такой «проблемы» нет? Просто я не вижу разницы.

Получается дублирующий паттерн вроде

Нет, конструкторы тоже можно наследовать если в конструкторе наследника ничего делать не нужно.

Почитай " Inheriting constructors" здесь: https://en.cppreference.com/w/cpp/language/using_declaration

struct B1 {  B1(int, ...) { } };
 
int get();
 
struct D1 : B1 {
  using B1::B1;  // inherits B1(int, ...)
  int x;
  int y = get();
};
 
void test() {
  D1 d(2, 3, 4); // OK: B1 is initialized by calling B1(2, 3, 4),
                 // then d.x is default-initialized (no initialization is performed),
                 // then d.y is initialized by calling get()
  D1 e;          // Error: D1 has no default constructor
}

очень опытный разработчик на С++

навеяло

#include <iostream>
 
template <typename... Arguments>
class HW;
 
 
template <class T>
class HW<T>
{
public:
    HW(T t): ch(t) {}
    ~HW() { std::cout << ch;}
private:
    T ch;
};
 
template <typename T, typename... ARGS>
class HW<T, ARGS...> : public HW<ARGS...>
{
public:
    HW(T t, ARGS... args):HW<ARGS...>(args...), ch(t){}
    ~HW() { std::cout << ch;}
private:
    T ch;
};
 
template <typename... ARGS>
void Print(ARGS... args)
{
    HW<ARGS...> hw(args...);
    (void)hw;
}
 
int main()
{
    Print('H','e','l','l','o',' ','W','o','r','l','d','\n');
}

Вообще-то проводились практически испытания. Писать с нуля абсолютно столько же времени

Да. Именно. Я ведь учитываю время УЖЕ затраченное на разработку

Я не понял позиции, отстаиваемой в этой фразе. Ты писал, что что-то там x2 — я ответил, что никакого x2 там нет, с классами и без классов писать одинаково. Вот по поводу шаблонов уже можно говорить.

Но и не значит, что могут быть хуже других

Я написал, что могут, только в инверсной форме. Например, лапша на goto и глобальных переменных всегда сложнее в написании и поддержке. Например, развесистое дерево иерархии менее гибкое и сложнее в поддержке, чем почти любой другой подход.

Стояночка. В glsl есть vec4/mat4 и есть умножение между ними. Это как минимум анолог перегрузки оператора умножения в C++ с разными типами. Это не элемент ООП ?

Эм-м-м.... а при чем тут ООП? Где тут объекты? Перегрузка операторов — это еще не ООП.

Я не понял позиции, отстаиваемой в этой фразе. Ты писал, что что-то там x2 — я ответил, что никакого x2 там нет, с классами и без классов писать одинаково. Вот по поводу шаблонов уже можно говорить.

Время уже затраченное на разработку Qt это X. Еще столько же время на переразработку без ООП это еще X. Итого 2X.

Я написал, что могут, только в инверсной форме. Например, лапша на goto и глобальных переменных всегда сложнее в написании и поддержке. Например, развесистое дерево иерархии менее гибкое и сложнее в поддержке, чем почти любой другой подход.

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

Эм-м-м…. а при чем тут ООП? Где тут объекты? Перегрузка операторов — это еще не ООП.

vec4 и mat4 - это аналоги объектов из C++. Как минимум у них есть конструкторы и перегруженные операции умножения.

Очередной топик из серии «я не такой как все»

Но что же поделать, если я не такой как все? 99% работодателей считает, что если бы у меня были способности, то я бы уже давно свалил за бугор или хотя бы изучил какой-то востребованный на рынке стэк, и сидел бы целыми днями тренировался проходить собеседования. Я не сделал ничего из этого. Все знают, что программист может жить только ради одного — продавать себя. А мне это забыли сказать. Тот факт, что я предпочел заниматься чем хочу и радоваться познанию мира, внезапно выкинуло меня в те самые 1%.

ТС при анонсе своего проекта обронил фразу, что выбрал С потому что так принято

ТС выбрал Си изначально потому, что особо не владел и не хотел владеть C++. потому что 95% книг и статей по C++ годятся только для подтирания жопы. Внезапно ТС узнал, что бывает годный C++, про который он никогда не слышал. И тогда ТС подумал «блин, надо было сразу на крестах писать», но было уже поздновато.

Я уже 10 сообщений назад написал, что никого не принуждаю, конечно пишите как хотите и на чем хотите

Есть объективные факторы, которые позволяют писать те же фичи быстрее. Иметь больше эффекта при той же затрате времени — это круто.

Мне кажется, что проблема с конструкторами и исключениями очень элегантно решена в Rust

Пф-ф-ф, в Object Pascal объекты создавались статическими методами в незапамятные времена. Я вообще не могу припомнить ни одного языка, где существовала бы аналогичная проблема. Именно потому я в десятый раз прошу: когда вы говорите «классы», то уточняйте, что имеете в виду под классами. Потому что в крестах максимально бесформенная ублюдочная интерпретация этого термина, грубо говоря «класс — это круто, всё что круто — это класс» — эталонное определение классов в C++ из палаты мер и весов, можете не сомневаться, что Страуструп для себя их примерно так и описал изначально.

P.S. В качестве примера можно вспомнить о WebAssembly. Это не единственный, но важный пример

Кстати, а что там по поводу WAsm-то? Ты же в курсе, что производительность среднего алгоритма в вакууме на JS равняется производительности WAsm?

Время уже затраченное на разработку Qt это X. Еще столько же время на переразработку без ООП это еще X. Итого 2X

А, ну так здесь я не спорю. Если бы сиюминутная коммерция двигала индустрию, то мы бы все писали на коболе с фортраном. К счастью, библиотеками вроде Qt пользуется достаточно много человек, чтобы время на ее разработку можно было условно принять за ноль.

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

Что плохо в классах C++? Я исходном сообщении есть ссыль на целый талмуд о том, что именно плохо.

vec4 и mat4 - это аналоги объектов из C++. Как минимум у них есть конструкторы и перегруженные операции умножения

Где объявлены эти конструкторы и операции их умножения? Да нигде, это вшито в само понятие типа GLSL.

Конечно нет. Метод родительского класса и вызываете в любом месте. С конструктором так не выйдет: клиенту нельзя создать объект через конструктор родительского класса.

Я бы взял из C++ в C возможность ненапряжно лепить вменяемую архитектуру для средних и больших проектов. Линукс кернел не в счет, это ОС, а не, например, кад.

Еще взял бы стандартную библиотеку по типу STL.

Про RAII, у меня двоякое впечатление от ее реализации в плюсах. Оно скорее не работает чем работает. Почему-то это никого не волнует, ну да ладно, это я рукожоп.

Справедливости ради скажу, что я бы пару-тройку проектов на своих работах перевел бы с плюсов на голые си. Но мне не дадут по понятным причинам. Как бабы. Я хочу, но мне не дают.

Нет, конструкторы тоже можно наследовать если в конструкторе наследника ничего делать не нужно.

Я знаю. А если делать таки что-то нужно (одинаковое для всех конструкторов)? Или добавить новых конструкторов к родительским?

добавить новых конструкторов к родительским?

Да. Так же как и если нужен новый метод, который делает то что делает метод родителя и ещё кое-что. Никакой разницы между методами и конструкторами тут нет…

Qt пользуется достаточно много человек, чтобы время на ее разработку можно было условно принять за ноль

Не суть, за ноль или нет. Я к тому, что из-за очередной моды никто не ринется переписывать хренову тучу кода, и хорошо. А была бы воля фанатиков, так переписали бы и Qt без ООП.

Что плохо в классах C++? Я исходном сообщении есть ссыль на целый талмуд о том, что именно плохо.

Продублируй, а то я не пойму какое именно сообщение.

Где объявлены эти конструкторы и операции их умножения? Да нигде, это вшито в само понятие типа GLSL.

А какая разница? Смысл в их поведении, а не в том, где они объявлены.

мне лень перерывать ворох ваших постов, и их слишком много, но я точно помню это что фигурировали слова что «так принято»

Нельзя вызвать метод родительского класса. Наследник наследует методы и они становятся его методами.

Можно.

Наследник наследует методы и они становятся его методами.

Дизассемблер показывает что нет. Если не переопределять или метод не виртуальный, то будет напрямую вызываться метод родительского класса. Что там навыдумывали не имеет большого значения, главное как оно работает на самом деле.

С конструктором так не выйдет в том числе из за ABI инициализации vtable.

Если я, к примеру, буду писать что-то в 100% сишном стиле, и мне потребуется полиморфизм (например, паттерн стратегия), я в гробу видал эмулировать vtable вручную.

То же касается шаблонов vs code duplication. Ковырял я однажды коллекции EFL – больше ни за какие коврижки в этот идиотизм под названием C не полезу.

Namespaces. Короткие префиксы всего, что библиотека экспортирует, – это возможно и решение для времён, когда этих библиотек было полторы штуки. А нынче рулят reverse DNS. И кстати, объектная запись obj.f(x) лучше чем obj_f(obj, x) в т.ч. логической группировкой связанных вещей, даже не будь там virtual и private/protected.

Exceptions. Написать короткий читабельный green path и поймать ошибку в точке входа – или на каждую строчку логики минимум три строчки обработки ошибок. Сишный вариант нечитабелен.

Ну а из exceptions следует RAII. Хотя finally мне категорически не хватает, т.к. далеко не всякий cleanup – освобождение ресурса. Александреску юзает самодельный макрос, а этим сраным «концептуалистам» в комитете видите ли поперёк горла приятную мелочь для людей сделать. Боятся нагружать свой такой простой и интуитивно понятный каждому язычок всякой хернёй.

А вот RTTI в 99.9999% случаев нахрен не нужен, и за dynamic_cast надо бить.

Короче, фичи C++ юзать надо там, где при их отсутствии их придётся многословно, коряво и неэффективно эмулировать на C.

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

Справедливости ради, я уже давно читаю твои комментарии по диагонали в лучшем случае, и мог упустить что-то.

я бы уже давно свалил за бугор

Я думал, ты в Израили живешь О_о

Что там навыдумывали не имеет большого значения, главное как оно работает на самом деле.

Да ты компиляторо-анархист.

Я с рейтингом не спорю, хотя и не свосем представляю что именно он отражает.

Просот смешно, что no-name язык сумел занять в нем первое место в далеком году.

Опять подвох. Что значит «вменяемая»?

Очевидно, вопрос был задан специально в такой форме, с подвохом. Если затребовать ответ на него прямо, то ответ будет «никакая».

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

Будет потеряна возможность снижения показателя «WTFs per minute».

Два самых неприятных бага, которые я правил в последнее время, можно было предотвратить, если использовать Си++ нормально.

Я пониаю, что описание каждого конкретного случая занимает много времени. Но без перехода к конкретике наш разговор так и затихнет на уровне полунамеков.

Поэтому очень хочу посмотреть на такую библиотеку.

Давайте попробуем завершить разговор о языке, а потом перейдем к разговору о библиотеке.

О языке

То есть язык требует возвращать объекты по значению? Или он будет требовать все объекты выделять исключительно на куче?

Нет, в языке есть все «фичи» C++: указатели, placement new, RVO, move semantic и все-все-все. Кроме конструкторов и исключений.

В случае невозможности выделить память, измененный оператор new может возвращать nullptr или Optional, в зависимости от того, что покажется уместным вам.

Очень много вопросов об Optional. Давайте определим Optional<T> как тип, который содержит либо объект (указатель тоже является объектом), либо сообщение об ошибке. Насколько я помню, в последних версиях C++ в стандартной библиотеке повился optional, но мне не удалось с ним поработать.

производительность среднего алгоритма в вакууме на JS равняется производительности WAsm

Не готов с этим спорить, но с удовольствием посмотрел бы на пруфы.

Я пониаю, что описание каждого конкретного случая занимает много времени. Но без перехода к конкретике наш разговор так и затихнет на уровне полунамеков.

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

move semantic

Не представляю, как его реализовать без конструкторов и деструкторов. И не нужно каждый раз ждать от меня вопросов. Они из раза в раз одинаковые. Как это работает? Как выглядит в коде? Ну и тому подобное. Детали реализации, о которые всё разбивается.

определим Optional<T> как тип, который содержит либо объект (указатель тоже является объектом), либо сообщение об ошибке.

Слишком размыто. Какой размер у Optional<T>, что из себя представляет сообщение об ошибке, и так далее.

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

Если у тебя получится такое, я бы не отказался посмотреть на реализацию. Но делать такое в ближайшее время вряд ли буду. Моя позиция — если тянуть классы, нужны и исключения. Иначе боль. Если ты считаешь, что можно классы взять, а исключения не тянуть — флаг в руки. Как уже много раз говорил, я бы посмотрел на результаты, это интересно.