Здравствуйте, cppguard, Вы писали:

C>Здравствуйте, vopl, Вы писали:

V>>без капитализации нарабатываемой кодовой базы
C>Что такое "капитализация нарабатываемой базы"? Получение выгоды раз за разом из единожды написанного кода?

Да. К такому капитальному коду практически всегда относятся инструменты, которые сами по себе являются средствами производства — библиотеки/фреймворки, подобное. Почему в таком коде находит применение сабж — потому что пользователем данного кода является сам инженер, и его варианты использования лежат внутри инструмента а не снаружи, вот ему и требуются всякие "чтоб было посчитано в компайлтайме", "чтоб функцию с таким типом аргумента можно было вызвать а нестаким нет", "чтоб не писать ручками 100500 бойлерплейта а оно само чтобы сгенерировалось"...


V>>Как то раз пришлось озаботиться собственным автоматом для разводки событий, аля boost::signals, но со своим блекджеком. И вот чтобы достигать zero-cost в максимальном количестве вариантов использования, применяется вся эте чертыхня с constexpr/шаблонами и прочей метапрограммирование-шнягой. То что получилось в итоге я бы оценил как "охренительно великолепно", удалось добиться быстродействия, сравнимого с наивными виртуальными вызовами с одной стороны и занчительного удобства для прикладного использования с другой. Тут можно посмотреть код

C>Выглядит сложно, но можно в двух словах о том, что там действительно происходит? Почему, скажем, на Java это должно работать медленее (без учёта времени на JIT и сборку мусора)?

В двух словах — имеет место некая сложная (сложенная из множества подсистем) система, полностью выполняющая свое предназначение (функционально полная) эффективно (уровень быстродействия/удобства использования оценивается как хороший). При этом она не разваливается под тяжестью собственной сложности (органична), и как следствие, вполне устойчива при использовании/доработке (робастна). Всех этих показателей вряд ли можно достичь без использования метапрограмминга (constexpr, шаблоны, ...)

На Яве это будет работать не менее замечательно, при условии что в стандартной бибилиотеке Явы найдутся средства чтобы сделать это именно так. Если задача прецедентная — то такие средства с большой вероятностю там таки найдутся, и все будет хорошо. Но если задача не вполне прецедентная (со своим блекджеком), то таких средств в Яве не найдется, придется лепить костылями из доступных средств, вследствие чего быстродействие/удобство и прочие тактико-технические характеристики просядут. Собственно, в этом и есть сила C++, в нем ты можешь сам себе построить "средства производства" чтобы потом на их основе строить прикладуху как второй уровень. И вся система будет органична/эффективна. В Яве же средства производства поставляются центральным вендором, что в некотором смысле ограничивает разработчика.

Здравствуйте, cppguard, Вы писали:

C>Здравствуйте, vopl, Вы писали:

V>>без капитализации нарабатываемой кодовой базы
C>Что такое "капитализация нарабатываемой базы"? Получение выгоды раз за разом из единожды написанного кода?

Да. К такому капитальному коду практически всегда относятся инструменты, которые сами по себе являются средствами производства — библиотеки/фреймворки, подобное. Почему в таком коде находит применение сабж — потому что пользователем данного кода является сам инженер, и его варианты использования лежат внутри инструмента а не снаружи, вот ему и требуются всякие "чтоб было посчитано в компайлтайме", "чтоб функцию с таким типом аргумента можно было вызвать а нестаким нет", "чтоб не писать ручками 100500 бойлерплейта а оно само чтобы сгенерировалось"...


V>>Как то раз пришлось озаботиться собственным автоматом для разводки событий, аля boost::signals, но со своим блекджеком. И вот чтобы достигать zero-cost в максимальном количестве вариантов использования, применяется вся эте чертыхня с constexpr/шаблонами и прочей метапрограммирование-шнягой. То что получилось в итоге я бы оценил как "охренительно великолепно", удалось добиться быстродействия, сравнимого с наивными виртуальными вызовами с одной стороны и занчительного удобства для прикладного использования с другой. Тут можно посмотреть код

C>Выглядит сложно, но можно в двух словах о том, что там действительно происходит? Почему, скажем, на Java это должно работать медленее (без учёта времени на JIT и сборку мусора)?

В двух словах — имеет место некая система, сложенная из множества подсистем (то есть сложная), полностью выполняющая свое предназначение (функционально полная) с хорошим уровнем быстродействия/удобства использования (эффективная), при этом она не разваливается под тяжестью собственной сложности (органичная), и как следствие, вполне устойчива при использовании/доработке (робастная в аспекте жизненной динамики). Всех этих показателей вряд ли можно достичь без использования метапрограмминга (constexpr, шаблоны, ...)

На Яве это будет работать не менее замечательно, при условии что в стандартной бибилиотеке Явы найдутся средства чтобы сделать это именно так. Если задача прецедентная — то такие средства с большой вероятностю там таки найдутся, и все будет хорошо. Но если задача не вполне прецедентная (со своим блекджеком), то таких средств в Яве не найдется, придется лепить костылями из доступных средств, вследствие чего быстродействие/удобство и прочие тактико-технические характеристики просядут. Собственно, в этом и есть сила C++, в нем ты можешь сам себе построить "средства производства" чтобы потом на их основе строить прикладуху как второй уровень. И вся система будет органична/эффективна. В Яве же средства производства поставляются центральным вендором, что в некотором смысле ограничивает разработчика.