Использовать ли голые указатели, 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 еще разок.

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