БЛин, а почему поддерживает только линукс и солярку?
А где HPUX?

HP-UX - гавно! Как и все, что HP делает.

http://www.borland.com/cbuilderx/tour/C++BuilderX%20Turbo%20Demo.htm

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

А так, поставил, пол-дня поигрался и в общем не впечатлился. Ничем не лучше VSlickEdit, ну разве что отладчик посимпатичнее сделан. А так, много чего не хватает. Да и эта первая версия оставляет ощущение недоделаности какой-то. Да и цена какая-то запредельная.

Хороший отладчик

Если хотите действительно хороший отладчик то смотрите CodeForge.

ну ни в отладчике его прелесть... а один проект на всём работает..

я загнал сырцы OpenGLной програмки под Linux, собрал с icc и gcc, потом проверил под Windows подгрузку png(на icc & cl), кое что подправив, и вернулся в Linux.

точно не скажу, может он и пойдёт под HP-UX - там только JDK надо версии 1.4.2.

>HP-UX - гавно! Как и все, что HP делает.
Слишком категорично, но в любом случае железо очень распростаненное.

2Dimentiy.

>А для нативного кода как и всегда - редактор ресурсов. Хотя я не могу сказать, что это прям неудобно. По привычке один фиг, а ресурсов меньше кушается чем с немеряными библиотеками. Намного причём.

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

2Dimentiy.

>Знаю я что такое managed и unmanaged код, но речь-то шла о нативном насколько я понимаю ещё нить разговора. Если же разговариваем про CLI, то какие сравнения с билдером? Вообще, какой .NET на linux.org.ru? ;-)))

Все правильно, речь шла о средстве разработки для создания "нативных" приложений на С++. Как раз программы написанные на С++ Builder из-за их медленной работы нельзя считать таковыми. В этом смысле код написаный на С++ для CLI и скомбинированный с unmanaged кодом будет работать гораздо быстрее и, соответственно, будет фактичеки существенно "нативнее". Конечно это криво, однако на данный момент ничего другого лучше нету (речь идет о средстве быстрой разработки графичеких приложений на С++, VS NET + MFC по понятным причинам к таковым не относится). И в Borland все это прекрасно понимают, поэтому и появился C++BuilderX. Хорошие компиляторы - сторонних производителей, поскольку сами приличный компилятор так и не смогли создать. Да это на самом деле и не нужно, поскольку хорошие уже давно имеются (intel, gcc, microsoft и т.п.). IDE у них вроде пока получались вмолне сносные, поэтому IDE свой. Осталась только хорошая библиотека визуальных компонентов. VCL - не пойдет, потому что написана на паскале и заточена под него. CLX (QT) - тоже не пойдет, потому что интерфейс графического приложения, чтобы оно не выглядело диким, должен соответствовать окружению. CLX в этом смысле подходит только для создания приложений под KDE. Поэтому выбрали самый легкий путь - библиотеку wxWindows. Ее скорее всего хорошо заточат под Windows, а под все остальное - как придется. Это предположение косвенно подтверждает то, что в текущей версии C++BuilderX графические компоненты имеются только в версии для Windows.

А по вопросу о связи NET и Linux - смотри проект Mono (www.go-mono.com).

> Все правильно, речь шла о средстве разработки для
> создания "нативных" приложений на С++.
...
> В этом смысле код написаный на С++ для CLI и скомбинированный с
> unmanaged кодом

Уважаемый, "нативный" код в данном контексте - это код для платформы Win32. Код для платформы .NET - это совсем другая песня.
Покажите мне .NET runtime для Windows ME хотя бы, тогда можно будет говорить. Да, WinME - та ещё бяка, но "случаи бывают разные".

> А по вопросу о связи NET и Linux - смотри проект Mono
> (www.go-mono.com).

Это известная штука, но таки .NET крепко гвоздями прибит к Win32, а особенно COM - и клоны никогда не будут иметь сопоставимую функциональность, имхо. Это не Java..

> Простейшая задача - создать диалоговое окно с изменяемыми
> размерами, и чтобы элементы управления подстраивались под размеры
> окна. Как решить такую задачу с помощью редактора ресурсов?

Если смотреть моё сообщение в контексте - я не защищаю редактор ресурсов, а как раз говорю, что для Win32-программирования (не dotnet) никаких серьёзных изменений не произошло. Не надо придираться к словам.

WinForms - это не .NET-специфичная вещь, а набор COM-объектов, и _можно_ было сделать такой же конструктор для Win32. Другое дело, что посчитали нецелесообразным, опять же лишний повод для разработчиков использовать dotnet. Так что _в_этом_аспекте_ тот же билдер - "лучше". Потому что позволяет делать то, чего VC не позволяет вообще (быстрое создание GUI для Win32). Другое дело, как он это позволяет.

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

? Dimentiy Ваши два последних сообщения показывают Ваш уровень знания предмета. .Net Framework можно установить на любую версию windows (включая Me и 98), за исключением Windows 95 (и 3.x) WinForms - это не набот COM-интерфейсов

2Dimentiy

>Уважаемый, "нативный" код в данном контексте - это код для платформы Win32. Код для платформы .NET - это совсем другая песня. Покажите мне .NET runtime для Windows ME хотя бы, тогда можно будет говорить. Да, WinME - та ещё бяка, но "случаи бывают разные".

Как уже правильно было замечено, программы написанные для платформы NET будут работать на всех версиях Windows, начиная с Windows 98. Ограничение тут только одно - писать и отлаживать такие программы можно только на Windows 2000 и выше. А что считать "нативным" кодом - это уже дело вкуса. Для меня лично более "нативный" код, это код который работае быстрее.

>Это известная штука, но таки .NET крепко гвоздями прибит к Win32, а особенно COM - и клоны никогда не будут иметь сопоставимую функциональность, имхо.

В том то все и дело, что платформа NET никак не привязана к COM. Приложения NET могут использовать объекты COM, эта возможность предусмотрена для совместимости со старыми приложениями, но это вовсе не обязательно. Лучшая иллюстрация этого положения - реализация в проекте Mono классов ADO.NET и ASP.NET. В частности в ADO.NET уже реализована поддержка следующих СУБД: IBM DB2 Universal Database, MySQL, Oracle, PostgreSQL, Microsoft SQL Server, SQL Lite, Sybase (www.go-mono.com/ado-net.html). Так что клоны NET Framework могут быть вполне функциональными. Единственное ограничение для клонов связано с использованием через интерфейс NET других приложений. Например под Linux нельзя будет из своих программ конструировать отчеты в MS Word или Exel, потому что нет версий Word и Exel под Linux. Но это ограничение относится и к программам на платформе Java.

>WinForms - это не .NET-специфичная вещь, а набор COM-объектов, и _можно_ было сделать такой же конструктор для Win32. Другое дело, что посчитали нецелесообразным, опять же лишний повод для разработчиков использовать dotnet.

С названием WinForms имеется некоторая путаница. Действительно есть такая библиотека COM-объектов, она поставляется с некоторыми продуктами Microsofs (MS Office, MS IE и т.п.). Однако она давно уже не развивается и присутствует в указанных продуктах только для совместимости. Помимо этого, название WinForms часто используют для именования библиотеки NET-классов Windows.Forms. С этим и связана путаница.

А по поводу создания конструктора "WinForms для Win32" что можно сказать? Интерфейс Win32 давно устарел и морально и физически. В любом случае нужна дополнительная прослойка.

>А по поводу создания конструктора "WinForms для Win32" что можно сказать? Интерфейс Win32 давно устарел и морально и физически. В любом случае нужна дополнительная прослойка.

Небольшое дополнение. Еще не нужно забывать, что сейчас достаточно интенсивно развиваются 64-разрядные аппаратные платформы: IA64 и AMD64. И соответственно под них затачиваются свои версии Windows. Кроме того имеется большой рынок мобильных устройств, для которых тоже нужет софт. Думаю, что в данной ситуации ставка на использование виртуальной машины NET является вполне оправданной.

Re:

> .Net Framework можно установить на любую версию windows (включая
> Me и 98), за исключением Windows 95 (и 3.x)

Посыпаю голову пеплом :) Действительно, можно. Я просто всегда SDK ставил и почему-то экстраполировал на Runtime....

> WinForms - это не набот COM-интерфейсов

Де-факто это обёртка вокруг соответствующих COM-объектов. Начиналось это всё добро как "Microsoft Forms X.Y Object Library".

Re:

> Еще не нужно забывать, что сейчас достаточно интенсивно
> развиваются 64-разрядные аппаратные платформы: IA64 и AMD64. И
> соответственно под них затачиваются свои версии Windows. Кроме
> того имеется большой рынок мобильных устройств, для которых тоже
> нужет софт. Думаю, что в данной ситуации ставка на использование
> виртуальной машины NET является вполне оправданной.

Всё так. Никто и не говорил что dotnet - это ерунда. Было бы это решение ерундой, не стало бы так быстро использоваться.

Просто изначально базар вообще про Builder был. А dotnet там ни при чём. Ну ни при чём, и всё тут! :)

>Просто изначально базар вообще про Builder был. А dotnet там ни при чём. Ну ни при чём, и всё тут! :)

Конечно не при чем. В свое время когда компания Netscape развалилась Microsoft со своим продуктом Internet Explorer тоже не причем была. А сейчас, когда компания Borland вдруг ни с того ни с сего начала напрягаться и лихорадочно создавать новое средство разработки - C++BuilderX, dotnet тоже ни при чем.

Просто если бармалеи ничего путного не смогут сделать из C++BuilderX, то придется вообще забыть про этот продукт, про все эти Builder`ры.

Чел, с тобой никто не спорит :)
Флейм начался с утверждения, что в VS.NET 2003 есть хорошие средства для визуального быстрого построения GUI для программеров на C++.
Я сказал, что это средство не для создания нативного кода, как тот же Builder. И я прав.
Ты сказал, что пофигу нативный код или не нативный если он работает так как надо и делает требуемое. И ты тоже совершенно прав.
Об чём спор-то?

> Просто если бармалеи ничего путного не смогут сделать из
> C++BuilderX, то придется вообще забыть про этот продукт, про все
> эти Builder`ры.

По-моему это по-любому, независимо от того сделают ли "путное" или нет. Потому что сделать путное, но выйти на рынок вторыми - это уже очень плохо. Да и какчество у них год от года..
Delphi for .NET ещё потягается.