Welche Vorteile hat C, was kann man an C loben?

[groovemaster]

net schrieb:

das nicht, viel schlimmer: mit c++ kann man sich fehler basteln die durch einen scharfen blick auf den code nicht zu erkennen sind. beispiel:

...
  int *a = (int*)0x1234;
  volatile int *b = (int*)0x1234;
  
  cout << a << endl;  // ok
  cout << b << endl;  // huch?
...

Und was soll daran jetzt fehlerhaft sein? Dass die STL Funktionalität vermissen lässt? Hatten wir nicht schon geklärt, dass die scheisse ist?
Ich wundere mich zB auch immer, warum signed char und unsigned char für op<< genauso implementiert ist wie char. Da signed char und unsigned char Typen für Ganzzahlen mit Bytegrösse sind, sollte dort auch der Zahlenwert ausgegeben werden, und nicht das entsprechende Zeichen wie bei char.

net schrieb:

mag sein dass das nur mein subjektiver eindruck, ist aber bei java passt alles zusammen. es ist ähnlich wie mit c. beide sprachen unterstützen eine begrenzte anzahl von konzepten.

Und das ist jetzt was? Gut, weil ich nicht überfordert werde? Oder schlecht, weil ich nicht die Freiheiten habe, die ich mir wünsche oder die ich brauche? Wie du schon sagst, es ist subjektiv und damit keine objektive Beurteilung für die Nachteile einer Sprache.

net schrieb:

ich bin ein einfach gestrickter mensch und einfach gestrickte menschen brauchen einfach gestrickte programmiersprachen...

Sagt ja auch niemand was dagegen. Aber es gibt halt auch Leute, die komplizierter gestrickt sind, und die sich durch die Möglichkeiten von C++ nicht erschlagen fühlen. Dennoch muss es natürlich Ziel sein, eine Sprache im Rahmen ihrer Konzepte so einfach und durchschaubar wie möglich zu halten. Und da hat C++ in der Tat Nachholbedarf, imo. Wie ich bereits sagte, es wäre schon mal viel getan, wann man die C Kompatibilität verwirft.

net schrieb:

aber das...

add (a,b,c,d,e);

oder das...

add (&a, number_of_terms);

ist noch ein stückchen intuitiver.

Sehe ich nicht so. Willst du denn tatsächlich in C add für jede mögliche Anzahl an Parametern definieren? Das ist zum einen aufwändig und zum anderen begrenzt. Und fehlende Funktionsüberladung tut ihr Übriges. Du musst dann schon sowas wie

add5(a,b,c,d,e);
// oder
add3(a,b,c);

schreiben. Und wenn ich deine zweite Variante richtig verstehe, ist es dort das gleiche, lediglich eine Indirektion weniger. Du willst mir doch nicht wirklich weismachen, dass das einfacher sein soll, oder?
Im Mathematikunterricht haben wir auch nicht geschrieben

assign(a, add(b, c))

sondern

a = b + c

Das versteht jeder, weil Menschen nunmal eingetrichert wurde, so zu denken. Genauso wie Menschen nunmal leichter mit dezimalen Zahlen umgehen können als mit hexadezimalen Zahlen, obwohl es dafür eigentlich keinen Grund gibt.

net schrieb:

man erkennt schon allein am funktionsaufruf, dass es sich um eine art addition nicht-primitiver datentypen handeln muss, sonst könnte man's ja mit '+' machen.

Und das bringt mir was genau?

net schrieb:

ja, templates sind an sich eine feine sache. allerdings muss man auch dabei höllisch aufpassen, dass man sich nicht mörderisch grossen code generiert

Ja, das stimmt. Rein von der technischen Seite her, ist damit die Codegrösse aber erstmal nicht höher als in C, da erst bei Instanzierung des Templates die Definition erfolgt. Ob du in C also

add_int(int,int);
add_float(float,float);

verwendest, oder in C++

template <class T>
add(T,T)

und dann mit int und float instanzierst, läuft letztendlich aufs Gleiche hinaus.
Zudem kannst du mit Traits und expliziter Instanzierung den Rahmen eingrenzen, so dass es nicht ins Uferlose ausartet. Gibt bestimmt auch noch andere Möglichkeiten.

net schrieb:

...und was die konstanten angeht: die einzigen 'echten' konstanten kriegt man nur mit #define hin.

Ja, in C. In C++ gibt es auch ohne #define "echte" Konstanten.

net schrieb:

äää, aber eigentlich sollten wir doch über die vorteile von c schreiben und nicht über die macken von c++ ...

Sehe ich genauso. Aber wie gesagt, bis auf den besseren Support sehe ich da keine.

@Daniel E.
Vielleicht einfach mal Klappe halten, wenn man nix zu sagen hat. Ist zwar nicht meine Art, aber solche unqualifizierten und arroganten Sprüche kannst du dir sparen.
Btw, ich rede nicht nur über void*, sondern auch über ..._cast, const-correctness, malloc/new, etc.pp. Vor Gebrauch das nächste mal also bitte Gehirn einschalten.

[Gast]

net schrieb:

was würde es bringen, wenn c funktionsüberladung könnte?

Lass mal überlegen...

Man könnte z.B. Funktionen überladen

[Gast]

net schrieb:

was würde es bringen, wenn c funktionsüberladung könnte?

Nur mehr Probleme, weil C die Typen sehr viel strenger behandeln müsste.

[net 0]

groovemaster schrieb:

net schrieb:

...und was die konstanten angeht: die einzigen 'echten' konstanten kriegt man nur mit #define hin.

Ja, in C. In C++ gibt es auch ohne #define "echte" Konstanten.

äääh, ich hoffe du spielst jetzt nicht auf sowas wie 'const int a = 2' an. das einzige, was dabei konstant ist, ist die '2'.

groovemaster schrieb:

net schrieb:

äää, aber eigentlich sollten wir doch über die vorteile von c schreiben und nicht über die macken von c++ ...

Sehe ich genauso...

...und deshalb: hier z.b. steht mehr --> http://burks.brighton.ac.uk/burks/pcinfo/progdocs/cppcrit/index003.htm
(und das woll'n wir ja nicht alles abschreiben)

[wieso?]

Wie ich bereits sagte, es wäre schon mal viel getan, wann man die C Kompatibilität verwirft.

Warum? Was sollte schlechtes daran sein?

[groovemaster]

net schrieb:

äääh, ich hoffe du spielst jetzt nicht auf sowas wie 'const int a = 2' an.

Yep. a ist ein konstanter Ausdruck. Du kannst damit also Sachen machen wie

char buf[a];

In C geht das nicht. Oder zumnidest ist es dann ein VLA, afaik.

[Daniel E.]

groovemaster schrieb:

@Daniel E.
Vielleicht einfach mal Klappe halten, wenn man nix zu sagen hat. Ist zwar nicht meine Art, aber solche unqualifizierten und arroganten Sprüche kannst du dir sparen.
Btw, ich rede nicht nur über void*, sondern auch über ..._cast, const-correctness, malloc/new, etc.pp. Vor Gebrauch das nächste mal also bitte Gehirn einschalten.

Das hat nichts mit dem Typensystem zu tun, das in C und C++ bis auf die void-Zeiger-Wandlung haarscharf das gleiche ist (sofern C bzw. C++ die entsprechenden Typen kennt, natürlich). Ich schicke dir gerne den aktuellen C- sowie den C++-Standard per Mail zu, dann kannst Du dich selbter von diesen unqualifizierten Sprüchen überzeugen.

Guck, ProgChild erzählt schon wieder den gleichen, pardon. Schmarrn, da kann einem langsam echt der Hut hochgehen.

[net 0]

groovemaster schrieb:

net schrieb:

äääh, ich hoffe du spielst jetzt nicht auf sowas wie 'const int a = 2' an.

Yep. a ist ein konstanter Ausdruck...

nur scheinbar. ein '(int)&a = ...;' oder 'const_cast' könnte das ändern. #defines sind gegen solche schweinereien immun.

[user89]

Groovemaster schrieb:

Nope. C und C++ sind strikt voneinander zu trennen. Gemeinsamkeiten rühren lediglich daher, dass C als Basis diente. Nicht mehr und nicht weniger. Genauso könnte man sagen, dass Java ein aufgemotztes (oder abgespecktes?) C++ ist

Das ist in meinen Augen Schwachsinn.
c++ ist eine neue Sprache die den Vorgänger beinhaltet und in sich hat.

Das "C-Sprachpaket" wurde um OOP erweitert.
Klar dass wenn man die OOP features benutzt die alte Methode nicht mehr verwendet.
Was strikt zu trennen ist, ist die Art der Programierung.
Auf jedenfall sind sie nicht so strikt zu trennen wie ich glaube dass du meinst.

[Gast]

net schrieb:

groovemaster schrieb:

net schrieb:

äääh, ich hoffe du spielst jetzt nicht auf sowas wie 'const int a = 2' an.

Yep. a ist ein konstanter Ausdruck...

nur scheinbar. ein '(int)&a = ...;' oder 'const_cast' könnte das ändern. #defines sind gegen solche schweinereien immun.

Jetzt weiss ich auch woher groovemasters sig kommt

C-Casts in C++ stinken - basta

[Gast]

user89 schrieb:

Groovemaster schrieb:

Nope. C und C++ sind strikt voneinander zu trennen. Gemeinsamkeiten rühren lediglich daher, dass C als Basis diente. Nicht mehr und nicht weniger. Genauso könnte man sagen, dass Java ein aufgemotztes (oder abgespecktes?) C++ ist

Das ist in meinen Augen Schwachsinn.
c++ ist eine neue Sprache die den Vorgänger beinhaltet und in sich hat.

Und das in abgeänderter Form. Das hatten wir aber schon inf mal.

[user89]

belehrt mich wenn das nicht stimmt aba is wie ein Insekt, dass sich verpuppt.

Am Anfang konnte es nur kriechen, dann bekam es Flügel.

Klar dass die die Fliegen wollen nur noch die Flügel verwenden.

Trotzdem landet und steht das Tier auf den Beinen das es vorher hatte.

und nur weil es Flügel hat muss es das Kriechen ja ned verlernen. bzw nur in der Luft bleiben.

[user89]

es verwendet das was es gerade braucht und auch die neue verwendet die beine des "alten Körpers"

[groovemaster]

Daniel E. schrieb:

Das hat nichts mit dem Typensystem zu tun

Hast Recht. ..._cast ist ja dafür da, um lecker Pizza zu bestellen. Hatte ich ganz vergessen. Und das Ergebnis von new kann natürlich auch an jeden Zeiger zugewiesen werden wie bei malloc.
Offenbar heisst für dich Typsystem, implizite Umwandlung. Für mich nicht. Da gibt es noch jede Menge mehr. Also war deine Bemerkung unpassend, und zudem überheblich.

Daniel E. schrieb:

Ich schicke dir gerne den aktuellen C- sowie den C++-Standard per Mail zu

Brauchst du nicht, habe ich bereits. Lies sie, und du wirst sehen, dass es mehr Unterschiede als void* gibt.

net schrieb:

nur scheinbar. ein '(int)&a = ...;'

Was heisst scheinbar? Ein Compiler darf hier a im Speicher ablegen, um eine Adresse zurückzuliefern. Das ändert trotzdem nichts daran, dass a ein konstanter Ausdruck ist.

net schrieb:

oder 'const_cast'

Führt zu undefiniertem Verhalten. Was im Übrigen bei deinem Cast oben auch der Fall ist.

user89 schrieb:

Das ist in meinen Augen Schwachsinn.
c++ ist eine neue Sprache die den Vorgänger beinhaltet und in sich hat.

Nein, C und C++ haben lediglich eine gemeinsame Teilmenge. Wir befinden uns schliesslich nicht mehr im Jahre 1979.
Und dass das Design einer C++ Anwendung von der einer C Anwendung abweicht, braucht hier wohl nicht weiter erwähnt werden. Aber es gibt halt auch ganz triviale semantische Unterschiede, wie Casts oder

// c
void foo(void);
// c++
void foo();

Und das geht zB in der stdlib weiter. Wusstest du eigentlich, dass es in C++ keine Funktionen wie sinf oder cosf gibt?
Alle diese kleinen bis grossen Unterschiede sind dann doch recht zahlreich.
Daher strikt trennen!

[Daniel E.]

groovemaster schrieb:

Daniel E. schrieb:

Das hat nichts mit dem Typensystem zu tun

Hast Recht. ..._cast ist ja dafür da, um lecker Pizza zu bestellen. Hatte ich ganz vergessen. Und das Ergebnis von new kann natürlich auch an jeden Zeiger zugewiesen werden wie bei malloc.
Offenbar heisst für dich Typsystem, implizite Umwandlung. Für mich nicht. Da gibt es noch jede Menge mehr. Also war deine Bemerkung unpassend, und zudem überheblich.

Herrje, C++ enthält das gesamte Typensystem als Subset, außer eine in C eingefügte Lücke, die Wandlung von void-Zeigern, für die es in C einen guten Grund gibt. Ansonsten behandelt die Sprache C++ Typen genau so streng oder nicht streng wie C, ich frage mich, was daran so schwer zu kapieren ist.

edit: Und was ein *_cast mit unserem Thema zu tun hat, weiß ich auch nicht. Ich habe nicht behauptet, die Typsysteme seien identisch (da hätte man auch einfachere Gegenbeispiele finden können: class zB), sondern nur, daß sie, bis auf die obige Ausnahme, gleich streng sind.

Brauchst du nicht, habe ich bereits. Lies sie, und du wirst sehen, dass es mehr Unterschiede als void* gibt.

Be-wei-sen, be-wei-sen.

[Gast]

Daniel E. schrieb:

Brauchst du nicht, habe ich bereits. Lies sie, und du wirst sehen, dass es mehr Unterschiede als void* gibt.

Be-wei-sen, be-wei-sen.

Zum Beispiel char*. Hier castet C automatisch (Auch wenns vielleicht schwachsinn ist). C++ kann das nicht.

#include <stdio.h>
#include <malloc.h>

void hallo(int num) {
    printf("Hallo %d\n", num);
}

int main (int argc, char* argv[]) {
    char* p;
    p = malloc(4);

    hallo(p); // C++ fehler

    free(p);

    return 0;
}

[Daniel E.]

ProgChild schrieb:

Daniel E. schrieb:

Brauchst du nicht, habe ich bereits. Lies sie, und du wirst sehen, dass es mehr Unterschiede als void* gibt.

Be-wei-sen, be-wei-sen.

Zum Beispiel char*. Hier castet C automatisch (Auch wenns vielleicht schwachsinn ist). C++ kann das nicht.

Nein. Auch wenn *dein* C-Compiler das Programm übersetzt -- die Sprache kennt nicht mal malloc.h.

Guck dir mal einen halbwegs kompatiblen Compiler an, sagen wir, http://www.comeaucomputing.com/tryitout/ Der läßt auch im C-Modus Dinge wie 'int *p; char *q=p;' nicht zu, eben strikt nach Norm.

Der Nächste bitte

[groovemaster]

@Daniel E.
Sinnlos mit dir zu diskutieren, da du sowieso alles besser weisst. Casts haben bei dir also nichts mit dem Typsystem zu tun? Ehrlich gesagt ist diese Argumentation so traurig, wie sie an der Realität vorbei geht. Ich habe jetzt keine Lust, alle Unterschiede aufzuführen. Das kannst du ja selber machen. Hier noch ein Beispiel für dich:

int (*a)();
	int (*b)(int);
	a = b;

Oder wenn wir schon bei konstanten Ausdrücken sind, wie wäre es damit

const int a = 0;
	char* b = a;

Aber nein, hast ja Recht. Hat alles nix mit dem Typsystem zu tun.

[Daniel E.]

groovemaster schrieb:

Sinnlos mit dir zu diskutieren, da du sowieso alles besser weisst.

Ja, in dem Fall weiß ich es wirklich besser. Das C++-Typensystem ist nicht strenger als das C-Typensystem, sieht man von der Wandlung von void-Zeigern ab.

Casts haben bei dir also nichts mit dem Typsystem zu tun?

Doch, natürlich, aber die haben als Argument in einer Diskussion über das C-C++-Subset, worum es hier die ganze Zeit geht, nichts verloren.

Ehrlich gesagt ist diese Argumentation so traurig, wie sie an der Realität vorbei geht. Ich habe jetzt keine Lust, alle Unterschiede aufzuführen. Das kannst du ja selber machen. Hier noch ein Beispiel für dich:

int (*a)();
	int (*b)(int);
	a = b;

Netter Versuch, aber 'int (*a)()' ist in C leider syntaktisch was anderes als in C++ (hat einen anderen Typ). Die C++-Interpretation des Quelltextes (die man in C 'int (*a)(void); ... b = a;' schreiben würde) sollte nicht durch einen standardkonformen Compiler wandern.

Oder wenn wir schon bei konstanten Ausdrücken sind, wie wäre es damit

const int a = 0;
	char* b = a;

Naja, das ist kein gültiges C99 (geht auch nicht durch den Compiler), hat also in der Diskussion nichts verloren.

Nochmal, bitte.

[groovemaster]

Daniel E. schrieb:

Doch, natürlich, aber die haben als Argument in einer Diskussion über das C-C++-Subset, worum es hier die ganze Zeit geht

In welcher Höhle lebst du denn? Darum geht es überhaupt nicht.
Aber um es nochmal verständlich für _dich_ zu schreiben, es geht um die Vorteile von C und mein Statement dazu, dass ich bis auf den besseren Support keinen sehe, weil C++ ua eine striktere Typisierung hat. Und selbst wenn das nur void* wäre, dann ist das immer noch strikter.

Daniel E. schrieb:

Netter Versuch, aber 'int (*a)()' ist in C leider syntaktisch was anderes als in C++

Es ist syntaktisch das Gleiche, der Unterschied ist semantischer Natur. Und darum ging es ja. C++ kennt keine "Funktionen mit unbestimmten Parametern". Dehalb strikter. Man kann sich mit C++ durch besagten Code also kein Bein wegschiessen, mit C schon.

Daniel E. schrieb:

Naja, das ist kein gültiges C99 (geht auch nicht durch den Compiler), hat also in der Diskussion nichts verloren.

Hehe, du bist echt ein Troll. Dass das kein gültiges C ist, ist mir schon klar. Das war ja gerade der Witz an der Geschichte. C++ ist in der Lage, einen konstanten integralen Ausdruck, was 0 ist, in einer Variable zu speichern, und diesen entsprechend, zB für die Evaluierung zu einem Nullzeiger, verwenden. C kann das nicht, und macht daraus 'ne "normale" Konstante. Und wiedderum strikter, da in C++ hier keine Informationen zum Typ des Ausdrucks verloren gehen, auch wenn sich das syntaktisch nicht äussert.

Wie wär's, wenn du nicht einfach mal deine sinnlosen Beiträge stecken lässt. Bisher hast du nur rumgestänkert, Müll geschrieben (ok, der Beitrag von ProgChild ist kein gültiges C), nichts zum Thema beigetragen und ein höchst arrogantes Benehmen an den Tag gelegt. "Bitte abstellen!"