Опрос: Три-пять лучших фич C++

Потоки я тоже не использую. А вот filesystem использую.

В результате получится намного больше продублированного кода с большим шансом совершить ошибку.

+1. Зачем изобретать велосипед, если велосипед уже сделали умные опытные люди?

Без using namespace b; и namespace a = b; это совсем не то.

// goo.h
#ifndef GOO_H
#define GOO_H
#include "foo.h"
extern namespace_struct const goo;
#endif // GOO_H

// goo.c
#include "goo.h"
static int my_bar(int a, char * s) { /* ... */ }
static void my_baz(void) { /* ... */ }
namespace_struct const goo = { my_bar, my_baz };

// other_main.c
#include <stdio.h>
#include "foo.h"
#include "goo.h"
int main(int argc, char** argv) {
  namespace_struct const * const xoo = (argc > 1 ? foo : goo);
  xoo->baz();
  printf("%d", xoo->bar(3, "hello"));
  return 0;
}

glib заиспользуй, там все обернуто красивыми макросами и не будет дублирования

Ну вот и с твоим предложением на тему выкидывания из стандартной либы будет то же самое :) И так уже было когда все изобретали свои изводы STL

А с чего ты взял, что они умные и опытные?

Не тащи :) Отстегивай стдлибу и превозмогай :)

Там значительные рантайм накладные расходы. C++ быстрее. Ну и это Гном, а значит зашквар.

Остается спросить «А ты кто?» :)

Это идиома, которая привязана к определённым фишкам языка.

А с чего ты взял, что они умные и опытные?

С того, что инкапсуляцию, наследование и полиморфизм не выкинули сразу на мороз, а тащат уже 30 лет. Значит, проверенная временем технология.

За Пуст в серьезных проектах в лучшем случае бьют по рукам, а в худшем - увольняют.

Ога, миллионы мух не могут ошибаться.

Какой экстремистский экстремизм. Список столь серьзных проектов будет?

Ога, миллионы мух не могут ошибаться.

Ни разу ваще не видел критики, что эти принципы плохие

а также std::unique_ptr (shared_ptr слишком жирный).

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

В GCC она намертво прибита к исходникам компилятора и её ещё замучаешься правильно кросскомпилировать чтобы исключения не сломались.

Итак, мой список, как и обещал:

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

2. Модули. Уже и так, и сяк к ним подбираются, а никак не могут подобраться. Реализация раздельной компиляции в C/C++ — это пережиток прошлого, и индустрия не продвинется, пока не научится «компилировать заголовки» (не путать с предварительно отпарсенными заголовками, которые нынче принято называть «предварительно скомпилированными»).

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

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

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

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

Критики полно :) Набирай любой концепт в гугле со словами «concidered harmful», «bullshit» и «crap» :))

Напиши тогда сам без накладных расходов с помощью макросов или кодогенерации. Гном, кстати, несмотря на «плохой рантайм», работает гораздо шустрее KDE.

Так если убрать из стандартной библиотеки все, то никуда не денешься.

Ну тут как бы да.

Работать будет, согласен. Но надо знать типы и всё это делать вручную, как фича языка оно куда лучше выглядит и проще в использовании.

За Пуст в серьезных проектах в лучшем случае бьют по рукам, а в худшем - увольняют

Boost очень большой, там есть отдельные годные либы, вроде intrusive containers.

Можно свою стандартную библиотеку написать.

Для счётчика ссылок я предлагаю использовать наследование объекта от общего класса счётчика ссылок, вроде IUnknown или BReferenceable. Два счётчика ссылок для одного объекта и отдельный блок в памяти – это перебор и в большинстве случаев не требуется.

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

Ммммдаааааа. Хули нам.

с помощью макросов или кодогенерации

Зачем если есть готовый C++?

Кто и как эту шустрость измерял?

По моим ощущениям KDE работает шустрее на одном и том же железе. Кто прав?

Кто прав?

Выхлоп профайлера :) Все остальное «маняощущения»

1. Исключения.
2. Шаблоны (без всякой магии, просто шаблоны, чтобы можно было делать обобщённые контейнеры).
3. Классы, можно без виртуальных методов и наследования. В целом виртуальные методы тоже иногда пригождаются, но и просто классы это полезно.
4. Пространства имён.
5. Синтаксические мелочи, например чтобы () писать вместо (void).

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

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

что там отлаживать в списке из next-prev указателей? :) Свободные функции их обработки? :) Или «классы» с этими методами?

Его можно через класс с лямбдой и деструктором сделать.

Нельзя, потому что в defer можно будет кидать исключения, а в деструкторе не всегда можно кидать исключения. JeanHeyd Meneide говорил что после включения defer в С, будет от него предложение в комитет по поводу включения defer также в С++.

Вот полное видео на эту тему: https://www.youtube.com/watch?v=8JxsyAqdo0U

что там отлаживать в списке из next-prev указателей? :) Свободные функции их обработки? :) Или «классы» с этими методами?

Почему-то ты триггернулся на двусвязанный список. Красно-черные деревья поотлаживать не хочешь?

С интрузив-структурами обратно это будут либо свободные функции, либо методы классов. И что же там такого в красно-черных деревьях, что заставляет тебя кидать понт будто это рокет-саенс? :)

Однако, они должны использоваться не для реализации STL

Это еще почему?

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

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

То, что это не делается за пару часов, но требуется достаточно часто, чтобы люди с ментальностью «да что там связанный список написать», «да что там аллокатор свой сделать», «стандартыне строки? да зачем они нужны» не подпускались ни к одному коммерческому проекту. По крайней мере я бы не позволил тебе растянуть сроки релиза в 2-3 раза из-за «разве ж это рокет-саенс?». Или может быть ты пользуешься самописным компилятором, и браузер, через который ты мне пишешь, у тебя тоже свой?

Как интересно можно реализовать готовые алгоритмы для статически типизированного языка без шаблонов? При том, что ты не знаешь заранее ни типов контейнеров ни типов элементов

Ну посмотри на Go, например. Там даже без шаблонов встроенные типы полиморфны. Потому что приколочены в компилятору. Эта приколоченность дает возможность их лучше оптимизировать, выдавать более адекватные сообщения об ошибках, и намного быстрее компилировать.

Это все уже сделано много раз :) А ты все еще с ментальнстью изобретателя колеса, первооткрывателя что луна не из зеленого сыра.

По крайней мере я бы не позволил тебе растянуть сроки релиза в 2-3 раза из-за «разве ж это рокет-саенс?».

Ты и не в том положении, чтоб мне что-то позволять-не позволять :)

А как быть с пользовательскими типами контейнеров и типами элементов?

Про сообщения об ошибках я уже писал.

Про скорость компиляции. Это точно имеет большое значение, что код компилируется на сколько-то быстрее с современным железом? Может лучше сфокусировать внимание на скорости выполнения? А то такими доводами вообще JS всех уделывает.

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

Ты же понты кидаешь, наверное у тебя все свое? :) То деревья, то вдруг компилятор-браузер :) Ты определись, об чем твои понты.

1) неймспейсы 2) умные указатели 3) throw

остальное какбы пох.

Возможность компилировать формулы с кастомными типами. То есть - минималистичные классы (можно без наследования/полиморфизма итд) чтобы этот самый кастомный тип описать, и возможность перегрузки операторов.

Или может быть ты пользуешься самописным компилятором

А у меня есть недоделанный для Си с доп. фичами (языка), собирался на него перейти но пока не успел.

А как быть с пользовательскими типами контейнеров и типами элементов?

Понять и простить. Я упомянул очень простые штуки, в том числе на основе которых можно писать составные контейнеры, и уж при самом-самом крайнем случае писать что-то по-настоящему свое. Без строк в 2021 очень неприятно писать программы, знаешь ли.

Про скорость компиляции. Это точно имеет большое значение, что код компилируется на сколько-то быстрее с современным железом? Может лучше сфокусировать внимание на скорости выполнения? А то такими доводами вообще JS всех уделывает

Да, JS и Go, индустрия своё слово сказала.

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

Имхо лучший Си это современный Паскаль, единственное, что регистрозависимости не хватает.