Здравствуйте, BulatZiganshin, Вы писали:
BZ>Здравствуйте, Khimik, Вы писали:
K>>на какую платформу тогда переводить мою программу: проект на C# слишком легко взломать, а C++ это древний ужас
BZ>haskell. хотя c++14 тоже можно вытерпеть. уж всяко лучше delphi7 — память под строки распределяется автоматом, память освобождается умными указателями, проблемы по сравнению с c# только в том что нельзя свободно создавать объекты внутри выражений
Всегда забавно видеть аргументы вроде "память под строки распределяется автоматом" в разговоре о современных языках программирования. Так жечь только С++ники могут. Сразу видно, люди не привыкшие к удобствам
Я пробую перевести мою Delphi-программу с VCL на Firemonkey, уже столкнулся с кучей проблем, и подозреваю что успешного результата так и не будет. Если не ошибаюсь, последняя Delphi скомпилирована с VCL, а не Firemonkey, так что естественно с последним должно быть полно багов и проблем. А если Windows умрёт, а Embarcadero так и не осилят перевод всего на Firemonkey и забросят Delphi? Я плохо представляю, на какую платформу тогда переводить мою программу: проект на C# слишком легко взломать, а C++ это древний ужас. Или я что-то вижу не так? Можно ли прогнозировать, что если Delphi умрёт, то наступит закат шаровары? Извиняюсь если вопрос профанский.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать". АБ Стругацкие.
Здравствуйте, Khimik, Вы писали:
K>на какую платформу тогда переводить мою программу: проект на C# слишком легко взломать, а C++ это древний ужас
haskell. хотя c++14 тоже можно вытерпеть. уж всяко лучше delphi7 — память под строки распределяется автоматом, память освобождается умными указателями, проблемы по сравнению с c# только в том что нельзя свободно создавать объекты внутри выражений
Здравствуйте, Khimik, Вы писали:
K>Я плохо представляю, на какую платформу тогда переводить мою программу: проект на C# слишком легко взломать, а C++ это древний ужас.
Если интересует кроссплатформенность, то могу рассказать конкретно про Java, на коей я программирую.
У меня есть несколько программ на Java+SWING, они действительно работают кроссплатформенно, но есть и подводные камни. Во-первых, интерфейс даже со скином выглядит угловато и на один-два шага менее современно, чем в современных ОС, во-вторых есть некоторые недоработки, к примеру копи-паста в ячейках таблицы не работает по дефолту, её надо включить (не очень сложно, но таких мелочей — вагон и маленькая тележка). И ни один из Layout Manager'ов мне не понравился, но есть сторонние, удобство на "4".
Зато продуманный язык, продуманный SDK, ничего не ломается от версии к версии, собираю Ant'ом с совместимостью с древноватым JRE 1.6, включаю внутрь инсталлера JRE и всё работает везде. Для особых хардкорщиков можно использовать JRE 1.5, тогда будет работать вообще везде (хотя я не могу представить, что это должна быть за конфигурация).
Но... кроссплатформенность не нужна. По крайней мере у меня Windows опрежает Линукс в разы.
Здравствуйте, Khimik, Вы писали:
K>Извиняюсь если вопрос профанский.
Что касается шаровары — писать надо на том, чем лучше всего владеешь. Тут у некоторых приносящий деньги софт вообще на D7 написан. На BoS есть тётенька, которая макросы на VBA продаёт.
Я раньше писал шаровару на Delphi 7, до сих пор есть пара живых проектов на Delphi 2007.
Но новые проекты начинаю на C#. Хотя сейчас думаю что хорошо бы начинать их на чем-нибудь кроссплатформенном типа Java.
А так, для винды — конечно C# — быстро и удобно.
Здравствуйте, Nonmanual Worker, Вы писали:
NW>Здравствуйте, Khimik, Вы писали:
NW>Я раньше писал шаровару на Delphi 7, до сих пор есть пара живых проектов на Delphi 2007. NW>Но новые проекты начинаю на C#. Хотя сейчас думаю что хорошо бы начинать их на чем-нибудь кроссплатформенном типа Java. NW>А так, для винды — конечно C# — быстро и удобно.
Для некоторых проектов сейчас C# более кросс-платформенный, чем Java
Десктопный Windows, Windows Store и Windows Phone нативно + Mac, iOs и Андроид на Xamarin
Здравствуйте, Khimik, Вы писали:
K> Извиняюсь если вопрос профанский.
Нормальный вопрос.
Подходи к нему прагматично. Если цель просто переписать на чем-то новом, то ничего не трогай. Разве тебе это принесет какой-то доход?
Если цель выйти на другие платформы, то действительно попробуй Qt. Не думаю, что это будет так сложно изучить, в наш-то век, где все уже отвечено на stackoverflow
Здравствуйте, Khimik, Вы писали:
K>Я пробую перевести мою Delphi-программу с VCL на Firemonkey, уже столкнулся с кучей проблем, и подозреваю что успешного результата так и не будет. Если не ошибаюсь, последняя Delphi скомпилирована с VCL, а не Firemonkey, так что естественно с последним должно быть полно багов и проблем. А если Windows умрёт, а Embarcadero так и не осилят перевод всего на Firemonkey и забросят Delphi? Я плохо представляю, на какую платформу тогда переводить мою программу: проект на C# слишком легко взломать, а C++ это древний ужас. Или я что-то вижу не так? Можно ли прогнозировать, что если Delphi умрёт, то наступит закат шаровары? Извиняюсь если вопрос профанский.
У нас сейчас проекты на Turbo Delphi 2006. Рассматривали переход на Firemonkey (XE5 вроде), но только за 2 часа поверхностного тестирования нашел 9 критических ошибок в интерфейсе — масса визуальных глюков — желтые пятная на TForm, синие пятна в TMemo, в High DPI видны стыки внутри контролов, тормоза. На Intel'е интерфейс мигает. Вообщем все очень криво написано. В XE6 все баги остались на месте. Жрет память. Решили не связываться. Решили перейти на Lazarus.
Здравствуйте, PeterOfLight, Вы писали:
POL> У нас сейчас проекты на Turbo Delphi 2006. Рассматривали переход на Firemonkey (XE5 вроде), ...Решили не связываться. POL> Решили перейти на Lazarus.
А вы его смотрели?
Я как-то поигрался с ним, те компоненты*, что в Delphi нормально работают из коробки, в Lazarus сначала их надо найти, скачать (нашлось в archive.org), скомпилировать, потом отловить баги -- с этим последним я так и не справился — трудоемко оказалось.
А в Дельфи работало из коробки. Вообще для меня смысла не нашел, так "портировать".
*) мне не отрисовка графики, а мне компоненты аудио нужно было
Вообще, тут правильно говорят — если работает и цель не лежит увеличить количество платформ... как-то не хочется трогать.
Но вроде у Лазаруса даже не больше платформ.
На Lazarus мы мигрируем из-за кросс-платформенности. Нужна Mac версия.
Мы не будем использовать LCL/VCL — мы практически закончили свою систему контролов, чем-то похожую на Firemonkey, только проще и стабильнее. Она нам также нужна для написания сложных контролов.
С Pascal пока уходить не хотим. А Firemonkey поражает количеством багов. Поэтому пришлось делать свое решение. Много своих старых наработок.
Если бы я был С++ программистом, то сейчас перешел бы на Qt — вроде замечателная и популярная кросс-платформенная среда.
Здравствуйте, cencio, Вы писали:
C>Здравствуйте, PeterOfLight, Вы писали:
POL>>Если бы я был С++ программистом, то сейчас перешел бы на Qt — вроде замечателная и популярная кросс-платформенная среда.
C>неужели перейти на Qt сложней чем написать кучу своих контролов? Qt он в принципе даже проще чем "современный С++"
Исходники сложного профессионального продукта, результат 12-ти летней работы нескольких человек. Я не представляю как это переписать в разумные сроки.
K>>Я плохо представляю, на какую платформу тогда переводить мою программу: проект на C# слишком легко взломать, а C++ это древний ужас.
V>Откройте для себя Qt.
писал большие проекты на Qt. В 5й версии ещё больше запутали со сборкой. Но это не самое главное, страшно, что всегда где-то что-то то не работает или ломается, сторонних компонентов ноль.
Возможность компилировать под разные платформы — ещё та реклама. В одном проекте вообще пришлось отказаться от мак версии, так как соотношение времени на разработку под две платформы, исправление ошибок и тестирование под две платформы одновременно было несоизмеримо высоким. UI получается везде не совсем нативный по поведению (UX) (это если на QWidget писать) и приходится использовать нативные вставки для каких-то вещей (например, показывать прогресс на таскбаре в пиктограмме программы под виндой или диалог открытия файлов и т.д).
Сейчас стандартный и красивый UI предлагают писать на QML, но компонентов тоже ноль. При этом, если захочется не тащить с собой исходники QML, а скомпилировать их, то придётся платить и постоянно, так как это опция платная и действует по подписке.
Самому же пытаться сделать аналог хотя бы такого http://www.almdev.com/ — это ж сколько времени уйдёт...
Здравствуйте, PeterOfLight, Вы писали:
POL>Исходники сложного профессионального продукта, результат 12-ти летней работы нескольких человек. Я не представляю как это переписать в разумные сроки.
Зачем?
Зачем обязательно нужен натив?
Все кого я знаю, работающих с маком, все без исключения пользуются виндовыми прогами.
Через параллель или вайн, не знаю.
Но пользуются.
У самого уже лет 8 головная машина линукс, хотя проф. разработчик для вин-платформы.
Нахрена козе баян, с этим переписыванием?
Если ваш софт немерянно крут, поставляйте свой софт с лицензией на виду.
Да хоть образы инсталл виртуалок.
ОЕМ версии намного дешевле.
Здравствуйте, Вертер, Вы писали:
В>Возможность компилировать под разные платформы — ещё та реклама. В одном проекте вообще пришлось отказаться от мак версии, так как соотношение времени на разработку под две платформы, исправление ошибок и тестирование под две платформы одновременно было несоизмеримо высоким.
Мы сделали на Qt единый GUI практически без нативных ставок под 3 платформы: Windows+OSX+Linux. Единственный момент наше ядро было написано на голом C++ со строками в UTF8, поэтому портирование под UNIX прошло вообще без проблем.
