Weiterentwicklung nach Prüfung: Neue Programmiersprache

[barbier]

Wieso nicht jeder C++ nimmt, wenns DIE Sprache ist? Ganz einfach: sie ist SEHR komplex.

C++ ist eine Multiparadigmensprache, man kann da prozedural, objektorientiert, generisch, sogar funktional programmieren. Es gibt aber so viele Features, Techniken, usw. dass man Jahre braucht, um die Sprache richtig zu beherrschen. Schon allein die Templates sind ein enormes Gebiet, sie sind Turing Complete, und somit eine Sprache in einer Sprache (es ist möglich, mit dem Compiler zur Compilezeit zu rechnen, zB Fibonacci zur Compilezeit).

Für typische Businessanwendungen sind C#/Java zu bevorzugen, da man schneller fertig ist, und vor allem kein Experte sein muss, um halbwegs stabile Anwendungen zusammenzubringen (Pointer und Buffer Overflows sind beliebte Fehlerquellen bei C/C++). Für Java/C# Leute sollte noch gesagt werden, dass es in C++ KEINE automatische Speicherverwaltung gibt; Speicher freigeben muss man selber. (Es gibt aber zigtausend Smartpointer usw. um das zu automatisieren.) Ausserdem sind Kopien in C++ standardmäßig by-value, nicht by-reference wie bei Java oder C#.

C++ zu lernen schadet ganz sicher nicht; Cpp-Experten sind gesuchte Leute. Aber ich warne davor, die MFC als Beispiel zu nehmen. Modernes C++ sieht anders aus. Man siehe sich Boost C++ Libraries oder Loki | Main / HomePage an. C++0x wird auch einige Neuerungen einführen, wie zB variadic templates oder concepts, und ein Wechsel vom .hpp/.cpp Aufbau hin zu reinen standardisierten precomilierten Headern zeichnet sich ab. Aber das nur am Rande...

[.vash]

Falls irgendjemand lange Weile hat dann schadet C++ sicherlich nichts. Es ist auch meine Lieblingsprogrammiersprache - eignet sich aber halt nicht in jedem Anwendungsgebiet. Aus dem Grund würde ich mich auch Java/C#/PHP nicht ganz verweigern - jeder der Experte auf seinem Gebiet

[Guybrush Threepwood]

Wenn man sich richtig mit COBOL auseinandersetzt dann kann man auch schnell einen gutbezahlten Job finden.

Was aber nicht daran liegt das Cobol so toll ist, sondern das es leider immer noch an sehr vielen Stellen eingesetzt wird weil man das nicht mal einfach so umstellen kann.

Ich persönlich bin zur Zeit (und das wohl noch lange) ASP.Net Entwickler mit C# und jeder Menge Javascript und ich muss sagen das C# und das .Net Framework echt eine tolle Sache ist mit der man sehr viel (größtenteils sehr einfach) erreichen kann wo man sich in C oder C++ einen abbrechen müsste.

Trotzdem "hängt mein Herz" an C (ohne ++ ), das ist IMHO eine super Sprache aber leider für Desktopanwendungen zu umständlich.

C#, was ja praktisch der Nachfolger ist, ist da wie gesagt sehr viel praktischer, aber leider an vielen Ecken auch zu einer Kindergartenprogrammiersprache mutiert.

Java hab ich selbst noch nie was mit gemacht, reizt mich aber auch absolut nicht...

[.vash]

C# ist Microsofts Wunschnachfolger ...

"Der" Nachfolger für C++ ist de facto C++0x (klingt l33t oder?)

[perdian]

C# [...] ist da [...] leider an vielen Ecken auch zu einer Kindergartenprogrammiersprache mutiert.

Wie definierst du eine "Kindergartenprogrammiersprache" bzw. was sind deren "Features"?

[carstenj]

Hi,

"Der" Nachfolger für C++ ist de facto C++0x (klingt l33t oder?)

das ist nicht der Nachfolger, sondern ein aktualisierter Standard. Das 0x soll andeuten, dass der Standard bis 2009 erscheinen soll.

[MarkusLe]

Das # in C# steht für ++++, die +++ Generation wurde übersprungen zumindest ist mir kein direkter Nachfolger von C++ bekannt und der vollkommen sinnlose "Zustand" D kann eigentlich auch nix (zumindest ist mir nix bekannt) was man nicht mit C++ oder C# genauso machen könnte.

MfG

Markus

[Guybrush Threepwood]

Wie definierst du eine "Kindergartenprogrammiersprache" bzw. was sind deren "Features"?

Viele Dinge die in C natürlich waren sind in C# nicht mehr möglich oder nicht einfach so weil man halt den Entwickler vor verschiedenen Programmierfehlern schützen will die man aber eh nur am Anfang macht bzw. schnell findet.

Ein paar Beispiele wären:

-Kein Fall Through zwischen den case Blöcken bei einem switch mehr möglich

-keine impliziete Kovertierung von bool nach int

-0 und null ist ein Unterschied (vorallem im Zusammenhang mit Punkt 2 nervig)

und gibt noch ein paar andere Dinge über die ich mich ab und zu ärgere bzw. mich frage ob man das unbedingt so machen muss und den Entwickler so an der Hand nehmen muss

Aber wie gesagt alles in allem ist C# wirklich gut.

[perdian]

-keine impliziete Kovertierung von bool nach int

Das hälst du für einen Fehler im Design? Im Gegenteil, ich halte sowas für geradezu zwingend notwendig in einer Sprache, die kein Makroassembler sondern eine vernünftig durchdachte Sprache ist. Okay, die Polemik mal beiseite geschoben: Ein Boolscher Typ ist eben nunmal kein numerischer Typ - und hat mit diesem auch (prinzipiell) nichts gemeinsam - von daher: true ist etwas anderes als 1 und false ist etwas anderes als 0.

-0 und null ist ein Unterschied (vorallem im Zusammenhang mit Punkt 2 nervig)

Auch hier sehe ich eigentlich nur Vorteile - gerade und besonders wenn es um die Objektorientierung geht.

Es gibt durchaus Situationen in denen ich einen Check wie diesen hier

durchführen möchte:

Integer i = getSomeInteger();

if(i == null) {

  System.err.println("Keine Eingabe gemacht");

} else if(i.intValue() == 0) {

  System.out.println("Nix zu tun");

} else {

  doStuff(i);

}

Naja das ist eben die Frage, wie man das "an die Hand nehmen" interpretiert. Sicherlich gehen bei Sprachen wie Java oder C# bestimmte Manipulationsmöglichkeiten verloren (direkter Speicherallokierung, Pointerarrithmetik, etc.) aber dadurch, dass man sich um solche LowLevel Details keine Gedanken mehr machen muss gewinnt man einiges an Produktivität. Die Frage ist also: Brauche ich diese Details wirklich oder ist es nicht vielleicht doch (ab und zu) mein eigenes Ego, was mir einfach sagt "Das hast du aber alles gelernt, beherrschst es jetzt und auf einmal will das der Rechner alles automatisch machen, dabei kann ich das doch viel besser".

Für solche Dinge gibt es oftmals eine recht einfache Art und Weise das herauszufinden: Überlege, wie du es machen würdest, dass es eher der Art und Weise entspricht, die dir intuitiv erscheint und überlege dann, ob alle Randbedingungen immer noch erfüllt werden. Ich habe die Erfahrung gemacht, dass vieles (nicht alles!) von dem, wo man sagt "Was soll denn der Blödsinn" plötzlich sehr sinnvoll erscheinen, wenn man mal etwas unter die Oberfläche blickt und dem ganzen ein wenig detaillierter nachgeht.

[.vash]

Also wir driften in eine sinnlose Grundsatzdiskussion ab könntne also eigentlich abbrechen ^^

-keine impliziete Kovertierung von bool nach int

-0 und null ist ein Unterschied

Hierzu will ich aber meinen Senf noch dazu geben: ist das nicht wiedersprüchlich

bool soll implizit nach int konvertiert werden können - ok

warum dann nicht 0 und null auch? auch wenn ich persönlich es andersrum besser finde bool ungleich int und 0 ungleich null - eins von beiden wäre wenigstens durchgehend.

[Guybrush Threepwood]

Nein ist kein Wiederspruch

In C# kann bool nicht impliziet in int umgewandelt werden und es besteht ein Unterschied zwischen 0 und null. Das heißt beides ist nicht einfach durch das andere austauschbar.

@Perdi

Das ist reine Ansichtssache. Dadurch das man Zahlenwerte einfach als boolsche Werte interpretieren kann, lassen sich viele beqeume Vereinfachungen schaffen. Der einzige Punkt der dagegen spricht ist nur das von mir angesprochene an die Hand nehmen des Programmierers. Man muss es ja nicht nutzen wenn es möglich ist.

Dein Beispiel mit dem Integer funktioniert so übrigens nicht weil du einem int kein null zuweisen kannst. Das funktioniert nur bei einem "Obejkttypen", von daher macht diese Argumentation keinen Sinn.

Aber vash hat recht das führt sehr weit vom Thema des Threads weg, aber von mir aus können wir das irgendwo .Net Forum weiter diskutieren

[perdian]

Das ist reine Ansichtssache.

Natürlich, ansonsten würde es ja keine 10^6 Seiten lange Diskussionen über solche Themen geben ;-)

Dein Beispiel mit dem Integer funktioniert so übrigens nicht weil du einem int kein null zuweisen kannst.

Ich weiss nicht, wie es unter C# ist aber unter Java gibt's neben dem primitiven int auch durchaus eine "richtige" Integerklasse.