Visual C++ oder C#?

[aths]

Ich will in der kostenlosen Express-Version etwas rumspielen. Wenn ich das richtig verstehe, kann man immer nur eine Express-Version gleichzeitig installieren. Selbst wenn ich sowohl C++ als auch C# installieren könnte – was lohnt mehr? Ich will zunächst nur kleine Testprogramme schreiben um mit dem System warm zu werden, zum Beispiel dass ich ein Array auf einen Button-Klick hin sortiere und dann ausgebe. Falls sich herausstellt dass das so funktioniert, könnte ich möglicherweise mittelfristig von Delphi lassen; mir wird laufend erzählt dass VCL veraltet sei.

Welche Programmiersprache ist besser – Teamprogrammierung spielt keine Rolle, ich brauch es nur für eigene Mini-Tools – C++ oder C#? (Minimale Erfahrung habe ich in beiden Sprachen, aber nicht genug um Vorteile abschätzen zu können.)

[()V()r.Freeze]

Hat beides Vor- und Nachteile. Ich persönlich würde zu C# tendieren, vor allem wenn es nur um kleine Applikationen geht. Mit Windows Forms kannst du einfach eine GUI erstellen, aber auch Konsolenapplikationen sind mit C# ohne weiteres möglich. Subjektiv finde ich, dass C++ schwieriger zu erlernen ist, als C#, vor allem was Debugging angeht.

[Ganon]

Wenn dein Ziel ein "Delphi-Ersatz" ist, dann wohl eher C#. C++ ist da einfach zu Low-Level, featurereich und somit unnötig kompliziert imo.

Und ich hab mehrere VS-Express-Varianten (VC++, VC#, VB.NET) drauf. Geht also.

könnte ich möglicherweise mittelfristig von Delphi lassen; mir wird laufend erzählt dass VCL veraltet sei.

Allgemein würde ich es mir sehr gut überlegen proprietäre Programmiersprachen zu nutzen. Und ja, .NET fällt da auch drunter, jedoch zeigt sich bei MS langsam ein Weg zur Offenheit, weswegen es nicht ganz sooo kritisch ist. ;)

[aths]

Werden in Visual C++ Express die Windows-Elemente (Forms, Buttons, ...) nicht oder nicht so gut unterstützt?

Edit: Ja, ich installiere gerade beides, C++ und C#. Das scheint zu gehen (puh!) Bei C++ sehe ich die lange Entwicklungszeit sowohl als Vor- als auch als Nachteil: Freie Codebibliotheken dürfte es für C++ wie Sand am Meer geben. Aber je nach Compiler oder Zielplattform könnte was anderes rauskommen. Bei C# hoffe ich einfach mal, dass der Code stringenter ist und derselbe Code immer zum selben Ergebnis führt.

Noch mal edit: Ich glaube dass C# keine globalen Variablen unterstützt. Das hielte ich aber für hilfreich. Auf der anderen Seite würde mich C# wohl vor Pointerarithmetik verschonen.

[Ganon]

Werden in Visual C++ Express die Windows-Elemente (Forms, Buttons, ...) nicht oder nicht so gut unterstützt?

Na wenn du das C++ von .NET (C++/CLI oder so) nutzen willst, dann hast du quasi schon ein halbes C# und damit geht auch alles afaik. ;) Und ich hab da was im Hinterkopf dass C++/CLI nicht wirklich mehr so von MS "gemocht" wird, aber das weiß ich gerade nicht zu 100%.

Ich gehe jetzt vom normalen Std::C++ aus. ;)

Auf der anderen Seite würde mich C# wohl vor Pointerarithmetik verschonen.

Das ist ja nicht mal das Problem. Muss man ja nicht nutzen. Für normale GUI-Anwendungen bietet sich C# einfach an. Der Garbage-Collector etc. ersparen einem viel Kopfzerbrechen. Auch ist die Syntax in C# wesentlich schlanker, aber ähnlich mächtig.

C++ sucht man eher in Non-GUI-Bereichen.

Und was meinst du mit "Globale Variablen"? Singletons?

[aths]

Das ist ja nicht mal das Problem. Muss man ja nicht nutzen. Für normale GUI-Anwendungen bietet sich C# einfach an.Ja ich glaube, das ist der ausschlaggebende Punkt. C++ ist die Erweiterung einer Systemprogrammiersprache, C# wurde gleich mit dem Gedanken an Windows-Fenster entworfen.

Und was meinst du mit "Globale Variablen"? Singletons?Mit globalen Variablen meine ich Variablen (und Structures) die direkt von allen Klassen genutzt werden können. Ein "var a: integer;" außerhalb einer Funktion in Delphi legt den Integer a an, der innerhalb der Unit von überall aus les- und beschreibbar ist.

[Gnafoo]

Wenn es um Managed C++ vs. C# geht, dann würde ich ganz klar C# vorziehen. C++/CLI ist einfach auf das klassische C++ aufgesetzt und das merkt man auch (z. B. gibt es sowohl die klassischen C++-Objekte, als auch .NET-Objekte, zwei sehr verschiedene Mechanismen). C# ist direkt mit .NET entwickelt worden und inzwischen auch sehr mächtig. Klar haben beide Sprachen ihre Vor- und Nachteile, aber C# integriert sich meiner Meinung nach einfach besser in .NET (VB.NET wäre btw. auch noch eine gute Alternative).

C++/CLI hat seine Stärken imho vor allem dort, wo man Managed- und Unmanaged-Code zusammenbringen möchte. Ein .NET-Wrapper für C++-Bibliotheken schreiben etc. Aber gerade an diesen Stellen gibt es diverse Fallstricke. Beispielsweise muss man immer aufpassen, wenn man Objekte über die Managed/Unmanaged-Grenze schieben will. Adressen von .NET-Objekten können sich wegen dem GC jederzeit ändern etc.

[Yavion]

Wenn man nicht gerade native (z.B. Win32) programmieren muss, sondern im "managed code" schreibt, ist C# die effektivere Sprache.

Zum einen hat C# recht praktische Konstrukte, wie Delegate, Lambda-Expressions und LINQ mit integriert, die es so in C++ nicht gibt und einem jede Menge LOCs sparen können.
Zum anderen muss man sich mit C# zumeist nicht darüber Gedanken machen, mit welchen Libraries man einfachste Probleme löst.
Man braucht z.B. keine Extra Libraries nur um Array-Längen abfragen zu können und das Speichermanagement wird einem sowieso abgenommen.
C#-Code ist somit oft leichter lesbar und besser verständlich als C++ Code.



Globale Variablen würde man in C# über public properties eines Singletons regeln. Was das angeht, erspart einen C# z.B. das ganze Getter-Setter Dedöns um Zugriffsrechte zu regeln.

[Gnafoo]

Mit globalen Variablen meine ich Variablen (und Structures) die direkt von allen Klassen genutzt werden können. Ein "var a: integer;" außerhalb einer Funktion in Delphi legt den Integer a an, der innerhalb der Unit von überall aus les- und beschreibbar ist.

Was einer globalen Variable am nächsten kommt sind statische Klassen/Member bzw. das Singleton-Pattern. Das kommt aber mit denselben Problemen wie globale Variablen daher. Sprich: jeder kann daran herumdoktern. Das erzeugt implizite Abhängigkeiten zwischen Objekten, die von außen nicht ersichtlich sind, erschwert Unit-Testing und die Erweiterung der Objekte durch Vererbung etc.

Singletons haben ihre Berechtigung (Logging-Klassen z. B.), aber man sollte vorsichtig damit umgehen.

Edit:

Zum einen hat C# recht praktische Konstrukte, wie Delegate, Lambda-Expressions und LINQ mit integriert, die es so in C++ nicht gibt und einem jede Menge LOCs sparen können.
Zum anderen muss man sich mit C# zumeist nicht darüber Gedanken machen, mit welchen Libraries man einfachste Probleme löst.
Man braucht z.B. keine Extra Libraries nur um Array-Längen abfragen zu können und das Speichermanagement wird einem sowieso abgenommen.
C#-Code ist somit oft leichter lesbar und besser verständlich als C++ Code.

Ich stimme dir zu, dass C# im .NET-Umfeld besser passt, aber delegates gibt es in C++/CLI auch und Lambdas kennt C++0x ebenso. Seit C++ kann man sowieso meist std::vector dem klassischen Array vorziehen (oder man nimmt eine .NET-Klasse bei C++/CLI) und C++ bringt durchaus auch einige gute Features, die bei C# nicht vorhanden sind. Templates sind ungleich mächtiger als Generics, RAII kann sehr hilfreich sein etc. Was mich eher daran stört ist, dass hier sehr viele unterschiedliche Konzepte aus traditionell verschiedenen Systemen zusammenkommen und dadurch vieles doppelt vorhanden ist und kompliziert wird (std::vector oder eine List? Pointer, Referenz, Smart-Pointer oder Handle? C++-Klasse oder ref-Klasse?).

[Ganon]

Ein "var a: integer;" außerhalb einer Funktion in Delphi legt den Integer a an, der innerhalb der Unit von überall aus les- und beschreibbar ist.

Ui, ganz übler Programmierstil ^^

Aber davon ab, unter C# sollte das gehen. Unter Java würde das Ganze so aussehen und sollte unter C# ähnlich sein:


public class Klasse {
public static Integer a = 0;
}


Nun kannst du von überall aus mit Klasse.a zugreifen. Aber wie gesagt, schön ist das nicht gerade sofern du schreiben zugreifst.

[aths]

Ok, ich werde mal C# in der nächsten Zeit etwas antesten. Die IDE sieht fast aus wie Delphi aber intern funktioniert einiges anders. Immerhin gibts die ganzen wichtigen Fenster-Elemente in C# auch.

[Ganon]

Die IDE sieht fast aus wie Delphi

.NET und der ganze Kram drum herum kommt afaik von aufgekauften Borland-Entwicklern :D

[PatkIllA]

Ok, ich werde mal C# in der nächsten Zeit etwas antesten. Die IDE sieht fast aus wie Delphi aber intern funktioniert einiges anders. Immerhin gibts die ganzen wichtigen Fenster-Elemente in C# auch.
Mit WPF gibt es das sogar doppelt und komplett unterschiedlich.
Die ganzen Elemente gibt es in .NET und nicht C#.

[FlashBFE]

Zum einen hat C# recht praktische Konstrukte, wie Delegate, Lambda-Expressions und LINQ mit integriert, die es so in C++ nicht gibt und einem jede Menge LOCs sparen können.

Du bist ein Held! Der Threadstarter will auf aller unterster Ebene anfangen (was man an der Frage nach den globalen Variablen auch merkt) und du haust mit solchen Konstrukten um dich.

Ich würde dem TS auch empfehlen, da er nicht in den C-Sprachen "verwurzelt" ist, lieber in Visual Basic .NET einzusteigen. Die Sprache ist für Neueinsteiger erwiesernermaßen leichter in der Syntax zu verstehen und setzt einige neuere .NET Konzepte geradliniger um.

Zudem gibt es mit MS Small Basic soetwas wie eine zusätzliche auf .NET aufbauende Lernsprache, die so auf die häufig benötigten Grundfunktionen reduziert wurde, dass Anfänger schnell und ohne Umwege zu Ergebnissen kommen.

Hauptsache ist jedoch, dass man als Anfänger sich nichtmehr mit C++ abplagt. Das ist bei den vielen guten Alternativen einfach verschwendete Mühe.

[Yavion]

Du bist ein Held! Der Threadstarter will auf aller unterster Ebene anfangen (was man an der Frage nach den globalen Variablen auch merkt) und du haust mit solchen Konstrukten um dich.

Ich würde dem TS auch empfehlen, da er nicht in den C-Sprachen "verwurzelt" ist, lieber in Visual Basic .NET einzusteigen. Die Sprache ist für Neueinsteiger erwiesernermaßen leichter in der Syntax zu verstehen und setzt einige neuere .NET Konzepte geradliniger um.

Zudem gibt es mit MS Small Basic soetwas wie eine zusätzliche auf .NET aufbauende Lernsprache, die so auf die häufig benötigten Grundfunktionen reduziert wurde, dass Anfänger schnell und ohne Umwege zu Ergebnissen kommen.

Hauptsache ist jedoch, dass man als Anfänger sich nichtmehr mit C++ abplagt. Das ist bei den vielen guten Alternativen einfach verschwendete Mühe.

Moment. Du meinst, weil jemand globale Variablen einsetzt, hat er prinzipiell wenig Plan von Programmierung? -Wenn man bisher eher prozedural programmiert hat, kann man das eben besonders gut, ohne viel über OOP zu wissen. Das bedeutet ja nicht, dass man "auf unterster Ebene" neu anfangen muss.

Was VB.NET angeht, gehen die Meinungen auseinander.
Der einzige Vorteil von VB.NET gegenüber C# ist m.E. ehrlich gesagt, dass man weniger geschweifte Klammern tippen muss, die auf deutschen Tastaturlayouts ungünstig liegen.
Da der TE ja schon über C/C++ Kenntnisse verfügt, stellt sich ja die Frage des auch nicht. ;)


(...) Was mich eher daran stört ist, dass hier sehr viele unterschiedliche Konzepte aus traditionell verschiedenen Systemen zusammenkommen und dadurch vieles doppelt vorhanden ist und kompliziert wird (std::vector oder eine List? Pointer, Referenz, Smart-Pointer oder Handle? C++-Klasse oder ref-Klasse?).

Genau das meinte ich. Man hat viele Möglichkeiten, die auch sicher alle iwo ihre Daseinsberechtigung haben aber im .NET Umfeld wird nur ein Teil davon wirklich verwendet. Z.B. würde man std::vector an irgendeiner Stelle vermutlich in ein IEnumerable konvertieren, weil irgendein .NET-Objekt, z.B. ein Control genau das erwartet.

[=Floi=]

http://www.uni-trier.de/fileadmin/urt/doku/csharp/v30/csharp3.pdf
noch etwas zum lesen. :)

[Monger]

Du kannst übrigens beliebig viele Visual Studio Varianten parallel installieren, sogar aus verschiedenen Versionen (2005, 2008, 2010...). Deshalb: gerade bei den Express Editionen bietet es sich an, mal überall reinzuschnuppern.


C++/CLI ist ja auch kein "klassisches" C++ mehr. Es ist dem angelehnt, aber Microsoft betont auch selbst immer wieder, dass es nur dazu da ist um die Brücke zwischen Managed und Unmanaged Code zu schlagen. Das macht also Sinn, wenn du eine große C++ Anwendung pflegst, und deren Komponenten allmählich für Managed Code umbauen willst. Oder wenn du aus anderen Gründen noch auf Unmanaged Code angewiesen bist.

Das ist heute aber sehr begrenzt. Es gibt ab Windows 7 sogar ein managed Framework für (User mode) Treiber, Services gehen sowieso schon seit langem. Wenn du Zugriff auf DirectX haben willst, gibt es dafür mittlerweile auch passende Wrapper oder Frameworks wie WPF und XNA, die zumindest Teile daraus abbilden.

Deshalb: wenn du nicht gerade eine der wenigen speziellen Entwickler bist die z.B. Kernel Mode Treiber für neue Grafikkarten schreiben o.ä. , gibt es wenig Grund sich freiwillig C++/CLI "anzutun".

[Monger]

Übrigens: ist ja nicht so, dass man in C#/VB.NET nicht auch unmanaged Code aufrufen könnte. COM ist überhaupt kein Problem, und selbst Aufrufe z.B. an die Win32 API gehen - wenn auch etwas fummelig.

[Gast]

Wer es noch nicht kennt:

http://msdn.microsoft.com/de-de/express/default.aspx

Bisschen runterscrollen zu "Webcasts & CodeClips" und die Dateien "C++0x in Visual Studio 2010" Teil 1 bis 5 runterladen. Sind ein paar ganz nette Tuts. :)

[PatkIllA]

Wenn du Zugriff auf DirectX haben willst, gibt es dafür mittlerweile auch passende Wrapper oder Frameworks wie WPF und XNA, die zumindest Teile daraus abbilden.
Das Benutzen von DirectX ist wohl nur ein marginaler Teil von WPF

[Matrix316]

Ich hab C++ im Studium gelernt und arbeite aber zur Zeit meistens mit C# und das finde ich wesentlich angenehmer. Visual Basic ist im Prinzip auch net schlecht, aber wenn man zwischen C# und VB wechselt, nervt die unterschiedliche Klammersetzung bzw. deklarierung von Variablen.

[Monger]

Das Benutzen von DirectX ist wohl nur ein marginaler Teil von WPF
Wollte damit nur ausdrücken, dass es selbst für gebräuchliche unmanaged APIs wie eben z.B. DirectX mittlerweile gute Frameworks gibt. WPF deckt natürlich nur einen kleinen Teil von DirectX ab, und WPF ist zugleich auch deutlich mehr als "nur" 3D Grafik.
Für den Otto-Normal (Windows) Entwickler reichen die ganzen Managed Frameworks mittlerweile dicke.

[PatkIllA]

Für den Otto-Normal (Windows) Entwickler reichen die ganzen Managed Frameworks mittlerweile dicke.Würde ich auch so sagen. Der Zutritt zur unmanaged Welt ist ja auch nicht verschlossen.

[The_Invisible]

ich weiß net, mir kommen programme geschrieben in managed sprachen und/oder vms immer etwas träge vor. zb habe ich vor über einem jahr eine art logfile-analyzer für größere mail-logfiles geschrieben und das native programm war mindestens um den faktor 5 schneller (gegen java).

deswegen kann ich es irgendwie nicht ganz nachvollziehen wenn manche sagen das geschwindigkeitsmäßig fast kein unterschied mehr besteht. oder ich bin einfach zu dumm um managed sprachen richtig anzuwenden. ;D

mfg

[Expandable]

Hängt natürlich davon ab, was du gemacht hast, aber Faktor 5 spricht dann doch eher für einen Fehler seitens des Programmierers :)

Im Normalfall sind die Performanceunterschiede zwischen nativen und managed Sprachen vernachlässigbar.

[Frucht-Tiger]

Java I/O hat aber schon des öfteren auf den Deckel bekommen, da können so Unterschiede schon vorstellen, wenn man das Framework nicht optimal nutzt.

Es soll ja schon ewig ein Nachfolger kommen, weiß gar nicht obs der jetzt noch in JSE 7 gepackt hat.

Topic: Auf jeden Fall C#, zum Einarbeiten ins Programmieren/OOP ist es die bessere Wahl.

[Ganon]

Es soll ja schon ewig ein Nachfolger kommen, weiß gar nicht obs der jetzt noch in JSE 7 gepackt hat.

Java NIO gibt's schon seit Java 1.4 ;) Man muss es nur nutzen, dann ist's auch schneller. Klar, dass es lahm ist, wenn man große Dateien mit einem BufferedReader einliest ;)

JavaIO ist meist komplett Thread-Sicher. Das ist natürlich ein Bremsklotz, wenn man es nicht braucht.

Stichworte sind FileChannel bzw. *Channel allgemein.

Man schaue sich zum Beispiel mal die Java-Datenbanken HSQLDB oder H2 an. Die müssen sich featuremäßig und auch performancemäßig nicht hinter MySQLInnoDB und PostgreSQL verstecken. Und sind zu 100% in Java geschrieben. Also gehen tut's ;)

[Frucht-Tiger]

Java NIO gibt's schon seit Java 1.4 ;) Man muss es nur nutzen, dann ist's auch schneller. Klar, dass es lahm ist, wenn man große Dateien mit einem BufferedReader einliest ;)
NIO ist mir schon ein Begriff, aber sollte da nicht noch was kommen für Dolphin?

Nicht an dich, sondern allgemein:

Wir brauchen unbeding einen Sticky-Thread in dem ein paar Tipps zum Einstieg ins Programmieren gegeben werden. Jedesmal ufert das in diese olle Geschwindigkeits Diskussion aus, die überhaupt nicht im Sinne der Threadstarter ist und jeder nur seine Lieblingssprache an den Mann bringen will.

[Ganon]

NIO ist mir schon ein Begriff, aber sollte da nicht noch was kommen für Dolphin?

Es sollte nur das Resourcen-Management vereinfacht werden, sodass man nicht andauernd try/catch verschachteln muss. Also statt (Pseudo-Code):


Stream i = null;
try {
i = Stream.open(file);
i.read();
} catch(IOException ex) {
// bla
} finally {
if(i!=null) {
try {
i.close();
} catch(IOException) {
//bla
}
}
}


einfach nur:

try {
Stream i = Stream.open(file);
i.read();
} catch(IOException) {
}


Denn NIO ist eigentlich recht gut von der Performance und auch ziemlich "Low-Level" für Java. Glaube kaum, dass da C(++) jetzt wahnsinnig schneller ist. Da dürfte eher die Platte / das Netzwerkinterface begrenzen.

[Gast]

C# macht gerade einem Anfänger das Leben deutlich leichter. Massig Fehler, die man in C++ machen kann, sind mit C# gar nicht möglich. Du kannst so ohne weiteres keinen Unsinn im Speicher anstellen. Wenn man will, kann man allerdings auch die ganzen Schweinereien, die C++ bietet auch in C# nutzen. C/C++ Bibliotheken können mit pInvoke auch sehr einfach in C# eingebunden werden.

Der einzige Vorteil von C++ in meinen Augen ist evtl. die Geschwindigkeit, die oft aber irrelevant ist. Sinnvollere Algorithmen helfen erstmal mehr.

"Während C einem eine Pistole gibt um sich selbst in den Fuss zu schiessen, ist's bei C++ ein Maschinengewehr..."

[Gast]

Ich habe mal ein unmanaged VC++ 2008 Projekt nach 2010 konvertiert. Danach ging leider gar nichts mehr, also kompilieren war nicht mehr möglich. Unzählige Syntax Error Fehlermeldungen in irgendwelchen Dateien, die mir vollkommen unbekannt sind. Hat jemand ähnliche Erfahrungen oder gar ein paar Tipps? Gibt es da irgendwelche Änderungen in VC++ 2010?

Sorry für OT, wollte nur keinen neuen Thread eröffnen. Und Danke im Voraus.

[Coda]

"Während C einem eine Pistole gibt um sich selbst in den Fuss zu schiessen, ist's bei C++ ein Maschinengewehr..."
Cal. 50

[Capt'N Coax]

Cal. 50

Aber hallo.

@Topic:
Es ist halt nicht so cool, in C# oder Java zu programmieren wie die Hardcore 1337 C++ Jungs. Die haben aber auch meistens jede Menge Zeit zur Grundlagenforschung, sind stressresistent oder kommen schlicht nicht drum rum.

Ich behaupte mal, dass der meist geringe Laufzeitvorteil nativer C++ Anwendungen bei weitem nicht die wesentlich höhere Implementierungsdauer wettmacht, von den WAPZ (Wut-Anfällen per Zeile) ganz zu schweigen.

Die C++ CTOR/DTOR Galore will kein Mensch implementieren, und wer von Java oder C# kommt und versucht in der Standard Library (im Zusammenspiel mit Fremdlibs erst recht) wie gewohnt Strings zu benutzen kann nur den Kopf schütteln. Zusätzlich zu lustigen Späßen wie der zusätzliche Header Pflegeaufwand und allen möglichen Schweinereien, die es ermöglichen den selben Code auf gefühlten 20000 verschiedenen Arten lösen zu können.

Das mag ganz toll für Cracks sein, aber fang mal an, den 1337 Code von "so einem" zu interpretieren.

Ich trink da lieber 'n Kaffee (schwarz und lecker) und prügel in Java + Eclipse stressfrei meine Anwendung runter. Die Java (SE) API funktioniert halt einfach und ist umfangreich, ohne total überladen zu sein, und sie ist benutzbar ohne 10 Tutorials gelesen zu haben. In C# scheint das ähnlich zu sein, dort habe ich aber nicht so viel Erfahrung.

[=Floi=]

Wer es noch nicht kennt:

http://msdn.microsoft.com/de-de/express/default.aspx

Bisschen runterscrollen zu "Webcasts & CodeClips" und die Dateien "C++0x in Visual Studio 2010" Teil 1 bis 5 runterladen. Sind ein paar ganz nette Tuts. :)


geht nicht ohne anmeldung --> fail