Schule: Zinsrechnung in Borland C++
-
asc schrieb:
[Unabhängig davon sind die Borlandprodukte nicht mehr die aktuellesten...
cu AndréAbsolut falsch und sehr mutig von Dir.
Gruß
Freak C++ Borland
-
Freak C++ Borland schrieb:
Absolut falsch und sehr mutig von Dir.
Ich rede von Borland, nicht von Codegear oder Embacaderro.
(Und selbst letztere sind was den C++ Standard angeht noch ein gutes Stück von anderen aktuellen Compilern entfernt, auch wenn der Codegear C++ Builder 2009 etwas aufgeholt hat)
-
asc schrieb:
2. Borland C++ hat soviel mit C++/CLI zu tun, wie eine Kirsche mit einer Kokusnuss.
Du siehst da tatsächlich so wenig Gemeinsamkeiten?
Daß C++Builder-Fragen hier nichts zu suchen haben, sehe ich natürlich auch.
Aber die konzeptionelle Ähnlichkeit zwischen C++Builder und C++/CLI, eher noch Managed C++, sind doch eigentlich nicht zu übersehen, oder?
-
audacia schrieb:
Du siehst da tatsächlich so wenig Gemeinsamkeiten?
Ja.
audacia schrieb:
Aber die konzeptionelle Ähnlichkeit zwischen C++Builder und C++/CLI, eher noch Managed C++, sind doch eigentlich nicht zu übersehen, oder?
Für mich sind die Unterschiede groß genug um wie beim Vergleich Kirsche/Kokusnuss mich auf das Essbar zu beschränken. Es mag zwar im Konzept Ähnlichkeiten geben, die Syntax und die Art der Umsetzung unterscheiden sich IMHO aber gewaltig.
-
Wo sollen denn da die Gemeinsamkeiten sein ?
-
Zunächst dürfte unzweifelhaft sein, daß beim Entwurf von .NET vieles (neben Java) von Delphi und der VCL inspiriert war. Nicht umsonst war Anders Hejlsberg, der ursprüngliche Architekt von Delphi, einer der federführenden Entwickler von .NET und C#.
In beiden Fällen entschied man sich, das neuartige Objektmodell auch von C++ aus nutzbar zu machen und schuf einen Hybrid-Compiler, der sowohl das herkömmliche C++-Objektmodell als auch mittels Spracherweiterungen (property/__property, delegate/__closure, new/__declspec(hidesbase), finally/__finally, ...) dasjenige von Delphi bzw. .NET zugänglich machte. Dabei beschränken sich die Spracherweiterungen großenteils auf die "interface-level capabilities": weder C++Builder noch C++/CLI unterstützen den "syntactical sugar" von Delphi (COM-Integration, Class Helpers, anonyme Methoden, resourcestring) oder C# (partielle Klassen, anonyme Methoden, LINQ). Die sekundären Objektmodelle sind nicht kompatibel mit den nativen C++-Objektmodellen (d.h., gemischte Klassenhierarchien sind z.B. nicht möglich), aber einige C++-only-Features können auf die sekundären Objektmodelle angewandt werden (z.B. kann man Templates für VCL- oder managed-Klassen schreiben). Die sekundären Objektmodelle sind soweit als möglich an C++-Gewohnheiten angepaßt, jedoch behandelt der Compiler sie anders, z.B. generiert er ausführliche RTTI für sie.
Hinreichend viele Gemeinsamkeiten, um der Erwähnung wert zu sein, wie ich finde
-
Dieser Thread wurde von Moderator/in Jochen Kalmbach aus dem Forum C++/CLI mit .NET in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Das sehe ich aber nur als Gemeinsamkeit an, das man nen Apfel und ne Kokusnuss essen kann.
Die Konzeptionellen Ähnlichkeiten die Du hier anführst sind IMHO vom Standpunkt der eigentlichen Programmierung so weit weg bzw. so allgemein gehalten, dass sie bei der Konkreten arbeit nicht wirklich weiter helfen. Auf der Ebene bekommt man sicherlich auch ne menge anderes Zeug auf einen gemeinsamen Nenner.
-
Was erwartest du denn? Code-Sharing jenseits von Standard-C++?
Ich habe meine Äußerung ausführlich konkretisiert. Nun werde du mal konkreter.
-
Das von Knuddlbaer ist doch zu verstehen.
Du bist nicht in der Lage diesen 3 Zeiler zu verstehen, aber versuchst hier ein Referat über C++ zu halten, lächerlich.cu