LINUX.ORG.RU

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

Исправление SR_team, (текущая версия) :

В классическом варианте это звучит так: не читал - но осуждаю

Использовал и осуждаю. Либа работает, доработок не требует, так что что там наменяли в свежих версиях языка я не знаю. Сужу по тому, что было на момент использования.

Как может быть вся либа завязана на сборщик мусора, если далеко не вся либа вообще имеет дело с памятью?

А вот так. Включаешь -betterC, что бы собраться без GC рантайма и часть compile-time фич отваливается. Без -betterC, с пометкой каждой функции @nogc все compile-time фичи работают и рантайм не использует GC, но он линкуется к бинарю и отодрать его стрипом нельзя

Как рефлексия может быть завязана на сборщик мусора? Как метапрограммирование может быть завязано на сборщик мусора?

Без сборщика мусора (режим -betterC) отваливается часть функционала связанная с RTTI, то что в C++ работает без всяких сборщиков мусора

Ну а насчет «хз на сколько юзабельно оно в итоге получится» - я подозреваю, что ты не знаешь, насколько юзабельно оно сейчас.

Как я писал - да, я хз как оно в текущей версии D, но вывод у тебя не совсем верный. Они запретили перегрузку new/delete, что бы пользователь не путался и new/delete всегда относились к GC, потом задепрекейтели delete (и возможно в текущих версиях уже удалили). И в этих условиях выкидывают GC из фобоса там, где он не нужен (из исключений например выкидывали, что бы завести их в -betterC). Как они будут в этих условиях классы от GC отвязывать я хз - в сторонних либах свои реализации New/Delete, и на сколько я помню, без GC класс даже на стеке аллоцировать нельзя.

Но ты давай, расскажи, что -betterC и без GC (@nogc) это разные штуки, почти разные языки и то что без -betterC к каждому бинарю линкуется неиспользуемый рантайм с GC это нормально - диски нынче большие, и пользователи потерпят

Исходная версия SR_team, :

В классическом варианте это звучит так: не читал - но осуждаю

Использовал и осуждаю. Либа работает, доработок не требует, так что что там наменяли в свежих версиях языка я не знаю. Сужу по тому, что было на момент использования.

Как может быть вся либа завязана на сборщик мусора, если далеко не вся либа вообще имеет дело с памятью?

А вот так. Включаешь -betterC, что бы собраться без GC рантайма и часть compile-time фич отваливается. Без -betterC, с пометкой каждой функции @nogc все compile-time фичи работают и рантайм не использует GC, но он линкуется к бинарю и отодрать его стрипом нельзя

Как рефлексия может быть завязана на сборщик мусора? Как метапрограммирование может быть завязано на сборщик мусора?

Без сборщика мусора (режим -betterC) отваливается часть функционала связанная с RTTI, то что в C++ работает без всяких сборщиков мусора

Ну а насчет «хз на сколько юзабельно оно в итоге получится» - я подозреваю, что ты не знаешь, насколько юзабельно оно сейчас.

Как я писал - да, я хз как оно в текущей версии D, но вывод у тебя не совсем верный. Они запретили перегрузку new/delete, что бы пользователь не путался и new/delete всегда относились к GC, потом задепрекейтели delete (и возможно в текущих версиях уже удалили). И в этих условиях выкидывают GC из фобоса там, где он не нужен (из исключений например выкидывали, что бы завести их в -betterC). Как они будут в этих условиях классы от GC отвязывать я хз - в сторонних либах свои реализации New/Delete, и на сколько я помню, без GC класс даже на стеке аллоцировать нельзя.

Но ты давай, расскажи, что -betterC и без GC (@nogc) это разные штуки, почти разные языки и то что без -betterC к каждому бинарю линкуется неиспользуемый рантайм с GC это нормально - диски нынче большие, и пользователи потерпят