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

I>Какая доля луноходов в общей массе?

Большая, если твой дом на Луне...

AG>>Нативная то идёт быстрее, но это если перед тобой — прямая дорога. Проторенная тысячами путников.

I>Именно! Но судя по тому, что ниже, ты не понимаешь экономику кроссплатформенного проекта.

...я никогда и не искал вакансию экономиста...

I>Экономишь время исключительно за счет:
I>1 бизнес-логики — никаких сложностей нет, т.к. от платформы не зависит.
+100500
I>2 базовых функций нативных платформ, типа открыть-прочитать файл
+100500
I>Исключительно эта часть у тебя будет в одном экземпляре.
Эта часть — да в одном.

I>Всё остальное — по числу платформ и это в лучшем случае, т.к. могут быть нюансы, по нескольку версий в зависимости от возможностей какого нибудь иос.

Ну здесь не совсем так:
a) При разработках на C++ Qt5 для Windows/Linux львиная доля окошек (ну скажем — обычных окон) — также один экземпляр.
b) Те же многопоточные решения — закрываются на Qt и не требуют от меня копания в потоках исполнения конкретной OS.
c) Для всяких там iOS не в курсе, ими не занимался.

AG>>Если будет шаг влево/вправо — то придется искать обходные пути (и зачастую довольно длинные)

I> Именно это тебя ждет и в кроссплатформенной версии.
I>Например, ты выяснил, что тебе нужен X, который в Маке иначе как стоя раком не запустишь.
...уже упоминал, что на Маке ничего не делаем...

I>Ты наверное ждешь, что кроссплатформенный фремворк весь из себя идеальный, и в ём магическим образом сделали X
Про идеальный — никто и не говорит. Просто — достаточно хороший (в меру качественный).

I>Вот пример — писали прогу на 4 платформы. Использовали сторадж, который работал везде хорошо, кроме одной из платформ.
I>Как побороть? Нативныйм кодом. А теперь выясняется, что этот же сторадж, кроме как раком завести не получается.
I>Что делать ? Нашли другую реализацию. Теперь дело за малым — во всех платформах реалализовать новый вариант.
I>Оказалось, что во всех платформах для нового движка структура АПИ отличается — файловое апи, стримы, база данных и хрен знает что.
I>Теперь кроме адаптации, надо написать слой, который дает универсальное АПИ, что бы BL была действительно кроссплатформенной.

Выше описана проблема архитектуры — что надо было выносить на уровень business logic, а что оставить в "реализационно-техническом слое".

I>Итого — по скромной оценке в 4 раза больше работы, чем для нативных вариантов. 3 раза сделали ненужную работу, 1 раз нужную + слой для кроссплатформенности.

Вопрос в другом: что это за прога и насколько адекветные (для этой задачи) разработчики?

I>А в теории надо бы добавить недостающую платформу.
...
Вот тут-то и думается, что книга GoF и другие книжки по паттернам проектирования — обязаны быть нашей настольной литературой.
Да, и с книгами Александреску дружить нужно!
Это очень важно для любых разработок, даже если пишем всё для одной платформы.

I>Что это за стек такой?

Технологические программы, управление в специализированных системах, расчёты и моделирование.
Ранее я много занимался SCADA и MES системами (это отдельное направление).
В общем, там где применение C++ сам Бог послал.

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

I>Какая доля луноходов в общей массе?

Большая, если твой дом на Луне...

AG>>Нативная то идёт быстрее, но это если перед тобой — прямая дорога. Проторенная тысячами путников.

I>Именно! Но судя по тому, что ниже, ты не понимаешь экономику кроссплатформенного проекта.

...я никогда и не искал вакансию экономиста...

I>Экономишь время исключительно за счет:
I>1 бизнес-логики — никаких сложностей нет, т.к. от платформы не зависит.
+100500
I>2 базовых функций нативных платформ, типа открыть-прочитать файл
+100500
I>Исключительно эта часть у тебя будет в одном экземпляре.
Эта часть — да в одном.

I>Всё остальное — по числу платформ и это в лучшем случае, т.к. могут быть нюансы, по нескольку версий в зависимости от возможностей какого нибудь иос.

Ну здесь не совсем так:
a) При разработках на C++ Qt5 для Windows/Linux львиная доля окошек (ну скажем — обычных окон) — также один экземпляр.
b) Те же многопоточные решения — закрываются на Qt и не требуют от меня копания в потоках исполнения конкретной OS.
c) Для всяких там iOS не в курсе, ими не занимался.

AG>>Если будет шаг влево/вправо — то придется искать обходные пути (и зачастую довольно длинные)

I> Именно это тебя ждет и в кроссплатформенной версии.
I>Например, ты выяснил, что тебе нужен X, который в Маке иначе как стоя раком не запустишь.
...уже упоминал, что на Маке ничего не делаем...

I>Ты наверное ждешь, что кроссплатформенный фремворк весь из себя идеальный, и в ём магическим образом сделали X
Про идеальный — никто и не говорит. Просто — достаточно хороший (в меру качественный).

I>Вот пример — писали прогу на 4 платформы. Использовали сторадж, который работал везде хорошо, кроме одной из платформ.
I>Как побороть? Нативныйм кодом. А теперь выясняется, что этот же сторадж, кроме как раком завести не получается.
I>Что делать ? Нашли другую реализацию. Теперь дело за малым — во всех платформах реалализовать новый вариант.
I>Оказалось, что во всех платформах для нового движка структура АПИ отличается — файловое апи, стримы, база данных и хрен знает что.
I>Теперь кроме адаптации, надо написать слой, который дает универсальное АПИ, что бы BL была действительно кроссплатформенной.

Выше описана проблема архитектуры — что надо было выносить на уровень business logic, а что оставить в "реализационно-техническом слое".

I>Итого — по скромной оценке в 4 раза больше работы, чем для нативных вариантов. 3 раза сделали ненужную работу, 1 раз нужную + слой для кроссплатформенности.

Тут вопрос в другом: что это за прога и насколько адекватные (для этой задачи) были её разработчики?

I>А в теории надо бы добавить недостающую платформу.
А в практике — хорошо продумать архитектуру проекта, чтобы потом не ломать...

Вот тут-то и думается, что книга GoF и другие книжки по паттернам проектирования — обязаны быть нашей настольной литературой.
Да, и с книгами Александреску дружить нужно!
Это очень важно для любых разработок, даже если пишем всё для одной платформы.

I>Что это за стек такой?

Технологические программы, управление в специализированных системах, расчёты и моделирование.
Ранее я много занимался SCADA и MES системами (это отдельное направление).
В общем, там где применение C++ сам Бог послал.