C++: Realtime везде и повсюду

[xelaz]

сишники? stl ?

stl же по духу ближе к сишарпу с дотнетом. итераторы вот эти всякие... не представляю, как на нем можно писать "как на сях" ...

я, честно говоря, не плюсист нифига, но по мне так писать на простых сях объектно ориентированные вещи - проще, чем в плюсах жестко контролировать ресурсы.

В плюсах не так сложно контролировать ресурсы. RAII в помощь.
Работает эффективнее любого дотнетовского гарбаджа.
Если правильно писать, можно вообще без единого динамического выделения памяти обойтись. Все через стэк. И ни единой утечки памяти.
Так же с сетями и прочими ресурсами. И программа структурируется правильно, и выделяется или освобождается все когда надо. Более того, тулзы, как правило, лучше работают с определением сколько памяти нужно выделить под стэк, чем сколько ее нужно динамически.

[xelaz]

И кстати, не надо stl мешать с сишарпом. В сишарпе есть разве templates? В С++ есть. Весь стл на этих templates. А между прочим, templates - это фича, которая вся в статике компилируется. Можно программы писать вычисляющие значение еще до того, как она запущена - как константа. А это между прочим, существенное преимущество, перед сями - смещения большой доли кода или потенциальных ошибок из ран-тайм в компайл-тайм область. Но как я выше говорил, надо очень хорошо это все знать и уметь использовать.

[xelaz]

в риалтайме вообще чем меньше динамики - тем лучше. Создал/распределил на старте - и понеслась.

Вот именно по этому конструкторы и деструкторы С++ особенно удобны - где все делается на старте автоматом - для глобальных обхектов (которые есть зло, как все знают). Но в том же реалтайме нужно иногда и память экономить, и нужно поэтмоу использовать временные объекты, в локальном скопе видимости. БОлее того, использование локальных объектов существенно позволяет упростить программу, и лучше проконтролировать ее сложность путем анализа на объекты и последующего их синтеза в программу, выражаясь гегелевским языком. Чего намного сложнее сделать, когда все объекты глобальны и заранее выделены.

[Mastodont]

И кстати, не надо stl мешать с сишарпом. В сишарпе есть разве templates? В С++ есть. Весь стл на этих templates. А между прочим, templates - это фича, которая вся в статике компилируется. Можно программы писать вычисляющие значение еще до того, как она запущена - как константа. А это между прочим, существенное преимущество, перед сями - смещения большой доли кода или потенциальных ошибок из ран-тайм в компайл-тайм область. Но как я выше говорил, надо очень хорошо это все знать и уметь использовать.

stl держится немного не на том, а конкретно на двух вещах: на контейнерах и на алгоритмах.

в си-шарпе/java есть generics, которые тоже компайл тайм.

[xelaz]

в си-шарпе/java есть generics, которые тоже компайл тайм.

спасибо. Почитал сравнение дженерикс в джаве и темплэйты в с++

Comparison of Java and C++ - Wikipedia, the free encyclopedia

Получаем, например, следующее: каждая статическая переменная в джаве разделяется классами с разными параметрами типов, тогда как в С++ это разные классы и эти переменные только для тех классов.
Ну т.е. waste of space для джавы, и тем больше, чем больше параметров для типов. Такие объекты с лишней ифнормацией, например, хранить в массиве будет очень невыгодно.

В С++ темплэйты - Turing Complete - т.е. можно например, вычислить факториал в статике. В джаве - нет - что означает, подобные вычисления будут делаться все же в ран-тайме.

В С++ классы или функции для темплэйтов - отдельные, в джаве - одна функция для всех параметров - т.е. видимо ран-тайм резолюшн вызова.

[Mastodont]

спасибо. Почитал сравнение дженерикс в джаве и темплэйты в с++

Comparison of Java and C++ - Wikipedia, the free encyclopedia

Получаем, например, следующее: каждая статическая переменная в джаве разделяется классами с разными параметрами типов, тогда как в С++ это разные классы и эти переменные только для тех классов.
Ну т.е. waste of space для джавы, и тем больше, чем больше параметров для типов. Такие объекты с лишней ифнормацией, например, хранить в массиве будет очень невыгодно.

В С++ темплэйты - Turing Complete - т.е. можно например, вычислить факториал в статике. В джаве - нет - что означает, подобные вычисления будут делаться все же в ран-тайме.

В С++ классы или функции для темплэйтов - отдельные, в джаве - одна функция для всех параметров - т.е. видимо ран-тайм резолюшн вызова.

давай по порядку.

ты пишешь что "каждая статическая переменная в джаве разделяется классами с разными параметрами типов, тогда как в С++ это разные классы и эти переменные только для тех классов. "
а дальше делаешь вывод что "Ну т.е. waste of space для джавы, и тем больше, чем больше параметров для типов."

если твое "разделяется" это "shared"/static - то получает как раз наоборот - в С++ вариант потребляет больше памяти, чем в Java, т.к. в С++ каждый concrete тип полученный параметризацией темплейт/или женерик класса будет иметь свою копию статических членов.

потом ты пишешь "Такие объекты с лишней ифнормацией, например, хранить в массиве будет очень невыгодно." - это тоже непонятно, т.к. подразумевается расход памяти на статические члены никак не зависит от массива и его размеров, потому как их только одна копия на класс на процесс (или эквивалентвую абстракцию).

про "В С++ темплэйты - Turing Complete - т.е. можно например, вычислить факториал в статике. В джаве - нет - что означает, подобные вычисления будут делаться все же в ран-тайме." ок - факториал ты в С++ можешь вычислить в режиме компиляции, я могу вычислить 25 числе в последовательности фибоначи. Какую полезную функциональность можно реализовать использую эту технику, так чтобы она превосходила С#/Java?

"В С++ классы или функции для темплэйтов - отдельные, в джаве - одна функция для всех параметров - т.е. видимо ран-тайм резолюшн вызова."

что такое "отдельные / одна функция" - отдельный кусок java byte code, или машинный код таргет платформы, или что еще?

[xelaz]

давай по порядку.

ты пишешь что "каждая статическая переменная в джаве разделяется классами с разными параметрами типов, тогда как в С++ это разные классы и эти переменные только для тех классов. "
а дальше делаешь вывод что "Ну т.е. waste of space для джавы, и тем больше, чем больше параметров для типов."

если твое "разделяется" это "shared"/static - то получает как раз наоборот - в С++ вариант потребляет больше памяти, чем в Java, т.к. в С++ каждый concrete тип полученный параметризацией темплейт/или женерик класса будет иметь свою копию статических членов.

Отвечаю

Только что еще раз пересмотрел ту таблицу по ссылке, и увидел, что Джава просто не поддерживает вариант, когда Тип параметра используется дла статической перменной. Я предполагал что Джава поддерживает, и имел в виду эти статические типы (из числа template arguments)
Если бы Джава поддерживала, то эта фича, наряду с джавовской "расшаренностью" таких переменных, была бы waste of space, т.к. пришлось бы выбирать какой именно тип имеется в виду в рантайме (поскольку он шэред). И хранить максимальный размер такой статической переменной (зависящий от используемого конкретного типа параметризующего класс).

Но именно типы параметров нельзя использовать для создания статических членов в джаве.

В этом случае да, в С++ "вэйст оф спэйс" происходит для тех статических типов, которые не являются Template Arguments.

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

Пусть статические переменные разделяются классами и их типы не являются параметрами класса.
Присвоив значение такой переменной, воздействует на все классы сразу, хотя чисто технически это другие типы, и тогда возникает вопрос: а почему на разные типы должно действовать это изменение? Это ведь все равно, что отказаться от ООП и использовать глобальные переменные - тот же эффект в итоге.

В этом плане, в С++ такое разделение реализовано более грамотно с учетом, что это все таки разные типы.

потом ты пишешь "Такие объекты с лишней ифнормацией, например, хранить в массиве будет очень невыгодно." - это тоже непонятно, т.к. подразумевается расход памяти на статические члены никак не зависит от массива и его размеров, потому как их только одна копия на класс на процесс (или эквивалентвую абстракцию).

Здесь ты прав. Статические переменные - это копия на класс, а не на объект. Т.е. хранится она вне объекта.
Однако джава их и не поддерживает:

Type parameter of templated class cannot be used for static methods and variables. (см. ту же ссылку выше)

вместо этого там про другие переменные (не те что заданы типом)

Static variables are shared between instances of classes of different type parameters


И опять же:
One version of the class or function is compiled, works for all type parameters. - это означает, что берется максимальный размер для текущего параметра, что класс должен в ран-тайме определять размер параметра и кусок кода для него (вместо константно скомпилированного отдельного варианта для С++, где такой выборки нет для всего инстанциированного экземпляра)

про "В С++ темплэйты - Turing Complete - т.е. можно например, вычислить факториал в статике. В джаве - нет - что означает, подобные вычисления будут делаться все же в ран-тайме." ок - факториал ты в С++ можешь вычислить в режиме компиляции, я могу вычислить 25 числе в последовательности фибоначи. Какую полезную функциональность можно реализовать использую эту технику, так чтобы она превосходила С#/Java?

Такую, что тем самым смещается часть вычислений (достаточно большая часть) из рантайм области в компайлтайм. Но я уже это отметил ранее.
СТЛ кстати очень много выводит таким образом в компайлтайм.

"В С++ классы или функции для темплэйтов - отдельные, в джаве - одна функция для всех параметров - т.е. видимо ран-тайм резолюшн вызова."

что такое "отдельные / одна функция" - отдельный кусок java byte code, или машинный код таргет платформы, или что еще?

это означает, что если расписать, как это реализовано, то получаем приблизительно такое:



funtion()
{
switch TemplateArg
case Type1:
do something_related_to_type_1
case Type2:
do something_related_to_Type_2
....
}

Это рантайм чистой воды.

В с++ это будет:

functionType1()
{
do something related to type 1 only, don't choose anytihng
}

functionType2()
{
only type 2-related things
}


Код, какую из функций выбрать - статически влинкован, нет рантайм выбора для него.


Вопрос теперь: даже если в джаве это не машинный таргет код платформы, а именно байт код, (вроде как универсализм и независисмостть тем самым подчеркивается),
каким образом в статике обходится ограничение для разделяемых типов-параметров разного размера? На мой вгляд никак.
Или у тебя есть свои соображения по этому поводу?

[extremal]

Это нах не надо в Java, потому как хранить состояние в static - это дурной тон как и вообще глобаные переменные. static используется в основном вместе с final, то есть для констант только. Любое использовние static ведет к тому что проблематично написать unit test, т.к. static невозможно замокать. Соотвественно паттерн Singleton - на самом деле является анти-паттерном, потому что его нельзя замокать

[aikhome]

кывт на гдее, иииихааа

[Karadur]

Это нах не надо в Java, потому как хранить состояние в static - это дурной тон как и вообще глобаные переменные. static используется в основном вместе с final, то есть для констант только. Любое использовние static ведет к тому что проблематично написать unit test, т.к. static невозможно замокать. Соотвественно паттерн Singleton - на самом деле является анти-паттерном, потому что его нельзя замокать

да ладно.
static в C++ и Java - это контекст, общий для всех инстансов класса.
Странно было бы говорить, что это дурной тон. Такие ситуации возникают сплошь и рядом.
Без статика ты будешь всë равно создавать некие уникальные менеджеры, куда имеют доступ все инстансы. Но это зачастую более громоздко, чем простой статик. Плюс ещë время обращения будет дольше.

[xelaz]

Это нах не надо в Java, потому как хранить состояние в static - это дурной тон как и вообще глобаные переменные. static используется в основном вместе с final, то есть для констант только. Любое использовние static ведет к тому что проблематично написать unit test, т.к. static невозможно замокать. Соотвественно паттерн Singleton - на самом деле является анти-паттерном, потому что его нельзя замокать

дурным тоном будет использовать паттерн синглтон там, где можно обойтись без него. Однако сам паттерн реализует именно ту задачу которая на него возложена - быть глобальным, и при этом не раскидываться кишками.

потом, не надо путать ту глобальность, навязываемую джавой в результате шаринга статических переменных для классов с разными типами и ограничение той глобальности сделанное в С++ для статик переменных только для тех классов, где она используется. Они может и остаеются глобальными, но в более узком спектре.