Welche IDE außer dem Builder?
-
Jansen schrieb:
Zeus schrieb:
da Borland nach den erscheinen von C++ BuilderX alle Produktinformationen von C++Builder 6 von der Webseite genommen hat
http://www.borland.com/cbuilder/
Augen auf beim Eierkauf!
Haste wohl Tomaten auf dem Auge:
Wo ist der Link!
http://www.borland.com/products/
ein direkt Link kann ich auch eingeben in mein Web-Browser!Naja sie haben halt die Seiten nicht entfernt nur den LINK, halt faule Webmaster!
-
Zeus schrieb:
Haste wohl Tomaten auf dem Auge
Das wollte ich dich fragen ...
sie haben halt die Seiten nicht entfernt nur den LINK
... aber du hast es ja gerade noch selbst eingesehen.
Ansonsten empfehle ich dir dringend, mal die bisherigen, zahlreichen Beiträge zum Thema C++BuilderX, Zukunft der VCL etc. hier zu lesen, damit wir nicht alles widerkäuen müssen.
-
Irgendwie hast du keine Lust meine Frage zu beantworten!
-
Welche Frage?
"Wo ist der Link?" oder was? Keine Ahnung.
Ist hier ja auch nicht relevant, da du ursprünglich behauptet hattest, dass Borland alle Informationen zum BCB6 von der Website entfernt hätte. Was ganz offensichtlich nicht stimmt, also immer schön vorsichtig mit solchen verallgemeinernden Aussagen.
-
Anscheinend hat C++/VCL keine Zukunft, da Borland nach den erscheinen von C++ BuilderX alle Produktinformationen von C++Builder 6 von der Webseite genommen hat!Bleib bei meiner Aussage! Ich habe nie behauptet, dass Sie die Seiten entfernt haben.
Nur die Möglichkeit auf diese Seiten anzuzeigen!
-
Entschuldige bitte. Sie haben die Informationen also nicht von der Webseite entfernt sondern von der Webseite genommen. Das sind natürlich zwei völlig verschiedene Dinge, die jeweils eine komplett andere Bedeutung haben.
Ja klar.
die Möglichkeit auf diese Seiten anzuzeigen
http://www.borland.com/mobile/cbuilder/index.html unten links
http://www.borland.com/kylix/index.html dito
usw.Das kommt davon, wenn man ungenaue Aussagen macht. Z.B. mit "nach dem Erscheinen des C++BuilderX den Link zum BCB6 von der Produkte-Seite entfernt" hättest du dir das ganze Theater sparen können.
-
Das von ein Moderator wird mir zu blöd!
Falls ich irgendeine URL brauche komme ich zu dir!
-
Jansen schrieb:
murphy schrieb:
auch für linux gibt es bereits projekte die dotnet auf linux lauffähig machen werden
Selbst wenn Mono einmal richtig funktionieren sollte bleibt doch zu hoffen, dass es sich unter den Linux/Unix-Programmierern nicht durchsetzen wird.
Das hoffe ich auch.
.NET und C# sind doofJansen schrieb:
win32 [...] seit fast 20 jahren im einsatz
War nicht Win3.x das erste "32bit"-System von MS? Das gab's jedenfalls erst Anfang der 90er.
1. Das erste 32-Bit-Sytem vom Micro$oft war Windows 95.
2. vor 20 Jahren war grad mal Windows 1.03 draußen.Zur Frage:
VisualWx + wxWindows + MinGW =
-
Zeus schrieb:
Falls ich irgendeine URL brauche komme ich zu dir
Gern. Aber vorher bitte die FAQ und die Suchfunktion benutzen!
so_!@H schrieb:
Das erste 32-Bit-Sytem vom Micro$oft war Windows 95.
Und das war auch nur ein DOS-Aufsatz!
Aber ca. 1993 gab es schon WindowsNT (3.1), und das war von Anfang an 32bit.
Windows 1.0 erschien erst 1985, vor 20 Jahren war MS-DOS 2.0 aktuell.
http://members.fortunecity.com/pcmuseum/windows.htm
http://www.michael-prokop.at/computer/windows.html
-
hallo,
@zeus: ich brauche kein prophet zu sein um 1+1=2 zu berechnen!
du sagtest das der schwachpunkt der vcl wäre das er nicht in c++
geschrieben wurde. man könnte sowas wie die vcl überhaupt nicht
in standardisiertem c++ schreiben. oder glaubst du die leute von
borland haben die sprache der vcl per mi, ma, mau ausgesucht?
C# ist sehr nah an c++ angelegt, aber unterstüzt eben auch dinge
die benötigt werden um eben die von dir so propagandierte RAD-Um-
gebung überhaupt erst zu ermöglichen.
ich weiss dass man über sprachen nicht streiten braucht, das artet
immer in so eine art relitionskrig aus, aber man sollte sich doch
davor hüten immer gleich mit dem spruch "das ist doch ein scheiss"
über andere sprachen zu urteilen. und dotnet ist mitlerweile schon
in der zweiten runde, und hat wieder ein loch gestopft, es unterstüzt
nun auch eine art templates.
managed c++ (visual c++.net) ist nur eine übergangsgeschichte, auf
kurz oder lang wird sich dies nicht halten können genauso wenig
wie die mfc...der prophet
murphy
-
murphy schrieb:
hallo,
@zeus: ich brauche kein prophet zu sein um 1+1=2 zu berechnen!
Sinnloser Satz, ich bin andere Meinung, deswegen kann ich also nicht 1+1 rechen!! Ja Toll!
murphy schrieb:
du sagtest das der schwachpunkt der vcl wäre das er nicht in c++
geschrieben wurde. man könnte sowas wie die vcl überhaupt nicht
in standardisiertem c++ schreiben. oder glaubst du die leute von
borland haben die sprache der vcl per mi, ma, mau ausgesucht?Die VCL würde in Object Pascal geschrieben, da diese Spache über Features Unterstützt die C++ nicht hat ist klar, dass man Sie nicht in ANSI C++ schreiben kann. Das selbe ist wenn ich ein Framework in C++ schrieben würde und nach Delphi tansportieren würde. Dann muss man Object Pascal erweitern.
murphy schrieb:
C# ist sehr nah an c++ angelegt, aber unterstüzt eben auch dinge
die benötigt werden um eben die von dir so propagandierte RAD-Um-
gebung überhaupt erst zu ermöglichen.Von der Syntax sind sie sich ähnlich, aber nicht von der Konzepte.
murphy schrieb:
ich weiss dass man über sprachen nicht streiten braucht, das artet
immer in so eine art relitionskrig aus, aber man sollte sich doch
davor hüten immer gleich mit dem spruch "das ist doch ein scheiss"
über andere sprachen zu urteilen.Mach ich nicht! Professionale Entwickler entscheiden den Einsatz einer Sprache nach den Problem , der gestellt ist und nicht nach seine Lieblingssprache. Deswegen wird C/C++ nicht austerben.
murphy schrieb:
managed c++ (visual c++.net) ist nur eine übergangsgeschichte, auf
kurz oder lang wird sich dies nicht halten können genauso wenig
wie die mfc...managed c++ wird auch nicht aussterben, da .NET so ausgelegt ist, dass man mit jeder Objekt-orientierte Programmiersprache mit .NET arbeiten kann.
PHP.NET, VB.NET, C#, Managed C++, JAVA.NET und alle andere.
-
Warum C++/MFC nicht wegen C#/.NET aussterben wird!
Spieleprogrammierung
systemnahe Programmierung
Systemprogrammierung (es werden keine Treiber mit GC geben)
Programme, die allgemein effizient und sparsam programmiert werden mussen!MFC bietet Document/View-Architektur! Viele Programme haben diese Architektur!
-
hallo,
doc/view ist aber auch sehr eng mit mdi verbunden, und mdi wird kaum mehr eingesetzt...
mfg
murphy
-
murphy schrieb:
doc/view ist aber auch sehr eng mit mdi verbunden
Halte ich eher für ein Gerücht...
-junix
-
Zeus schrieb:
Warum C++/MFC nicht wegen C#/.NET aussterben wird!
Spieleprogrammierung
systemnahe Programmierung
Systemprogrammierung (es werden keine Treiber mit GC geben)
Programme, die allgemein effizient und sparsam programmiert werden mussen!MFC bietet Document/View-Architektur! Viele Programme haben diese Architektur!
Spieleprogrammierung: ich glaub mit der MFC komsmte da nicht weit.
Systemnahe Programmierung: Es soll nciht die Aufgabe eines Frameworks sein, systemnah zu sein (natürlich möglichst) aber nichts destotrotz sollte ein Framework das darunterliegende System möglichst abstrahieren. Dieser Punkt erfüllt die MFC definitv NICHT
Systemprogrammierung (Treiber): Auch hier wirst du kaum mit der MFC arbeiten, sondern eher mit der passenden System API. Ausserdem sind Treiber doch auch recht häufig in C verfasst.
Programme, die [...bla schwall schlagwortgehampel...]: Dann verzichtet man sowieso auf ein Framework da das grundsätzlich OVerhead mit sich bringt. Auch da ist die MFC fehl am Platz
Und Doc/View ist ebenfalls kein Argument für die MFC. Das kann jedes andere Framework auch oder es lässt sich bequem "nachrüsten" (siehe meinen Doc/View mit VCL Artikel)....das nur so by the way...
-junix
-
Welche Aufgabe hat ein Framework?
-
junix schrieb:
Spieleprogrammierung: ich glaub mit der MFC komsmte da nicht weit.
Systemnahe Programmierung: Es soll nciht die Aufgabe eines Frameworks sein, systemnah zu sein (natürlich möglichst) aber nichts destotrotz sollte ein Framework das darunterliegende System möglichst abstrahieren. Dieser Punkt erfüllt die MFC definitv NICHT
Systemprogrammierung (Treiber): Auch hier wirst du kaum mit der MFC arbeiten, sondern eher mit der passenden System API. Ausserdem sind Treiber doch auch recht häufig in C verfasst.
Programme, die [...bla schwall schlagwortgehampel...]: Dann verzichtet man sowieso auf ein Framework da das grundsätzlich OVerhead mit sich bringt. Auch da ist die MFC fehl am Platz
Und Doc/View ist ebenfalls kein Argument für die MFC. Das kann jedes andere Framework auch oder es lässt sich bequem "nachrüsten" (siehe meinen Doc/View mit VCL Artikel)....das nur so by the way...
-junix
Entschulidung für meine unpräzise Aussage ich meinte:
C/C++ WinAPI/MFC/ATL/VCL/Directx SDK und Co.
-
junix schrieb:
Und Doc/View ist ebenfalls kein Argument für die MFC. Das kann jedes andere Framework auch oder es lässt sich bequem "nachrüsten" (siehe meinen Doc/View mit VCL Artikel).
Wo ist der Artikel?
-
Zeus schrieb:
Welche Aufgabe hat ein Framework?
Abstraktion einer API und Vereinfachung des Handlings derselben.
(Was z.B. die MFC nicht wirklich erfüllt)
Zeus schrieb:
Wo ist der Artikel?
Noch nicht ganz fertig und daher nur halb publik:
http://www.junix.ch/bcb/help/doc_view/
Wer einen alten BCB hat, der sollte eine neue Anwendung erstellen mit dem selben Namen und die Projektdateien (ausser BPR) überscheiben. Anschliessend alle Dateien dem Projekt hinzufügen.
Anregungen etc. sind willkommen.
-junix
-
junix schrieb:
Zeus schrieb:
Welche Aufgabe hat ein Framework?
Abstraktion einer API und Vereinfachung des Handlings derselben.
(Was z.B. die MFC nicht wirklich erfüllt)
-junixStimmt MFC wird nicht als Framework bezeichnet! Dennoch scheint MFC leider eine Zukunft zu haben, die Borland mit der VCL im C++ Bereich nicht zu haben scheint!