@MaximKz

Добрый день.

Я давно программирую на Delphi и часто слышал про FireMonkey. Но раньше не было возможности вникнуть в эту “тему”, а сейчас появилось время изучить этот фреймворк, или хотя бы понять, для чего он нужен?
Буду признателен, если у кого-то есть опыт использования FireMonkey, и он поделится своими впечатлениями.

Спасибо.

Добавлено через 4 минуты
Мои же первые впечатления о FireMonkey немного противоречивые,
до сих пор не могу уловить сильные стороны этого фрейморка(чего нет в VCL).
Например, 3D-интерфейсы - это красиво, но в каких задачах используется эта “красота” ?

0

@MasterDread

"А в ответ тишина..."
Если с прошлого месяца тема висит пустая, то напрашивается вывод, что у FireMonkey нет опыта использования. Одноразовые програмки "Hello word!" - не в счет.
Не так давно, я лично интересовался вопросом FMX .... и вас ждет разочарование.

0

@Fulcrum_013

MaximKz, Для развешивания свистоперделок аля WPF только круче. Ну еще годна для 3D визуализации начального уровня счета по наукам. Но это больше актуально для С++ Builder чем для Delphi. Так же разроботка под мобильные платформы только через FMX, так что основное назначение таки свистоперделки.

1

@MaximKz

Fulcrum_013, спасибо за ответ.

т.е. FireMonkey можно сравнивать с известной WPF и даже считать, что FM лучше ?
Тогда это обнадеживает.

Блистающие кнопочки, это то, что показывает реклама. Но меня такая реклама скорее пугает(какая-то "детская" реклама)

Этот момент, пожалуйста подробней.
Я правильно понял, что у Delphi нет родных средств под мобильные платформы и они решили использовать стороннюю FMX?

0

@Fulcrum_013

НУ почему же стороннюю? Она в исходе была на дельфе разработана потом они ее купили и расширили под мобайл. Суть в том что для кросс-платформенной разработки главная проблема не в смене проца и т.п., это компиляторы научились разруливать еще в 70-е. Главная проблема в обертках API. Поэтому для кроссплатформы и понадобилась другая библиотека основанная на той же технологии. Т.е. если в VCL хендл окна и т.д. доступны, то в FMX это уже полностью под капотом потому что для разных осей это различно, а переделывать так в VCL - похоронить горы уже существующего под нее кода, при том что в сфере внутрикорпаративного софта свистопирделки нужны чуть менее чем никак. Поэтому просто добавили другую ветку библиотеки, растущую от того же TComponent с некоторыми компонентами-обертками подменяемыми в зависисмости от оси под которую компилится.
WinForms - это кастрированная по самые немогу VCL. Исходное название проекта - С# Builder который в исходе предназначался на замену Visual Basic. WPF - средство навешивания свистоперделок основанное на той же технологии.
Т.е. средства для непрофессиональны разрабов. Дельфа/Builder - это в общем то средства того же назначения только для профессиональной ниши.
Ну это скорее для манаджеров чем для разрабов. Им то тоже моск промывают свистоперделками WPF и они на блеск ведутся. А как бы то что к какой то более-менее масштабной разработке все эти WPF и т.п. со всеми этими архаичными GC и т.д. пригодны менее чем никак - ну откуда этим манаджерам понимать то?

1

@MaximKz

Спасибо за грамотный ответ.

Про FireMonkey в общих чертах многое прояснилось, остались лишь пару вопросов, по которым у меня сомнения:
1) кроме GUI у этой библиотеки(FireMonkey) есть другое предназначение? М.б. кроссплатформенные БД, или набор полезных классов(Списки, Коллекции, ...) ?
2) FireMonkey изначально библиотека одного программиста из Улан-Удэ. А после приобретения библиотеку привели в серьезный вид для профессиональной разработки?

Буду признателен, если поделитесь опытом..

0

@Fulcrum_013

MaximKz, Ну как бы визуальные компоненты GUI это 10% того что есть VCL. FMX добавляет эти же 10% только в кросплатформенно-свистоперделочном варианте плюс набор 3D компонет. Все остальное она пользует тоже самое что и VCL с адаптацией к реалиям кросплатформы. Т.е. к примеру ADO которе есть только в винде в FMX недоступен. А FireDAC имеющий то же назначение на месте.
Да именно так. При этом как подозреваю в исходе VCL тоже разработка одного программиста, в последствии расширяемая постоянно разрастающимся в штатах отделом.

Добавлено через 9 минут
Там в принципе нет ничего такого чтобы не осилил бы один человек в относительно небольшое время. Разве что в следствие отсутствия в паскале средств автоматического управления временем жизни и взаимосвязями объектов засовывание двунаправленного полу-атомата под капот получается слишком объемным.
С учетом того что отсутствие этих средств в библиотеке тормозит развитие С++ Builder и в крайней версии в синтаксис языка внесены изменения устраняющие препятствия к добавлению в язык средств аналогичных C++, и то что преподавание паскаля в универах свернули по всему миру примерно во второй половине 90-х, то по всей видимости жить дельфе осталось не долго. Постепенно завершат перевод разрабов на С++ Builder, который и так сильно затянулся (дельфа в исходе задумывалась как переходное средство).

0

@MasterDread

Уважаемый, вы шутите?
В RAD Studio язык программирования (C++ или Delphi) не играет НИКАКОЙ роли(это просто синтаксис команд). Что хорошего делфисты получат, когда поменяют синтаксис своих команд с "Pascal" на "Си" ? Ничего нового! Библиотеки те же, концепция та же... только вместо begin end теперь скобки { }

С точностью наоборот, за 22 года существования RAD Studio с братьями-близнецами(C++ Builder и Delphi), никто не увидел НИ ОДНОГО примера, где близнец C++ превосходит Delphi.
Близнец-"Delphi" выигрывает по всем позициям!

Вы все еще думаете, что: "завершат перевод разрабов на С++ Builder" ? .... Напрасно.

0

@Fulcrum_013

Играет и огромную. Разницы нет только между пасклем и "С с классами" (который очень долго называли С++). А превосходство средств управляемой автоматики С++ над полным отсутствием оных в пакале разительно. Библиотека же на дельфе ограничивает взаимодействие с ней со стороны С++ до уровня "С с классами", устаревшему к началу нулевых. Собственно это и есть тот негоразд который либа на дельфе вносит в билдер.
Везде там же где С++ превосходит паскаль. Кстати так о птичках ниши этих близнецов пересекаются довольно слабо. Дельфа в основном пользуется в системах исключительно СURD-направленности и там различий действительно найти трудно, потому что рукописного кода почти ноль.
А преимущества C++ Builder проявляются в задачах где основная обработка данных выполняется не разу не СУБД, но которым тоже необходим и GUI и доступ к СУБД. Причем чем сложнее предметная область тем сильнее превосходство С++.

Добавлено через 4 минуты
Хотя бы одну назовите?

0

@MaximKz

А что это такое?
Я раньше не слышал. Видать, безнадежно отстал :-(

0

@Fulcrum_013

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

Добавлено через 7 минут
Смартпоинтеры и т.д. Причем не столько искоробочные, сколько средства их создания, позволяющие очень просто создавать автоматику управления взаимосвязями и жизненным циклом объектов под любую предметную область/задачу. Т.е. все строится на автовызове деструктора при выходе объекта размещенного на стеке из скопа, автогенерации деструкторов и шаблонах позволяющих имитировать поведение объекта на стеке для объекта размещенного в куче. Т.е. по сути средства автоматической реакции на разрыв ссылки или удаление объекта, позволяющие создать средства автоматического разрыва взаимосвязей принудительно удаляемого объекта, и средства позволяющее автоматически уничтожать объекты потерявшие необходимый комплект взаимосвязей.
Т.е. современная, гораздо более совершенная, гибкая и эффективная, чем изобретенный в 59-ом для нужд ФП GC, технология автоматического управления жизненным циклом и взаимосвязями, предназначенная для реалий именно ООП.

0

@MasterDread

ну... //
Т.е. Вы ушли от конкретного вопроса(сравнение близнецов C++Builder и Delphi) и переключились на абстрактные возможности, малоиспользуемых диалектов C++ в других платформах(даже не назвали каких), и еще раскопали термин "Pascal". Современные разработчики Delphi никогда не слышали это термин, а язык программирования называется Delphi, со всеми современными возможностями: Generics(Обобщённое Программирование), Анонимные методы, RTTI: Динамическая идентификация типов, Автоматическое управление памятью, сериализация объектов, и т.д...
Любой Java и C++ программист при упоминании "виртуальных конструкторов" в Delphi впадает в ступор. А узнав, что студент без опыта реализовал проект на Delphi в 5 раз быстрее, чем дяди на Java и C++ ... тут начинаются жалобы. Ой, мы много лет ждем и надеемся, что Delphi(от малюсенькой фирмы) не выдержит конкуренции мировых гигантов MS и Google. А надежды все не сбываются.
Уже целых 22 года в RAD Studio совместно существуют два близнеца C++Builder и Delphi. И большинство программистов выбирают begin end вместо скобок { }
...
А теперь, как и в прошлый раз, Вы сделайте вид, что не заметили и переведите разговор в другую тему.
Вперед.

0

@D1973

	Комментарий модератора
	Fulcrum_013, MasterDread, не надо превращать тематический раздел в очередной холивар!!! По теме высказались - хорошо, остальное - тут! По предупреждению!

0

@Fulcrum_013

Бред сивой кобылы. У нас в группе к примеру из 25 человек begin-end выбрал только один и тот потому что комп билдер не тянул вообще, а дельфу кое-как осиливал.
Я вообще о стандартных возможностях С++ которые были в нем в исходе и полностью поддерживаются С++ Builder (а он как бе и 17-ый стандарт поддерживает). Только до конца 90-х практически никто не понимал как их использовать и пользовали преимущественно "С с классами", да и сейчас мало кто понимает. А вы о чем?

Добавлено через 6 минут
Ну эта малюсенькая фирма имеет договоры о разделе сфер влияния с мелкомягкими еще с 80-х и мелкомягкие к ней бегут ежели что надумают в духе визуальной разработки. Только вот не забывайте что и в производителях компиляторов С++ эта фирма одна из трех мировых лидеров, во всяком случае под винды. И давно устаревшая дельфа им как то тоже не очень. Тогда вынуждены были - они на рынке паскаля монополистами были. А сейчас паскаль абсолютно устарел, после того как разобрались на что плюсовая автоматика способна. ТАк что тянуть за уши дельфу до уровня плюсов в общем не комильфо хотя и приходится. Ее если до ума довести плюсы получатся. Поэтому зачем изобретать лисапет если полный переход профессиональной части индустрии на C++ начался 25 лет назад? А непрофессиональной мелочью действительно пусть мелкаярыбешка типа мелкомягких и гуглов кормятся.

0

@Евгений Стронг

Как вообще можно убогий C++ сравнивать с простым и понятным Delphi? Впервые вижу подобное "сравнение". Или вы умеете выводить Hello world на С++ и теперь его везде хвалите? Порог входа совершенно разный. Сегодня важно делать быстро, удобно и с наименьшим количеством ошибок. Уже рынок захватывает визуальное программирование, где программист тратит время на логику приложения, а не на тонны кода (и это правильно). Delphi в этом направлении крайне близок к идеалу, в отличии от той же несчастной связки C#+WPF. Про плюсы вообще промолчу. низкоуровневое программирования для железа - да. И то не лучший выбор. А про все остальное и писать смысла нет.

0

@D1973

	Комментарий модератора
	Евгений Стронг, я, кажется, уже предупреждал о недопустимости продолжения холивара? Да, предупреждал! Вот и не обижайтесь.

0

@hhtest1000

Смотря для чего вам нужен firemonkey, имхо для мобилок под делфи нет ничего лучше fgx native,
а обезьяна нужна только для кроссплатформености, опять же имхо.
Короче очередной холивар на тему, нужен делфи или нет. Если он не нужен, шуруйте в питонисты или куда вам там блогеры советуют. Каждой задаче свой инструмент!

0

@Beltar

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

Вопрос такой, у меня завелся планшет под Win10, стоит ли для кодинга под него использовать FMX? Свистелки и 3D-эффекты мне неинтересны, но могут быть интересны контролы, рассчитанные именно на то, чтобы тыкать в них пальцем. Стандартные виндовые как бы целиком завязаны на мышь. (опыта разработки хоть чего-то мобильного у меня нет, впрочем, я и, как пользователь в смартфонах не особо понимаю)

Так же есть ли литература о разработке компонентов под FMX? Будет грустно, если я не смогу, например, ни задействовать свои компоненты для построения графиков, сделанные под VCL, ни переделать под FMX.

0

@krapotkin

лучше завести отдельную тему

0