Использовать ли голые указатели, new, delete и т.п. в новом проекте или сразу начинать с стандарта 11+?

Использовать ли голые указатели, new, delete и т.п. в новом проекте

Нет.

сразу начинать с стандарта 11+

Да.

С C++17, хотя бы, 11 это ни о чем.

Сейчас почти все и всë пишут на C++11, особенно учитывая то, что в этом стандарте ООП в этом языке таки довели до ума.

C++11 – это версия стандарта, в которой и появился RAII, трудно назвать такое «ни о чём».

Исторически да, его вклад огромен, но для новых проектов в 2025 году это ни о чем. Смысл то какой.

Автор явно делает свои первые шаги, и там принципиальной разницы нет. Но да, почему бы не смотреть сразу на C++23?

Всецело поддерживаю это предложение. Просто я имел в виду, что 17 это некий разумный минимум, если по каким-то причинам не использовать просто последний стандарт.

new, delete

А как новые стандарты избавят тебе от new при создании объекта? Или от написания деструктора в класса в котором ты будешь юзать delete?

C++11 – это версия стандарта, в которой и появился RAII, трудно назвать такое «ни о чём».

Чего чего? В 11ых действительно появилось много такого что тектонически поменяло программирование на плюсах, но RAII был задолго до.

А как новые стандарты избавят тебе от new при создании объекта?

использовать std::make_unique

Или от написания деструктора в класса в котором ты будешь юзать delete?

раз нет new, то нет и delete ;-)

использовать std::make_unique

Это просто сахарок избавляющий от необходимости explicitly spell-out an exact lhs type, ну и sequence point. Больше там нет ничего, в отличие от std::make_shared.

А как новые стандарты избавят тебе от new при создании объекта? Или от написания деструктора в класса в котором ты будешь юзать delete?

А про умные указатели не в курсе, да?

auto p = std::make_shared<CoolClass>();

Удалится оно само, когда не останется указателей на объект. Так что да, избавляет от new и delete.

Владеющих голых указателей лучше избегать и использовать std::unique_ptr/std::shared_ptr. Но это же дивный мир C++, ты можешь подключить какую-нибудь библиотеку, которая тебя вынудит использовать new/delete (например Qt).

Для объектов Qt да, но у них там своя машинерия внутри, *parent в конструкторах и удаление дочерних объектов в деструкторах. А для объектов и структур данных, не связанных с Qt классами, никто не заставляет использовать new и delete, и вообще это нежелательно.

Да для себя хоть на ассемблерных вставках пиши! Если на заказ, что тебе просто будет спокойнее спать, если станешь использовать умные указатели и STL - зачем зря рисковать?

Я так понимаю, что у тебя первый вариант?

Ответ здесь: C++ Core Guidelines: Resource management

Именно для нового проекта плюсы вообще не надо выбирать ни старые ни новые никакие, раз есть такая возможность, ради чего вообще? Язык активно коболизируется, чтобы ты там ни писал, с высокой вероятностью будет на выброс

Я пытался донести мысль, что в реальных задачах жестко соблюдать правило «нигде не использовать new/delete» часто может не получиться.

Имхо, «не так страшен чёрт как его малютка». И вообще, если мы о правилах заговорили - единственное которому я неукоснительно следую: «write what you know, know what you are writing». А все эти насильно навязанные политики на тему умных указателей - от лукавого. Вот скажите ещё что ни разу в жизни «delete this» не приходилось делать…

А что там такого в C++11 довели до ума для ООП? Это ж прежде всего способ мышления, взгляд на мир, редко скованный какими-то языковыми особенностями. Экстремально позднее связывание, передача сообщений, сохранение состояния — что кардинально нового сюда принёс C++11?

Зачем в деструкторе класса вызывать какой-то там delete? :)

Забавно что самый популярный C++ фреймворк (это Qt конечно же) до сих заставляет писать код с new и редко с delete.

А что там такого в C++11 довели до ума для ООП?

Добавили override и final как минимум.

Жизнь боль

Офигеть. До этого как без них жили?))

Это просто сахарок

Это не просто какой-то там сахарок, а сахарок, который вычищает код от говна. Дальше достаточно простейшего текстового поиска и на руках почти полная гарантия отсутствия утечек. История почти как с неуловимыми сишными кастами и их более продуманные аналоги reinterpret_cast/const_cast/…

Что промелькнуло у меня из этого документа на экране про указатели и RAII, то выглядит логично. Действительно, сырые указатели иногда необходимы. Даже в расте их практикуют (в виде ссылок, но с проверяемым временем жизни. Проверка дает оценку сверху, но все же хоть что-то)

Вообще, как много языков можете назвать, для которых были написаны гайдлайны? Гайдлайны по тому, как надо писать, и как не надо. Я вот помню одну старую книгу про то, как избегать «ошибок на фортране».

Итого получаются C++ и фортран. Есть еще кандидаты в этот великолепный список?

или сразу начинать с стандарта 11+?

Сразу бери максимально свежий стандарт, поверь, там постоянно появляются штуки, которые действительно делают жизнь проще. Возможно не хватит опыта это оценить и некоторое время будешь писать говно, а новые стандарты как пятая нога. Читай всякие C++ Core Guidelines, там есть весьма дельные советы, озарение придет быстрее

Вообще, как много языков можете назвать, для которых были написаны гайдлайны?

Солидные паттерны проектирования

15 лет стандарту, молодой еще, так что посиди 20 лет на C++98 еще.

Забавно что самый популярный C++ фреймворк (это Qt конечно же) до сих заставляет писать код с new и редко с delete.

«Вы не понимаете, это другое!». А по факту всё всегда решает грубая сила — если нет силёнок написать аналог какой-нибудь мощной библиотеки, то утираются со всеми своими моднявыми штучками и тихо юзают ненавистное «легаси».

Есть еще кандидаты в этот великолепный список?

Да их куча - берите книги с названием, где Thinking, Idiomatic или Effective присутствуют. Вот для примера:

1. Thinking in Java. Bruce Eckel
2. Thinking Forth. Leo Brodie
3. Effective Perl Programming: Ways to Write Better, More Idiomatic Perl. Joseph N. Hall / Joshua A. McAdams / brian d foy Hall / Mcadams / Foy

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

Имхо, «не так страшен чёрт как его малютка». И вообще, если мы о правилах заговорили - единственное которому я неукоснительно следую: «write what you know, know what you are writing».

bugfixer ★★★★★ (29.08.25 19:34:32 MSK) «write what you know, know what you are writing»

👍

Используй Rust.

За «Thinking Forth» спасибо! После ухода Крона что-то я подзабыл про эту книгу. Крон увлекался этим языком

Прям new / delete я бы не стал. Есть умные указатели. Но для вызовов функций, типа в качестве а-ля ссылки можно, т.е. когда есть умный указатель на объект A и нужно дать его попользоваться (без передачи владения) в объект B.

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

Ну-ка, ну-ка, а в чем плюс от использование std::make_unique?

ЕМНИП, его добавили просто так (как и вообще многое).

std::make_shared имеет смысл, но std::unique_ptr up(std::make_unique<A>(param)) ничем не лучше std::unique_ptr<A> up(new A(param));

довели до ума

Добавили override и final как минимум.

#include <cstdlib>
#include <iostream>

struct override {
  virtual ~override() {
    std::cout << __func__ << '\n';
  }
} final;

struct final final: override {
  ~final() override final {
    std::cout << __func__ << '\n';
  }
} override;

int main() {
  return EXIT_SUCCESS;
}

Психи.

P.S. Да, этот код компилируется.

Я бы начал с последнего стандарта. Что такое голые и не голые указатели, я не знаю. new/delete я избегаю, лучше статически выделить всё, что надо. Но если иначе никак - придётся кучей пользоваться..

Как уже пояснял анонимус тут, смысл в том, чтобы сократить количество new/delete в коде.

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

в новом проекте

Значит для себя пишешь. Ну а если для себя, тогда научись писать код нормально, а не так, как в STL.

Предвосхищая гневные комментарии, я считаю STL полнейшим говном:

std::vector<A> vec;
std::vector<A>::iterator it;
if ((it = std::find(vec.begin(), vec.end(), value)) != vec.end()) {
    //do some
}

Потому что нормальные люди пишут в ООП, а не в @#$%ом «обобщенном программировании от Александра Степанова (автора STL)»:

Vector<A> vec;
A *object;
if (object = vec.find(value)) {
    //do some
}

Где у класса Vector<T> есть метод T *find(const T& value, T *since = NULL, T *finish = NULL) const

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

На isocpp написано что make_unique это exception safe вариант.

Я игнорирую анонимусов на linux.org.ru.

А смысл? new T(args) явно короче, чем std::make_unique<T>(args), а смысла несет ровно столько же.

stl была копромисс - цельнотянутая с ада

и у тя семантика разная

ну и стандартная реакция «ооп» криво для уже двух-сортных алгебр

философию программирования на выбранном языке.

Что это? Что делать тем, кто код пишет то, мне например не до филосовстрования.

https://en.wikipedia.org/wiki/P._J._Plauger#:~:text=Programming on Purpose

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

фортран для слабаков

Настоящие_Программисты(TM) если меняют исполняющее устройство - за здают в архив все рулоны сырцов на старое устройство и пересоздают сырцы для нового исполняющего устройства с учётом обновлённых технических требований и накопленных эвристик и инсайтов - как результат по мере удешевления вычислений снижаются требования к памяти хранения и памяти исполнения