c++.de :: Warum ist hier soooo wenig los?

wischmop2 Mitglied 18:52:00 04.08.2002 Titel:

Zitat:

Original erstellt von Shade Of Mine:
Schon mal probiert ein C++ Programm mit einem .NET Programm zu kombinieren?

Hmmm, damit hast Du vielleicht den Nagel auf den Kopf getroffen! Genau dieses Problem habe ich momentan, siehe [url] NET-Komponenten in native Programme einbinden [/url].

Zitat:

... Ich nicht, ich habs auch nicht vor, aber jetzt sag mal, was daran soviel einfacher sein soll als Java und C++!

Achja: Managed C++ != C++
Managed C++, VB.NET, etc sind ja keine ernst zu nehmenden Sprachen. .NET Programmiert man mit C#!

Ok, Managed C++ (heisst das so?) ist nicht C++. Und da liegt vielleicht auch schon die "Lösung" drin!

(Vorweg: all das habe ich noch nicht selber ausbrobiert, aber so soll es angeblich gehen...)
Man kann in VC++ dieses Managed und Unmanged C++ kombinieren. Wenn man eine Managed-C++ KLasse programmiert, dann soll man diese Klasse auch direkt in z.B. C# verwenden können. Ob das auch für Unmanged C++ gilt (also echtes C++) weiss ich nicht, wenn nicht wäre dieses Managed C++ als Wrapper nützlich, in dem man evtl. einfach ohne weitere Implementierung von der echten C++ Klasse ableitet.

So, oder so ähnlich soll es wohl gehen. In 3-4 Wochen werde ich mich damit beschäftigen müssen, dann kann ich mehr dazu sagen.

Momentan haben wir nämlich in unserer Firma das Problem, dass wir mit einer anderen Firma fusionieren. Dazu sollen auch 2 Programme nun zu einem gemacht werden. Das Problem: Unseres ist in C++ (speziell Borland C++ Builder), das von denen ist in APL programmiert. Wir müssen auf Programmteile von denen zurückgreifen, die auf unsere. Unseren Code können wir zwar auch als DLL zur Verfügung stellen, die ihren aber nicht, die können nicht mal eine Adresse einer ihrer Funktionen bestimmen, ist halt APL, ne interpretierte Sprache.
Und deren Vorschlag war, dass wir gemeinsam auf NET umsteigen. Die können wohl in NET-Code übersetzen... Naja, und dann soll das angeblich wie oben beschrieben funktionieren.

Finde ich zwar voll "ätzend", aber wenn's wirklich damit "so einfach" funktioniert (bin aber auch noch etwas Skeptisch), dann hat für mich .NET schon einen gewaltigen Pluspunkt. Zumindestens finde ich dann das Konzept "theoretisch" genial (nein, ich hasse M$ trotzdem

). Das man dafür gleich alles nach .NET portieren muss und evtl. auf solche Ömmelsprachen wir ManagedC++ als Hilfsmittel zurückgreifen muss, gefällt mir nicht.
Deshalb wäre mir ein externes Einbinden von NET-Programmen durch ein instantiieren einer CLR schon deutlich lieber. Aber wie schon gesagt, in 3-4 Wochen muss ich mich wahrscheinlich damit beschäftigen :mad:

, momentan suche ich nach Argumenten, mit denen ich den restlichen Entwicklern dieses Vorgehen ausreden kann bzw. die mich auch davon überzeugen, dass der Weg völlig falsch ist.

So, aber nun ist hier doch gar nicht mehr soooo wenig los, oder

(auch wenn's inzwischen in "Rund um die Programmierung gehört")

Shade Of Mine Moderator 19:42:00 04.08.2002 Titel:

Zitat:

Original erstellt von wischmop2:
Man kann in VC++ dieses Managed und Unmanged C++ kombinieren. Wenn man eine Managed-C++ KLasse programmiert, dann soll man diese Klasse auch direkt in z.B. C# verwenden können.

Das wage ich zu bezweifeln. Denn dann koennte diese Klasse ja ein template sein. Und damit ist es nicht mehr .NET kompatibel. Oder man koennte in dem Unmanaged C++ andere Grenzen von .NET ueberschreiten... Auf jedenfall duerfte Unmanaged C++ Code nicht .NET kompatibel sein.

Prof84 Mitglied 19:48:00 04.08.2002 Titel:

@wischmop2
Tja, ich würde jetzt sagen:
Deine bisherige Argumentationskette war ein Knieschuss ...

O'Dog Mitglied 20:12:00 04.08.2002 Titel:

Zitat:

Original erstellt von wischmop2:
@O'Dog: Ich kann Dir zwar in dem Punkt zustimmen, dass Microsoft das NET-Framework sicherlich auch für den Markt der App-Server entwickelt hat, aber sicherlich nicht aussliesslich. Dann hätte demnach Sun und eben nicht Bea etc. das meiste Geld darin verdienen müssen - ist aber nicht so.

Na ja, SUN verkauft natürlich auch seine J2EE-Produkte (iPlanet-Server). Das Problem ist das sämtliche Spezifikationen seien es APIs für J2EE oder J2SE offen sind, d.h. das jeder Hersteller der diese Umsetzen will das auch tun kann.

Etwas zu spezifizieren und etwas zu implementieren sind zwei paar Schuhe wie wohl SUN erfahren musste. So sind die Lösungen von IBM und Bea in dem Bereich Marktführer.

Andererseits würde SUN ohne dieses Vorgehen keine industrieweite Unterstützung für die Java-Technologie haben, so wird auch der ganze Prozess der Spezifikation nicht allein von SUN getragen sondern im sogenannten Community Prozess entwickelt, wodran sich viele Firmen und Organisationen beteiligen.

Das .NET-Framework ist nur teilweise offengelegt und ist zudem mit Patenten überhäuft was es für andere Unternehmen nicht sehr attraktiv
macht. Siehe auch:

http://www.microsoft.com/germany/ms/windowsnetserver/
Wie Ballmer doch sagte:
"Das größte Wachstumspotenzial liegt nach Ballmers Einschätzung im Serverbereich. .NET, die neue Microsoft-Plattform für XML-Webdienste, die Informationen, Geräte und Anwender in einer einheitlichen und personalisierten Weise miteinander verbindet, beschreibt der Microsoft-Chef als Seele der derzeitigen Geschäftsaktivitäten"

MS hat mitlerweile auch das Internet entdeckt

und sieht für die nächsten Jahre eine vernetzte Welt mit einem .NET-Server als Mittelpunkt der zukünftigen Entwicklung. Alles drumherum seien es Mobile-Anwendungen oder andersartige Client bauen darauf auf.

O'Dog

O'Dog Mitglied 20:16:00 04.08.2002 Titel:

Ach so, fast vergessen

Zitat:

Original erstellt von wischmop2:
Naja und dann 1+1 = ?

2

O'Dog

rüdiger Moderator 21:08:00 04.08.2002 Titel:

Zitat:

Original erstellt von wischmop2:
Man kann in VC++ dieses Managed und Unmanged C++ kombinieren. Wenn man eine Managed-C++ KLasse programmiert, dann soll man diese Klasse auch direkt in z.B. C# verwenden können. Ob das auch für Unmanged C++ gilt (also echtes C++) weiss ich nicht, wenn nicht wäre dieses Managed C++ als Wrapper nützlich, in dem man evtl. einfach ohne weitere Implementierung von der echten C++ Klasse ableitet.

Da sieht man ja wie leicht das geht ;)

dotNET hat zu viele Fehler und mängel. Vieles existiert/funktioniert nut auf den lustigen Werbezetteln von Microsoft.

dotNET not yet

wischmop2 Mitglied 08:47:00 05.08.2002 Titel:

Hab mich nun mal ein wenig mehr in die Praxis von dotNET eingelesen. Wie's aussieht scheint das wohl doch nicht so einfach zu gehen, managed und unmanaged code zu vermischen, es hat mich zu beginn immer iritiert, dass die Beispiele die Endung "cpp" hatten, obwohl es dann doch Managed C++ war!
Zumindest demnach, was ich recherschiert habe, benötigt man dafür ähnliche Mechanismen, wie auch bei JAVA, nur das es sich hierbei um den bereits schon bekannten Ansatz von COM-Objekten handelt. Um Managed Code von einem Unmanaged Code aufzurufen, muss man wohl die mscoree.dll laden, in dieser dann mit der Funktion DllGetClassObject sich eine Referenz auf das Objekt geben lassen, etc.

Also doch nicht so einfach mit dem Kombinieren! Ich hab's nur so gehört und das wurde mir auch so als das revolutionäre an dotNET verkauft. Nun bin ich ja froh, dass es wirklich "nix anderes" wie Java ist.

Also: Wenn's sich nicht so einfach kombinieren lässt, und danach sieht es ja aus, dann nehme ich alles zurück und schliesse mich der allgemeinen Meinung an: ".NET ist Sch***** !"

Shade Of Mine Moderator 10:49:00 05.08.2002 Titel:

Zitat:

Original erstellt von wischmop2:
dann nehme ich alles zurück und schliesse mich der allgemeinen Meinung an: ".NET ist Sch***** !"

Ne, also das wuerde ich nicht sagen. Ich bin da eher Kingruedis Meinung: .NET ist noch nicht reif!

CMatt Mitglied 10:55:00 05.08.2002 Titel:

Zitat:

dotNET hat zu viele Fehler und mängel. Vieles existiert/funktioniert nut auf den lustigen Werbezetteln von Microsoft.

z.B ?

[ Dieser Beitrag wurde am 05.08.2002 um 10:56 Uhr von CMatt editiert. ]

rüdiger Moderator 11:10:00 05.08.2002 Titel:

Portabilität
Standardisierung
Verbreitung/Popularität
Sprach übergreifend (okay das funktioniert, aber auch nur mit anderen dotNET sprache, aber bald sollen ja COBOL usw. Compiler hinzukommen, mal schauen ob das auch krüppel Versionen der standardisierten Sprache sind)