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


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



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

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


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



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

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

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


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


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


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


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


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


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

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

Блин! Ещё раз: я не предлагал изменить логику работы enum конечно же! А добавить новый механизм, в котором одинаковые значения запрещены.
Я тоже использую enum-ы с одинаковыми значениями. Когда это надо.

Тогда тоже пишите в паскале. В чем проблема?

К слову, в C# со строками все это сделано гораздо удобнее, чем в голом C/C++, но опять-таки в основном за счет очень толстых библиотек.

А речь как я понял про С/C++. Коли так, то почти все ваши пожелания - пока что фантастика.
Посмотрите историю эволюции C++ (03 - 11 - 14 - 17) - там появляются новые фишки, но совсем другого рода. К вашим паскале-подобным "удобствам" отношения не имеют.
И наверняка на то есть причины - новые стандарты появляются в голове не одного человека, в этом участвует сообщество серьезных мега-программеров.

Поэтому я согласен лишь с одним пунктом (1): за более жесткий контроль числа инициализаторов массива. Имхо, весьма полезная "фишка".
Пусть и не ошибка "вылетает", но хотя бы варнинг.


Это легко реализовать в run-time, всего один раз запускать проверку на дубликаты значений.
Я бы сделал так: const struct, или лучше: constexpr struct, дав значения каждом полю прямо при объявлении (С++11).

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

Что-то типа unique_case в SV? Атрибут такой ввести? Ну, пусть.

Ошибка вылезет на этапе исполнения. Но тут вопрос шашечек или ехать. Да и не всегда это ошибка.
А включать-выключать warning - лишние хлопоты. (например 20 процентов массивов надо контролировать на заполнение, а остальные - нет).

Отличное решение!
Но, увы, оно не работает, если явно указать размер массива:
int array[3] = {1,2};
Компилятор не ругается, а последнее значение array[2] он тупо заполнит нулем.
А если речь, например, про float array[3] = { 1, 2 }, то в array[2] будет не ожидаемый float 0.0, а просто 4 нулевых байта... Скверная ситуация ((
И то не факт, что именно так поступит тот или иной компилятор - нужно проверять. Отсюда вопрос: а надо ли?

На край хотя бы встроенная локальная #pragma для анализа подобных массивов.

Обертку для удобства сделайте сами.

А вообще при желании всяческих проверок и т.п. добро пожаловать в метапрограммирование и stl

В данном случае это уже некий сарказм

А чего такого) Мы уже используем прелести Си++11 для микроконтроллеров. Можно и Си++14. Удобно.

Аналогично!
Сокращается объем текста кода, его проще читать, да и размер прошивки тоже выходит меньше.
Имхо, С++14 пока что рановат в обычных МК-проектах, да и мало кто из компиляторов под МК его полностью держит, но ... (С) "еще не вечер"

Но городить метапрограммированием банальную проверку массива на недостающие инициализаторы - это, имхо, уже перебор. Это уже прям "масло масляное", имхо ))
Наверно, проще будет вообще отказаться от таких "странных" инициализируемых не нулем массивов и переделать их под constexpr структуры с явной инициализацией полей.
Например: коды команд, строковые коды запросов/ответов для, например, внешнего модема.

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

IAR ARM начиная с версии 8 поддерживает как 11 так и 14. Да и разница между 11 и 14 заметна не любому глазу.


Посмотрите в сторону std::array. С ним можно делать все тоже самое.