Сообщение Re[14]: С++ всё? Rust навсегда? от 23.06.2020 8:37
Изменено 23.06.2020 8:39 lpd
Re[14]: С++ всё? Rust навсегда?
Здравствуйте, chaotic-kotik, Вы писали:
CK>решение 1 — можно сделать оптимизацию для случая, когда параметры занимают мало места и размещать из не в динамической памяти, а в самом объекте Functor. Упрвление памятью не проблема, т.к. функтор реализует value семантику.
CK>решение 2 — используем move семантику для параметров.
Использовать move-семантику для оптимизации, особенно везде — это вообще дно. Оптимизировать нужно только узкие места программы. Передача аргументов не играет решающей роли в быстродействии. ЕСЛИ у тебя большие объекты копируются в критичном коде при легковесной обработке их, можно легко сделать только для них метод MoveObject(), а не перегружать язык новыми типами &&(имеющими только академический интерес) с запутанным синтаксисом.
CK>проблема 3 — внезапно тебе потребовалась поддержка cancellation и для этого тебе нужно добавить еще один метод в твой базовый класс и реализовать его в куче разных реализаций
CK>решение 3 — можно добавить реализацию cancel в одном месте.
CK>Это конечно сложнее в реализации, но это IMO упрощает код. Подход Си с классами проще на первый взгляд, но это выливается в сложности в дальнейшем.
По-моему можно обойтись виртуальными функциями и RTTI.
Да я и не против шаблонов самих по себе, какими они были в классическом С++. Я считаю тупиковым путь развития С++, потому что добавляются только представляющие узкий интерес для специалистов языкам фичи, вместо добавления языку новых возможностей общего назначения. И на Java/C# пишется уже гораздо больше.
CK>решение 1 — можно сделать оптимизацию для случая, когда параметры занимают мало места и размещать из не в динамической памяти, а в самом объекте Functor. Упрвление памятью не проблема, т.к. функтор реализует value семантику.
CK>решение 2 — используем move семантику для параметров.
Использовать move-семантику для оптимизации, особенно везде — это вообще дно. Оптимизировать нужно только узкие места программы. Передача аргументов не играет решающей роли в быстродействии. ЕСЛИ у тебя большие объекты копируются в критичном коде при легковесной обработке их, можно легко сделать только для них метод MoveObject(), а не перегружать язык новыми типами &&(имеющими только академический интерес) с запутанным синтаксисом.
CK>проблема 3 — внезапно тебе потребовалась поддержка cancellation и для этого тебе нужно добавить еще один метод в твой базовый класс и реализовать его в куче разных реализаций
CK>решение 3 — можно добавить реализацию cancel в одном месте.
CK>Это конечно сложнее в реализации, но это IMO упрощает код. Подход Си с классами проще на первый взгляд, но это выливается в сложности в дальнейшем.
По-моему можно обойтись виртуальными функциями и RTTI.
Да я и не против шаблонов самих по себе, какими они были в классическом С++. Я считаю тупиковым путь развития С++, потому что добавляются только представляющие узкий интерес для специалистов языкам фичи, вместо добавления языку новых возможностей общего назначения. И на Java/C# пишется уже гораздо больше.
Re[14]: С++ всё? Rust навсегда?
Здравствуйте, chaotic-kotik, Вы писали:
CK>решение 1 — можно сделать оптимизацию для случая, когда параметры занимают мало места и размещать из не в динамической памяти, а в самом объекте Functor. Упрвление памятью не проблема, т.к. функтор реализует value семантику.
CK>решение 2 — используем move семантику для параметров.
Использовать move-семантику для оптимизации, особенно везде — это вообще дно. Оптимизировать нужно только узкие места программы. Передача аргументов не играет решающей роли в быстродействии. ЕСЛИ у тебя большие объекты копируются в критичном коде при легковесной обработке их, можно легко сделать только для них метод MoveObject(), а не перегружать язык новыми типами &&(имеющими только академический интерес) с запутанным синтаксисом.
CK>проблема 3 — внезапно тебе потребовалась поддержка cancellation и для этого тебе нужно добавить еще один метод в твой базовый класс и реализовать его в куче разных реализаций
CK>решение 3 — можно добавить реализацию cancel в одном месте.
CK>Это конечно сложнее в реализации, но это IMO упрощает код. Подход Си с классами проще на первый взгляд, но это выливается в сложности в дальнейшем.
По-моему можно обойтись виртуальными функциями и RTTI.
Да я и не против шаблонов самих по себе, какими они были в классическом С++. Я считаю тупиковым путь развития С++, потому что добавляются только представляющие узкий интерес только для специалистов языкам фичи, вместо добавления языку новых возможностей общего назначения. И на Java/C# уже давно пишется гораздо больше.
CK>решение 1 — можно сделать оптимизацию для случая, когда параметры занимают мало места и размещать из не в динамической памяти, а в самом объекте Functor. Упрвление памятью не проблема, т.к. функтор реализует value семантику.
CK>решение 2 — используем move семантику для параметров.
Использовать move-семантику для оптимизации, особенно везде — это вообще дно. Оптимизировать нужно только узкие места программы. Передача аргументов не играет решающей роли в быстродействии. ЕСЛИ у тебя большие объекты копируются в критичном коде при легковесной обработке их, можно легко сделать только для них метод MoveObject(), а не перегружать язык новыми типами &&(имеющими только академический интерес) с запутанным синтаксисом.
CK>проблема 3 — внезапно тебе потребовалась поддержка cancellation и для этого тебе нужно добавить еще один метод в твой базовый класс и реализовать его в куче разных реализаций
CK>решение 3 — можно добавить реализацию cancel в одном месте.
CK>Это конечно сложнее в реализации, но это IMO упрощает код. Подход Си с классами проще на первый взгляд, но это выливается в сложности в дальнейшем.
По-моему можно обойтись виртуальными функциями и RTTI.
Да я и не против шаблонов самих по себе, какими они были в классическом С++. Я считаю тупиковым путь развития С++, потому что добавляются только представляющие узкий интерес только для специалистов языкам фичи, вместо добавления языку новых возможностей общего назначения. И на Java/C# уже давно пишется гораздо больше.