Хаха, и ведь самое забавное: если спросить ИИшку напрямую почему она написала иероглиф, то ИИ даже не поймет в чем ошибка, ибо для нее это будут просто 2 очень схожих токена
А почему нельзя? Например если ты уже знаешь что будешь перезаписывать память - то загулять не имеет смысла. На ПК кажется мелочью, но тот же embedded, где каждый байт программы на счету - это уже имеет хороший вес
Про генерацию кода во время компиляции - это уже отдельный этап Compile-time, который явно появился в Zig (Comptime называется)
А по библиотеке компонентов - было бы неплохо читать JSON/XML и другие конфиг форматы во время компиляции, и заполнять структуры и тд. Удобная штука на самом деле, но опять же "никакая строка не должна быть переписанная, будь она написана в 1986 или 2026"
От себя могу добавить как идею (хотя я уже потихоньку это реализовываю для своего движка) - делать public/protected поля с указанием кому именно они относятся. Пример: "public(FRenderer, FPhysics): ....". И тогда поле как бы является публичным, но только если обращение идет из класса/структуры FRenderer или FPhysics. Получается такой своеобразный "умный friend" (так как мы не раскрываем прям все поля и методы, как это делает обычный friend)
Да, согласен, эпохи были бы неплохой идеей. Да и в принципе если сейчас не заняться плюсами, то они рано или поздно уйдут в наследие по типу COBOL
Мне это очень напоминает утечку памяти - все больше от С++ вытекают другие языки призванные его "решить" или даже "убить" - тот же Rust, TrapC, Zig, Carbon и другие. И именно из-за такого большого наплавления других языков начинается путаница - вроде все от С++, а каждый не хочет дружить с каждым (ну или я плохо знаю о них,подправьте если что)
И про отдельную стадию с реализацией - вообще хорошая идея, были случаи когда вводили в стандарт, а потом "упс, а оно не работает то оказывается! ¯\_(ツ)_/¯" (вспоминаем тот же плачевный std::auto_ptr)
Ну а про исключения... Мало что сказать могу, лично я имею дело со встраиваемыми системами и игровыми движками, там исключения по определению выключены
И под конец могу сказать что тут уже гонка быстрее вымрет - язык.... или комитет 💀 (ладно, это была плохая шутка)
P.S. Подумал еще об стандартах - на самом деле палка с двумя концами, которую никто не хочет брать. Вот сколько не замечал - все крупные проекты сидят на одних стандартах, никто не хочет обновляться. А если делают - то только в совсем безумных обновлениях, когда прям уверены что могут. И в тоже время комитет С++ "нужно сделать фичу так, чтобы она запустилась из кода С++98" - ну классно просто. И программисты не идут в будущее, и комитет не идет в будущее. Пути эволюции свернули куда-то не туда...
Великое правило интернета номер 34 гласит: Если это существует...
Хаха, и ведь самое забавное: если спросить ИИшку напрямую почему она написала иероглиф, то ИИ даже не поймет в чем ошибка, ибо для нее это будут просто 2 очень схожих токена
Cool
А почему нельзя? Например если ты уже знаешь что будешь перезаписывать память - то загулять не имеет смысла. На ПК кажется мелочью, но тот же embedded, где каждый байт программы на счету - это уже имеет хороший вес
Смысл всей басни такова: Не смотря C++, мы продолжаем его любить :)
Хорошая, приятная статья. Было интересно почитать, спасибо. Удачи тебе, автор
По своей природе очень похоже на написание кода для GPU, где обычно условия не приветствуются :)
Можно всю итерацию вычислять цвет пикселя, а затем в самом конце происходит умножение на ноль и все вычисления коту под хвост
Да, довольно таки ужасно, но зато без ветвлений + предсказуемо...
Про генерацию кода во время компиляции - это уже отдельный этап Compile-time, который явно появился в Zig (Comptime называется)
А по библиотеке компонентов - было бы неплохо читать JSON/XML и другие конфиг форматы во время компиляции, и заполнять структуры и тд. Удобная штука на самом деле, но опять же "никакая строка не должна быть переписанная, будь она написана в 1986 или 2026"
От себя могу добавить как идею (хотя я уже потихоньку это реализовываю для своего движка) - делать public/protected поля с указанием кому именно они относятся. Пример: "public(FRenderer, FPhysics): ....". И тогда поле как бы является публичным, но только если обращение идет из класса/структуры FRenderer или FPhysics. Получается такой своеобразный "умный friend" (так как мы не раскрываем прям все поля и методы, как это делает обычный friend)
Да, согласен, эпохи были бы неплохой идеей. Да и в принципе если сейчас не заняться плюсами, то они рано или поздно уйдут в наследие по типу COBOL
Мне это очень напоминает утечку памяти - все больше от С++ вытекают другие языки призванные его "решить" или даже "убить" - тот же Rust, TrapC, Zig, Carbon и другие. И именно из-за такого большого наплавления других языков начинается путаница - вроде все от С++, а каждый не хочет дружить с каждым (ну или я плохо знаю о них,подправьте если что)
И про отдельную стадию с реализацией - вообще хорошая идея, были случаи когда вводили в стандарт, а потом "упс, а оно не работает то оказывается! ¯\_(ツ)_/¯" (вспоминаем тот же плачевный std::auto_ptr)
Ну а про исключения... Мало что сказать могу, лично я имею дело со встраиваемыми системами и игровыми движками, там исключения по определению выключены
И под конец могу сказать что тут уже гонка быстрее вымрет - язык.... или комитет 💀 (ладно, это была плохая шутка)
P.S. Подумал еще об стандартах - на самом деле палка с двумя концами, которую никто не хочет брать. Вот сколько не замечал - все крупные проекты сидят на одних стандартах, никто не хочет обновляться. А если делают - то только в совсем безумных обновлениях, когда прям уверены что могут. И в тоже время комитет С++ "нужно сделать фичу так, чтобы она запустилась из кода С++98" - ну классно просто. И программисты не идут в будущее, и комитет не идет в будущее. Пути эволюции свернули куда-то не туда...
Писал движок на GitHub
Но перешел на GitCrab
Теперь ни движка, ни репозитория
А еще майнкрафтовский Java-код обфусцирован (переменные названы типа _ab2942 и тд.)
Но уже спокойно есть разные инструменты, ИИ алгоритмы и тд. чтобы понять смысл кода и переименовать переменные обратно в их привычное название