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

Где там? Внутри библиотеки? Да пофиг. Важно что наружу торчит. А всё, что торчит наружу, всегда легко заворачивается в C++ RAII технологию. И снова ты не увидишь никаких malloc() / free().

По сабжу - ответ двоякий. Если начать использовать только новые стандарты типа C++11, то может потеряться чувство «что там под капотом». Хорошим способом будет так: написать на голых указателях, помучаться, а потом все места с указателями написать правильно с пониманием что и почему в новых стандартах сделано. Ну а в профессиональной жизни уже конечно использовать только новые стандарты, но обычно в процессиональных коллективах просто кочергой по морде отмудохают, если это сделано не так - так что заранее можно не думать, коллеги люлей вломят если что не так.

Что там описывает стандарт C++ - не имеет никакого значения. Значение имеет только то, что выплёвывает g++.

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

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

Ну ты один раз залез и написл необходимый минимум C++-обёрток под все нужные вызовы в этой библиотеке. А потом херак-херак и оперируешь уже этими обёртками, не думая.

Нулевой указатель это 0, который неявно приводится к типу bool как false.

auto напрочь убивает читаемость кода. Во многих даже C++11 проектах auto запрещено.

Объясняю:

auto a = f();
auto b = g(a);
auto c = h(b);

Что такое a, b, c?

Чтобы это понять нужно найти функцию и посмотреть ее тип. Если это шаблон (или неявный шаблон, который вовращает auto), то еще веселее.

В обычном редакторе код читать невозможно совсем. А в редакторе с LSP (или IDE) нужно вставать курсором на выражение и смотреть тип. То есть ты можешь просмотреть только одну строчку кода, на которой стоит курсор.

Также это введет к очень большой вложенности типов. Тип boost::chrono:: timezone::local — это ненормальность. Когда нет auto программист думает о том, что тип должен быть не только понятным, но и чтобы пользователь этого типа не умер от старости, когда его печатает.

так а если будет нужно чото сделать с передачей самого инвокабл объекта?

Я не понял вопроса.

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

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

Переборщик (iterator) — детали реализации функции find. Я не просил дать мне переборщик, я просил указатель на объект массива.

Можно сделать, чтобы итератор создавался из указателя. Нужен итератор — сделай его. Почти всегда, когда ты вызываешь find итератор не нужен.

Кстати, говоря о итераторах, лучше использовать т.н. «Java style iterator», как в Qt. Он предоставляет выбор: использовать виртуальные функции (что имеет смысл, когда скорость не важна) или написать шаблон. STL выбора не дает, если хочешь итератор для какого-то контейнера, то только писать шаблон.

Да, всегда нужно говорить, что обсуждая C++, речь идет не о бумажке, а о существующих реализациях. Иначе в демагогии ISO можно утонуть. И, как правило, это только GNU C++ и Visual C++.

Присоединяюсь и пигную safocl.

STL не лучшим образом оптимизирован. Например, существует EASTL.

Что такое a, b, c?

Ответ: а хрен его знает. Если бы это были int или float, то было бы понятнее? Это температура, скорость, количество пользователей у сервиса? Методы надо называть нормально и использовать специфичные типы, чтобы не складывать яблоки с апельсинами, и тогда auto не будет пугать.

Это не очень удобно и не всегда возможно. Допустим тебе нужно вызвать foo(this), когда foo принимает владение, а this лежит в std::unique_ptr, о котором внутри самого класса ничего неизвестно.

Речь не об этом. А о том, что даже правильно названные методы не дают понятия о типе.

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

так они же уже написаны — в stl )))

и? это избавляет от проверки? — или ты будешь без проверки «распаковывать» данные по нему?

Во многих даже C++11 проектах auto запрещено.

с++11 это древнейшее легаси — даже с++17 уже легаси — забудьте и не упоминайте таковое вообще нигде с данного момента (обращение ко всем, а не на «ВЫ» к одному человеку)

Что такое a, b, c?

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

В обычном редакторе код читать невозможно совсем.

возможно тогда покрупнее шрифт может сделать тебе?

Я не понял вопроса.

увы...

Я не просил дать мне переборщик, я просил указатель на объект массива.

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

Переборщик (iterator) — детали реализации функции find.

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

Да, всегда нужно говорить, что обсуждая C++, речь идет не о бумажке, а о существующих реализациях.

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

STL не лучшим образом оптимизирован.

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

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

для понимания кода нужно знать контекст испоьзования, а тип вообще никак на таковое не сможет указать

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

а чем явно указанный тип поможет?

... ну и какое соответсвтие имеет относительно аспекта обсуждения сие высказывание вообще?

С++98 нормальный стандарт, какое легаси. Можно подумать, в новых стандартах что-то полезное добавили.

а чем явно указанный тип поможет?

Не разочаровывайте меня. Это тот момент когда в приведенном примере нормализация происходит. И это именно то что разваливает ваш концепт «тип не имеет значения, компилятор справится, главное контекст» напрочь.

Что за бред? А Boost как работает? Точно так же, компиляторозависимые сущности использует.

auto напрочь убивает читаемость кода.

С читаемостью всё норм, когда читаешь код, то вообще пофиг на тип. Ты дальше условный auto a = ...; a.do_that(); и этого достаточно. Я часто печатаю какой-нибудь забористый кусок на бумаге и читаю прогуливаясь, акцент лишь логике алгоритма, что она верна.

Проблемой может лишь стать модификация кода с auto в блокноте. Но LSP помогаторы стали весьма годными и закрывают эти неудобства. Юзай lsp и не жужжи.

Но вот плюс у auto есть огромный - когда ты пишешь код, то ты в потоке, каждое отвлечение на «а что там возвращает это говно из библиотеки, как его написать правильно» сбивает и ты теряешь концентрацию и надо заново настраиваться и «загружать» в голову контекст. Короче говоря - это реально помогает поднять производительность кодонаписания. Это должно быть знакому любому, кто писал свой алгоритм, а не правил какую-нибудь готовую херь.

А если тебе уж так сильно надо, то заменить все auto на конкретный тип спокойно смогут все те же LSP помогаторы, если их, конечно, кто-то этому научит. А если не научил до сих пор, то не сильно то и надо, видимо

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

в худшем - на неожиданные переполнения

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

Можно подумать, в новых стандартах что-то полезное добавили.

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

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

STL не лучшим образом оптимизирован.

А что конкретно оптимизировано не лучшим образом?

Я пока слышал претензии разве что в адрес std::unordered_map и std::regex. Причем касательно std::unordered_map там, насколько я понимаю, просадка производительности по сравнению с другими реализациями хэш-таблиц происходит из-за требования сохранения валидности итераторов. А это требование, емнип, проистекает из возможности «прозрачной» замены std::map на std::unordered_map без потери корректности. Т.е. в случае std::unordered_map проблема не в отсутствии оптимизации, а в изначальных требованиях. Что по поводу std::regex не знаю, не интересовался, только слышал краем уха.

Какие-то другие примеры?

PS. Всякие std::ostream-ы вроде как тормоза по определению, опять же by design.

PS. Всякие std::ostream-ы вроде как тормоза по определению, опять же by design.

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

Что по поводу std::regex не знаю

"Нестандартные" внешние библиотеки быстрее работают.

«Нестандартные» внешние библиотеки быстрее работают.

Я в том смысле что не знаю причин, по которым std::regex работает медленнее. Либо здесь реально неоптимизированная реализация, либо же это опять by design из-за каких-то требований.

Что такое a, b, c?

А если f(), g() и h() возвращают лямбда функции что прикажете выписывать в качестве имен типов?

Вы имете ввиду возвращают указатели на функции? Сделать typedef (чтобы не городить лапшу) и этот тип возвращать.

Вы имете ввиду возвращают указатели на функции?

Нет, я имею в виду возврат лямбда-функции по значению.

#include <iostream>

auto f(int a) {
    return [a](int i) { std::cout << a + i << std::endl; };
}

template<typename L>
auto g(L && l) {
    return [l](int g) { l(g); };
}

int main()
{
    auto a = f(13);
    auto b = g(a);
    b(10);
}

std::map тоже не фонтан. Почему-то используется красно-черное дерево, хотя в реальных тестах АВЛ-деревья работают быстрее, особенно на поиск.

Хотя стандарт не запрещает использовать АВЛ.

Ого, какой лютый изврат. Я, если честно, даже не знал, что так можно в C++14.

А в чем смысл так писать код?

std::map тоже не фонтан. Почему-то используется красно-черное дерево, хотя в реальных тестах АВЛ-деревья работают быстрее, особенно на поиск.

Как обычно, не все так однозначно: https://stackoverflow.com/questions/5288320/why-is-stdmap-implemented-as-a-red-black-tree

Ого, какой лютый изврат.

Это не изврат.

Я, если честно, даже не знал, что так можно в C++14.

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

А в чем смысл так писать код?

Например, для использования функциональной парадигмы.

И, как правило, это только GNU C++ и Visual C++.

Clang смотрит на тебя с подозрением.

Это асимптотика. Высота дерева же маленькая и константа O(1) при удалении больше времени занимает, чем O(log(N)) при малом log(N).

А clang++ реализует GNU C++ в основном. Своих расширений у него очень мало (которые не реализованны в GNU C++). Оно и понятно, ведь единственная цель clang++ — заменять g++, потому что кому-то (не будем показывать пальцем) не понравилась GPLv3, хотя устраивала GPLv2.

Вот прямо совсем недавно тыкал чужую программу, которая в clang собирается, а в gcc не хочет (тыкал по работе, поэтому исходников не покажу, увы).