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

Да. И? С чём ты споришь-то?

Стандарт может ввести требование поддерживать __attribute__ и смысла в этом будет больше, чем от [[такого]] синтаксиса атрибутов.

Стандарт может ввести требование поддерживать __attribute__

Нет, не может. Они хотели, но у них не получилось. Слишком много кто в лес, кто по дрова.

и смысла в этом будет больше, чем от [[такого]] синтаксиса атрибутов

Нет, не будет, потому что [[такой синтаксис]] - это новый синтаксис с семантикой, описанной в стандарте, который можно если не реализовать, то хотя бы безопасно проигнорить. А с __attribute__ легко нарваться на идентичное написание, но разное поведение в ньюансах.

Собстно, чё далеко ходить:

The __restrict keyword differs from the __declspec (restrict) modifier in the following ways: …

Тут в рамках одного компилятора ножки на льду разъезжаются. А когда их 20+ - представить страшно.

А когда их 20+ - представить страшно.

Стараниями ISO их осталось 3.

С частичной поддержкой с++23:

GCC
Clang
MSVC
Apple Clang
EDG eccp
Intel C++
Nvidia HPC C++ (ex PGI)

С частичной поддержкой с++20:

Cray C/C++ (CC)

GCC
Clang
MSVC

Вот 3.

Apple Clang

См. 2 пункт.

EDG eccp

Только фронтэнд для C++ гуглится.

Intel C++

А, ну его GCC сильно обогнал даже на процессорах Intel. Но, да, забыл я про него.

Nvidia HPC C++

Это же для программирования под Nvidia CUDA и OpenMP.

Cray C/C++ (CC)

Тоже какой-то мутный компилятор. Нигде не видел его поддержки под #ifdef. А вот Borland, Watcom и т.п. — видел.

См. 2 пункт.

Нет, не см. Технически - это разные комплияторы.

Intel C++

А, ну его GCC сильно обогнал даже

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

Ещё у амуды свой форк силанга, но я не знаю, чё с ним.

Cray C/C++ (CC)

Тоже какой-то мутный компилятор.

Какой-то мутный - это ты. А Cray - это Cray. Крэя знать надо.

Это как?

Вот именнно, у тебя получаетя урезанный итератор.

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

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

Но и возвращать итератор для функции линейного поиска тоже абсурд. Я же объект хочу получить, а не переборщик. Почему детали реализации торчат наружу?

Так ты почитай что функция ищет, даже из сигнатуры очевидно.

Сразу с C++17 или на Go переходи.

Владеющих голых указателей лучше избегать

Подписываюсь под каждым словом, особенно «владеющих».

Без голых указателей вообще далеко не уедешь, множество библиотек имеет их в прототипах функций

Так что да, избавляет от new и delete.

Есть ли какие-то объективные причины использовать смарт-поинтеры, если new вызывается в конструкторе, а delete в деструкторе? Ну, кроме того, что меньше строчек.

«люди» не отдупляют ( и это хорошо!?) что индексы в массиве == что указатели

а потом натыкешься на чела который умеет в указатели но не различает имя от именуемого

ибо практика может замещать понимание

Есть - автоматизация. Вручную, нет гарантий вообще. Со смартпоинтером, нет проблемы «забыли вызвать» или «вызвали дважды». А ситуации когда забыли - сплошь и рядом.

new/delete я избегаю, лучше статически выделить всё, что надо

Обнаружен профессиональный писатель хелловордов.

а нет ли в этом проявления глубокой детской фортраны?

Начни с C++98. Когда почувствуешь, что чего-то не хватает поищи в C++ > 98. А лет через 15, когда окончательно устанешь, переходи отдыхать на Haskell/OCaml/F#.

Есть ли какие-то объективные причины использовать смарт-поинтеры, если new вызывается в конструкторе, а delete в деструкторе?

Да, exception safety. Если ты заньювил указатель в конструкторе, а потом улетел в исключение. Для этого, к примеру, достаточно вызвать new еще разок.

А что за проект? Для себя, или наружу?

Начинай с того что сможешь осилить.

начинать со стандарта c++26 (ну или хотя бы с c++23).

хоть один пример для чего использовать new и delete напрямую если только не пишешь сам стандартную либу можно?

Но если иначе никак - придётся кучей пользоваться..

не понятно — что такое «куча» в абстрактной машине c++?

ты о чём? :

std::vector<A> vec;
auto find_view = vec | std::views::filter( std::bind_front( std::ranges::equal_to(), value ) )
                     | std::views::take(1);

if ( not find_view.empty() ) {
    //do some with find_view.front()
}

Я не знаю, что такое абстрактная машина С++. Куча это когда ты пишешь malloc или new.

key-value inmemory db

нет — то что ты указал это

(1.4) — dynamic storage duration

[basic.stc#general-1.4] (https://eel.is/c draft/basic.stc#general-1.4)
[basic.stc.dynamic] (https://eel.is/c draft/basic.stc.dynamic)

foo(unique_ptr<T>(new T()), unique_ptr<U>(new U())); // unsafe

https://eel.is/c draft/expr.new#example-5

117 символов в строке?

Тут даже классический STL короче и яснее будет.

Как это читать? Ну если filter еще более-менее понятно, то что такое bind_front? Как можно понять, не залезая в документацию? Что-то связывается с чем-то спереди? std::bind1st переизобрели или что? Абсолютно дебильное название, которое не говорит о смысле функции.

И это все еще ужасно в сравнении с приведенным мной примером. Я напомню: мы линейный поиск делаем, а тут буковок прям выше крыши. Функцией линейного поиска будут пользоваться, если она короче написания for. Если for написать короче, то пользоваться этой функцией нет смысла. Печатать больше, кода больше, следовательно, багов больше, ясности меньше.

Потому что указатель удобнее итератора.

и чем же удобнее?

Указатель может неявно быть проверен на NULL

а итератор на `end()` (да и зачем на nullptr проверять если ищешь в контейнере?)

Удобнее тем, что реализация функция не торчит наружу. Просил объект — на указатель на объект.

Нет, итератор не может быть проверен неявно на end.

Проверять на нулевой указатель за тем же, зачем и на end, убедиться, что объект найден.

так а если будет нужно чото сделать с передачей самого инвокабл объекта? в твоём случае будет неуниверсально — а так будет все универсально — но ты как я понял явный неприветственник для разных стилей программирования (функционального в частности)

Конкретно find в 99% случаев нужен по всему контейнеру, а не по подмножеству. И ситуация настолько плоха, что единственное существующее стандартное решение - std::ranges::search.

std::ranges::find, std::ranges::find_if, std::ranges::find_if_not

ну так это же нужно будет проверить)

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

есть же `auto`

так итератор и есть объект)))

ну ты же и сделаешь свой смарт-поинтер по сути тогда — зачем кодировать что уже накодировано? ну и в `std::` обычно все самое лучшим образом заоптимизированное — вдобавок еще и компилятор-определённым способом

std::bind1st переизобрели или что?

нет — просто начинается бинд с начала, — есть еще `std::bind_back`

не залезая в документацию

а как вообще что-то юзать не читая документацию? по словам явно тут на самом деле — что принимает уже документацию почитать))

И это все еще ужасно в сравнении с приведенным мной примером

ну это уже с моей точки зрения субъективно — и не имеет никакого смысла обсуждать)

Удобнее тем, что реализация функция не торчит наружу.

реализация чего не торчит наружу?

Не вынудит, ты можешь любой сырой указатель завернуть в что-то не сырое.

ну и в std:: обычно все самое лучшим образом заоптимизированное

STD - это не про оптимизацию, а про максимально правильную реализацию чего-то стандартного. Оптимизировать там обычно нечего. Что там в std::vector оптимизировать, оно тупое как полено внутри. А вот написать std::vector чтобы идеоматически всему что надо соответствовало со всеми там итераторами - вот где в дурку уедешь. Если бы STD был прям офигеть как «оптимизирован», не появлялось бы всяких альтернативных библиотек с контейнерами. Ну, да, альтернативные появляются не потому, что STD не оптимизировано, а скорее потому, что в STD не всё есть, но иногда и по первой причине, например люди хотят какой-то особый свой vector с какими-то приколами, которые в их мире считаются «оптимизировано».

Это не важно. Важно то, что это тащит в зависимости программы сложнющий и недетерменированный malloc. А также вызывает утечки памяти, если забыть освободить выделенную память. Лучше с этим вообще не связываться по-возможности.

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

а никто не говорит, что нужно при каждом чихе выделять в динамическом сторадже — но для того, что бы не забыть есть как раз уже сделанное — смарт-поинтеры, контейнеры, алгоритмы...
не использовать динамическую память это плохой совет, поскольку тогда пришлось бы «ванговать» что бы выделить в автоматическом или ином нединамическом варианте стораджа (в обыденности называют «на стеке»)...

сложнющий и недетерменированный malloc

откуда все эти сведения? стандарт с++ не описывает каким он должен быть в реализации, кроме основных функциональных свойств.