Abfrage.. bin zu blöd...
-
@Narrensicher: Das ist aber C, kein C++
.
-
Narrensicher schrieb:
Auch wenn man mittlerweile kaum noch gute C++ Bücher antrifft, probier's z.B. mit 'C++ von A bis Z Das umfassende Handbuch'. Zwar versucht auch hier der Autor, den Leser zu einem 'genormten' C++-Programmierer zu 'erziehen', der sich gefälligst an den Standard zu halten hat, aber immerhin wird in einigen Randbemerkungen noch darauf hingewiesen, dass C-Funktionen in C++ einsetzbar sind. Auch wenn es nicht empfohlen wird. Warum? Niemand weiß es genau. Ist eben so eine Meinung. (Hinweis: Es gibt keinen objektiven Grund, eine Funktion, die eine Aufgabe zufriedenstellend löst, NICHT auf zu rufen.)
typensicherheit z.b. bei den funktionen. plus std::string *ist* einfacher und intuitiver als ein ein NTBS und die zugehörigen strxxx funktionen. wenn man mit den standardcontainern arbeitet und sich dabei für den c++-way entschieden hat, ist es äußerst unklug, den code mit anderen (C-)funktionen zu mischen. (z.b. sollte man dann bei cout/cin sync_with_stdio angeben)
und ein "genormter" c++ programmierer, wird wohl kaunm
#include <stdio.h>in seinen programmen verwenden. das heißt#include <cstdio>und die funktionen daraus liegen im namespace std. damit ist das, was du geschrieben hast, tatsächlich *nicht* c++.
-
Narrensicher schrieb:
(Hinweis: Es gibt keinen objektiven Grund, eine Funktion, die eine Aufgabe zufriedenstellend löst, NICHT auf zu rufen.)
Wenn eine Funktion in C++ sicherer implementiert werden konnte als die äquivalente C-Funktion, weil die Sprache die Mittel dazu bietet, gibt es keinen objektiven Grund, sie NICHT zu benutzen.
-
queer_boy schrieb:
und ein "genormter" c++ programmierer, wird wohl kaunm
#include <stdio.h>in seinen programmen verwenden. das heißt#include <cstdio>und die funktionen daraus liegen im namespace std.Warum hängt sich daran eigentlich immer jeder auf? Das ist doch sowas von nebensächlich, dass es zum Schreien ist. Soweit ich weiß hat es keine Auswirkungen auf irgendwas, genauso ob man nun "int main()" oder "void main()" oder "int main( int argc, char *argv[], char *envp[] )" schreibt. Sobald man genug kann, um ernsthaft zu programmieren, spielt das absolut keine Rolle mehr und ansonsten verwirren die Diskussion die armen Anfänger nur
queer_boy schrieb:
damit ist das, was du geschrieben hast, tatsächlich *nicht* c++.
Klar... C++ muss doch nicht zwingend aus den in-/outstreams bestehen. Du kannst dir ein xk-Zeilen-Projekt basteln, was angeblich nicht C++ wäre. Ist es aber.
-
Hallo
Na ganz so egal ist das ja nun nicht. Gerade als Anfänger sollte man sich angewöhnen standardkonform zu programmieren, weil sonst irgendwann mal gar nichts mehr geht (portieren, anderer compiler) Das muss doch nicht sein. Und ebenson ist c eben nicht c++
chrische
-
chrische5 schrieb:
Hallo
Na ganz so egal ist das ja nun nicht. Gerade als Anfänger sollte man sich angewöhnen standardkonform zu programmieren, weil sonst irgendwann mal gar nichts mehr geht (portieren, anderer compiler) Das muss doch nicht sein. Und ebenson ist c eben nicht c++
chrische
Und in drei Jahren beschließt irgend ein erlauchtes Gremium einen neuen Standard, der wieder völlig andere Dinge 'vorsieht'. Dass Programmiersprachen sich im Laufe der Zeit immer wieder verändert haben, ist ganz normal. Solange man ein paar wenige Grundkonzepte kapiert, ist es auch unerheblich, was momentan gerade 'der Standard' ist. Weil in wenigen Jahren kann es schon wieder ganz anders aussehen.
Jeder sollte bis zu einem gewissen Grad 'seinen eigenen Standard' bzw. 'Stil' entwickeln. Denn wirklich 100% standardgetreu programmiert niemand.
-
Narrensicher schrieb:
...Denn wirklich 100% standardgetreu programmiert niemand.
Na, das ist wohl mehr Klischee ("nobody is perfect", "So jung kommen wir nich wieder zusammen", ....) als Realität.
Und außerdem IMO kein Argument, nicht wenigstens zu versuchen standardkonform zu programmieren.Ich würde mal andersherum sagen: Wer ein guter (oder besserer) Programmierer werden will, sollte den Standard kennen - und sei es nur, um zu wissen, wo er davon abweicht und welche Risiken er damit eingeht.
Die Tatsache, dass es verschiedene Standards gibt (derzeit C++98, später vllt. mal C++0x), bedeutet auch nicht, dass man sie nicht kennen muss, sondern das Gegenteil.
Gruß,
Simon2.
-
Narrensicher schrieb:
chrische5 schrieb:
...Gerade als Anfänger sollte man sich angewöhnen standardkonform zu programmieren, weil sonst irgendwann mal gar nichts mehr geht...
Und in drei Jahren beschließt irgend ein erlauchtes Gremium einen neuen Standard, der wieder völlig andere Dinge 'vorsieht'. ... Solange man ein paar wenige Grundkonzepte kapiert, ist es auch unerheblich, was momentan gerade 'der Standard' ist. Weil in wenigen Jahren kann es schon wieder ganz anders aussehen. ...
Dem schließe ich mich absolut nicht an. Das mag zwar für ein Hobbyprogrammierer der niemals in einen Team arbeiten wird nicht so relevant sein, aber ein Standard hilft auch beim verstehen fremden Codes. Man sollte sich IMHO immer so weit an einen Standard halten, wie der Compiler es zulässt.
Und wer sich wirklich ernsthaft mit einer Sprache auseinander setzen will (ob nun Privat oder Beruflich) sollte sich zumindest in Grundzügen ab und zu umschauen ob ein neuer Standard (ich sage hier z.b. C++0x) kommt, und was sich im groben ändern könnte.
cu André
-
Klar sollte man sich an den Standard halten, aber ob man die <stdio> oder die <stdio.h> einbindet, ist sowas von schei*egal
Abgesehen davon schließt C++ nunmal C mit ein, ob du's willst oder nicht. "printf" ist eine genauso zulässige C++-Anweisung wie "cout <<". C++ ist eine Programmiersprache und keine Bibliothek. Was ihr meint, ist, dass manche C++-Programme auch C-Programme sind, das macht sie aber noch lange nicht nicht-C++.
Und eine Nebenfrage: Worin entscheidet sich eigentlich sogenannter "standard-konformer" C++-Code von "nicht-standard"-Code?
Zwei Beispiele hätten wir schonmal: <stdio> vs <stdio.h> und die main-Funktion, eventuell noch die C++-Streams im Gegensatz zu den "printf" / "str..."-Funktionen.
Wenn es nur um solche irrelevanten Dinge geht, ist die Diskussion absolut sinnfrei. Wichtig ist allein, dass man beides kennt und halbwegs mit umgehen kann, was man davon nun verwendet bleibt wohl jedem selber überlassen...
-
Badestrand schrieb:
Klar sollte man sich an den Standard halten, aber ob man die <stdio> oder die <stdio.h> einbindet, ist sowas von schei*egal
Das ist eben nicht egal. Der Header stdio.h ist eben kein Standard und muss deshalb nicht angeboten werden. Wenn du ein Programm schreibst und auf einem anderen Compiler compilierst das diesen Header nicht hat dann hast du erstmal schön viel Arbeit alles anzupassen...
Es geht nicht um solchen Kleinkram. Printf etcpp sind auch im C++ Standard enthalten, da diese Funktionen aber alte Fragmente aus C sind und nicht von den C++ Vorteilen (Typsicherheit, ...) profitieren sollte man diese möglichst meiden.
Und das mit main ist sowiso so ne Sache. Laut C++ Standard sind gültig:
int main(); // int main( void ); int main( int argc, char** argv );Sonst nichts. Laut C Standard sind auch andere Rückgabewerte erlaubt, z.B.:
void main();Und schon sind wir wieder beim Thema. Du schreibst ein C++ Programm mit void main() {} Funktion und gibst es einem Kollegen der einen Compiler verwendet welcher keine unkonformen main Funktionen zulässt. Zack, schon muss er wieder rumeditieren.
-
Badestrand schrieb:
...
Und eine Nebenfrage: Worin entscheidet sich eigentlich sogenannter "standard-konformer" C++-Code von "nicht-standard"-Code?...Ganz einfach darin, dass sich Dein Code plötzlich auf einem anderen Compiler/System nicht mehr compilieren lässt.
Badestrand schrieb:
...Wenn es nur um solche irrelevanten Dinge geht, ist die Diskussion absolut sinnfrei. ...
Solche Dinge sind absolut relevant, wenn Du mal Dein 50.000 Zeilenprogramm statt in 2 Tagen in 5 Monaten portiert hast.
Gruß,
Simon2.
-
Badestrand schrieb:
...Wenn es nur um solche irrelevanten Dinge geht, ist die Diskussion absolut sinnfrei. ...
Irrelevant?
Dann nehmen wir doch mal das ganz einfache Beispiel "new".
Wie fängst du ab ob die Allokierung erfolgreich war? Viele Beispiele verwenden noch heute die nicht standardkonforme Prüfung (Prüfung gegen 0/NULL). Wenn du aber auf ein Standardkonformen Compiler arbeitest geht das gänzlich nach hinten los (das Programm verabschiedet sich mit einer Exception).
cu André
-
Gut, da scheinen unsere Meinungen ja auseinanderzugehen...
Simon2 schrieb:
Solche Dinge sind absolut relevant, wenn Du mal Dein 50.000 Zeilenprogramm statt in 2 Tagen in 5 Monaten portiert hast.
Nein, wenn es nur um "main" und "<stdio>/.h" geht, ist es irrelevant. Da brauchst du nämlich für ein noch so großes Projekt 2 Minuten und nicht 5 Monate.
asc schrieb:
Dann nehmen wir doch mal das ganz einfache Beispiel "new".
Wie fängst du ab ob die Allokierung erfolgreich war? Viele Beispiele verwenden noch heute die nicht standardkonforme Prüfung (Prüfung gegen 0/NULL). Wenn du aber auf ein Standardkonformen Compiler arbeitest geht das gänzlich nach hinten los (das Programm verabschiedet sich mit einer Exception).Das ist dann was anderes, das meinte ich nicht. Sowas ist natürlich relevant und jeder C++-Programmierer sollte wissen, dass "new" Exceptions schmeißt, statt NULL zurückzugeben. Das gehört schließlich schon zum Sprachkonzept dazu und hat inhaltliche Auswirkungen, eben anders als die vorher erwähnten Sachen
-
Badestrand schrieb:
Gut, da scheinen unsere Meinungen ja auseinanderzugehen...
Simon2 schrieb:
Solche Dinge sind absolut relevant, wenn Du mal Dein 50.000 Zeilenprogramm statt in 2 Tagen in 5 Monaten portiert hast.
Nein, wenn es nur um "main" und "<stdio>/.h" geht, ist es irrelevant. Da brauchst du nämlich für ein noch so großes Projekt 2 Minuten und nicht 5 Monate.
Je nach größe des Projekts und Unterschieden kann eine Portierung durchaus mehrere Monate dauern. Und wenn du nur zwei Minuten dazu brauchst, es sind zwei Minuten zu viel!
Badestrand schrieb:
asc schrieb:
Dann nehmen wir doch mal das ganz einfache Beispiel "new".
Wie fängst du ab ob die Allokierung erfolgreich war? Viele Beispiele verwenden noch heute die nicht standardkonforme Prüfung (Prüfung gegen 0/NULL). Wenn du aber auf ein Standardkonformen Compiler arbeitest geht das gänzlich nach hinten los (das Programm verabschiedet sich mit einer Exception).Das ist dann was anderes, das meinte ich nicht. Sowas ist natürlich relevant und jeder C++-Programmierer sollte wissen, dass "new" Exceptions schmeißt, statt NULL zurückzugeben. Das gehört schließlich schon zum Sprachkonzept dazu und hat inhaltliche Auswirkungen, eben anders als die vorher erwähnten Sachen
Ist auch nichts anderes als iostream.h, stdio.h o.ä. zu verwenden. Nur mit ein wenig drastischeren Folgen.
-
David_pb schrieb:
Je nach größe des Projekts und Unterschieden kann eine Portierung durchaus mehrere Monate dauern. Und wenn du nur zwei Minuten dazu brauchst, es sind zwei Minuten zu viel!
Das ist gröbster Unfug. Die main-Funktion von "void main()" in "int main()" umzubauen, dauert etwa 20 Sekunden, wenn du noch das "return 0;" dazunimmst.
Wenn die betreffenden Header mit ".h" statt ohne eingebunden sind, lässt du sie in allen Dateien automatisch ersetzen. Und wenn ich nur 2 Minuten zum portieren brauche (was man ja auch nicht gerade häufig macht), dann bin ich einfach nur glücklich!David_pb schrieb:
Ist auch nichts anderes als iostream.h, stdio.h o.ä. zu verwenden. Nur mit ein wenig drastischeren Folgen.
Ähm... Ist schon was anderes... Einfach mal drüber nachdenken...
Ich sage nicht, dass man möglichst nicht nach dem C++-Standard programmieren soll. Ich sage nur, dass es Schwachsinn ist, jeden Anfänger (oder auch Fortgeschrittenen) wegen "void main" anzuschnauzen
-
Badestrand schrieb:
...
Wenn die betreffenden Header mit ".h" statt ohne eingebunden sind, lässt du sie in allen Dateien automatisch ersetzen. Und wenn ich nur 2 Minuten zum portieren brauche ...Die Tatsache, das du dann den namespace std mit beachten mußt stört dich da nicht?
-
Braunstein schrieb:
Badestrand schrieb:
...
Wenn die betreffenden Header mit ".h" statt ohne eingebunden sind, lässt du sie in allen Dateien automatisch ersetzen. Und wenn ich nur 2 Minuten zum portieren brauche ...Die Tatsache, das du dann den namespace std mit beachten mußt stört dich da nicht?
Was meinst du damit? Ändert sich doch nix, wenn ich "#include <iostream.h>" statt "#include <iostream>" schreibe? Kanns nicht testen, mein Compiler will das nicht
-
@Badestrand: eben WEIL diese Dinge so einfach anders zu machen sind, warum sollte man sie dann nicht standardkonform machen? Es kostet dich ja nichts, dein programmierkonzept o.ä. ändert sich ja nicht im geringsten. Du schreibst einmal int statt void und lässt das .h weg (und fügst u.U noch ein c vorne dran) Was spricht denn dagegen das zu tun? Nichts! Und gerade einen Anfänger störts noch weniger, der hat es sich noch nicht angewöhnt, umso besser, kann er leicht auf das standardkonforme umsteigen.
Es mag in diesen Punkten vllt nicht viel ausmachen, ob man es stdkonform macht oder nicht... aber da es absolut nichts kostet, es konform zu machen, warum sollte man es denn bewusst nicht so tun? Wenn wir den Nutzen mit den Kosten vergleichen ist er eig. unendlich mal gröszer, da die Kosten eben 0 sind und der Nutzen nicht (wenn auch sehr gering)
(btw: enthält string.h aka cstring nicht was komplett anderes als string? Wäre vllt verwirrend u.U)
-
Badestrand schrieb:
Ändert sich doch nix, wenn ich "#include <iostream.h>" statt "#include <iostream>" schreibe?
Wenn du es so herrum machst wird dich der Compiler (warum eigentlich), sollte der Compiler dir einige Fehler ausspucken.
So etwa... ist kein Element von std.
Lustig wird es vor allem dann, wenn man die header mischt, wenn man z.Bsp. externe Quellcodes mit verwendet. Insbesondere das Mischen von iostream und iostream.h führt zu interessanten Fehlern.
-
Ich fühle mich missverstanden
Es ist doch keine Frage, dass man nach dem Standard programmieren sollte. Es ist auch keine Frage, dass das gerade in größeren Projekten sinnvoll ist.
ABER (der Streitpunkt), ich bin der Ansicht, dass diese 2 zwei Punkte für Anfänger absolut irrelevant ist.Und ich denke, wir beenden die Diskussion lieber, führt wohl zu nix
(und ich stehe allein auf weiter Flur :D)