Как бы вы заменили ключевое слово «новое»?

Проблема соответствует new, delete, new[], delete[]

Ничего особенного.
Вы должны обернуть распределение памяти внутри класса, чтобы это не сильно повлияло на обычных пользователей. Один объект может быть обернут интеллектуальным указателем. В то время как массив может быть представлен std::Vector‹›

нельзя использовать #define с new, как с malloc.

Причина такой лажи с malloc заключалась в том, чтобы ввести собственный уровень управления памятью между вашим приложением и стандартным уровнем управления памятью. Это потому, что в C вам не разрешалось писать собственную версию malloc. В C++ вполне законно написать свою собственную версию new, что делает этот трюк ненужным.

Я не вижу причин заменять ключевое слово new чем-то другим (и, кажется, комитет C++ согласен со мной). Он понятен и делает то, что должен. Вы можете переопределить operator new в своем классе, не нужно использовать определения.

Чтобы устранить проблему new[]/delete[], вы можете использовать std::vector.

Если вы хотите использовать интеллектуальный указатель, вы можете использовать его, но я хочу контролировать, когда будет использоваться интеллектуальный указатель. Вот почему мне нравится, как это работает в C++ — высокоуровневое поведение с возможностью управления низкоуровневыми деталями.

Я бы дал ему семантику new в С# (более или менее):

1. Выделяет память для объекта.
2. Инициализирует память, устанавливая для переменных-членов их значения по умолчанию (обычно 0 для значений, null для ссылок).
3. Инициализирует механизм динамической привязки объекта (виртуальные таблицы в C++, таблицы определения типов для управляемых виртуальных машин).
4. Вызывает конструктор, после чего виртуальные вызовы работают должным образом.
5. Для языка без сборки мусора (на данный момент для нового языка) верните smart_ptr или аналогичный результат вызова.

Кроме того, сделайте все объекты либо значимыми, либо ссылочными типами, чтобы вам не приходилось явно указывать smart_ptr. Разрешите new выделять кучу только для ссылочных типов и убедитесь, что он содержит информацию для правильного вызова деструктора. Для типов значений new вызывает конструктор памяти из стека.

Используйте сборку мусора, чтобы вам никогда не приходилось сопоставлять новое с чем-либо.

Используя классы контейнеров STL и различные boost:smart_ptrs, нет необходимости явно вызывать new или delete в коде C++.

Несколько мест, где вам может понадобиться вызвать new (например, для инициализации интеллектуального указателя), используют идиому именованного конструктора для возврата указателя типа класса, заключенного в например, boost:shared_ptr.

Но C++ и STL очень и очень усердно работают над тем, чтобы вы могли обращаться с большинством объектов как с объектами-значениями, поэтому вы можете создавать объекты, а не указатели, и просто использовать их.

Учитывая все это, нет особой необходимости заменять новый оператор — и это может привести к множеству проблем, будь то необходимость использования сборщика мусора или снижение тонкого низкоуровневого управления, которое C++ предлагает программистам.

Если ваш новый язык является сборщиком мусора, вы можете не использовать ключевое слово new. Это то, что сделал Python (и Lisp сделал почти 5 десятилетий назад!). Также см. ответ Питера Норвига на аналогичный вопрос здесь. (Разве отсутствие «новости» не является хорошей новостью?)

Иногда вы хотите заменить конструктор фабрикой. Это хорошо известный рефакторинг. Заменить конструктор фабричным методом. Так может это и имелось в виду в статье?

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

Среды внедрения зависимостей, такие как Unity, выводят эту концепцию на новый уровень. Как видно из следующего кода C#, для создания интерфейса IMyClass не применяется "новое":

IUnityContainer myContainer = new UnityContainer();
myContainer.RegisterType<IMyClass, SomeClass>();
IMyClass thing = myContainer.Resolve<IMyClass>();

Причина, по которой C++ имеет отдельный оператор new (или C malloc), в первую очередь заключается в том, что можно создавать объекты, время жизни которых превышает область действия функции, которая их создает.

Если бы у вас было удаление хвостовых вызовов и продолжения, вам было бы все равно - все объекты могут быть созданы в стеке и иметь неограниченную протяженность - объект может существовать до тех пор, пока вы не вызовете продолжение, которое соответствует выходу объекта из области видимости и его уничтожению. . Затем вам может понадобиться что-то для сборки мусора или иного сжатия стека, чтобы он не заполнялся ненужными объектами (Chicken Scheme и TinyOS 2 — это два разных примера создания эффекта динамической памяти без динамической памяти либо во время выполнения, либо время компиляции; Chicken Scheme не допускает RAII, а TinyOS не допускает истинного динамического распределения), хотя для большого объема кода такая схема не будет сильно отличаться от RAII с возможностью выбора изменения порядка объекты уничтожаются.