Как раз затем, чтобы не реализовывать их каждый раз :)
Да, не реализовывать каждый раз — это хорошо, но мне это видится путем к стандартной библиотеке C++ со всеми ее минусами и плюсами.
А чем не вариант написать свои malloc()/calloc()/free()?
Можно, но не всегда, и далеко не в каждом случае это оправдано, особенно при малом объеме памяти, там беда с фрагментацией кучи наступает. Иногда проще поправить код и перевести все в статически выделенную память.
Я воспринимаю C как язык, код на котором должен легко переноситься между платформами. Существует множество платформ, на которых динамическая память почти не существует. И если брать кусок кода, написанный по стандарту, то в нем нужно искать только *alloc и думать что с ним делать, а теперь добавляется еще 2 функции, которые могут выделять память и даже не содержат в имени подстроку «alloc». И эти 2 функции легко реализуются через уже существующие, так что я не понимаю зачем их тащить в стандарт.
Согласен, это можно переписать на strcpy, memcpy или другой вариант копирования, но с точки зрения портирования кода это дополнительные действия.
Оно понятно, но у меня не хватает фантазии такое представить. Использовать NULL как константу в арифметике — это странно, даже в случае с арифметикой указателей. Вот и спрашиваю, вдруг кто видел подходящий пример.
Блоки видны явно, но распределены по коду и находятся не в том месте, где будут выполнены. На мой взгляд, это несколько усложняет чтение кода, особенно при пошаговой отладке. Это нормально, но как-то не в духе языка.
Ну не обязательно кривой, хотя тут кому как нравится. Если просто разрешить накапливать код в макроопределении, то это откроет возможность реализации defer и других подобных инструментов, но не будет так явно выделяться. К примеру, есть #include, он позволяет просто воткнуть один файл в другой. Для предотвращения повторного включения используется конструкция из #ifndef #define, все хорошо, но можно было сделать какой-нибудь require_once. Инструмент получился бы хороший, но не гибкий, нужны и перечисленные выше. Получается раздувание языка, а C вроде как хорош своей компактностью и логичностью.
Функции содержат неявное выделение памяти в куче. Для программирования под МК это прям печалька, особенно когда нельзя скопипастить кусок кода без переделки вот таких моментов. И еще одна проблема — как использовать нестандартную кучу?
Безымянные параметры функций
Ох и бардак же начнется.
Включение двоичных файлов в исходный файл
ИМХО: единственное реально ценное нововведение.
Прощай, NULL, или nullptr на низком старте
Странно это все, почему бы не заставить работать NULL так, как от него ожидается (да, привести тип к указателю)? Что именно это может сломать?
Оператор defer
Забавная штука, но отложеные вызовы не совсем в духе C (кусок кода накапливается по ходу программы, а потом выполняется). Кода нет, а его выполнение есть — в C так не носят, понятно что революция, но вот надо ли оно… Лучше бы дали возможность написать такое макросами.
Эти насосы надо врезать близко ко дну бака с водой, без заполнения они не работают. Сальники в этих насосах весьма ненадежны, а корпус не герметичен. В конечном итоге содержимое бака с водой оказывается на полу.
Не факт, что помогло бы. Переменная любого типа фиксированного размера может переполниться, так что double тоже подвержен этой проблеме. Ведь может быть ошибка в алгоритме, приводящая, например, к бесконтрольному умножению в цикле. Сообщение о переполнении в определенном месте позволит локализовать проблемный участок.
Да, не реализовывать каждый раз — это хорошо, но мне это видится путем к стандартной библиотеке C++ со всеми ее минусами и плюсами.
Можно, но не всегда, и далеко не в каждом случае это оправдано, особенно при малом объеме памяти, там беда с фрагментацией кучи наступает. Иногда проще поправить код и перевести все в статически выделенную память.
Согласен, это можно переписать на strcpy, memcpy или другой вариант копирования, но с точки зрения портирования кода это дополнительные действия.
Если рассуждать не о внесении в стандарт, а о расширении компилятора, то любая вменяемо проработанная функциональность приветствуется.
Функции содержат неявное выделение памяти в куче. Для программирования под МК это прям печалька, особенно когда нельзя скопипастить кусок кода без переделки вот таких моментов. И еще одна проблема — как использовать нестандартную кучу?
Ох и бардак же начнется.
ИМХО: единственное реально ценное нововведение.
Странно это все, почему бы не заставить работать NULL так, как от него ожидается (да, привести тип к указателю)? Что именно это может сломать?
Забавная штука, но отложеные вызовы не совсем в духе C (кусок кода накапливается по ходу программы, а потом выполняется). Кода нет, а его выполнение есть — в C так не носят, понятно что революция, но вот надо ли оно… Лучше бы дали возможность написать такое макросами.
С оригинальным зарядником?
А где формируется информационный поток для телегида? Откуда эту информацию получает оператор?
Еще вариант — положить на github рядом с кодом.
Эти устройства на продажу будут? Или будет openhardware и будет выложен проект платы?