(Не)доработки языков программирования, которые хотели ли бы вы Опции

[GetSmart]

Почему не делают в ЯВУ возврат из функций несколько переменных?

Вроде бы несложно было бы объявить функцию типо так:
(int,int,char) funcname(char);
а потом аналогично использовать при вызове:
(a,b,c) = funcname('A');
причём даже в некоторых местах так:
(,,e) = funcname('A');
таким образом не используя часть переменных/регистров

То есть по сути ситуация аналогичная передаче параметров через регистры, когда (ну например в АРМ) первые 3 параметра передаются в регистрах. И возврат результата по логике строго аналогичен процессу передачи параметров, только не "в", а "из". Обычно возврат нескольких параметров делают через передачу ссылок, что в некоторой степени универсальнее, т.к. можно часть ссылок не использовать в зависимости от "нити" алгоритма. Однако, такой способ требует выделение места в стеке или в другой раме под ссылочные переменные. Что на современном уровне компиляторостроения не есть гуд. Хранение и передача (возврат) переменных в регистрах - предпочтительнее.

Сообщение отредактировал Omen_13 - Feb 22 2010, 14:14

Причина редактирования: Тема переименованна по просьбе автора

[GetSmart]

Продолжаем фантазировать.
Надо что-то вроде инкомплит-тайп-каст'а. Чтобы сделать "принудительное" чтение переменной типа result = *(volatile *)&var; которая объявлена конечно же неволатильной. Скажете: сделай сразу переменную волатильной. А я отвечу: хочу массив неволатильных переменных, а первый элемент волатильный))) Ну и для всяческих приблуд pack/align/const.

Хотя инкомплит неудачное название. Лучше что-то вроде "атрибут-тайп-каст". Понятно, что что-то похожее можно сделать через стандартный тайп-каст, но хочется чтобы это работало без явного указания ширины переменной, вобщем лишней инфы. И из этой же оперы, хотелось делать тайп-каст (signed) или (unsigned). Это уже инкомплит-тип.

Сообщение отредактировал GetSmart - May 21 2018, 19:42

[jcxz]

1. Было-бы лучше, если бы в си, при объявлении инициализированного массива с явно указанной размерностью
int m[N] = {1, 2, 3};
компилятор выдавал бы ошибку компиляции если количество инициализаторов не равно N.
Это очень полезно для создания связанных списков: define_значение/значение_константы.
2. Было бы очень полезно, если бы в константных выражениях можно было смешивать строки и значения:
enum {z1 = 5};
char const t[] = "string" z1 " - " (z1+2)*9;
3. Было бы классно если бы строковые константы можно было задавать не только в форме ASCIIZ (завершающийся нулём набор символов), но и в виде:
длина_строки "строка" (без 0 в конце). Хотя это решается автоматически при выполнении пункта 2.
4. Полезно было бы в stdlib в обязательном порядке внести прототип функции _Printf(void *(*)(void *), void *, char *, ...) - т.е. функцию из семейства printf...() передающую поток выводимых символов не на stdout (printf()) или в память (sprintf()), а в callback-функцию (первый аргумент _Printf()).
5. Было бы очень полезно наличие в языке возможностей задания списков define-ов (или enum) с уникальными значениями. Т.е. чтобы на:
enum {V_1 = 11, V_2 = 12, V_3 = 13, V_4 = 11, ...};
вылетало на ошибке компиляции типа: "V_4 - duplicate value".
Часто приходится задавать или списки define ног контроллера или каналов DMA, портов и пр. ресурсов, в которых каждый элемент списка должен иметь уникальное значение, не совпадающее с другими. При каждом редактировании очень неудобно каждый раз перепроверять весь список на наличие конфликтов, особенно если значения справа от "=" - это не литеральные константы, а выражения.
Приходится выкручиваться через проверяющие макросы.

[Forger]

1. Было-бы лучше, если бы в си, при объявлении инициализированного массива с явно указанной размерностью
int m[N] = {1, 2, 3};компилятор выдавал бы ошибку компиляции если количество инициализаторов не равно N.

Дык, он и так ругается, но лишь в одном случае - число инициализаторов больше размерности массива.
Увы, не ругается, если меньше. Просто "забивает" недостающие нулями. Это действительно неудобно.

2. Было бы очень полезно, если бы в константных выражениях можно было смешивать строки и значения:

В голом виде (без STL и типа того), подобная затея - это рассадник опасных и довольно коварных ошибок на абсолютно ровном месте:
как минимум нужно контролировать размерности типов данных на разных платформах, в т. ч. "банальный" char.
Вангую головную боль, в принципе, на ровном месте.
К тому же такое "оружие" опасно отдавать в руки новичками.

3. Было бы классно если бы строковые константы можно было задавать не только в форме ASCIIZ (завершающийся нулём набор символов), но и в виде:
длина_строки "строка" (без 0 в конце).

Код

const char t1[] = "012";
const char t2[3] = { '0', '1', '2' };

t1 будет иметь длину 4 байта, а t2 - 3 байта.
Определить длину t1 можно лишь найдя ноль в конце, у t2 размер указан явно. Все логично.

Но, если убрать ноль у t1, сделав его длину 3 байта, то как в коде понять, что он имеет размер в 3 байта?
Как отличить его с "классической" строкой в 4 байта?
Путаница на абсолютно ровном месте. Имхо, опасная блажь!

4. Полезно было бы в stdlib в обязательном порядке внести прототип функции _Printf(void *(*)(void *), void *, char *, ...) - т.е. функцию из семейства printf...() передающую поток выводимых символов не на stdout (printf()) или в память (sprintf()), а в callback-функцию (первый аргумент _Printf()).

Это легко делается и сейчас: достаточно лишь "перегрузить" встроенную функцию "putc" своей собственной реализацией, игнорируя второй параметр FILE *.
Вот ее прототип: int putc(int ch, FILE *stream);
В этом случае при сборке проекта линкер "возьмет" реализацию putc из вашего кода, а не штатную из библиотеки stdio.

5. Было бы очень полезно наличие в языке возможностей задания списков define-ов (или enum) с уникальными значениями. Т.е. чтобы на:
enum {V_1 = 11, V_2 = 12, V_3 = 13, V_4 = 11, ...};
вылетало на ошибке компиляции типа: "V_4 - duplicate value".

Очень спорная потребность: могут начаться проблемы как минимум со сторонним кодом, где дублированные значения могут быть созданы намеренно.

[jcxz]

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

Я писал, что хотелось бы ошибку при не равно, а не только при больше. Что будет при меньше я прекрасно знаю, именно поэтому и написал такой пункт.

В голом виде (без STL и типа того), подобная затея - это рассадник опасных и довольно коварных ошибок на абсолютно ровном месте:

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

Но, если убрать ноль у t1, сделав его длину 3 байта, то как в коде понять, что он имеет размер в 3 байта?
Как отличить его с "классической" строкой в 4 байта?

Прочитайте моё сообщение внимательнее прежде чем критиковать.
Я пишу, что хотелось бы не только "классические" строки (это называется обычно ASCIIZ), а и строки в формате длина,символы_без_0_в_конце.

Путаница на абсолютно ровном месте. Имхо, опасная блажь!

Теперь расскажите это создателям Паскаля и тем десяткам тысяч программистов кто его использует.
Если Вы не в состоянии понять для чего это нужно, это ещё не повод говорить "блажь".
Например: программа получает текстовый поток данных, который разбивает на лексемы (слова) заменяя строковые значения лексем их номерами из некоего словаря. Значит - в программе есть некий массив лексем, константный и возможно довольно большой.
Теперь объясните, пожалуйста, как эффективно (т.е. - быстро) организовать поиск лексем в таком массиве, если принять, что лексемы имеют сильно разные размеры и что для удобства читаемости (и редактирования) исходника лексемы очень желательно иметь в виде строк (а не в виде {'a','b',...}) и лексемы нельзя расположить в некоем удобном для поиска порядке, а порядок их расположения одна относительно другой определяется другими критериями (разбивка на логические группы, связь со значениями define-ов и т.п.) ???
Так вот: с байтом длины поиск в таком списке лексем будет идти гораздо быстрее чем со списком ASCIIZ-строк.

Это легко делается и сейчас: достаточно лишь "перегрузить" встроенную функцию "putc" своей собственной реализацией, игнорируя второй параметр FILE *.

Данный пункт скорее касается компиляторов для PC, потому что в тех компиляторах для МК, с коими я работал (IAR и в CCS) такая функция и так имеется (_Printf()).
А в компиляторах на PC часто нежелательно перегружать putc(), потому что она может быть нужна.

Очень спорная потребность: могут начаться проблемы как минимум со сторонним кодом, где дублированные значения могут быть созданы намеренно.

Внимание: я не пишу что нужно изменить работу enum, я пишу что хотелось бы такой механизм. А назваться он естественно должен не enum. Enum там приведён для примера списка, который хотелось бы переделать по другому.

Не согласен. Личный пример, как описываю альтернативные функции для портов STM32:

И что? Как это поможет от дубликатов? Вот у Вас AF_TIM1 и AF_TIM2 имеют одинаковые значения и при этом это нормально скомпилится. А не должно компилиться.

[ViKo]

И что? Как это поможет от дубликатов? Вот у Вас AF_TIM1 и AF_TIM2 имеют одинаковые значения и при этом это нормально скомпилится. А не должно компилиться.

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