Войти
ФлеймФорумПрограммирование

Имеет ли смысл вводить следующие изменения в С?

Страницы: 1 2 312 13 Следующая »
#0
(Правка: 19:46) 19:37, 5 мая 2019

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

Вот, собственно, список:
1. - перегрузка функций.
2. - обработка исключений с помощью try-catch-finally.
3. - шаблоны (как синтаксический сахар).
4. - пространство имен.
5. - наследование структур.
6. - отдельный тип данных для строк (а не просто массив char), хранящий информацию только в Unicode (UTF-8, UTF-16, UTF-32 - по выбору пользователя), а при записи/чтении из внешних источников - требующего явного указания кодировки в которую/из которой записываем/читаем строку.
7. - строгая конвенция по именованию переменных, функций, структур и т.д.


#1
(Правка: 19:56) 19:56, 5 мая 2019

1.-6. это уже давно Паскаль
7. это как?

#2
19:59, 5 мая 2019
7. это как?
Имеется ввиду - некоторое соглашение, согласно которому, например, имена структур должны начинаться всегда с большой буквы, имена функций и переменных с маленькой, имена констант - все буквы в верхнем регистре, а слова из которых состоят имена - должны разделяться символом нижнего подчеркивания и т.д.
#3
20:04, 5 мая 2019

1. Ломает совместимость, но хотелось бы.
2. Не знаю.
3. Можно бы.
4. Можно бы.
5. Это уже к С++'у, так что нет.
6. Нет.
7. Нет.

#4
20:08, 5 мая 2019

Vlad2001_MFS, а можно узнать - почему касательно 6 и 7 пункта такое категоричное "нет" (в особенности мне непонятно касательно пункта 7)?

#5
20:16, 5 мая 2019

Bakuard
6-ой пункт тоже практически бессмысленный. На Си пишут всякие внутренности, вроде драйверов, прошивок и т.д. Там лишние расходы на эти строки нафиг не нужны. Си - это не тот язык, где нужны такие вещи.
Я не являюсь экспертом и по 6-му пункту не могу дать 100% правильное мнение.

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

#6
20:17, 5 мая 2019

Вот только крестопроблем в C нам и не хватало!

#7
20:27, 5 мая 2019

Bakuard
1-5. C++
6. Руками
7. Линтерами

#8
20:39, 5 мая 2019

0. (Отключаемая) проверка выхода за границы массива.

#9
21:15, 5 мая 2019

Vlad2001_MFS, по поводу пункта 7 - никто не говорит, делать это принудительно линкерами. Это просто соглашение. И если его принять и начать тыкать в него носом разрабов - говнокода станет меньше.

Насчет пункта 6 - вводить новый тип данных ля строки и отказываться от обычных массивов char - я думаю и вправду плохая идея. Но ведь ничто не мешает иметь нормальный тип для строк параллельно с старыми char массивами.

kipar  - я правильно понимаю, что такая проверка будет осуществляться только на этапе компиляции?

Васян -

6. Руками
- в этом и проблема. Когда начинаешь работать со сторонним софтом - у одного один тип строк, у другой библиотеки - тоже свой, короче каша. И при этом куча багов. Был бы один стандартный тип, поддерживаемый сообществом - было бы удобней и багов меньше.
#10
21:22, 5 мая 2019

Bakuard
> говнокода станет меньше
Говнокод появляется не из-за стиля кода.

> только на этапе компиляции
А как ты собираешься проверять выход за границы массива на этапе компиляции?

> Был бы один стандартный тип, поддерживаемый сообществом - было бы удобней и
> багов меньше.
"Ах, вот если б не было зимы..."
Этого не будет никогда, так это идеальный случай. А идеала, как известно, не бывает.

#11
21:24, 5 мая 2019

Bakuard
> я правильно понимаю, что такая проверка будет осуществляться только на этапе
> компиляции?
Нет, в рантайме.

#12
21:49, 5 мая 2019

Bakuard
1-6 вроде и неплохо бы, с другой стороны - возьми С++ и пиши "С with classes" стайл, аки думец третий.

#13
21:55, 5 мая 2019

1-5 можно было бы сделать, но только если при этом не сломалась бы бинарная совместимость.

#14
21:55, 5 мая 2019

kipar
> Нет, в рантайме.
-fsanitize=address

Страницы: 1 2 312 13 Следующая »
ФлеймФорумПрограммирование