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

1. Шаблоны
2. Классы
3. RTTI

Инкапсуляция, наследование, полиморфизм, не?

Это вопрос не про Си, а про идеальный C++.

Ну так WitcherGeralt и использует идеальный C++ - си с классами.

Инкапсуляция, наследование, полиморфизм, не?

Нет поддержки, Не нужно, Да.

1. ссылочный тип; 2. шаблоны; 3. статический полиморфизм.

1. Шаблоны

Нравятся сообщения об ошибках из STL?

Классы

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

RTTI

Все хотят. ХЗ, почему в 2021 этого до сих пор нету.

ООП, шаблоны, RAII.

1. ссылочный тип

Без алгебраических типов и прочих встроенных контейнеров? Что ты будешь им передавать? Три уровня вложений стандартных контейнеров, аля shared_ptr<std::variant<str>>

2. шаблоны;
3. статический полиморфизм

Это разве не одно и то же?

и потому те же Go и Rust отказались от классов.

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

PS: поздравляю с трудоустройством )

ООП

Ооп, оп-оп-оп, опа гангам стайл. Под ООП за десятилетия понималось целая куча разнородных концепций. Кто-то даже JS называет ООП, хотя он всю жизнь был функциональным языком, и вообще это первый массовый язык с лексическими замыканиями.

шаблоны

Забавно, что создатели Go не разделили твою позицию. Несмотря на это, некая степень полиморфизма в Go есть на уровне базовых конструкций.

RAII

Я так понимаю, с классами. Или с исключениями? Или с тем и другим?

Классы, заместитель типа auto, лямбда выражения.

Нравятся сообщения об ошибках из STL?

Достаточное количество смазки помогает при работе с ними.

Слишком общо

Просто классы, как фича для структурирования - из просто лапшекода в ресторанный спагетти код с нотками абстракции.

Тоже поздравляю с трудоустройством. Вольер хоть удобный или один банан на весь опенспейс?

Классы, заместитель типа auto, лямбда выражения

Это пока что самый сочный список. Претензия к классам та же: «если говорить про конкретно классы, как зонтик, под которым собрана целая куча разнородных инструментов, то этот зонтик — говно, и потому те же Go и Rust отказались от классов».

От классов нужны только конструкторы/деструкторы и перегрузка.

Ооп, оп-оп-оп, опа гангам стайл.

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

создатели Go не разделили твою позицию

Поломались немного и запилили дженерики. Так что мимо.

Я так понимаю, с классами. Или с исключениями?

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

Нравятся сообщения об ошибках из STL?

Достаточное количество смазки помогает при работе с ними

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

Просто классы, как фича для структурирования - из просто лапшекода в ресторанный спагетти код с нотками абстракции

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

Тоже поздравляю с трудоустройством. Вольер хоть удобный или один банан на весь опенспейс?

Удаленка. Кто ж в короновирусную эпоху сидит в офисе?

Из нового: aggregate initialization.

Если из относительно мелких вещей, то:

• RAII
• исключения
• пространства имён
• перегрузка функций

Не буду оригинален: исключения, шаблоны, RAII.

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

Та же претензия: ООП ООП рознь. Лисп 1960 года — это тоже вроде как ООП, по крайней мере со слов Алана Кэя. Очеидно, оно было сильно раньше крестов и качество реализации ООП в крестах мягко говоря не лучшее.

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

Однако, это не обязательно привязывать к инициализации. D и Go пошли по другому пути. Да что там, даже в GCC есть атрибут cleanup типа.

Нравятся сообщения об ошибках из STL?

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

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

Идиотизм возводить субъективное в абсолют. И приводить опять таки доводы с субъективными весами в доказательство. ООП методология прекрасна. Реализация в C++ прекрасна. Разумеется если умеешь этим пользоваться и получать от этого удовольствие.

Гениальные гении придумали новую методику: «Ох, как же это неестественно смешивать свойства и методы? Как же вы заблуждались ранее. Эх, сейчас мы перевернем мир разработки…»

Да это просто другой бренд. Другая реклама, другой продукт, адепты которого будут нести любую херню, чтобы обесценить уже имеющийся.

Да мне по..ю, что кому-то не нравится реализация ООП в C++. Хотите писать на очередном убийце C/C++ - да, бл…, пожалуйста. Только вот, мне это не аргумент, что «даже в … отказались от …».

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

Шаблоны позволяют написать один раз то, что в Си будет кучу раз продублировано. Также шаблоны не создают рантайм накладных расходов.

Нафига эти фантазии нужны? Если нельзя плюсы, бери без плюсов. Если можно плюсы - бери плюсы.

D и Go пошли по другому пути. Да что там, даже в GCC есть атрибут cleanup типа.

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

А полиморфизм? Виртуальное наследование? Множественное наследование? Неявное и явное преобразование? Перегрузка операторов? Поддержка семантики перемещения?

Лямбды, constexpr/consteval, атрибуты, модули, корутины. Если появится defer, то и его тоже.

Предлагаешь добавить в Си фичи из C99?

1. низкий порог вхождения
2. автоматическое управление памятью
3. кросплатформенность

=)

Если появится defer, то и его тоже.

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

Меня немного повеселила эта статья https://habr.com/ru/post/243593/

В Go используется правило регистра первой буквы имени — если название начинается заглавной буквы — это public-доступ, если со строчной — private. Вначале может показаться неудобством, но с первых строк на Go, понимаешь, насколько это было удобное решение.

Хахахахаха, оуенно!!! Супер довод: Вначале может показаться неудобством, но с первых строк на …(ВСТАВИТЬ НУЖНОЕ)…, понимаешь, насколько это было удобное решение.

Ну бл…, это шедевр, сейчас со стула упаду :-)

Нравятся сообщения об ошибках из STL?

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

// C program to demonstrate designated initializers
// with arrays.
#include <stdio.h>
void main(void)
{
    int numbers[100] = {1, 2, 3, [3 ... 9] = 10,
          [10] = 80, 15, [70] = 50, [42] = 400 };
 
    int i;
    for (i = 0; i < 20; i++)   
        printf("%d ", numbers[i]);
     
    printf("\n%d ", numbers[70]);
    printf("%d", numbers[42]);
}

1 2 3 10 10 10 10 10 10 10 80 15 0 0 0 0 0 0 0 0 
50 400

// C program to demonstrate designated initializers
// to determine size of array.
#include <stdio.h>
 
void main(void)
{
    int numbers[] = {1, 2, 3, [10] = 80, 15,
                    [70] = 50, [42] = 400 };
    int n = sizeof(numbers) / sizeof(numbers[0]);
    printf("%d", n);
}

71

// C program to demonstrate designated
// initializers with structures
#include <stdio.h>
struct Point
{
    int x, y, z;
};
 
int main()
{
     
    // Examples of initialization using
    // designated initialization
    struct Point p1 = {.y = 0, .z = 1, .x = 2};
    struct Point p2 = {.x = 20};
     
    printf("x = %d, y = %d, z = %d\n",
          p1.x, p1.y, p1.z);
           
    printf("x = %d", p2.x);
     
    return 0;
}

x = 2, y = 0, z = 1
x = 20

// C program to demonstrate designated initializers
// with structures and arrays combined
#include <stdio.h>
void main(void)
{
    struct point { int x, y; };
    struct point pts[5] = { [2].y = 5, [2].x = 6, [0].x = 2 };
    int i;
    for (i = 0; i < 5; i++)   
        printf("%d %d\n", pts[i].x ,pts[i].y);
}

2 0
0 0
6 5
0 0
0 0

Си я предлагаю поскорее закопать чтобы не мучился. Нет ни одного оправданного случая его использования кроме работы с очень устаревшим железом/ПО.

То на что я указал уже добавлено в стандарт C++20 (могли бы и пораньше догадаться такую ерунду добавить), но несколько отличается от Си, например порядок объявления должен совпадать. Они ещё конструкторы по умолчанию вызывают для полей без указания значения.

пространства имён

// foo.h
#ifndef FOO_H
#define FOO_H
typedef struct {
  int (* const bar)(int, char *);
  void (* const baz)(void);
} namespace_struct;
extern namespace_struct const foo;
#endif // FOO_H

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

// main.c
#include <stdio.h>
#include "foo.h"
int main(void) {
  foo.baz();
  printf("%d", foo.bar(3, "hello"));
  return 0;
}

RAII все же не совсем фишка языка, а скорее идиома.

То, что ты указал вообще нахрен не нужно для работы с железом. Там как раз C и нужен - простой и без выпендрёжа.

Большинство крупных сишных программ и так пишутся в ООП стиле

так было по инерции мышления из 90х, по стандартам 98го :) С обретением обобщенного программирования все это стало опционально. А с С++11 начиная не очень нужно даже в самом С++.

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

Я же говорю: тут вопрос про идеальный С++, а не про Си. Вообще, убивца С/С++ тоже должен быть такой парочкой. Т.е. должно быть два языка: простой и его отрицание для более высокоуровневого использования, фичи в которых будут перетекать из одного в другого.(перетекать в смысле стандартов)

Если в Си добавить классы, то нужно ещё добавлять и исключения. После этого это уже будет не Си, а урезанный Си++. Зачем он такой, если можно сразу Си++ взять? Просто не пользуйся тем, что не нужно.

Итак, назовите от трех до пяти фич крестов, которые бы вы взяли с собой на необитаемый остров Си.

Лучше сформулировать вопрос иначе: что надо выкинуть из C++ (или запретить использовать) чтобы получился хороший язык? Я предлагаю выкинуть 90% libstdc++, это по большей части жирный нечитаемый долго компилирующийся мусор. Пусть фанаты каким-нибудь Boost пользуются.

предлагаю поскорее закопать

Сам жаловался на токсичность, но сам же в неё и скатился.

Если в Си добавить классы, то нужно ещё добавлять и исключения.

Не вижу связи. У Windows в ядре Си с исключениями. Бывает и наоборот.

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

Это все и в Си реализуется. Да, нет синтаксической поддержки, но можно и руками сделать.

Я постоянно не использую. Например потоки и файлы C++ для меня – чистый мусор. Удобнее пользоваться stdio.h. Полезны там разве что std::map, set, vector а также std::unique_ptr (shared_ptr слишком жирный).

Я ценю скорость сборки, размер исполняемого файла и бинарную совместимость.

У тебя свое подмножество у кого-то еще другое, а у остальных третье :) Есть вариант, что ты будешь один фиг в меньшинстве... Прям как щас :)

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

Ну вот пусть и будут подмножества в отдельных библиотеках. Зачем заставлять всех тащить этот мусор?