Возможно глупый совет, но не пробовали ли вы делать минимальный размер субрегиона в RegionTree допустим 8х8 или 16х16, и делать там сплошную битовую маску? Мне кажется, это было бы эффективней и по памяти, и по времени доступа.
Проблема в том, что кроме параметра "красоты" код должен быть рабочим. По этому параметру плохи оба варианта.
Исходный пример делает по сути detach, не удаляя саму ноду списка.
Пример "со вкусом" оставляет утечку entry->next — т.к. "удалённая" нода перезаписывается копией следующей — но исходная останется висеть в памяти. Не говоря о том, что он свалится при удалении хвоста, у которого нет next
Знаете, шутка неудачная. Вы пытались показать, насколько крут C#. В результате вы показали, что на нём можно легко и непринуждённо отстрелить себе ногу по самое лицо. Зачем мне тогда C#, если я могу точно так же стрелять себе по ногам в родном С++, без привязки к MS и рантайма в 200Мб? :)
Прежде всего, я не явист. Я просто знаю, что там есть этот пакет. К тому же, Java много где работает в режиме интерпретации байткода. Так что нет, нельзя хотя бы поэтому.
Далее, по поводу "слабо". Подобные финты с манипуляцией стеком применяются крайне редко и в нативном коде. Причём пишутся на ассемблере, под конкретную архитектуру-платформу-ABI. Ваш же пример напоминает мне старую шутку про троллейбус из буханки.
Теперь конкретно по примеру.
Вы можете потенциально расстрелять стек своим неумелым топтанием вверх.
Ваш код всё сломает нафиг при переходе даже на x64 (не говоря о других платформах), по двум причинам сразу.
Вы рискуете отстрелить себе пол-программы по самые гланды если случится инлайнинг.
Вы рискуете сделать непонятно что если JIT вдруг не произойдёт.
Из-за слома return address ваша программа вылетит в никуда.
Короче, вы написали то, что считается отборнейшим говнокодом даже на С/С++.
А знает ли кто-нибудь вменяемую библиотеку фасада логгирования? Т.е. уже написанные функции вывода сообщения, пачка макроссов и т.п. Потому как писать каждый раз велосипед на эту тему немного раздражает.
Как-то многовато действий. Методы внешнего типа могут использовать данные из PImpl напрямую — и тогда накладные расходы будут в одном лишнем уровне индирекции.
Вариант любопытный. Но к сожалению такой же костыль для хождения по граблям как и все остальные. Он не решает гораздо более пакостную проблему — namespace pollution, когда вместе с безобидным заголовком вектора в пространство видимости попадает половина стандартной библиотеки.
Модули, которых нет. И не будет минимум до 20-го года. А то и дольше, учитывая скорость работы комитета.
На самом деле, это б-м реально.
Если загружать голые рантаймы ноды для каждого пользователя и производить запуск через прокси-executable. Пример — nvm, который просто скрипт.
Проблем тут две
Хм, я вот считаю что показанный вами скриншот гораздо приятней — гораздо живее. С технической стороны он может и попроще (по листикам видно), но общее качество картинки NMS повторить не смог.
А ничего особо. Помню только сам факт его наличия.
Уточняю, что я не эмбедщик, и сужу поверхностно. Просто насколько я помню, ни одна попытка втащить управляемую среду на микроконтроллеры не увенчалась широким успехом — просто из-за толщины рантайма или ограничений по памяти, в которые не влезет никакой GC. А б/м известных языков с управлением ресурсами без рантайм-оверхеда у нас 3 штуки. Их я перечислил выше.
А альтернатив нету особо. Эмбед — ограниченные ресурсы, следовательно GC туда не сильно встаёт. Сейчас языков б/м известных языков без GC — 3 штуки. C, C++, Rust.
С — старичок, относительно прост. Но в плане безопасности программирования почти ничем не отличается от ассемблера.
С++ — на данный момент монструозен в плане поддержки стандарта; в плане отстрела себе ноги по самую шею не сильно далеко ушёл от С
Возможно глупый совет, но не пробовали ли вы делать минимальный размер субрегиона в RegionTree допустим 8х8 или 16х16, и делать там сплошную битовую маску? Мне кажется, это было бы эффективней и по памяти, и по времени доступа.
Эта штука удаляет ноду по указателю. Следовательно, указатель надо ещё где-то получить. Подозреваю, это пример какой-то внутренней функции.
Ответил комментарию выше
Да, меня уже поправили. Пишу в основном на С++, поэтому отвык от трюков "указатель на указатель".
Да, точно. Там присваивание указателей.
Там кроме утечки проблема с удалением последнего элемента.
Проблема в том, что кроме параметра "красоты" код должен быть рабочим. По этому параметру плохи оба варианта.
Исходный пример делает по сути detach, не удаляя саму ноду списка.
Пример "со вкусом" оставляет утечку
entry->next— т.к. "удалённая" нода перезаписывается копией следующей — но исходная останется висеть в памяти. Не говоря о том, что он свалится при удалении хвоста, у которого нетnextЗнаете, шутка неудачная. Вы пытались показать, насколько крут C#. В результате вы показали, что на нём можно легко и непринуждённо отстрелить себе ногу по самое лицо. Зачем мне тогда C#, если я могу точно так же стрелять себе по ногам в родном С++, без привязки к MS и рантайма в 200Мб? :)
Прежде всего, я не явист. Я просто знаю, что там есть этот пакет. К тому же, Java много где работает в режиме интерпретации байткода. Так что нет, нельзя хотя бы поэтому.
Далее, по поводу "слабо". Подобные финты с манипуляцией стеком применяются крайне редко и в нативном коде. Причём пишутся на ассемблере, под конкретную архитектуру-платформу-ABI. Ваш же пример напоминает мне старую шутку про троллейбус из буханки.
Теперь конкретно по примеру.
Вы можете потенциально расстрелять стек своим неумелым топтанием вверх.
Ваш код всё сломает нафиг при переходе даже на x64 (не говоря о других платформах), по двум причинам сразу.
Вы рискуете отстрелить себе пол-программы по самые гланды если случится инлайнинг.
Вы рискуете сделать непонятно что если JIT вдруг не произойдёт.
Из-за слома return address ваша программа вылетит в никуда.
Короче, вы написали то, что считается отборнейшим говнокодом даже на С/С++.
sun.misc.unsafe?
А знает ли кто-нибудь вменяемую библиотеку фасада логгирования? Т.е. уже написанные функции вывода сообщения, пачка макроссов и т.п. Потому как писать каждый раз велосипед на эту тему немного раздражает.
Как-то многовато действий. Методы внешнего типа могут использовать данные из PImpl напрямую — и тогда накладные расходы будут в одном лишнем уровне индирекции.
Проблема в том, что это решение реально получается толще pimpl и больше подвержено всяким фокусам вроде переназначения делегатов.
Вариант любопытный. Но к сожалению такой же костыль для хождения по граблям как и все остальные. Он не решает гораздо более пакостную проблему — namespace pollution, когда вместе с безобидным заголовком вектора в пространство видимости попадает половина стандартной библиотеки.
Модули, которых нет. И не будет минимум до 20-го года. А то и дольше, учитывая скорость работы комитета.
del
На самом деле, это б-м реально.
Если загружать голые рантаймы ноды для каждого пользователя и производить запуск через прокси-executable. Пример — nvm, который просто скрипт.
Проблем тут две
Я не отрицаю, что это в принципе можно. Был же .NET Core Framework (или как он там назывался). Я только говорю, что оно пока не распространено широко.
А ничего особо. Помню только сам факт его наличия.
Уточняю, что я не эмбедщик, и сужу поверхностно. Просто насколько я помню, ни одна попытка втащить управляемую среду на микроконтроллеры не увенчалась широким успехом — просто из-за толщины рантайма или ограничений по памяти, в которые не влезет никакой GC. А б/м известных языков с управлением ресурсами без рантайм-оверхеда у нас 3 штуки. Их я перечислил выше.
А альтернатив нету особо. Эмбед — ограниченные ресурсы, следовательно GC туда не сильно встаёт. Сейчас языков б/м известных языков без GC — 3 штуки. C, C++, Rust.
С — старичок, относительно прост. Но в плане безопасности программирования почти ничем не отличается от ассемблера.
С++ — на данный момент монструозен в плане поддержки стандарта; в плане отстрела себе ноги по самую шею не сильно далеко ушёл от С
Rust — безопасен, но очень молод