Akella, 


Нет не видел. Сейчас посмотрел, я так понял это наборы дополнительных компонент для .NET и VCL.
У них есть небольшая возможность кастомизации внешности, но это так - "бонус", основная фишка - функционал.

Если говорить о внешности, то ИМХО тут лидер .NET со своим WPF,  а догоняет как раз Java с JavaFX  (пока, не до конца кросплатформенным :-( )




Подозреваю, что лучше не пробовать.  

Но требования программистов  "хотим кросплатформенную Delphi"  заставят embarcadero сделать что-то подобное (Delphi под QT  или GTK) и я сильно сомневаюсь, что первые версии будут лучше. Хотя, вероятней всего, они будут говорить "хотите кросплатформенность? у нас есть призм", назвать который кросплатформенным можно с трудом, но все же лучше чем ничего. 


Это сообщение отредактировал(а) Vasay - 10.5.2009, 03:30

конечно х64.
Если начать работать под линухой но в вин64 работать в "матрице" то это будет поддержка полутора платформ, а не двух

- проголосовал за кросплатформенность, ибо уже многократно поддерживал эту идею.
- моно, .НЕТ и ява это, ИМХО, не судите строго, обычные кривые костыли. и если ява достаточно развилась, то моно, как отдельно, так и в составе Delphi Prism ну никак не тянет на здравую кросплатформенность.
- считаю, что компилятор чего бы то ни было должен быть родным для платформы поэтому щас вплотную интересуюсь Qt. тем ни мение, Qt это не панацея - с точки зрения общения с операционкой и железом она на данный момент тощая. хотя, как плюс, туда можно сувать платформозависимые куски кода, выполняя тот или иной в зависимости от текущей операционки, если я ничего не поптал.

по сути тема кросплатформенности до сих пор остается непаханным полем, и смысла нет "просить кросплатформенности". откуда ей взяться?
сначала надо подумать над реализацией... 
зачем превращать могучий дельфи в жалкого клона существующих вялых технологий?

Угу.

Добавлено через 42 секунды
Дело не в том, что Dev поддерживают темы, у них Native стиль знаачительно привлекательнее, чем у джавы.

Добавлено через 2 минуты и 24 секунды

но почему бы не возобновить clx из D7?

Насколько я знаю, clx впервые появилась в Kylix.

ИМХО, игра не стоит свеч - embarcadero просто не потянет свою кросплатформенную либу. Да и зачем, когда можно использовать, например, QT, с ее обновленной лицензией.

Я так подумал - сделай они  VCL под QT, даже без pascal, какой-нибудь QT Builder - найдется достаточно желающих за это заплатить. 


CompWorm, 


Это легко осуществимо, когда речь идет об open source - дайте человеку исходник и он скомпилит это под свою платформу.

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



Это не костыль - это выход. Вам достаточно иметь .net framework (или JVM) под вашу платформу. И перед запуском приложение скомпилируется именно в код для вашего процессора (.net, кстати, сохраняет результат компиляции в системе), напрямую задействовав полный набор команд, а не работая на наборе команд Pentium  (половина которого ваш процессор еще и эмулирует), так как поставщик ПО скомпилировал свою программу именно под Pentium.

Будущее за этим подходом. Компиляция в native для win-платформы скоро уйдет в прошлое.

Какая разница под какой процессор откомпилирован код. Потребителя интересуют потребительские качества, а не используемые технологии. Если это бухгалтерия, совершенно без разницы под что там скомпилировано. Если это высокопроизводительные вычисления, это не будет VM.

так, это что-то хитрое ты написал для моего мозга.
поясни, если я тебе щас исходник дельфовый дам... от чистого сердца! ты мне его на БСД скомпилишь?
по поводу платформ... неужели так сложно ембаргодере написать компилятор для мака, линукса итп? да, такие проги НЕ будут кросплатформенными, однако не надо будет учить разные языки под разные платформы, и это, я считаю - плюс! если помимо компилятора допишут небольшой хвостик на подобии Qt - так ваще маза!

ну и вещь, которую я никогда не понимал (прошу не липить мне много минусов   ) - невероятное рвение открыть свой код всем желающим... сколько ни читал статей, так и не проникся этой идеей. вот написал я сложный вычислительный комплекс... и такая хитрая штука нужна всего-то 20 крупным заводам. они готовы купить по 50 штук $ копию. 
... и вот я открываю код, выкладываю его в интернет... а вот дальше я не улавливаю, с чего бы мне прибыль получить? программа считает, поддержка нафиг не нужна никому...



соглашусь с

скорость этих костылей на порядок ниже. для расчетных программ не годится.



будущее за деньгами.

CompWorm, 



Вообще-то я имел ввиду аппаратную платформу - x86, AMD64, IA-64....

Понятно, что под BSD не скомпилю - так как там код зависит от API windows, а вот под windows IA-64, почему бы и нет? 

Кстати, почему в начале десятилетия провалилась идея перевести десктопы на IA-64? Да потому что перекомпилировать свои программы никто не хотел, а встроенный в первую версию itanium-а эмулятор x86 был жутко тормозным.

Разработанная  AMD - AMD64 (позже лицензированная intel-ом и переименованная в Intel 64) оказалась более терпима к приложениям скомпилированным под x86. Но чего это стоило! Рекомендую почитать сколько костылей пришлось сделать, чтоб не повторить судьбу  IA-64 - http://ru.wikipedia.org/wiki/EM64T

Недавно видел тесты - сравнение производительности софта скомпиленного под х86 и AMD64, на соответствующих версиямх linux и одном и том же железе (маке с интеловским процессором). х86 уступил во всем, на некоторых операциях уступал до 40%.  

Кстати, сейчас существует достаточное количество процессоров не совместимых с x86. Как сверхмощных - тот же IA-64, различные версии SPARC, так и ультрадешевых - типа ARM Cortex-A8 на котором, вроде как существуют нетбуки.

И даже если под такой процессор будет windows (например под IA-64 он есть), то приложение скомпиленное под х86 там работать не будет! или будет но через программный эмулятор (ясно, что не очень быстро)


Надеюсь, я достаточно развернуто ответил на вопрос 
 

Теперь о .NET 

Приложение компилируется в промежуточный платформонезависимый код. Для того что бы запустить это приложение на новом процессоре нужно что бы MS под этот процессор выпустило windows и .NET framework, что, согласитесь проще, чем перекомпилировать под новый процессор все существующее ПО (блин, где x64 для делфи???). 

О производительности .NET

Насколько я знаю, при выполнении определенных условий, при первом запуске приложение написанное на .NET компилируется в исполняемый код процессора. Результат компиляции сохраняется в системе, при повторном запуске запускается уже этот код.

Так откуда приложение написанное, скажем, на делфи 7 и скомпиленное в набор инструкций для 32х разрядного пентиума, при запуске в 64х разрядном виндовс будет работать быстрее, чем .NET приложение которое при первом запуске благополучно скомпилировалось в родной 64х разрядный код?


п.с. ходят слухи, что windows 7 последняя OS от MS с поддержкой x86. Следующая ОS будет на базе проекта singularity, которая если и будет поддерживать х86, то только через программную эмуляцию.

п.п.с. Akella надеюсь, Вы не в обиде за такой отход от темы. 

чем проще? кому проще? производитель прикладного софта и так перекомпиляцией занимается все время.


возможно, оно не будет быстрее. вероятно, оно не будет быстрее на десяток процентов. наверняка реальная производительность человека, пользующегося этим софтом будет примерно такая же. 
смысл? я его вижу только для приложений, которые считают заметное время - для интерактивного приложения это от нескольких минут. что бы здесь улучшить производительность, необходимо оптимизировать алгоритмы и использовать специализированные (заточенные под конкретный проц) библиотеки. типа Intel MKL. только причем тут .NET   
получается, нам сватают "еще более производительный Word", который 95% времени простаивает в ожидании пользовательского ввода и еще 4% тратит на отображение красивостей

я не против дотнета, но не надо говорить что это наше все

какой ещё компилятор, если все дельфи программы работают на виндовых API и виндовых визуальных компонентах

Добавлено через 5 минут и 11 секунд

Нет, и в мыслях не было. Можно и на ТЫ. 

Добавлено через 5 минут и 30 секунд
Очень даже интересная информация и в тему!

весьма.


боюсь ошибиться, но в одной из версий, кажется 2007 или около того, была компиляция .Net х64... правда, не нативная... там еще ман прилагался, типа "как правильно программировать для х64"... но это конечно не то.   



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



ИМХО, это проблема среды дельфи, а не языка паскакаля. и это был риторический вопрос   . смысл в том, что не сложно, но косвенные факторы не позволяют.

Мне хотелось бы кроссплотформенности, но не думаю, что  Эмбаркадеро пойдёт на такое, скорее всего мы увидим x64, т.к. эта  мечта поближе к реальности   

О-о! А сейчас есть в продаже 32 битные камни????  Да и вообще какая связь между сингулярити и x64?
Если что то и появится на базе сингулярити, то еще очень и очень не скоро, а компьютер который вы щас купите успеет превратится в динозавра. Да и MS пока больше ставит на Azure. 

Из соседней темы:
http://blog.marcocantu.com/blog/delphi_liv..._2_roadmap.html

Сначала:


а потом:

64 пока что мало кому нужно, редко в каких алгоритмах применяется, а вот линукс набирает популярность.