История изменений

И что? Stl есть в доках по плюсам, что, не может существовать проекта на плюсах, в котором stl пользоваться запрещено? Если что, сам Страуструп требует забыть о new и delete и пользоваться умными указателями и контейнерами и при этом в каждом серьёзном проекте на плюсах запилена собственная версия умных строк. В доках по C есть и malloc и printf, однако в ядре ими пользоваться запрещено. Даже больше, в доках есть float это вообще встроенный тип, и с ним тоже kernel нельзя.

В рамках Ц/ЦПП я всегда получу что-то валидное, которое вписывается в рамки стандарта. Если я буду компилить сишный модуль, где буду дергать malloc и printf, то он просто не скомпилится т.к libc просто не будет. Но если ядро захочет, то оно спокойно будет экспортировать символы malloc и printf. А у вас в расте ведь нет рантайма (я ничего не путаю?, т.е. нет условной libstdc++.so), т.е. ошибку при сборке ты не получишь.

В тех же плюсах базовая синтаксическая конструкция new подразумевает наличие аллокатора и тоже, кстати, не возвращает nullptr.

Вообще-то возвращает. А наличие исключений ты не заметил.

И что? Stl есть в доках по плюсам, что, не может существовать проекта на плюсах, в котором stl пользоваться запрещено? Если что, сам Страуструп требует забыть о new и delete и пользоваться умными указателями и контейнерами и при этом в каждом серьёзном проекте на плюсах запилена собственная версия умных строк. В доках по C есть и malloc и printf, однако в ядре ими пользоваться запрещено. Даже больше, в доках есть float это вообще встроенный тип, и с ним тоже kernel нельзя.

В рамках Ц/ЦПП я всегда получу что-то валидное, которое вписывается в рамки стандарта. Если я буду компилить сишный модуль, где буду дергать malloc и printf, то он просто не скомпилится т.к libc просто не будет. Но если ядро захочет, то оно спокойно будет экспортировать символы malloc и printf. А у вас в расте ведь нет рантайма (я ничего не путаю?, т.е. нет условной libstdc++.so), т.е. ошибку при сборке ты не получишь.

В тех же плюсах базовая синтаксическая конструкция new подразумевает наличие аллокатора и тоже, кстати, не возвращает nullptr.

Вообще-то возвращает.

И что? Stl есть в доках по плюсам, что, не может существовать проекта на плюсах, в котором stl пользоваться запрещено? Если что, сам Страуструп требует забыть о new и delete и пользоваться умными указателями и контейнерами и при этом в каждом серьёзном проекте на плюсах запилена собственная версия умных строк. В доках по C есть и malloc и printf, однако в ядре ими пользоваться запрещено. Даже больше, в доках есть float это вообще встроенный тип, и с ним тоже kernel нельзя.

В рамках Ц/ЦПП я всегда получу что-то валидное, которое вписывается в рамки стандарта. Если я буду компилить сишный модуль, где буду дергать malloc и printf, то он просто не скомпилится т.к libc просто не будет. Но если ядро захочет, то оно спокойно будет экспортировать символы malloc и printf. А у вас в расте ведь нет рантайма (я ничего не путаю?, т.е. нет условной libstdc++.so), т.е. ошибку при сборке ты не получишь.

И что? Stl есть в доках по плюсам, что, не может существовать проекта на плюсах, в котором stl пользоваться запрещено? Если что, сам Страуструп требует забыть о new и delete и пользоваться умными указателями и контейнерами и при этом в каждом серьёзном проекте на плюсах запилена собственная версия умных строк.

В доках по C есть и malloc и printf, однако в ядре ими пользоваться запрещено. Даже больше, в доках есть float это вообще встроенный тип, и с ним тоже kernel нельзя.

В рамках Ц/ЦПП я всегда получу что-то валидное, которое вписывается в рамки стандарта. Если я буду компилить сишный модуль, где буду дергать malloc и printf, то он просто не скомпилится т.к libc просто не будет. Но если ядро захочет, то оно спокойно будет экспортировать символы malloc и printf. А у вас в расте ведь нет рантайма (я ничего не путаю?, т.е. нет условной libstdc++.so), т.е. ошибку при сборке ты не получишь.