История изменений
Исправление
MOPKOBKA,
(текущая версия)
:
А какие преимущества дает отсутствие такого боксинга/динамики, когда мы знаем к чему мы обращаемся? Если отбросить кодогенерацию.
Не могу ничего придумать. Даже если нужны какие то проверки, то они записываются в условный Trait, и на момент проверки совместимости типа с Trait отрабатывают. Ну там к примеру sizeof() типа не должен быть более 100, иначе он не подходит к данному Trait, а значит и к функции принимающей Trait.
Больше всего у меня опыта в С со всякими void* коллекцияами и боксингом. Что дают генерики как в Rust мне понятно к примеру, не надо void* писать. Что дает по сравнению с Rust настоящая статическая типизация?
Исправление
MOPKOBKA,
:
А какие преимущества дает отсутствие такого боксинга/динамики, когда мы знаем к чему мы обращаемся? Если отбросить кодогенерацию.
Не могу ничего придумать. Даже если нужны какие то проверки, то они записываются в условный Trait, и на момент проверки совместимости типа с Trait отрабатывают. Ну там к примеру sizeof() типа не должен быть более 100, иначе он не подходит к данному Trait, а значит и к функции принимающей Trait.
Мне по моему опыту ближе ручное повторение ADT и void* коллекции в С. Что дают генерики как в Rust мне понятно к примеру, не надо void* писать.
Исправление
MOPKOBKA,
:
А какие преимущества дает отсутствие такого боксинга/динамики, когда мы знаем к чему мы обращаемся? Если отбросить кодогенерацию.
Не могу ничего придумать. Даже если нужны какие то проверки, то они записываются в условный Trait, и на момент проверки совместимости типа с Trait отрабатывают. Ну там к примеру sizeof() типа не должен быть более 100, иначе он не подходит к данному Trait, а значит и к функции принимающей Trait.
Мне по моему опыту ближе ручное повторение ADT и void* коллекции в С. Что дают генерики как в Rust мне понятно к примеру.
Исправление
MOPKOBKA,
:
А какие преимущества дает отсутствие такого боксинга/динамики, когда мы знаем к чему мы обращаемся? Если отбросить кодогенерацию.
Не могу ничего придумать. Даже если нужны какие то проверки, то они записываются в условный Trait, и на момент проверки совместимости типа с Trait отрабатывают. Ну там к примеру sizeof() типа не должен быть более 100, иначе он не подходит к данному Trait, а значит и к функции принимающей Trait.
Весь мой опыт это ручное повторение ADT и void* коллекции.
Исправление
MOPKOBKA,
:
А какие преимущества дает отсутствие такого боксинга/динамики, когда мы знаем к чему мы обращаемся? Если отбросить кодогенерацию.
Не могу ничего придумать. Даже если нужны какие то проверки, то они записываются в условный Trait, и на момент проверки совместимости типа с Trait отрабатывают. Ну там к примеру sizeof() типа не должен быть более 100, иначе он не подходит к данному Trait, а значит и к функции принимающей Trait.
Исправление
MOPKOBKA,
:
А какие преимущества дает отсутствие такого боксинга/динамики, когда мы знаем к чему мы обращаемся? Если отбросить кодогенерацию.
Не могу ничего придумать. Даже если нужны какие то проверки, то они записываются в условный Trait, и на момент проверки совместимости типа с Trait отрабатывают. Ну там к примеру sizeof() типа не должен быть более 100, иначе он не подходит к функции.
Исходная версия
MOPKOBKA,
:
А какие преимущества дает отсутствие такого боксинга/динамики, когда мы знаем к чему мы обращаемся? Если отбросить кодогенерацию.