Что бы вы изменили в дизайне c++?

@Ciyoxe · Регистрация: 29.10.2021

Студворк — интернет-сервис помощи студентам

Тема ни о чём, просто напишите что думаете или мечтаете

Я очень люблю c++, альтернатив ему никаких и близко не вижу. И вот задумался, а что если...? У каждого программиста есть мечта создать свой собственный язык программирования с пасьянсом и барышнями, не так ли? Кажется, язык моей мечты очень близок к с++, но, как мне кажется, плюсики обладают некоторыми минусиками.

Если бы вы могли переделать что-либо в дизайне с++ (не оглядываясь на обратную совместимость и прочее такое, просто с корнями перелопатить всё), то что бы вы изменили? А какие новые возможности бы добавили? (сборщик мусора сразу в мусорку)
Заранее извиняюсь за весь бред ниже
Вот некоторые мои предложения. Что думаете? В чём я обделался?

0: Отказаться от совместимости с Сиии

1: Перемещение и копирование, классы и структуры
Вам не кажется, что семантика перемещения, все эти бесконечные конструкторы... дрянь?
Вам не кажется странным, что классы и структуры - по факту одно и то же?

Все объекты будут по умолчанию перемещаться, а точнее, просто тривиально копироваться с помощью memcpy().
Вместо конструкторов копирования будут вызываться явные методы (например object.clone())

Классы и структуры будут отличаться по своему поведению.

Структура не изменит своего настоящего поведения. Структура переместилась в новое место - старая структура никуда не делась и продолжила свою работу. Позже для неё вызвался деструктор.
По факту, для каждой копии вызывается деструктор.
То есть на один конструктор несколько деструкторов.

C++
1
2
3
4
5
6
7
{
    auto arr = std::vector<MyStruct()>();
    auto x = MyStruct();
    x.Foo(); //всё норм
    arr.push_back(x); // x тривиально скопировался
    x.Foo(); //всё норм
} //для x вызвался деструктор

А что же для классов? Тут правило простое. Один объект - один конструктор - один деструктор.
После перемещения класс забывается. Всё, его уже не существует и для него ничего не вызывается. Это будет жестко контролироваться компилятором.

C++
1
2
3
4
5
6
7
{
    auto arr = std::vector<MyClass()>();
    auto x = MyClass();
    x.Foo(); //всё норм
    arr.push_back(x); // x тривиально скопировался
    x.Foo(); //ошибка компиляции, x был перемещен
} //для x НЕ вызвался деструктор, он забыт

Проблемки начинаются с наследованием, но, как вариант, просто запретить наследование структур от классов

2: Приведения типов
Все неявные приведения типов будут запрещены. Никаких if ((int)x)
Оставить лишь один приведения - оператор as как заменитель static_cast + каст указателей,
например

C++
1
 auto i = x as double

Его можно будет перегружать
Вместо dynamic_cast была бы функция стандартной библиотеки, типа isInstanceOf<T>(T* object)->bool

3: встроенные типы как объекты
Разве не круто написать...?

C++
1
2
float x = 2;
float y = x.sqrt();

4: методы-расширения
У меня просто вопрос, возможно ли их вообще сделать в компилируемом языке типа c++?
Ведь для их использования нужно каждый раз компилировать всю программу целиком. Тогда о компиляции по отдельным единицам можно забыть и её время вырастет до небес? А возможно ли встраивать информацию о них в уже скомпилированные единицы? Как с этим справляется шарп?

5: Char бесполезен
Зачем делать отдельный тип для символов (да ещё городить огород из всяких char16_t char32_t), если можно использовать целые числа? А строки просто обернуть в класс string, который по факту vector<uint8_t>

6: ++ --
Ну...

C++
1
 int x = --(i++)++;

Уберите это, уберите!
++ можно ставить только справа от переменной, и означает он += 1. Всё.
Не надо нам никаких "Ну он увеличивает, потом возвращает, а этот возвращает, потом увеличивает"
Аналогично --

7: Указатели
Я бы вообще убрал чистые указатели. Есть ссылки, есть unique/shared.
Для особых случаев можно в стандартной библиотеке добавить раздел для отстрелов ног, включить туда функции работы с памятью напрямую (но вместо указателей адреса size_t)
Достаточно

8: Я хочу сахара
Кортежи не через зад, а с именованными параметрами

C++
1
2
3
4
(float x, float y) getPoint();
auto point = getPoint();
auto _x = point.x;
auto (x,y) = getPoint();

tagged unions и pattern marching (switch вообще удалить) (как в Rust)

Именованные параметры функций (если у функции миллиард необязательных параметров, а тебе нужно установить лишь последний из них)

Геттеры и сеттеры. Вместо функции int getX() {... будет свойство int get X() {...

Добавлено через 9 минут
Я совсем забыл..
9: Автовывод операторов
Перегрузили + - автоматически перегрузился +=
Перегрулили == - автоматически перегрузился !=
Перегрузили < и == - автоматически перегрузился <=
Почему нет?

Добавлено через 1 минуту
PS
Ну а шаблоны - это вообще длиннющий разговор, достойный отдельной темы

Verevkin · 30.10.2021, 17:17

Сообщение от DrOffset

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

Не знаю. Но меня устраивает первоначальная версия - о том, что Си - это прикол. Для чего-то, ведь, его сделали таким сложным, а?

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

З.Ы. По долгу службы мне приходится писать софт и на Си, и на Паскале. Вот я и сравниваю.

@DrOffset · 30.10.2021, 17:20

Сообщение от Verevkin

Для чего-то, ведь, его сделали таким сложным, а?

Он не был сложным для своего времени.
https://www.youtube.com/watch?v=JoVQTPbD6UY

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

https://www.youtube.com/watch?v=EY6q5dv_B-o

Verevkin · 30.10.2021, 17:25

Сообщение от DrOffset

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

Продолжай.

@DrOffset · 30.10.2021, 17:26

Сообщение от Verevkin

Продолжай.

Сообщение от DrOffset

не выдерживает фактологической проверки.

Я просто покажу как это делается, дальше сможете сами.

Например, в статье утверждается, что заявление было сделано на конференции "UnixWorld Software Development Forum".
Давайте поищем, что это за конференция такая?
Очень скоро мы обнаружим, что все ссылки с упоминанием этой конференции ведут только на эту шуточную статью. Неужели, если бы она правда существовала, это было бы так?

Verevkin · 30.10.2021, 17:34

Сообщение от DrOffset

Он не был сложным для своего времени.

Кстати, как это понимать? В те времена люди мыслили иначе?
Пусть статья - фейк, но в ней есть правильный акцент на то, что язык Си сделан сложным намеренно.

Добавлено через 3 минуты

Сообщение от DrOffset

Например, в статье утверждается, что заявление было сделано на конференции "UnixWorld Software Development Forum".
Давайте поищем, что это за конференция такая?
Очень скоро мы обнаружим, что все ссылки с упоминанием этой конференции ведут только на эту шуточную статью. Неужели, если бы она правда существовала, это было бы так?

Да я и не утверждаю, что статья подлинная. Но кто-то, ведь, её написал жэж! И изложенные в ней вещи вполне логичны (именно "логичны", а не "кажутся логичными"). Мне нравится сама гипотеза, что язык сделан сложным искусственно. Шоп жысь мёдом не казалась.

@DrOffset · 30.10.2021, 17:41

Сообщение от Verevkin

Кстати, как это понимать? В те времена люди мыслили иначе?

Конечно.
По сравнению с тем, что было до Си - это было гораздо проще.

Люди мыслят сообразно времени, в котором живут.
Вот здесь современный человек пытается управлять машиной 20-х годов, можно посмотреть за его впечатлениями: https://youtu.be/Lr_aZ20W4k4?t=1031
Намеренно сделали управление таким сложным? Там ведь и ошибка в управлении может привести к травме или выходу из строя машины.

Просто посмотри видео
https://www.youtube.com/watch?v=JoVQTPbD6UY
Они с первых секунд говорят, что стремились сделать использование компьютера проще.
И ведь учитывать стоит не только восприятие человеком, но и возможности реализации.

Verevkin · 30.10.2021, 18:02

Сообщение от DrOffset

По сравнению с тем, что было до Си - это было гораздо проще.

Согласен. Но со временем ничего не изменилось. Кроме людей, которые отупели.

Сообщение от DrOffset

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

Ты забываешь, что я Си с Паскалем сравниваю, а не с ассемблером.

Добавлено через 14 минут
Я думаю, что из-за искусственного усложнения и возникают пачками вот такие вопросы на форумах: Не могу передать объект класса в функцию

@DrOffset · 30.10.2021, 18:11

Сообщение от Verevkin

я Си с Паскалем сравниваю

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

Добавлено через 3 минуты

Сообщение от Verevkin

из-за искусственного усложнения и возникают пачками вот такие вопросы на форумах

Забавно, что именно этот вопрос - следствие попытки упрощения существовавшей до этого семантики, которая приводила к неочевидному поведению.

Сообщение от DrOffset

следствие попытки упрощения существовавшей до этого семантики, которая приводила к неочевидному поведению.

Особенности ссылок

Verevkin · 30.10.2021, 18:11

Сообщение от DrOffset

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

Да ёмаё, я не про это. Я имел в виду ТОЛЬКО СИНТАКСИС. И ничего более.
И я пытаюсь кого-то в чём-то переубедить. Я чисто субъективно пытаюсь понять, ЗАЧЕМ синтасис хорошего языка программирования сделали таким кривым и непонятным.

И ВСЁ. Только это.

@DrOffset · 30.10.2021, 18:13

Сообщение от Verevkin

Я чисто субъективно пытаюсь понять, ЗАЧЕМ синтасис хорошего языка программирования сделали таким кривым и непонятным.

...

Сообщение от DrOffset

И ведь учитывать стоит не только восприятие человеком, но и возможности реализации.

https://habr.com/ru/post/435292/

Verevkin · 30.10.2021, 18:14

Сообщение от DrOffset

Забавно, что именно этот вопрос - следствие попытки упрощения существовавшей до этого семантики, которая приводила к неочевидному поведению.

Вот я про то и говорю. Неужели нельзя было ИЗНАЧАЛЬНО разработать семантику, исключающую UB? Ну как так-то, а?

@DrOffset · 30.10.2021, 18:15

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

Добавлено через 56 секунд

Сообщение от Verevkin

Неужели нельзя было ИЗНАЧАЛЬНО разработать семантику, исключающую UB?

Нельзя, потому что UB - это следствие упрощения компилятора и кода, который он делает, и следствие попытки охватить большой объем архитектур.

Verevkin · 30.10.2021, 18:17

Сообщение от DrOffset

Нельзя, потому что UB - это следствие упрощения компилятора, и следствие попытки охватить большой объем архитектур.

Чо?

Пример приведи, плез.

@DrOffset · 30.10.2021, 18:20

Сообщение от Verevkin

Пример приведи, плез.

Ну вот например, переполнение знакового числа в C - UB.
Почему?
Да потому что разные архитектуры по-разному к этому относятся.
И чтобы нам сделать общее для всех решение - нужно его эмулировать программно.
И что мы в итоге получаем? Усложнение кода, который нам сделал компилятор, его более медленную работу.
Для каких-то задач это может быть приемлемым компромиссом, но только не для задачи написания операционной системы.

Croessmah · 30.10.2021, 18:21

Не по теме:

Сообщение от DrOffset

Ну вот например, переполнение знакового числа в C - UB.

В каком-то докладе Полухин рассказывал, что хотели пофиксить в стандарте C++ UB при переполнении знаковых и получили существенное снижение производительности в каких-то задачах/архитектурах.

Verevkin · 30.10.2021, 18:31

Сообщение от DrOffset

Ну вот например, переполнение знакового числа в C - UB.

Разве это UB?
Имхо, это, как раз, нормальное поведение программы. Если рукожопый программист не знает, как хранятся и обрабатываются процессором данные, то он сам дурак.
Да и причём тут семантика, которую мы тут обсуждаем?

Добавлено через 5 минут
Вот это UB или не UB?

C++
1
b += a++ * --b / ++a - ++b;

Croessmah · 30.10.2021, 18:32

Сообщение от Verevkin

Разве это UB?

Да.

Сообщение от Verevkin

как хранятся и обрабатываются процессором данные

А кто вам сказал, что все процессоры делают это одинаково?

@DrOffset · 30.10.2021, 18:32

Сообщение от Verevkin

Разве это UB?

@DrOffset · 30.10.2021, 18:34

Сообщение от Verevkin

Да и причём тут семантика, которую мы тут обсуждаем?

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

Verevkin · 30.10.2021, 18:35

Сообщение от Croessmah

А кто вам сказал, что все процессоры делают это одинаково?

А я этого и не утверждал. Но знаковый бит - он и в африке знаковый бит. Независимо от языка программирования.

Новые блоги и статьи Все статьи Все блоги /
Про "Windows must die!" kumehtar 04.11.2026 Знаете, чет накатило. . . . Когда-то это было почти боевым кличем: мол, нормальный человек сидит на DOS, OS/ 2 или Linux, а вот это вот - Must Die. А теперь человек произносит «мастдай» с усмешкой - и. . .	Красочные поля с номером страницы svg+background-image russiannick 04.11.2026 Красочные поля с номером страницы не менее важны чем в эпоху бумажных книг. Посему спешу представить почтеннейшей публике этот важный инструмент который эти поля и формирует. В процессе разработки. . .	Вступаем в новую фазу генерации favicons, векторную. russiannick 02.11.2026 Теперь нет нужды скрывать что используется простой svg. Исходный код изображения помещаем в поле и жмем кнопку. Исходник преобразуется в вид корректный для помещения в favicon или в url(). Нажатие. . .	Генератор паролей (вариант №4) Maks 01.11.2026 После публикации 3-го варианта генератора паролей, разослал его своим коллегам (с целью оценки), в итоге были получены следующие рекомендации: 1. Вернуть возможность использования знаков \| 1 l I;. . .
Генератор паролей (вариант №3) Maks 30.10.2026 Финальная версия генератора паролей 1С. Доработка решения в этот раз коснулась только визуальной части, а именно, добавлен реквизит ДопПараметры (тип Булево), который скрывает/ отображает реквизиты:. . .	Магическое мышление и магия, современная наука не отличима от магии (говорит ИИ Джемени) zorxor 30.10.2026 Джемени, расскажи, пожалуйста, что такое магическое мышление, что такое магия, почему современная наука чем-то напоминает магию? Фраза «Любая достаточно развитая технология неотличима от магии». . .	За какое время ИИ может подобрать пароль по хешу (рассказывает Джемени ИИ) zorxor 30.10.2026 Расскажи, Джемени, если известен хэш МД5, например, за сколько ИИ сможет подобрать соответствующий пароль? Искусственный интеллект (ИИ) может подобрать простой или средний по сложности пароль по. . .	Кто убил Suno? Почему наше солнышко погасло? (диалог с ИИ Джемени) zorxor 30.10.2026 Как убивали Suno. Хронология. «Убийство» музыкальной нейросети Suno — это затяжной процесс, в котором технологический хайп стартапа разбился о жесткую реальность судебных исков от гигантов. . .