Abfrage.. bin zu blöd...

[Badestrand]

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

[Shinja]

@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)

[Braunstein]

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.

[Badestrand]

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)

[queer_boy]

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

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...

zwischen #include <stdio> und #include <stdio.h> gibt es einen großen unterschied - den header stdio gibt es nämlich nicht.

zu stdio.h: es ist tatsächlich ziemlich irrelevant, ob man stdio.h oder cstdio inkludiert, compiler akzeptieren beides. es ist auch wahnsinnig langweilig, darüber zu streiten. es ist auch ziemlich öd, alle drei seiten zu schreiben, dass void main nicht standardkonform ist. es ist nicht nur öd, es ist ätzend und man verzweifelt oft daran, wie oft sich dieser fehler wiederholt.

ich bin einer der letzten, der sich darüber aufregt, wenn jemand im c++ forum funktionen wie printf usw. verwendet, aus dem einfachen grund, den du angeführt hast. es kann probleme damit geben, ja. wenn jemand diese funktionen verwendet, muss dieser person das klar sein. es muss ihr auch klar sein, dass es andere funktionen gibt, die dieselbe aufgabe vielleicht besser machen (nämlich: sicherer, schneller, einfacher) - aber das ist kein grund, zu antworten, dass "das C ist - und das ist böse". aber das tut auch niemand.

es ist *uns* vollkommen egal, ob jemand sich an den c++ standard hält oder nicht und seine programme im schrecklichsten mix schreibt. und jetzt kommt das große ABER:

C++ Forum schrieb:

C++
Fragen zu bestimmten Funktionen und Abläufen in C++ (nach dem ISO-Standard), damit man mal erfährt, was pure virtual bedeutet, oder wie das mit den Templates und der STL geht. Bitte keine Fragen zu Windows/Linux-Programmierung hier posten!

es geht in diesem forum eben um abläufe in C++ nach dem ISO-Standard - soweit so gut. und deshalb ist es gut und wichtig, dass man darauf hingewiesen wird, dass z.b. void main nicht standardkonform ist - auch nicht nach dem C standard - und es auch niemals war. andererseits gibt es das ANSI C forum:

C++ Forum schrieb:

ANSI C
Fragen zu bestimmten Funktionen und Abläufen in C, Benutzung der Standardlibs von C, Zeiger und Strings. Fragen zu >C für Dummies< hier stellen, bitte keine Fragen zu Windows/Linux oder C++!

und hier geht es um die Benutzung der Standardlibs in C. das bedeutet, dass man im C++ forum sofort darauf hingewiesen wird, wenn man funktionen aus der C standardbibliothek verwendet, dass man eventuell im ANSI C forum mit der frage besser aufgehoben sein wird.

und das hat nichts mit unfreundlichkeit oder standardfetischismus zu tun. es sind die regeln dieses forums, die gut funktionieren und an die sich die menschen halten. und ehrlich gesagt ist es mehr als freundlich und aufrichtig, dass sich alle so bereitwillig auf diese diskussion einlassen und euch zu erklären versuchen, was schon tausenden anderen menschen erklärt wurde und das trotzdem noch immer mit einer gewissen diskussionskultur.

PS - Anhang. ANSI C ist *kein* subset von C++ (nicht umsonst lässt sich der C++ standard seitenweise darüber aus). das sieht man z.b. daran, dass der letzte C Standard (C99) *nach* dem letzten C++ Standard (C++98) herausgekommen ist - und dementsprechend sich auch gar nicht auf ihn beziehen kann.

PPS - Was nach dem C++ Standard C von C++ unterscheidet. Beachte: der C99 standard definiert allerdings einiges davon (single line comments, bool, ...) und geht auch darüber hinaus (variable-lenght arrays, ...)
* C++ single-line comments
* neue schlüsselwörter
* character literale sind in C++ vom typ char, nicht int
* string literale sind in C++ konstant (die verwendung von char* ist deprecated)
* "tentative definitions" sind in C++ nicht erlaubt (siehe ANSI C Std. 6.9.2)
* structs haben ein eigenes scope (wenn man z.b. enums in einem struct definiert)
* konstante globale variablen haben per default internal linkage (in C external)
* die main-funktion darf nicht (rekursiv) aufgerufen und ihre adresse nicht gespeichert werden
* C++ erlaubt keine "compatible types" (structs mit unterschiedlichem namen aber selben inhalt)
* semantik beim (automatischen) void* konvertieren (hin und zurück(das schreckt vor allem die ANSI C leute, wenn ihnen jemand ein char* c=(char*) malloc anbietet
* implizite funktionsdeklarationen sind in C++ nicht erlaubt
* typen dürfen in C++ nicht in expressions deklariert werden
* return ohne value bei einer funktion, die aber mit einem rückgabetyp deklariert ist, ist ungültig

• static und extern in verwendung mit typdeklarationen ist nicht möglich
  * namen von typedef -typen dürfen nicht gleich sein, wie namen von struct (oder class , union ) typen
  * konstante objekte müssen initialisiert werden
  * die "implizit int"-regel gibt es nicht

so. und weil ich jetzt noch nicht mal bei der hälfte angekommen bin und es mir keinen spaß mehr macht, überlasse ich die ergänzung der liste wem anderen.

[Narrensicher]

Zum Thema new und malloc: Hier wird auch oft davon abgeraten, malloc() zu verwenden. Als Begründung hört man, dass malloc() keine Konstruktoren aufruft, während new das idR schon tut.
Niemandem scheint es in den Sinn zu kommen, dass man mitunter genau das wünscht zu tun: Zwar den Speicher anfordern, aber (beispielsweise mangels Parameter für einen Konstruktoren) noch nicht unbedingt eine Objektkonstruktion wünscht. Auch soll es vorkommen, dass einige Klassen gar keinen Standardkonstruktor zur Verfügung stellen, sondern beispielsweise nur solche Konstruktoren, die ein Objekt aus zwei oder mehreren Parametern konstruieren sollen. In solchen Fällen klappt eine Speicheranforderung mittels new ohnehin nicht mehr. Weil es auch nicht in allen Fällen erlaubt ist, kurzerhand einen Konstruktor mit null Parametern zur Klasse hinzuzufügen, sieht man ziemlich alt aus, wenn man sich von vorne herein darauf festlegt, nur ja niemals malloc und immer nur 'new' verwenden zu wollen.
malloc() andererseits sind Konstruktoren schlichtweg gleichgültig, weil es nur den Speicher bereitstellt, nicht aber auch noch implizit ein Objekt initialisiert. Es gab einmal die Faustregel, dass EINE Funktion GENAU EINE Aufgabe erfüllen sollte. Das ist für malloc() der Fall.
Der Operator 'new' hingegen tut mal dieses, mal jenes, und wenn er irgendwo unbemerkt in einer riesigen Klassenhierarchie einmal überladen wurde, gar noch wesentlich seltsamere Dinge. Auf keinen Fall ist eindeutig vorhersagbar, was genau diese new-Funktion tut.

So gut gemeint die Streambibliotheken, Stringklassen und Standard Templates auch sein mögen, dadurch, dass die Funktionen 'mächtiger' geworden sind (d.h. mehr Funktionalität mit einem einzigen Aufruf bereitstellen), sind sie im gleichen Maße unflexibler und sogar fehleranfälliger geworden.
C++ wird immer ähnlicher wie JAVA oder BASIC, indem man DAU-sichere Containerklassen und Monsterfunktionen standardmäßig bereitstellt sowie die ganze Speicherverwaltung dem Programmierer aus der Hand nimmt. In den Containern sind teilweise komplexe Datenstrukturen und Algorithmen kurzerhand bereitgestellt, ohne dass der Programmierer es ahnen würde. Der moderne C++-Programmierer wird immer mehr zum Anwender vorgefertigter, verpackter Lösungen, deren Funktionsweise er in vielen Fällen gar nicht versteht.
Seltsamer Weise modellieren sie dann hübsche UML-Software-Architekturen für irgend eine riesige Anwendung, und halten den Entwurf dann aus Prinzip für gelungen. Wen wundert die verbuggte Software, die man heutzutage überall bekommt. Kein Wunder, die Leute sind zwar gut beim Entwurf von Software-Architekturen, aber bei der Implementierung einfacher Datenstrukturen gibt's Probleme (weil man ja auf die vorgefertigten Container zurückgreifen kann!).
Zur guten alten Hochzeit der Sprache C gab's zwar ebenfalls verbuggte Software, aber lange nicht in dem Umfang wie heutzutage. Gerade eben habe ich dreimal eine panische Kernel-Attacke der Ubuntu-Distribution erlebt, vielleicht sehe ich das auch nur unter diesem momentanen Eindruck so:
Software, die man heutzutage (ob gekauft oder frei ist egal) einsetzen möchte, ist in 90% der Fälle schlimm verbuggt. Und vermutlich liegt das daran, dass sehr viele Leute um jeden Preis 'nach dem Standard' programmieren, ohne sich allzu viele eigene Ideen zu machen. Vom Programmierer zum Anwender. In diese Richtung führt die Standardisierungswut, die seit einigen Jahren in vielen Bereichen um sich greift. Und Ausschaltung der individuellen Problemlösungskompetenz. Als Nebeneffekt.

However mfg

[David_pb]

::operator new( size )

Alloziert uninitialisierten Speicher, eqivaltent zu malloc(). Und der Standard legt Verhaltensregeln für überaldenene Operatoren new/[] fest an die man sich halten sollte. Wenn das nicht geschieht ist der Code halt nicht konform (=> soviel zum nicht einhalten des Standards) und ein Programm verhält sich u.U. ganz anders als geplant.

[queer_boy]

Narrensicher schrieb:

Zum Thema new und malloc: Hier wird auch oft davon abgeraten, malloc() zu verwenden. Als Begründung hört man, dass malloc() keine Konstruktoren aufruft, während new das idR schon tut.
Niemandem scheint es in den Sinn zu kommen, dass man mitunter genau das wünscht zu tun: Zwar den Speicher anfordern, aber (beispielsweise mangels Parameter für einen Konstruktoren) noch nicht unbedingt eine Objektkonstruktion wünscht. Auch soll es vorkommen, dass einige Klassen gar keinen Standardkonstruktor zur Verfügung stellen, sondern beispielsweise nur solche Konstruktoren, die ein Objekt aus zwei oder mehreren Parametern konstruieren sollen. In solchen Fällen klappt eine Speicheranforderung mittels new ohnehin nicht mehr. Weil es auch nicht in allen Fällen erlaubt ist, kurzerhand einen Konstruktor mit null Parametern zur Klasse hinzuzufügen, sieht man ziemlich alt aus, wenn man sich von vorne herein darauf festlegt, nur ja niemals malloc und immer nur 'new' verwenden zu wollen.
malloc() andererseits sind Konstruktoren schlichtweg gleichgültig, weil es nur den Speicher bereitstellt, nicht aber auch noch implizit ein Objekt initialisiert. Es gab einmal die Faustregel, dass EINE Funktion GENAU EINE Aufgabe erfüllen sollte. Das ist für malloc() der Fall.
Der Operator 'new' hingegen tut mal dieses, mal jenes, und wenn er irgendwo unbemerkt in einer riesigen Klassenhierarchie einmal überladen wurde, gar noch wesentlich seltsamere Dinge. Auf keinen Fall ist eindeutig vorhersagbar, was genau diese new-Funktion tut.

new macht genau das, was du willst. und wenn du nicht weißt, was du willst und es deshalb für dich unvorhersagbar aussieht, ist das dein problem.

wenn eine klasse keinen standardkonstruktor zur verfügung stellt, willst du z.b. malloc verwenden, um das zu umgehen? dann umgehst du auch völlig das, was sich die implementatoren der klasse gedacht haben - nämlich, dass man für eine instanz dieser klasse einen *besonderen* konstruktor aufrufen muss. und das geht mit new. mit malloc nur umständlich. die eine funktion, die new hat, lautet "instanziiere die klasse" - und das macht es auch. versuch mal, string so zu verwenden:

string *s = (string*)malloc(sizeof(string));
(*s) = "foo";

und das fliegt dir nicht um die ohren? dass konstruktoren aufgerufen werden sollen hat doch einen sinn, oder stimmst du mir da auch nicht zu?

malloc tut auch mal dieses, mal jenes: mal gibt es speicher zurück, mal NULL - es wäre genauso sinnlos, sich dann da darüber aufzuregen, dass es auch mal NULL zurückgeben kann, obwohl es ja eigentlich nur eine aufgabe, nämlich freien speicher zurückzugeben, hat.

So gut gemeint die Streambibliotheken, Stringklassen und Standard Templates auch sein mögen, dadurch, dass die Funktionen 'mächtiger' geworden sind (d.h. mehr Funktionalität mit einem einzigen Aufruf bereitstellen), sind sie im gleichen Maße unflexibler und sogar fehleranfälliger geworden.
C++ wird immer ähnlicher wie JAVA oder BASIC, indem man DAU-sichere Containerklassen und Monsterfunktionen standardmäßig bereitstellt sowie die ganze Speicherverwaltung dem Programmierer aus der Hand nimmt. In den Containern sind teilweise komplexe Datenstrukturen und Algorithmen kurzerhand bereitgestellt, ohne dass der Programmierer es ahnen würde.
Der moderne C++-Programmierer wird immer mehr zum Anwender vorgefertigter, verpackter Lösungen, deren Funktionsweise er in vielen Fällen gar nicht versteht.

und was man nicht versteht, darf man nicht verwenden?

Seltsamer Weise modellieren sie dann hübsche UML-Software-Architekturen für irgend eine riesige Anwendung, und halten den Entwurf dann aus Prinzip für gelungen. Wen wundert die verbuggte Software, die man heutzutage überall bekommt. Kein Wunder, die Leute sind zwar gut beim Entwurf von Software-Architekturen, aber bei der Implementierung einfacher Datenstrukturen gibt's Probleme (weil man ja auf die vorgefertigten Container zurückgreifen kann!).

du widersprichst dir selbst. wenn es einfache datenstrukturen gibt, auf die man zurückgreifen kann, gibt es weniger bugs, weil diese vorgefertigten container nämlich funktionieren. das problem haben die leute nur dann, wenn sie deinem rat folgen und selbst container implementieren, die es schon gibt. aber das tun sie ja nicht.

Zur guten alten Hochzeit der Sprache C gab's zwar ebenfalls verbuggte Software, aber lange nicht in dem Umfang wie heutzutage. Gerade eben habe ich dreimal eine panische Kernel-Attacke der Ubuntu-Distribution erlebt,

blöd nur, dass der linux kernel in C geschrieben ist, nicht?

[LordJaxom]

Hinzu kommt noch ein Punkt: Der Denkprozess des Menschen. Einem Anfänger, der bisher einmal void main gelesen hat, und darauf hingewiesen wird dass es int main heisst, wirft einen Schalter um und merkt sich int statt void. Jemand, der während des Lernprozesses monatelang void main schreibt (weil es so irrelevant ist), und dann verpflichtet wird nach Standard vorzugehen (pingelige Compiler, Firmenpolitik, whatever), wird garantiert aus Gewohnheit zunächst x-mal diesen einen Fehler machen, der später korrigiert werden muss.

[Simon2]

Ehrlich gesagt, ist mir eigentlich auch vollkommen Wurst, ob jemand "void main()" oder "#include<iostream.h>" schreibt ... was mich nur wurmt, ist , dass

• anscheinend noch sooo viele derartige Codeschnipsele im Internet, Tutorien, Büchern, .... (denn da schnappen sich Anfänger diese auf) herumfliegen, dass es immer wieder Anfänger auf den "non-standard-Weg" schickt (ohne dass sie eine Chance haben, es zu bemerken) und
• diese "Kleinigkeiten" IMO ein Indiz dafür sind, dass in diesen Quellen noch einiges mehr an "Nicht-Standardkonformem" vermittelt wird.
  [/quote]
  Gerade Anfänger hätten bestimmt nichts dagegen, gleich standardkonform zu lernen (auch, wenn vermutlich einige den Sinn dahinter noch nicht in der Tiefe durchschauen) .... und da macht es mich einfach fuchsig, dass man sie ohne Not auf die falsche Fährte schickt.

Gruß,

Simon2.

[Dummie]

Vielleicht sollte man erstmal das Wort Standard erklären:

Der Standard garantiert einfach, dass all die benutzen Funktionen auch auf anderen Betriebssystemen richtig funktionieren. Das Problem warum gerade viele Anfänger noch in nicht standardkonformen C++ programmieren ist wahrscheinlich damit zu begründen, dass es einfach noch im Internet VIELE alte Tutorials gibts... Einfach Seiten die niemand mehr interessieren und wo sich ein Anfänger freut eine "Aneleitung" zum Programmiere gefunden hat... Wie auch immer... Man sollte sich n JEDENFALL an den Standard halten