Von C++ nach C# - C++ (German)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

Von C++ nach C#
Goto page 1, 2, 3 Next

C++Talk.NET Forum Index -> C++ (German)

View previous topic :: View next topic

Author

Message

Martin Aupperle
Guest

Posted: Sat Mar 25, 2006 8:06 pm Post subject: Von C++ nach C#

Hallo, es gibt ja ausreichend Lobpreisungen für C#, verglichen mit C++. Mich würde mal interessieren, welche Erfahrungen denn nun tatsächlich gemacht wurden, nachdem man sich entschieden hat, zukünftig mit .NET zu arbeiten. - Bei neuen Projekten - Bei der Konvertierung von C++ zu C# Insbesondere auch negative Punkte, Probleme etc. sind interessant. Positives kann man im Netz ja ausreichend finden. Grüße - Martin -- de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Marcel Müller
Guest

Posted: Sun Mar 26, 2006 1:06 am Post subject: Re: Von C++ nach C#

Marcel,

Martin Aupperle schrieb:

Quote:

es gibt ja ausreichend Lobpreisungen für C#, verglichen mit C++. Mich
würde mal interessieren, welche Erfahrungen denn nun tatsächlich
gemacht wurden, nachdem man sich entschieden hat, zukünftig mit .NET
zu arbeiten.

- Bei neuen Projekten

Wir sind ganz zufrieden.

Quote:

- Bei der Konvertierung von C++ zu C#

Das ist i.A. kein vertretbarer Aufwand. Es sei denn ein beträchtlicher
Teil der C++-Features wurden nie genutzt.

Die wenigen Sachen die ich aus Gründen der Interoperatibilität portieren
musste, bedurften in einzelnen Punkten deutlicher konzeptioneller
Anpassungen, da sich bestimmte Muster/Vorgehensweisen unter C# nicht
sinnvoll abbilden lassen.

Quote:

Insbesondere auch negative Punkte, Probleme etc. sind interessant.

Ist halt Windows only. Und damit ist der vielleicht größte Nachteil,
dass man sinnvollerweise einen IIS braucht. (Ich weiß nicht, inwieweit
Mono mittlerweile ernst zu nehmen ist.)
So richtig 100% sauber laufen die IIS6 Kisten unter Last nicht. Naja,
nach einem Reboot ist alles wieder gut. :-)

Eigentlich ist es schade um C++. Seit ein paar Jahren sind endlich
halbwegs brauchbare Compiler in der Fläche verfügbar, die wirklich
saubere C++-Programme erlauben. Seitdem sind die typischen C++-Fehler
mit amoklaufenden Pointern sehr rar, wenn man sich an ein paar
Spielregeln hält. Aber gute C++-Programmierer zu bekommen, ist eine
Sache für sich. Die sinnvolle Einarbeitungszeit in C#/Java ist einfach
geringer. Ich vermute allerdings, dass sich das mit den Generics
schleichend ändern wird. Heute sind es nur die gesparten Downcasts, und
ein paar Compile-Time-Checks. Aber wenn erstmal Features wie partielle
Spezialisierungen und Lambda-Ausdrücke möglich und benutzt werden, ist
es vorbei mit der Einfachheit.

Marcel

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Boris Glawe
Guest

Posted: Sun Mar 26, 2006 9:06 pm Post subject: Re: Von C++ nach C#

Quote:

Insbesondere auch negative Punkte, Probleme etc. sind interessant.

Ist halt Windows only. Und damit ist der vielleicht größte Nachteil,
dass man sinnvollerweise einen IIS braucht. (Ich weiß nicht, inwieweit
Mono mittlerweile ernst zu nehmen ist.)
So richtig 100% sauber laufen die IIS6 Kisten unter Last nicht. Naja,
nach einem Reboot ist alles wieder gut. :-)

Sind solche Dinge nicht ein K.O. Kritierium?

..NET ist eine Einbahnstrasse mit Widerhaken. Die produktpolitischen Probleme
überwiegen eindeutig die paar Nachteile, die Java im Gegensatz zu C# hat. Wenn
ich tatsächlich managed Code brauche, dann eben Java.

Grüße Boris

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Daniel Weber
Guest

Posted: Sun Mar 26, 2006 10:10 pm Post subject: Re: Von C++ nach C#

Marcel Müller schrieb:

Quote:

So richtig 100% sauber laufen die IIS6 Kisten unter Last nicht.

OT: Das ist arg pauschalisiert, ich kenne durchaus belastete IIS 6
Maschinen, die nur bei Service-Packs oder wichtigen Hotfixes einen
Reboot wollen.

Quote:

Eigentlich ist es schade um C++.

Ich denke nicht, dass C# eine ernsthafte "Gefahr" für C++ darstellen
wird. Zum einen - wie Du schon sagst - weil man sich damit an Windows
kettet, zum anderen weil es bisher (so mein Eindruck) für große Projekte
nicht wirklich geeignet ist und weil es für viele Probleme fast schon zu
abstrakt ist.

Quote:

Die sinnvolle Einarbeitungszeit in C#/Java ist einfach geringer.

Wobei man sich damit auch Qualitätsprobleme vorprogrammiert: Wenn ich
mir da unsere Praktikanten ansehe, dann können davon zwar viele
rudimentäres Java, aber das Verständnis viele Abläufe (z.B.
Garbage-Collection) ist nicht da.

Solche Gimmicks sind zwar nette Features von Java/C#, aber IMO es
schadet nichts, wenn man sich schonmal in C++ selbst Gedanken um die
Speicherverwaltung machen musste.

Bye,
Daniel

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Richard
Guest

Posted: Sun Mar 26, 2006 10:30 pm Post subject: Re: Von C++ nach C#

Martin Aupperle wrote:

Quote:

Hallo,

es gibt ja ausreichend Lobpreisungen für C#, verglichen mit C++. Mich
würde mal interessieren, welche Erfahrungen denn nun tatsächlich
gemacht wurden, nachdem man sich entschieden hat, zukünftig mit .NET
zu arbeiten.

- Bei neuen Projekten

Kommt immer auf das Projekt an, aber es gibt halt Sachen die du in C#
nicht machen kannst. Außerdem ist C++ mit .NET und Windows.Forms auch ne
feine Sache

Quote:

- Bei der Konvertierung von C++ zu C#

Wieso sollte man eine in C++ geschriebene Anwendung nach C++
"konvertieren". Mann kann ja auch den alten Code in .NET weiternutzen
sofern man entsprechende Wrapper Klassen schreibt.

Quote:

Insbesondere auch negative Punkte, Probleme etc. sind interessant.
Positives kann man im Netz ja ausreichend finden.

a) Hoher Grundspeicherbedarf, selbst ne ganz einfache Anwendung(ein
leeres Windows.Forms Formular) benötigt gleichmal ca 15MB RAM

b) Framework muss installiert sein, für ne einfach Anwendung ziemlicher
Overhead

c) Kleine Unterschiede in den Framework Versionen, so dass es passieren
kann, dass du deine Anwendung bei einer neuen Frameworkversion schon
nicht mehr laufen lassen kannst. Ich hab da derzeit ne Anwendung, die
läuft unter 1.0 und 1.1 erfordert jedoch einer Änderung damit sie unter
2.0 lauffähig ist.

d) Geschwindigkeit, hier ein kleiner Vergleich:

http://www.programmersheaven.com/2/Art_CSharp_8

Quote:

Grüße - Martin

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Marcel Müller
Guest

Posted: Mon Mar 27, 2006 4:01 am Post subject: Re: Von C++ nach C#/.NET

Hallo,

jetzt wirds ziemlich OT. Ich leite mal um. Eine deutsche, unabhängige
..NET-Gruppe habe ich leider nicht gefunden.

Boris Glawe schrieb:

Quote:

Naja, von den Kunden hat eigentlich noch kaum einer etwas mitbekommen.
Höchtens dass mal eine Session unerwartet vorzeitig beendet wird. Aber
das äußert sich bei den besseren Programmen auch nur als "einmal länger
warten", da die besseren Applikationen mit automatischer
Session-Rekonstruktion arbeiten.
Ich denke das gehört alles eher in die Kategorie "Kinderkrankheiten von
Win2k3". Wir haben diesmal auch auf recht neue Technologie gesetzt. Ich
denke Win2k3 hat durchaus das Zeug dazu, ähnlich stabil oder sogar
besser als NT4 zu werden.

Ich denke ich meckere auf hohem Niveau. Unser Linux-Server liegt in der
Uptime-Liste auf Platz 3 und muss sich nur dem großen Datenbankserver
auf Platz 2 (übrigens MS-SQL) und einer Tandem mit NonStop-Kernel
geschlagen geben. Aber die muss man alle in Jahren messen.
Die Webapplikationsserver schaffen es im Moment vielleicht wenige
Monate. Aber das ist eben auch nicht so schlimm.

Quote:

.NET ist eine Einbahnstrasse mit Widerhaken. Die produktpolitischen
Probleme überwiegen eindeutig die paar Nachteile, die Java im Gegensatz
zu C# hat. Wenn ich tatsächlich managed Code brauche, dann eben Java.

Ja, das ist zwar richtig aber nur die halbe Wahrheit.

In der Sache geht es nicht um C# oder Java. Das ist völlig Banane. Die
Umschulung der Java-Leute auf C# war bei uns eine Sache von einigen
Tagen. Ich selbst kam von C++. Und da sowohl Java als auch C# im
wesentlichen eine Untermenge von C++ sind, war das auch kein
ernstzunehmendes Problem.

Der entscheidende Unterschied ist die zu .NET zugehörige
Klassenbibliothek für Webanwendungen. Und die kann sich wirklich sehen
lassen. Auch wenn es in der 1.1er Version noch ein paar Lücken gab.
Für die Entwicklung von Benutzerinterfaces ist das Konzepten wie JSP
weit voraus. Und es ist im besonderen auch kein Vergleich zu älteren
"Fallstudien" von M$, wie MFC - was ein Graus.

Und den Punkt können die oben genannten Nachteile nicht so einfach
aufwiegen. Natürlich spielt dei Historie des eigenen Unternehmens
bezogen auf M$ eine Rolle.

Natürlich gerät auch die Java-Front durch .NET unter Druck und da tut
sich auch schon etwas. Stand heute fährt man m.E. mit .NET ganz gut. Im
Backendbereich (ohne GUI) geht die Rechnung dagegen immernoch zugunsten
von Java aus.

Man sollte sich auch keiner allzugroßen Illusionen bezüglich der
vermeintlichen Unabhängigkeit von großen Firmen machen, wenn man .NET
meidet. Die nahezu alternativlosen Abhängigkeiten lauern an jeder Ecke.
Das fängt mit den Herstellern managebarer Server (Blades oder was auch
immer) an, geht mit dem Herstelern des jeweiligen SAN weiter,
Datenbankhesteller, Middleware und so weiter und so fort. Kein
Unternehmen kann es sich leisten auf jeder dieser Schienen mindestens
zweigleisig zu fahren.
Die Abhängigkeit mit .NET zu M$ ist also aus betriebswirtschaftlicher
Sicht eher eine ganz normale Sache als ein Ausnahmefall. Wenn
irgendeiner einer davon 180°-Wendung in seiner Produktpolitik hinlegt,
kommt man auch ins schwitzen. Lediglich als ganz kleine Firma oder
Privatman liegen die Kriterien anders.
Verglichen mit den knallharten Ellenbogenmethoden großer Softwarefirmen
wie SAP ist M$ übrigens schon fast eine "offene Community". Jene stellen
ihre Interessen weit über die der Kunden und verkaufen das, so es in
Konflikt zu den Kundeninteressen steht, den Ahnungslosen Managern auch
noch als neues, tolles Feature. Wie heißt es so schön: es wurde noch nie
jemand entlassen, weil er sich für SAP entschieden hat.

Ich denke, wenn man der Schlagzahl von .NET (1.0, 1.1, 2.0, 3.0) mit
hinreichend "Sicherheitsabstand" folgt, hat man durchaus Alternativen.
MONO wird sicher erwachsen. Ein Kooperationsunternehmen erstellt gerade
eine größere Applikation in MONO (ca. 500 Personentage). Mal sehen, was
da raus kommt. Ich glaube, sie sind ein wenig früh dran und werden für
den Traum der Unabhängigkeit noch ordentlich Lehrgeld bezahlen. Aber der
Tag wird kommen, an dem das nicht mehr so ist.

Marcel

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Martin Aupperle
Guest

Posted: Mon Mar 27, 2006 9:59 pm Post subject: Re: Von C++ nach C#

On Sat, 25 Mar 2006 21:33:31 +0100, =?ISO-8859-1?Q?Marcel_M=FCller?=
<news.5.maazl (AT) spamgourmet (DOT) com> wrote:

Quote:

- Bei der Konvertierung von C++ zu C#

Das ist i.A. kein vertretbarer Aufwand. Es sei denn ein beträchtlicher
Teil der C++-Features wurden nie genutzt.

Die wenigen Sachen die ich aus Gründen der Interoperatibilität portieren
musste, bedurften in einzelnen Punkten deutlicher konzeptioneller
Anpassungen, da sich bestimmte Muster/Vorgehensweisen unter C# nicht
sinnvoll abbilden lassen.

das interessiert mich. Könntest du einmal kurz erläutern,
1.) welche "konzeptionellen Anpassungen" notwendig waren
2.) welche Muster unter C++ sich nicht abbilden lassen?

Ich weiß natürlich, dass MI, templates und einiges andere in C# nicht
oder nicht vernünftig geht, so wie man es unter C++ gewohnt ist.
Meintest du das? Wenn ja, habe ich zumindest die Erfahrung gemacht,
dass es durchaus möglich ist, ohne MI und template-metaprogramming
auszukommen. Insbesondere wenn ich da so an den
Durchscnitts-Programmierer denke.

Quote:

Hmmm. Große Teile der Plattform sind doch standardisiert. Es sollte
technisch möglich sein, die Plattform z.B. auf UNIX bereitzustellen.
Dass Mono nicht schneller vorankommt, liegt einfach daran, dass es
außer ein paar Akademikern nur wenige interessiert. Wäre echter Bedarf
auf UNIX-Seite da. würde das auch schneller gehen.

Windows-only ist icht unbedingt ein Nachteil. Was kümmert mich was
anderes, wenn unsere Kinden alle Windows haben?

Quote:

Eigentlich ist es schade um C++. Seit ein paar Jahren sind endlich
halbwegs brauchbare Compiler in der Fläche verfügbar, die wirklich
saubere C++-Programme erlauben. Seitdem sind die typischen C++-Fehler
mit amoklaufenden Pointern sehr rar, wenn man sich an ein paar
Spielregeln hält. Aber gute C++-Programmierer zu bekommen, ist eine
Sache für sich. Die sinnvolle Einarbeitungszeit in C#/Java ist einfach
geringer. Ich vermute allerdings, dass sich das mit den Generics
schleichend ändern wird. Heute sind es nur die gesparten Downcasts, und
ein paar Compile-Time-Checks. Aber wenn erstmal Features wie partielle
Spezialisierungen und Lambda-Ausdrücke möglich und benutzt werden, ist
es vorbei mit der Einfachheit.

Genau. C# 3.0 hält ja Einiges in petto. Man sieht halt doch, dass
industrielle Softwareentwicklung einfach einer gewissen Komplexität
der Mittel bedarf.

Grüße - Martin

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Martin Aupperle
Guest

Posted: Mon Mar 27, 2006 10:06 pm Post subject: Re: Von C++ nach C#

On Sun, 26 Mar 2006 19:30:45 +0200, Richard <burj-al-arab (AT) gmx (DOT) de>
wrote:

Quote:

Kommt immer auf das Projekt an, aber es gibt halt Sachen die du in C#
nicht machen kannst.

Gib mal ein Beispiel aus der Praxis (also vielleicht jetzt nicht
gerade MI und template-metaprogramming)

Quote:

Außerdem ist C++ mit .NET und Windows.Forms auch ne
feine Sache

Na ja - die Syntax von C++/CLI finde ich gewöhnungsbedürftig. Aber
gehen tuts, das stimmt.

Quote:

Wieso sollte man eine in C++ geschriebene Anwendung nach C++
"konvertieren". Mann kann ja auch den alten Code in .NET weiternutzen
sofern man entsprechende Wrapper Klassen schreibt.

Nicht wirklich. Wir haben z.B. eine Anwendung, die sehr viel
Oberfläche hat (Eingabefelder, Liste etc.) Eingabeprüfungen, kleinere
Abläufe und vor allem Datebanbankzugriffe machen den Hauptteil des
Codes aus. Wie soll ich sowas wrappern? Der Aufwand wäre enorm. Und
was hätte ich erreicht? Ich hätte 10 bis 20 Jahre alten Code in das
neue System konserviert, und somit die Möglichkeiten für innovative
Lösungsmöglichkeiten verbaut. Nee - dann schon lieber gleich neu
hinschreiben.

Quote:

System auftriff. D.h. laufen mehrere .NET Komponenten, relativiert
sich das Argument. Schlimmer für mich ist z.B. die schlechte
Speicherausnutzung: Die Allokation sehr vieler kleiner Objekte ist
eine Katastrophe unter .NET (und BTW auch in Java).

Quote:

b) Framework muss installiert sein, für ne einfach Anwendung ziemlicher
Overhead

Na ja, ist in 5 Minuten ohne weiteren Benutzereingriff erledigt. C++
Programme brauchen auch ne Laufzeitbibliothek.

Quote:

Gilt übrigends nicht nur für das Framework selber, sondern auch für
alle anderen Komponenten: mehrere Versionen einer Komponenten können
nun endlich parallel und unabhängig voneinander vorhanden sien
(Stichpunkt: "DLL-Hell" )

Quote:

d) Geschwindigkeit, hier ein kleiner Vergleich:

http://www.programmersheaven.com/2/Art_CSharp_8

Lies das mal genauer. Beispiel: Der Code für das Sieb des Erathostenes

verwendet im Wesentlichen ganzzahlige Operationen und Array-Zugriffe.
Nun ist es aber so, dass arrays in C# "first class Objekte" sind,
incl. Indexprüfung etc. Im C++ Teil hat er natürlich nackte arrays
verwendet, also im wesentlichen rohe Speicherbereiche ohne
Zugriffsprüfung. Wenn also ein Großteil des Codes aus Feldzugriffen
besteht, ist doch klar, wer gewinnt.

Diese "Argumentation" erinnert mich an die - heute noch weit
verbreitete - Meinung, dass die C++ IOStreams aboluter Schrott sind,
da langsamer als printf. Beweis: Programm, das die Zahlen von 1 bis
1000 ausgibt, dauert mit Streams 10x so lang als mit printf.

Grüße - Martin

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Martin Aupperle
Guest

Posted: Mon Mar 27, 2006 10:06 pm Post subject: Re: Von C++ nach C#

On Sun, 26 Mar 2006 19:10:26 +0200, "Daniel Weber"
<spamtrap (AT) newsfeeder (DOT) dynfx.net> wrote:

Quote:

Wieso bist du zu dem Eindruck gekommen, dass C# für große Projekte
nicht so geeignet ist? (Wäre ganz wichtiger Punkt für mich - wir haben
definitiv ein großes Projekt, aber nur kleine Manpower).

BTW, ich denke auch, dass C# und C++ keine Gegensätze sind. C# wird
für C++ keine Gefahr darstellen. Es gibt immer Anwendungen, für die
eigentlich nur C++ in Frage kommt. Aber der Großteil der heute
anstehenden Programmierprojekte lassen sich mit .NET und C#
wahrscheinlich besser und schneller machen als mit traditionellem C++.

Ich kenne übrigends Leute, die schwören auf Cobol und machen damit
unglaubliche Sachen. Daraus leiten sie dann ab, dass man den ganzen
C++, Java und sonstigen Kram eigentlich gar nicht braucht. Diese
"Betriebsblindheit" sehe ich auch bei Leuten, die sich das C++ Mindset
über viele Jahre kultiviert haben.

Grüße - Martin

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Jakob Bieling
Guest

Posted: Tue Mar 28, 2006 2:10 pm Post subject: Re: Von C++ nach C#

Martin Aupperle <newsgroups (AT) PrimaProgramm (DOT) de> wrote:

Quote:

On Sun, 26 Mar 2006 19:30:45 +0200, Richard <burj-al-arab (AT) gmx (DOT) de
wrote:

b) Framework muss installiert sein, für ne einfach Anwendung
ziemlicher Overhead

Na ja, ist in 5 Minuten ohne weiteren Benutzereingriff erledigt. C++
Programme brauchen auch ne Laufzeitbibliothek.

Im Allgemeinen nicht. Es haengt von der Implementation ab, ob eine
Laufzeitbibliothek notwendig ist oder nicht.
--
jb

(reply address in rot13, unscramble first)

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Daniel Weber
Guest

Posted: Tue Mar 28, 2006 6:32 pm Post subject: Re: Von C++ nach C#

Martin Aupperle schrieb:

Quote:

Wieso bist du zu dem Eindruck gekommen, dass C# für große Projekte
nicht so geeignet ist?

Es erscheint mir zu unübersichtlich (verglichen mit C++) und die
Unübersichtlichkeit steigert sich stärker als die Projektgröße (also
z.B. Klassenzahl). Aber das ist eher ein subjektiver Eindruck. Für
kleine Komponenten hingegen komme ich damit zurecht.

Ein Weg wäre auch, das Backend in C++ umzusetzen und beim Frontend auf
C# zu setzen.

Quote:

BTW, ich denke auch, dass C# und C++ keine Gegensätze sind. C# wird
für C++ keine Gefahr darstellen. Es gibt immer Anwendungen, für die
eigentlich nur C++ in Frage kommt. Aber der Großteil der heute
anstehenden Programmierprojekte lassen sich mit .NET und C#
wahrscheinlich besser und schneller machen als mit traditionellem C++.

Schneller vielleicht ja, besser glaube ich nicht.

Quote:

Diese "Betriebsblindheit" sehe ich auch bei Leuten, die sich das C++
Mindset über viele Jahre kultiviert haben.

Hm, das mag sein.

Bye,
Daniel

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Gentoopower
Guest

Posted: Tue Mar 28, 2006 11:06 pm Post subject: Re: Von C++ nach C#

Martin Aupperle wrote:

Quote:

On Sun, 26 Mar 2006 19:30:45 +0200, Richard <burj-al-arab (AT) gmx (DOT) de
wrote:

Kommt immer auf das Projekt an, aber es gibt halt Sachen die du in C#
nicht machen kannst.

Gib mal ein Beispiel aus der Praxis (also vielleicht jetzt nicht
gerade MI und template-metaprogramming)

Ja glaubst du denn Templates werden in der Praxis nicht benutzt?
Ich meine eben genau damit Templates, die letzten 2 Projekte an denen
ich gearbeitet habe wären ohne Templates einfach nicht möglich gewesen.

Quote:

Außerdem ist C++ mit .NET und Windows.Forms auch ne
feine Sache

Na ja - die Syntax von C++/CLI finde ich gewöhnungsbedürftig. Aber
gehen tuts, das stimmt.

Bei welcher Visual Studio Version, bei der 2003 sieht ist die C++ Syntax
ganz normales C++ nur bei der 2005er siehts etwas komisch aus, aber auch
nur bei managed Code.

Quote:

Wieso sollte man eine in C++ geschriebene Anwendung nach C++
"konvertieren". Mann kann ja auch den alten Code in .NET weiternutzen
sofern man entsprechende Wrapper Klassen schreibt.

Nicht wirklich. Wir haben z.B. eine Anwendung, die sehr viel
Oberfläche hat (Eingabefelder, Liste etc.) Eingabeprüfungen, kleinere
Abläufe und vor allem Datebanbankzugriffe machen den Hauptteil des
Codes aus. Wie soll ich sowas wrappern? Der Aufwand wäre enorm. Und
was hätte ich erreicht? Ich hätte 10 bis 20 Jahre alten Code in das
neue System konserviert, und somit die Möglichkeiten für innovative
Lösungsmöglichkeiten verbaut. Nee - dann schon lieber gleich neu
hinschreiben.

Ja genauso sehe ich das auch. Wenn man ne riesen Anwendung hat wird die
entweder erweitert mit C++ oder neugeschrieben, aber in Einzelfällen
kann es durchaus sinnvoll sein, ne Wrapperklasse zu nutzen.

Quote:

a) Hoher Grundspeicherbedarf, selbst ne ganz einfache Anwendung(ein
leeres Windows.Forms Formular) benötigt gleichmal ca 15MB RAM

Stimmt schon. Man muss aber auch sehen, dass dieser nur einmalig pro
System auftriff. D.h. laufen mehrere .NET Komponenten, relativiert
sich das Argument. Schlimmer für mich ist z.B. die schlechte
Speicherausnutzung: Die Allokation sehr vieler kleiner Objekte ist
eine Katastrophe unter .NET (und BTW auch in Java).

b) Framework muss installiert sein, für ne einfach Anwendung ziemlicher
Overhead

Na ja, ist in 5 Minuten ohne weiteren Benutzereingriff erledigt. C++
Programme brauchen auch ne Laufzeitbibliothek.

Das meinst du jetzt nicht ernst oder?

Wo benötige ich denn z.B. ne Laufzeit Bibliothek, wenn ich mit dem
Borland C++ Builder ein Programm statisch kompiliere?

Quote:

c) Kleine Unterschiede in den Framework Versionen, so dass es passieren
kann, dass du deine Anwendung bei einer neuen Frameworkversion schon
nicht mehr laufen lassen kannst. Ich hab da derzeit ne Anwendung, die
läuft unter 1.0 und 1.1 erfordert jedoch einer Änderung damit sie unter
2.0 lauffähig ist.

Es ist möglich, 1.1 und 2.0 parallel zu haben. Überhaupt kein Problem.
Gilt übrigends nicht nur für das Framework selber, sondern auch für
alle anderen Komponenten: mehrere Versionen einer Komponenten können
nun endlich parallel und unabhängig voneinander vorhanden sien
(Stichpunkt: "DLL-Hell" )

Ja und du weist, wie groß ne Framework install ist:-)

Ich installiere dann für ein Programm das 5MB große ist 300MB an
Frameworks:-)

Quote:

d) Geschwindigkeit, hier ein kleiner Vergleich:

http://www.programmersheaven.com/2/Art_CSharp_8

Lies das mal genauer. Beispiel: Der Code für das Sieb des Erathostenes
verwendet im Wesentlichen ganzzahlige Operationen und Array-Zugriffe.

Ja und lies mal den Rest der Tests:-)

Quote:

Nun ist es aber so, dass arrays in C# "first class Objekte" sind,
incl. Indexprüfung etc. Im C++ Teil hat er natürlich nackte arrays
verwendet, also im wesentlichen rohe Speicherbereiche ohne
Zugriffsprüfung. Wenn also ein Großteil des Codes aus Feldzugriffen
besteht, ist doch klar, wer gewinnt.

Diese "Argumentation" erinnert mich an die - heute noch weit
verbreitete - Meinung, dass die C++ IOStreams aboluter Schrott sind,
da langsamer als printf. Beweis: Programm, das die Zahlen von 1 bis
1000 ausgibt, dauert mit Streams 10x so lang als mit printf.

Deine Argumentation lässt den Schluss zu, dass du ein C# Fanboy bist mit
wenig C++ Ahnung/Erfahrung.

Ich benütze auch oft und gerne C# aber nur dann wenn die Anforderungen
es erlauben.

Quote:

Grüße - Martin

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Marcel Müller
Guest

Posted: Wed Mar 29, 2006 3:06 pm Post subject: Re: Von C++ nach C#

Hallo,

Martin Aupperle schrieb:

Quote:

On Sat, 25 Mar 2006 21:33:31 +0100, =?ISO-8859-1?Q?Marcel_M=FCller?=
news.5.maazl (AT) spamgourmet (DOT) com> wrote:

Die wenigen Sachen die ich aus Gründen der Interoperatibilität portieren
musste, bedurften in einzelnen Punkten deutlicher konzeptioneller
Anpassungen, da sich bestimmte Muster/Vorgehensweisen unter C# nicht
sinnvoll abbilden lassen.

das interessiert mich. Könntest du einmal kurz erläutern,
1.) welche "konzeptionellen Anpassungen" notwendig waren
2.) welche Muster unter C++ sich nicht abbilden lassen?

Ich weiß natürlich, dass MI, templates und einiges andere in C# nicht
oder nicht vernünftig geht, so wie man es unter C++ gewohnt ist.
Meintest du das? Wenn ja, habe ich zumindest die Erfahrung gemacht,
dass es durchaus möglich ist, ohne MI und template-metaprogramming
auszukommen.

Ja, das stimmt. Aber es kann Aufwand sein.

Ich nenne mal ein paar Punkte am Beispiel eines Projekts.
Also, es geht um ein Framework zur Ereignis (Fehler-) Protokollierung
und -Bearbeitung. Das Framework ist Multi-Language (C++, Java, C#,
demnächst ABAP Object) und Multi-Platform (in Grenzen).

Die elementaren Komponenten sind Events (im Code per einzeiler
generierte Ereignisse) und EventHandler, die irgendwas damit machen.

Beispiel 1: Template, nicht durch Casts ersetzbar.

Da gibt es u.a. Klassen, die Events einfach in Logfiles schreiben.
Natürlich sind die alle Thread-Safe. Aber das genügt nicht immer.
Manchmal müssen auch parallele Instanzen eines Prozesses atomar in /ein/
Logfile schreiben.

Logischer Klassenbaum:
abstract class EventHandler
+- class EventLog (Logfile)
| +- class ChangingEventLogBase (zeitlich rotierendes Logfile)
| +- class DailyEventLog (täglich rotierendes Logfile)
| +- ...
+- class EventLogMT (Logfile, Multitasking-Sicher)
| +- class ChangingEventLogBaseMT (zeitlich rotierendes Logfile)
| +- class DailyEventLogMT (täglich rotierendes Logfile)
| +- ...
+- ...

In C++ ist alles ab ChangingEventLogBase als template realisiert.
template <typename BASE>
class ChangingEventLogBaseT : public BASE
{ ...
};
typedef ChangingEventLogBaseT<EventLog> ChangingEventLogBase;
typedef ChangingEventLogBaseT<EventLogMT> ChangingEventLogBaseMT;
// Alle tieferen Klassen Analog.

In Java und C# sind die Klassen ChangingEventLogBase und
ChangingEventLogBaseMT und analog alle tieferen exakt identische Kopien
des gleichen Sourcecodes, die sich ausschließlich im Klassennamen und
der Basisklasse unterscheiden. Hochgradig redundant und fehleranfällig.
Copy & Paste ist bekanntlich der persönliche Feind des Programmierers.

Natürlich hätte man das auch anders implementieren können, aber dann
hätte man halt ein MI-Problem. Außerdem ist MI zur Laufzeit langsamer
als das Template. Und ich spreche hier nicht von 5 Ereignissen, sonder
eher von 10^5 bis 10^6.

Beispiel 2: Globale Variable

smart_ptr<EventHandler> DefEH; // Default-Eventhandler

In 98% aller Anwendungen genügt das. Dann muss man zur Erzeugung einen
Events im Code nur schreiben:

DefEH->PostEvent(EventTemplate [, Parameter]);

Implementation in C#/Java:

class DefEH
{ private static EventHandler TheEH;

public static void SetEventHandler(EventHandler eh)
{ TheEH = eh;
}

public static PostEvent(...)
{ TheEH.PostEvent(...)
}
// hier folgen noch rund 50 weitere Varianten von PostEvent und
// DebugEvent für verschiedene Parameter und EventTemplate
// Kombinationen. Diese werden normalerweise in der Klasse
// EventHandler auf die virtuelle Funktion PostEvent(Event)
// abgebildet.
// In C++ sind es übrigens dank Default-Argumenten und
// template-Funktionen per se nicht mehr als 10 Varianten.
}

In Wirklichkeit ist natürlich alles noch komplizierter. So darf der Fall
DefEH == null nicht zu einem Abbruch führen. Das ist in C++ über einen
speziellen Smartpointer gelöst, der statt null ein spezielles statisches
Default-Objekt dereferenziert, was selbst ein Templateparameter des
Smartpointers ist.

Natürlich hätte man auch hier eine Statische Variable in einer Klasse
anlegen können. Dann wäre der Aufruf z.B. DefEH.TheEH.PostEvent(...).
Aber nach meiner Erfahrung führt beim Thema Fehlerbehandlung jeder
Buchstabe mehr dazu, dass es von den Programmierern weniger genutzt
wird. Außerdem hat die Aus Bibliotheks-Anwender-Sicht praktisch
identische Syntax den Vorteil der leichteren Erlernbarkeit und nur einer
einzigen Dokumentation für alle Sprachen.

Bespiel 3: String-Ersetzungen

Das Konzept zum Einfügen von Paranetern in die EventTemplates ist in den
Sprachen unterschiedlich. Der Punkt geht übrigens ausnahmsweise mal an
Java/C#, weil da die Typensicherheit einfacher zu Implementieren ist
(dank class Object). Dadurch wird das template aus C++ überflüssig.
Allerdings geht auch die strikte Typisierung verloren.

Von der Logik her ist es etwa so:

template <int N>
class EventTemplate // Klasse für Ereignis mit N formalen Argumenten
{ ...
// interne Logik zur Verifizierung, ob der Ereignistext auch wirklich
// N Platzhalter hat. Das passiert zwar erst zur Laufzeit, aber
// normalerweise zur Initialisierungszeit. Fehler werden dann zu 100%
// entdeckt.
}

template <typename P1>
class EventTemplate1 // Klasse für Ereignis mit einem formalen Argument
: public EventTemplate<1>
{ ...
public Event Create(P1 p1); // Factory-Methode, die dann von
// EventHandler aufgerufen wird, wenn PostEvent(EventHandler1, p1)
// aufgerufen wird.
};

Das Ganze von N = 0 bis N = 8. Ich weiss auch nicht elegant, aber selbst
C++ kennt keinen Weg um mit einer dynamischen Zahl von Argumenten per
Generic umzugehen, ohne die Typensicherheit aufzugeben.

Beispiel 4: MI-Problem

Für die Implementierung komplexer EventHandler, die ihre Daten bei einem
Log-Dienst abladen (TCP/IP, MQSeries/WebSphere oder RFC) kommt zum
Beispiel ein Cache-File zum Einsatz, um die Sache von der Verfügbarkeit
und Reaktionszeit des anderen Servers zu entkoppeln. Das ist letztlich
wieder einer Erweiterung von EventLog, dessen Fähigkeiten aber jetzt
nicht mehr öffentlich sind.

class EventLog
+- class EventLogCache
+- class CachedEventHandlerBase
+- class TCPIPEventHandler
+- class MQEventHandler
+- ...

class CachedEventHandlerBase
: protected EventLogCache // hide interface of EventLogCache ...
, virtual public EventHandler // ... but keep interface of
EventHandler public.

Der Trick klappt natürlich in Java/C# so nicht. Zudem gilt es
verschiedene Cache-Verfahren mit verschiedenen EventHandler zu
verquicken. Wieder ein MI-Problem.
Man muss hier auf Interfaces ausweichen, was den Klassenbaum natürlich
deutlich ändert und etliche Forwarder-Funktionen erfordert.

Beispiel 5: Object-Lifetime, Destruktor

Manche Eventhandler-Klasse führen vor der Zerstörung noch ein flush
durch. Dadurch wird beispielsweise bei dem oben genannten MQEventHandler
sichergestellt, dass die Ereignisse spätestens vor dem Beenden der
Applikation zum Server übertragen werden. Eine sofortige Übertragung ist
schon aus Performancegründen nicht gewünscht.
Das funktioniert sogar wenn die Bibliothek über einen Wrapper aus
nicht-OO-Sprachen, wie VB genutzt wird. Sehr praktisch!

In C# bekommt man das noch irgendwie hin, muss aber auch höllisch
aufpassen, da die Destruktionsreihenfolge gleichzeitig frei gewordener
Objekte nicht definiert ist.
In Java gibt es bis heute überhaupt keine Lösung. Zwar kann man mit
einem Shutdown-Hook das Programende abfangen, aber eine abgehängte
Klassenreferenz bekommt man nicht ohne weiteres mit. Das ist ein riesen
Gehangel mit einem statischen Container und WeakReferences. War mir zu
viel Arbeit => not supported.

Ich könnte noch weitere Punkte nennen. So erbt z.B. Event in Java/C# von
Exception, in C++ nicht. Das hat Nebenwirkungen auf die Implementation
bestimmter Funktionen innerhalb der Klassenbibliothek.

Einen Punkt zu den Nachteilen vielleicht noch: unmanaged Resources sind
in C# bei Webapplikationen obgleich anders suggeriert eine Katastrophe.
Wer sich also mit wechselnden COM-Objekten herumschlagen muss, die von
24/7 laufenden Prozessinstanzen benutzt werden, sollte sich also
schonmal auf Speicherlecks einstellen. Das Problem sind dabei nicht die
Lecks in den .NET Workerprozessen, sondern vielmehr, dass die
abhängigen, externen Tasks gar nicht terminieren. Wir haben das Problem
letztlich gelöst, indem wir die Prozessleichen von außen über einen
Watchdog-Task knallhart wegkillen.
Zumindest mit dem 1.1er Framework war kein Land in Sicht. In C++ oder
selbst VB war das nie ein Problem. Ich vermute einen Zusammenhang mit
der Destruktionsreichenfolge der COM-Marshalling-Objekte. Das schlechte
Design der COM-API leistet dem natürlich noch Vorschub.

Resume: es geht! Es geht sogar so, dass API-Interfaces weitgehend gleich
bleiben, aber der Preis dafür ist zuweilen recht hoch und kann in die
Größenordnung einer Neuentwicklung vorstoßen.

Den Fehler, GUI-Programme in C++ zu schreiben, haben wir
glücklicherweise nie gemacht. In Ermangelung gescheiter standardisierter
Bibliotheken (vor allem in der Vergangenheit) ist das eine der übelsten
Sachen.

Das Thema Plattformunabhängigkeit mag für die Programme oft von geringer
Relevanz sein, aber die Plattformunabhängigkeit des
Programmierer-Know-Hows ist sehr wohl ein Thema. Schließlich kostet das
bares Geld, für jede Plattform das Know-How zur jeweils passenden
Klassenbibliothek aufzubauen und zu halten. Es sei denn man präsentiert
sich als Fachidiot, der nur eines kann. Das hat in der heutigen Zeit, da
nahezu jedes System mit jedem anderen direkt oder indirekt verbunden
ist, aber nur bedingt Zukunft. Über Kurz oder Lang wird auch die
Forderung nach Systemübergreifenden Anwendungen (den Prozessen folgend)
nicht mehr wegzudiskutieren sein. Und spätestens an den
Unternehmensgrenzen ist Schluss mit einer homogenen Systemlandschaft.
Dann helfen nur noch Standards und All-Round-Wissen. Sonst guckt der
Kunde oder der Fachidiot in die Röhre (schlechtes Resultat respektive
Arbeitsamt).

Ich glaube das sind die /echten/ Vorteile von Java und C#. Sie haben
einfach nicht so viel Historie und man hat aus den Fehlern der Vorgänger
gelernt. C++ -> Java -> C#.
Es ist übrigens interessant, wie vorausschauend die Java-Leute rund um
Sun das vor 10 Jahren gesehen haben. Und erst in den letzten Jahren wird
der Nutzen in der Fläche klar.

Das hätte man von der Sache her auch alles ohne Java oder C# direkt mit
C++ haben können. Aber die Erfahrung lehrt, dass man die Programmierer
zu ihrem Glück zwingen muss. Dabei ist das Abschneiden der alten Zöpfe
und damit auch das Überbordwerfen gereifter Dinge ein notwendiges Übel.

Quote:

Insbesondere wenn ich da so an den
Durchscnitts-Programmierer denke.

Full-Ack. Was sich da für teuer Geld auf dem Markt so tummelt, ist
zuweilen tatsächlich unter aller Kanone. Viele programmieren heute noch
C, nur dass die Dateiendung nicht .c heißt. Auch Fragen in dieser Gruppe
machen das gelegentlich deutlich. Aber dabei gibt es wenigstens eine
Lernkurve.
Wer in C++ char* ohne const davor schreibt, hat mit großer
Wahrscheinlichkeit schon einen Fehler gemacht - das Ding heißt
std::string! (Eben habe ich bei der Aussage ja eine Sekunde geschwitzt,
aber ein grep -r "[^t] char\s*\*" * exemplarisch auf obiges C++ Projekt
war tatsächlich negativ.)

Quote:

Ist halt Windows only. Und damit ist der vielleicht größte Nachteil,
dass man sinnvollerweise einen IIS braucht. (Ich weiß nicht, inwieweit
Mono mittlerweile ernst zu nehmen ist.)

Hmmm. Große Teile der Plattform sind doch standardisiert. Es sollte
technisch möglich sein, die Plattform z.B. auf UNIX bereitzustellen.
Dass Mono nicht schneller vorankommt, liegt einfach daran, dass es
außer ein paar Akademikern nur wenige interessiert. Wäre echter Bedarf
auf UNIX-Seite da. würde das auch schneller gehen.

Naja, das (komerzielle) Problem von Open-Source ist halt, dass man nicht
nur für sich selbst entwickelt. Betriebswirtschaftlich ist es immer
etwas problematisch der Konkurrenz gleich mit zu helfen.

Quote:

Windows-only ist icht unbedingt ein Nachteil. Was kümmert mich was
anderes, wenn unsere Kinden alle Windows haben?

Im Server-Markt würde ich mich nicht zu sehr darauf verlassen. Außerdem
ist das Problemthema der Zukunft die Integration. Für die klassischen
Anwendungsprobleme wird nicht mehr jeder das Rad neu erfinden. Dafür
gibt es Klassenbibliotheken, gute IDEs mit Assistenten und
Standardlösungen. Aber mit Applikations- und Unternehmensübergreifenden
Fragestellungen wird sich noch lange Geld verdienen lassen. Und da ist
durchaus jede Menge Entwicklungsarbeit auf Basis der jeweiligen APIs
oder Interfaces der Standardanwendungen dabei. Die großen
Softwarelieferanten werden dieses Feld niemals umfänglich abdecken, da
die mangelnde Interoperatibilität eine der wesentlichen Säulen der
Kundenbindung ist. Man kooperiert nur mit sich selbst gut und drück mit
einem markbeherrschenden Podukt seine eigenen, i.a. wesentlich
schlechteren, Lösungen in anderen Bereichen durch. Mit Software anderer
Hersteller koopertiert man nur bei Marketingaussagen und im Notfall.
Firmen wie SAP oder auch M$ zeigen das immer wieder eindrucksvoll.
Die Ausnahme sind Unternehmen, die sie auf Integration spezialisiert
haben. Das heißt aber für den kunden mindestens drei Ansprechpartner:
Software1, Software2 und Integration. Mit allen Konequenzen, wie z.B.
Gewährleistung.
Das ist übrigens die Chance für Open Source! Die haben das
Interoperatibilitätsproblem nicht und kooperieren typischerweise sehr
gut miteinander. Dadurch ist der absolute Gesamtaufwand für die Lösung
eines Problems durch verschiedene beteiligte u.U. wesentlich geringer.

Marcel Müller

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Torsten Robitzki
Guest

Posted: Wed Mar 29, 2006 5:06 pm Post subject: Re: Von C++ nach C#

Quote:

Martin Aupperle wrote:
C++
Programme brauchen auch ne Laufzeitbibliothek.

Gentoopower wrote:

Das meinst du jetzt nicht ernst oder?

Wo benötige ich denn z.B. ne Laufzeit Bibliothek, wenn ich mit dem
Borland C++ Builder ein Programm statisch kompiliere?

Jedes Programm braucht eine Laufzeitbibliothek, wenn es zur Laufzeit
eine Funktion aufrufen möchte, die in eben dieser Bibliothek liegt (z.B.
malloc()). Ob diese Bibliothek nun statisch oder zur Laufzeit _gelinkt_
wird ist dabei eigentlich unerheblich. Bei dem OS, für das ich Software
z.Z. entwickle, wird diese Bibliothek z.B. immer zur Laufzeit gebunden,
ist aber auch Teil des OS und ist damit immer auf jedem Rechner bereits
installiert.

mfg
Torsten

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Tibor Pausz
Guest

Posted: Wed Mar 29, 2006 5:06 pm Post subject: Re: Von C++ nach C#

Martin Aupperle <newsgroups (AT) PrimaProgramm (DOT) de> wrote:

Quote:

Aber der Großteil der heute
anstehenden Programmierprojekte lassen sich mit .NET und C#
wahrscheinlich besser und schneller machen als mit traditionellem C++.

Die meisten Projekte lassen sich besser in J2EE realisieren und nicht in
..NET, wer Windows only Software braucht, für den ist .NET ein sinnvoller
Weg. Alle anderen sollten davon die Finger lassen und das läßt sich
vorallem durch politische Gründe belegen.

Quote:

Diese "Betriebsblindheit" sehe ich auch bei Leuten, die sich das C++
Mindset über viele Jahre kultiviert haben.

Ich sehe nur wie Du Dich in die Gefangenschaft von MS begibst, obwohl es
bei vielen Applikationen keinerlei Grund dafür gibt. Wenn man Server
Applikationen schreibt, dann sollte man sehen, daß sie möglichst
portabel sind. Daher sehe ich für Server Applikatione keinerlei Grund
..NET zu benutzen, die mögliche Alternative zu C++ ist J2EE und definitiv
nicht .NET.

Ein sinnvolle Aufteilung in Client und Server reduziert maßgeblich den
nichtportablen Codeanteil.

--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de

Display posts from previous:

	C++Talk.NET Forum Index -> C++ (German)	All times are GMT Goto page 1, 2, 3 Next
Page 1 of 3

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum