Warum sollte man C und C++ eigentlich nicht mischen... ?
-
It0101 schrieb:
camper schrieb:
Wieso nicht
cout<<"Beispiel mit\n" "zwei Zeilen\n";printf( "Beispiel mit\nzwei Zeilen\n" );int mprintf(char** lines) { int count=0; for (int l=0; lines[l]; l++) { for (int i=0; lines[l][i]; i++) { putchar(lines[l][i]); count++; } putchar('\n'); count++; } return count; } mprintf((char**){ "Hello string", mystr.c_str(), myobj.toString(), "I came to terminate you", 0 });?
-
Shade Of Mine schrieb:
Ich hoffe ich muss nie eine Anwendung verwenden an der du mitgeschrieben hast. Solche Aussagen tun weh.
Warum? Ich finde die Optik von Code nicht ganz unwichtig. Das optische Erscheinungsbild von Code kann die Lesbarkeit durchaus positiv beeinflussen.
Und gerade bei C++ kann Code schön aussehen.@Shade: Invers mutmaße ich mal, dass dir die Optik von Code egal ist?
Also quasi sieht dein Code so aus ( denn Optik ist ja egal ):
void test(int myint,double &mydouble){if(myint==2&&mydouble>-1)mydouble=17;else mydouble=16;}
-
It0101 schrieb:
...
Zweckmäßigkeit ist das höhere Gebot.
endl
manipulator function
<ostream>
ostream& endl ( ostream& os );
Insert newline and flush
-
Ach na los. Bis 1k views noch, dann erkläre ich diese Diskussion als geschlossen.
EDIT: @It01010: Ein freund wollte den Wald erklärt bekommen. Also hab ichs so kurz wie möglich gehalten und in eine Zeile geschreiben. in weniger als 5 minuten kam dies hier raus:
#include<stdlib.h> #define radian 1.5073f #define stacksize 32 typedef struct node_t{node*next; node*subnodefirst;}node;typedef struct tree_t{float x,y; node*firstnode; tree*next;}tree;typedef struct forest_t{tree* first; char*whose; }; forest_t* mkforest(int trees=100); tree* mktree(); void populate(tree_t*tree, node**stack); forest*mkforest(int restrict trees=100){int i=0;tree*lt;srand(time(NULL)); forest*f=malloc(sizeof(forest)); tree*gate=mktree();f->firstnode=gate;lt=gate; for(i=0; i<trees; i++){tree*nt=mktree(); lt->next=nt; lt=nt;}return f;} tree* mktree(){tree*ret=malloc(sizeof(tree)); ret->x=(rand()%trees)/5;ret->y=(rand()%trees)/5; node**stack=malloc(sizeof(node*)*stacksize); memset(stack, 0, sizeof(node*)*stacksize); populate(ret, stack);return ret;}void populate(tree*wut, node**stack) { int depth=0; int i; node*cur=stack[0]; while(cur){depth++; cur=cur->next; } if(depth>=stacksize)return; }
-
Zeus schrieb:
Zweckmäßigkeit ist das höhere Gebot.
Völlig richtig. Aber Zweckmäßigkeit ist durchaus subjektiv...
Ach nein ich vergas. C++ ist ja quasi eine Diktatur. Einer legt die Regeln fest und alle anderen müssen genau dieser Meinung sein.
Wer ist in dem Fall eigentlich unser meinungsvorgebender Führer?
-
It0101 schrieb:
Zeus schrieb:
Zweckmäßigkeit ist das höhere Gebot.
Völlig richtig. Aber Zweckmäßigkeit ist durchaus subjektiv...
Sie ist relativ aber bestimmt nicht zwingend subjektiv.
-
Zeus schrieb:
It0101 schrieb:
Zeus schrieb:
Zweckmäßigkeit ist das höhere Gebot.
Völlig richtig. Aber Zweckmäßigkeit ist durchaus subjektiv...
Sie ist relativ aber bestimmt nicht zwingend subjektiv.
"Nicht zwingend" ist aber kein ausreichend deutlicher Widerspruch zu "durchaus subjektiv".

-
Zeus schrieb:
It0101 schrieb:
Zeus schrieb:
Zweckmäßigkeit ist das höhere Gebot.
Völlig richtig. Aber Zweckmäßigkeit ist durchaus subjektiv...
Sie ist relativ aber bestimmt nicht zwingend subjektiv.
"nicht zwingend" reicht mir völlig. Danke Zeus

-
Cya ich geh auf ein Deutschkurs.
-
Zeus schrieb:
Cya ich geh auf ein Deutschkurs.
ich geh*'** auf einen Deutschkurs.*
-
It0101 schrieb:
Warum? Ich finde die Optik von Code nicht ganz unwichtig. Das optische Erscheinungsbild von Code kann die Lesbarkeit durchaus positiv beeinflussen.
Und gerade bei C++ kann Code schön aussehen.Wenn endl für dich schöner ist als \n dann weiss ich echt nicht in welchen Sprachen du programmierst. endl ist ja auch eben NICHT \n.
Ich schreib ja auch nicht einfach immer new Foo() wenn ich ein neues Objekt will weil mir new so gefällt. Die Semantik muss stimmen. Wenn die nicht stimmt, dann bringt dir der optisch schönste Code nichts.
@Shade: Invers mutmaße ich mal, dass dir die Optik von Code egal ist?
Nein, das ist einfach nur dumm.
Aber erstmal muss der Code korrekt sein bevor wir über Schönheit reden können. Es sei denn du nimmst den Anhalter zu ernst, denn dort wird ja gesagt dass Schönheit immer Wahrer ist als die Realität
Warum ich Angst vor deinem Code habe ist folgendes: Wenn du schon bei sowas trivialen die komplett falschen Prioritäten hast (subjektive schönheit über semantischer korrektheit) was kommt dann bei mathematischen Funktionen von dir raus? PI als 7.2 sieht optisch schöner aus? Oder 3 Nachkommastellen sind doof, ich finde 1 schöner?
Semantisch muss es passen - sonst brauchen wir garnicht weiter reden. Und endl ist semantisch falsch. Es erzeugt ein ähnliches Ergebnis wie \n, aber macht etwas komplett anderes.
Wenn du endl so toll findest, dann definiert dir eine konstante endline die \n als Wert hat. Oder schreib dir einen passenden manipulator. Du bist ja nicht gezwungen \n zu schreiben wenn du nicht willst.
Nur erzähl wenigstens dann Anfängern keinen Blödsinn.
-
Aus meiner Sicht ist std::endl semantisch nicht falsch, aber ok...
Wir müssen auch nicht einer Meinung sein.Es gibt einfach Punkte, die nicht entscheidend sind. Und wenn du von einer Angewohnheit bzgl. eines winzigen unwichtigen Details auf meinen kompletten Programmierstil schließt, dann ist dir ohnehin nicht mehr zu helfen...
Ich verlinke hier mal ein Tutorial eines Herrn Namens Volkard
http://www2.fh-augsburg.de/informatik/vorlesungen/XX/c_cplus/tutorial/henkel/Dazu zitiere ich mal aus Lektion 3 die "alles entscheidene Zeile 4":
cout<<"Hello, world!"<<endl;Oh mein Gott, bei allen Heiligen! Also was heutzutage Anfängern beigebracht wird ist wirklich entsetzlich!
Und mit keinem Wort wird dem unbescholtenen Anfänger gegenüber erwähnt, wie böse std::endl ist! Ich bin schockiert... 
-
Ich bin dafür, den Troll nicht weiter zu füttern.
-
It0101 schrieb:
Warum? Ich finde die Optik von Code nicht ganz unwichtig. Das optische Erscheinungsbild von Code kann die Lesbarkeit durchaus positiv beeinflussen.
Und gerade bei C++ kann Code schön aussehen.Aber man muß seinen Geschmack gelegentlich einem Realitätstest unterziehen. Ich schrieb früher auch lieber endl. Aber als dann Dateiausgaben immer anders aussahen als Konsoleausgaben, das war doch Murks.
-
volkard schrieb:
It0101 schrieb:
Warum? Ich finde die Optik von Code nicht ganz unwichtig. Das optische Erscheinungsbild von Code kann die Lesbarkeit durchaus positiv beeinflussen.
Und gerade bei C++ kann Code schön aussehen.Aber man muß seinen Geschmack gelegentlich einem Realitätstest unterziehen. Ich schrieb früher auch lieber endl. Aber als dann Dateiausgaben immer anders aussahen als Konsoleausgaben, das war doch Murks.
Leuchtet mir durchaus ein.

Ist ja nicht so, dass ich unbelehrbar bin.
Nur die Herangehensweise von Shade, dass es genau eine Lösung für eine Aufgabenstellung gibt, und alle anderen falsch sind, kann ich so nicht unterstützen. Aber ich akzeptiere seine Meinung.
-
It0101 schrieb:
Nur die Herangehensweise von Shade, dass es genau eine Lösung für eine Aufgabenstellung gibt, und alle anderen falsch sind, kann ich so nicht unterstützen. Aber ich akzeptiere seine Meinung.
Das hat Shade nicht gesagt und auch nie gemeint!
-
Shade sagt nicht, dass \n das einzig richtige wäre, er sagt, dass endl an der Stelle falsch ist! Und damit hat er Recht! Wenn du Zeilenende meinst, dann mach ein Zeilenende. Wenn du Zeilenende + flush meinst, dann sag endl (oder \n und flush)! Warum sagst du dann endl, wenn du Zeilenende (ohne flush) meinst?
-
Zeus schrieb:
It0101 schrieb:
Nur die Herangehensweise von Shade, dass es genau eine Lösung für eine Aufgabenstellung gibt, und alle anderen falsch sind, kann ich so nicht unterstützen. Aber ich akzeptiere seine Meinung.
Das hat Shade nicht gesagt und auch nie gemeint!
SeppJ schrieb:
Shade sagt nicht, dass \n das einzig richtige wäre, er sagt, dass endl an der Stelle falsch ist! Und damit hat er Recht! Wenn du Zeilenende meinst, dann mach ein Zeilenende. Wenn du Zeilenende + flush meinst, dann sag endl (oder \n und flush)! Warum sagst du dann endl, wenn du Zeilenende (ohne flush) meinst?
Genau das meinte ich weiter oben mit den dogmatischen Auslegungen für Dinge, die nie dogmatisch gemeint waren. Wenn Aussagen nicht haarklein erklärt werden und die Ausnahmen und wenns und abers in ellenlangen Absätzen erklärt werden, kommt immer jemand, der sie aus dem Kontext reißt und als absolute Aussagen mit Anspruch auf allgemeingültigkeit hinstellt, um sie a) so weiterzutragen oder b) dagegen zu wettern. In diesem Fall warst du, It0101 der b)-Fall

-
Also auf jeden Fall ist It0101 ein schlimmer Kontextreißer:
It0101 schrieb:
Zeus schrieb:
Sie ist relativ aber bestimmt nicht zwingend subjektiv.
"nicht zwingend" reicht mir völlig.
-
... womit dann auch die Fragestellung des OP entsprechend zu ändern wäre:
"Warum sollte man C und C++ eigentlich nicht mischen... ohne (guten) Grund?"
Die beantwortet sich damit allerdings von selbst.