Ist es sinnvoll heute noch C++ anzufangen?

[Michael E.]

+fricky schrieb:

~john schrieb:

Was ist das für ein Argument?...Meiner Meinung nach gehört der Mist rausgeschmissen. Und die Tatsache, daß Du noch nicht einmal kennst, spricht Bände.

ich schätze 99.9% aller C-programmierer haben sie noch nie verwendet und 98% wissen nicht, was das ist. wenn's trigraphs rausgeschmissen werden, würde sie keiner vermissen. du hast zwar recht, dass trigraphs überflüssiger bullshit sind, aber sie sind nichts, was die sprache C in irgendeiner form beeinträchtigt oder sonst irgendjemanden stören könnte, aus einem einfachen grund: fast niemand muss damit jemals was zu tun kriegen. und wenn er sein ganzes leben lang 24 stunden am tag C programmieren würde.

Wo wir wieder beim operator<<(volatile void*) sind. Aber du bist ja resistent.

[0xIng]

Also in der Softwareschmiede, für die ich arbeite, werden neue Projekte grundsätzlich nicht mehr in C++ umgesetzt, sondern nun nur noch in C# oder ggf. in Java, wobei dies eher selten. Früher war mal alles C++, jetzt beinahe alles C#.

[+fricky]

Michael E. schrieb:

+fricky schrieb:

~john schrieb:

Was ist das für ein Argument?...Meiner Meinung nach gehört der Mist rausgeschmissen. Und die Tatsache, daß Du noch nicht einmal kennst, spricht Bände.

ich schätze 99.9% aller C-programmierer haben sie noch nie verwendet und 98% wissen nicht, was das ist. wenn's trigraphs rausgeschmissen werden, würde sie keiner vermissen. du hast zwar recht, dass trigraphs überflüssiger bullshit sind, aber sie sind nichts, was die sprache C in irgendeiner form beeinträchtigt oder sonst irgendjemanden stören könnte, aus einem einfachen grund: fast niemand muss damit jemals was zu tun kriegen. und wenn er sein ganzes leben lang 24 stunden am tag C programmieren würde.

Wo wir wieder beim operator<<(volatile void*) sind. Aber du bist ja resistent.

nö, der unterschied ist: trigraphs sind einfach nur entbehrlich, aber aus (volatile) void* pauschal einen bool zu machen, ist extremer mist. zugegeben, diese macke kann man nicht C++ selbst ankreiden(*), sondern den codern der c++ standard-lib. aber als spektakuläres vorführobjekt, um zu zeigen, wie sich C++ schon bei banalsten dingen seltsam verhält, taugt es hervorragend.

(*)
vielleicht schon, weil c++ volatile und nicht-volatile als argument in überladungen unterscheidet. vielleicht kann mich einer aufklären, warum das so ist. wenn man sich den sinn von 'volatile' vor augen führt, müsste das doch garnicht sein, oder doch?

[Michael E.]

Wie gesagt, resistent. Deshalb hab ich auch schon keine Lust mehr zu diskutieren.

[knivil]

Trigraphs ... Parsen von Code unnötig verkompliziert

Ja und? Nach dem Parsen hat der Compiler den Syntaxtree und kann damit machen, was er will.

Zeigerarithmetik ist in einer Hochsprache überflüssig

Ich wuenschte, ich haette manchmal Zeiger in Sprachen wie Java (nicht unbedingt die Arithmetik).

Hochsprache

Wenn es danach geht, muessten wir alle in Lisp programmieren. Kaum eine andere Sprache erlaubt mir Zugang zum Syntaxtree.

operator<<(volatile void*) ... wie sich C++ schon bei banalsten dingen seltsam verhält, taugt es hervorragend.

Dieses Beispiel ist sowas von irrelevant fuer den taeglichen Programmieralltag ... Hat irgendwer ein relevantes Beispiel, welches einem das Leben schwer macht, wenn man C++ idiomatisch benutzt? More C++ Idioms

Also in der Softwareschmiede, für die ich arbeite, werden neue Projekte grundsätzlich nicht mehr in C++ umgesetzt, sondern nun nur noch in C# oder ggf. in Java, wobei dies eher selten. Früher war mal alles C++, jetzt beinahe alles C#.

Jaja, Industriestandard ... Revenge of the Nerds Beating the Averages

[+fricky]

knivil schrieb:

operator<<(volatile void*) ... wie sich C++ schon bei banalsten dingen seltsam verhält, taugt es hervorragend.

Dieses Beispiel ist sowas von irrelevant fuer den taeglichen Programmieralltag ...

der effekt ist aber witzig. hier noch was lustiges:

string a("c++ get off my ass");   // konstruktoraufruf mit parameter  
  string b();               // konstruktoraufruf ohne parameter (oder doch nicht?)

[Artchi]

+fricky schrieb:

der effekt ist aber witzig. hier noch was lustiges:

string a("c++ get off my ass");   // konstruktoraufruf mit parameter  
  string b();               // konstruktoraufruf ohne parameter (oder doch nicht?)

Wieder der beweis, über etwas zu urteilen, obwohl man es nicht kennt. Und es zeigt, das du nicht mal C kannst obwohl du dich C-Fanboy nennst, sonnst wäre dir aufgefallen, das string b(); ein Funktions-Prototyp ist (was auch der Compiler mit einem ERROR anmeckert). Das ist nun wirklich Basiswissen, oder?

Es muß, wenn dann heißen:

string b;

Du bist echt peinlich.

[+fricky]

Artchi schrieb:

Und es zeigt, das du nicht mal C kannst obwohl du dich C-Fanboy nennst...

in C gibts keine konstruktoraufrufe. da passieren solche verwechslungen garnicht erst.

Artchi schrieb:

...sonnst wäre dir aufgefallen, das string b(); ein Funktions-Prototyp ist (was auch der Compiler mit einem ERROR anmeckert).

bei mir meckert nix (vc 2005).

Das ist nun wirklich Basiswissen, oder?

nö, das ist die inkonsistente C++ syntax.

[_matze]

Also auf die Idee bin ich selbst noch nie gekommen, aber wenn man es mal ausprobiert, kriegt man keinen Fehler, sondern eine vorzügliche Warnung (VS2008):

1>c:\develop\testcenter v9\acquit\dlgtichawashadingcorrection.cpp(146) : warning C4930: 'std::string b(void)': Funktion mit Prototyp wurde nicht aufgerufen (war eine Variablendefinition gemeint?)

[JustAnotherNoob]

fricky, du bist echt gut.
Kein anderer Troll hat es bisher geschafft trotz offensichtlichen Nicht-Wissens so viel Aufmerksamkeit zu erlangen und auch mich immer wieder dazuzu treiben dir zu antworten

In C gibt es Pointer als Typen, aber dennoch kommt der * an den Namen und nicht zum Rest des Datentypes. Inkonsistente C-Syntax? Wayne? Ja richtig, wayne.. genauso wie das was du uns bisher vorgelegt hast. Vielleicht bringst du mal ein Beispiel was C so toll kann, was C++ nicht kann? Oder was Java kann, was C++ nicht kann? Und ich rede nicht von Workarounds.

[Belli]

JustAnotherNoob schrieb:

In C gibt es Pointer als Typen, aber dennoch kommt der * an den Namen und nicht zum Rest des Datentypes.

Wer sagt das?

[Scheppertreiber]

JustAnotherNoob schrieb:

In C gibt es Pointer als Typen, aber dennoch kommt der * an den Namen und nicht zum Rest des Datentypes.

Aber ja doch:

char  *p, buf[256];

Oder willst Du den kompletten Quellcode vollmüllen ?

[_matze]

Abgesehen davon, dass es optisch m.E. schöner ist, wenn der '*' am Bezeichner und nicht am Typ pappt, ist es jedem natürlich selbst überlassen. So eine Konvention existiert nicht. Scheppertreibers Beispiel demonstriert, warum es so auch sinnvoller sein kann.

P.S.: Meine Kristallkugel hat mir grad geflüstert, dass die Diskussion sich nun in die Richtung bewegen wird, ob man mehrere Variablen in einer Zeile deklarieren darf oder nicht...

[+fricky]

_matze schrieb:

Also auf die Idee bin ich selbst noch nie gekommen, aber wenn man es mal ausprobiert, kriegt man keinen Fehler, sondern eine vorzügliche Warnung (VS2008)

die warnung kriegste bestimmt weg, wenn du oben eine funktion hinschreibst: string b{return"hello";}

JustAnotherNoob schrieb:

In C gibt es Pointer als Typen, aber dennoch kommt der * an den Namen und nicht zum Rest des Datentypes.

beim dereferenzieren, oder wo?

JustAnotherNoob schrieb:

Vielleicht bringst du mal ein Beispiel was C so toll kann, was C++ nicht kann?

kommt drauf an, was du mit können meinst. C ist viel leichter lesbar. z.b. ist in C ein ausdruck der form: a = b->c(d); relativ eindeutig. in C++ gibt es dagegen viele möglichkeiten, was es bedeuten könnte.

[Michael E.]

Immer diese praxisnahen Beispiele. Wenn ich b im gesamten Programm nicht benutze, ist es mir doch egal, ob b jetzt eine Funktion oder ein Objekt ist. Aber sobald ich es benutze, fliegen mir die Fehler nur so um die Ohren, wenn ich mich bei der Deklaration vertan hab.

[LordJaxom]

_matze schrieb:

Abgesehen davon, dass es optisch m.E. schöner ist, wenn der '*' am Bezeichner und nicht am Typ pappt, ist es jedem natürlich selbst überlassen. So eine Konvention existiert nicht.

Es geht nicht um eine Konvention. Der Stern gehört zum Bezeichner, nicht zum Typ. Egal, wo dabei die Leerschritte sind, wären anderenfalls hier a und b Zeiger. Insofern ist das gesagte schon richtig.

char * a, b;

[Scheppertreiber]

Ich denke ja. Zumindest war das mit ein Grund für mich, Pascal ab- und C
anzuschaffen. 10 Seite Pascal ca. 10 Zeilen C

[Camba]

Oh man nun werdet doch nicht immer gleich persönlich, wenn fricky~ euch mal die Fehler von C++ vor Augen führt. Diesen Konstruktoraufruf, der in Wirklichkeit eine Funktionsdeklaration darstellt finde ich auch besonders tückisch. Darüber sind damals in meinem C++ Uni Kurs sehr viele Kommilitonen gestolpert und wunderten sich dann, warum sie eine seltsame und für sie völlig unverständliche Fehlermeldung vom Compiler bekamen.

Ihr Leute müsst mal bedenken, daß solche Tücken für Jemanden, der noch nicht seit 5 Jahren C++ programmiert und in jeder freien Minute den C++ Standard auswendig lernt, durchaus ein ernsthaftes Problem darstellen.

Noch fataler ist natürlich das altbekannte virtual Problem, was dutzende meiner Kommilitonen völlig hat an die Wand fahren lassen.

class abstract {
public:
	void init() { print(); }
	virtual void print() = 0;
	abstract() { init(); }
};

class abc : public abstract {
public:
	virtual void print() { cout << "Ich bin abc" << endl; }
};

int main(int argc, char* argv[]) {
	abc test;
	return 0;
}

Da soll der unerfahrene Neuling erstmal verstehen, was er hier falschgemacht hat und warum er mit einem obskuren runtime error R6025 abgestraft wird.

Und von solchen Falltüren gibt es in C++ noch einige mehr.

[asc]

Camba schrieb:

Oh man nun werdet doch nicht immer gleich persönlich, wenn fricky~ euch mal die Fehler von C++ vor Augen führt.

Es würde nicht stören wenn fricky selbst nicht absolut Kritikunfähig wäre, und seinen Standpunkt nicht als den einzig richtigen verbreiten würde. Wir wissen selbst das C++ nicht in jeden Fall optimal ist, aber dies gilt auch für sein ach so intuitives C (und einige Probleme von C++ basieren auf den C-Altlasten).

Dennoch greife ich lieber zu C++ als zu C, weil ich persönlich - trotz der Fallstricke - C++ für intuitiver halte (Gerade wenn man einige C-Altlasten auf ein Minimum reduziert). Und das "virtual-Problem" gibt es übrigens nicht nur unter C++, sondern unter wohl jeder Sprache die ein Objekt nicht vor der Abarbeitung aller Konstruktoren anlegt.

[Dravere]

@Camba,
Wir hätten hier nichts dagegen, wenn +fricky wirklich kritisieren würde. Es gibt Dinge in C++ die man stark kritisieren könnte, wenn man denn C++ versteht. Was +fricky hier aber tatsächlich macht ist reines rumgetrolle. Er kennt C++ nicht, kritisiert den grössten Müll und wenn man den gleichen Müll an seiner C Sprache kritisiert, dann aktzeptiert er diese Kritik nicht. Es ist völlig idiotisch, mit einer solchen Person überhaupt zu reden, weil es gar keinen Sinn hat. Denn diese Person will nicht kritisieren und darüber in einem vernünftigen Ton reden, sie will nur rumtrollen.

Deine Kritikpunkte sind übrigens auch nur so la la. Solche Fallen für Anfänger gibt es in jeder Sprache. Deshalb muss man eine Sprache auch lernen. Zudem gilt C++ seit jeher als eine komplizierte Sprache für Anfänger und man hat als Ziel noch nie angegeben, dass man eine einfache Sprache für Anfänger sein möchte.
Allerdings das mit dem Konstruktor zum Beispiel, wird im nächsten Standard berücksichtig und deshalb eine neue zusätzliche Schreibweise eingeführt, damit dies einheitlicher wird.

Grüssli