C, C++,c#

Wie bereits genannt, kann man in C durchaus auch OO programmieren. Der Aufwand ist aber nicht ohne....

Zitat

egal warum sie es machen => function pointer sind der anfang vom ende

Funktionspointer FALSCH EINGESETZT sind böse. Genau wie alles andere. Sogar gotos kann man sinnvoll einsetzen. "X ist immer böse" ist einfach nur Schwachsinn. Right tool for the right job.

Template-Signalfunktionalität geht nur mit Methodenpointer (signals sind dabei in Wirklichkeit Arrays von Methodenpointer). VTables - und somit virtuelle Methoden - gehen nur mit Methodenpointer.

Zum Threadthema:

C - naja, ich setz fast nur noch C++ ein statt C. Es gibt Bereiche, in denen es nur mit C geht (Mikrocontroller, Konsolen (zB die PS2 fasst man nicht mit C++ an), Sprachenbindings usw.) aber sonst finde ich, dass C zu oft - und falsch - eingesetzt wird. C für RAD-Prototyping? C für flexible erweiterbare modulare Engines? C für GUIs (vergleicht mal GTK+ und gtkmm)?

C++ - für Anwendungsentwicklung eindeutig NICHT vorzuziehen, dafür nehm in Java oder C#. C++ ist in der Spieleentwicklung sehr stark, und bei sehr performanten Anwendungen, die sich halbwegs deterministisch verhalten sollen (d.h. kein GC, der auf einmal 500 MB aufräumt und somit den Ping beim Multiplayermodus auf 900 ms hochschiessen lässt). C++ verfügt auch über Templates, die es in den anderen Sprachen einfach nicht so gibt (Generics sind nicht dasselbe!) Die Sprache hat genug Fehldesigns, um auszuflippen, ist aber tried-and-true. C++0x bügelt hoffentlich die schlimmsten Fehler aus (zB der auto-Typ für die STL-Iteratoren ist sehr fein, keine std::map< std::string, blabla > :: iterator Wurscht mehr).

C# - SEHR interessante Sprache, ISO-Standard, leider ist die Rechtslage trotzdem unsicher. Für Anwendungsentwicklung deutlich angenehmer als C++, da man viel schneller damit Ergebnisse hat. Der GC ist für typische Anwendungen genau richtig, aber zB für Videocapturing eher Hölle (wegen dem indeterministischen Verhalten). Dass in C# normalerweise by-reference (und nicht wie bei C/C++ by-value) kopiert wird, und das noch mit eingebautem Refcounting, ist ein RIESIGES Plus, da in den meisten Fällen by-reference kopiert werden will, ausser bei atomaren Datentypen (hab mir sowas schon oft für C++ gewünscht, selbstgestrickte Lösungen sind nie so toll wie das da, vor allem zwischen DLLs gibt es Probleme).

Zitat

Kannst du bitte genau erklären, was du meinst?
In C# werden ja Structs am Stack erstellt und auch by-value gepassed. In C++ kann man das selbst kontrollieren. Meinst du es ist besser, dass standardmäßig by-reference übergeben wird?
Referencecounting? Wüsste nicht, dass es so was in C# gibt (wozu auch?).
Übrigens denke ich, der GC von .NET wird sicher noch verbessert. Soweit ich weiß ist der zur Zeit noch nicht einmal generationell. Ich schätze es wird dann - ähnlich wie bei Java - mehrere GCs geben, aus denen man einen passenden für seine Applikation wählen kann. Da besteht aber sicher noch Entwicklungsbedarf. [/B]

Structs werden by-value kopiert, ja. Eine Ausnahme, die mir entfallen ist.

Nun, nicht unbedingt Referenzcounting, aber irgendeine Verwaltung. Das ist besonders bei Ressourcen wichtig, zB Texturen bei Spielen: Ball A will Textur X, Wand B will auch X -> X NUR EIN MAL laden, A und B ne Referenz geben. Wenn A und B keine Referenz mehr auf X haben, wird X automatisch entfernt. Sowas ist in C++ oft nicht trivial umsetzbar (besonders in Windows zwischen DLLs nicht).

Ja, by-reference is meistens besser, weil man meistens das will! Dann wird eben zB intern ein Referenzcounter inkrementiert oder wie auch immer, hauptsache by-reference. Ist schneller, unkomplizierter (by-value-Kopien können böse sein, zB wenn man vergisst im Copykonstruktor einen Speicherbereich anzulegen & zu kopieren und stattdessen nur der Pointer selbst kopiert wird), und erlaubt somit irssinnig einfaches Ressourcenmanagement.

Zitat von gue

@that: Glaubst du wirklich, dass DAS ihre Motivation ist?

Ja. C++ ist so ein neumodisches Zeug, viele Compiler funktionieren noch nicht richtig, und das ABI ändert sich immer wieder. Außerdem sind die ganzen C++-Features ja nur für Weicheier, und echte Männer programmieren in C.

Oder so ähnlich.

zu java:
es gibt theoretisch schon einen destruktor (finalize) nur wird der halt erst bei wirklicher entfernung des objekts ausgeführt, dass heißt wenn der GC das objekt löscht
man kann das zwar erzwingen, wirklich sinnvoll is es aber eh net

Zitat von samrider

man kann finalize zB verwenden um datenbankverbindungen sauber zu closen.

Ja, wenn man Resource Leaks provozieren will. Man sollte Ressourcen wie Datenbankverbindungen freigeben, wenn man sie nicht mehr braucht - nicht erst wenn die JVM der Meinung ist, das Objekt kann entfernt werden.