3. Objektreferenzen

Objektreferenzen

  • C

    Icematix schrieb:

    Hachja, die Bücher die einen anweisen "using namespace std;" zu schreiben, aber nicht erklären was das soll.

    In dem ganzen Buch kommt nicht einmal das Wort namespace vor, auch in keinem Code-Snippet/Auszug. Hier wird also ganz auf sie verzichtet.

    Hier werden konsequent gerne Funktionen und keine Methoden für die Klassen geschrieben 😕 Zum Beispiel bei der Operatorenüberladung schreibt man sich hier eine non-klassengebundene Funktion und keine Methode der respektiven Klasse.

    Auch schön: bool kennt hier scheinbar auch niemand.

    Im Übrigen verwirrt mich dieses Buch ein wenig ... ich sehe das hier in den C++-Codes meistens anders:
    Muss ich jetzt #include <something.h> schreiben oder reicht #include <something> ? 😕

    0
  • D

    Das kommt auf das File drauf an. Die Standardbibliothek Header haben in der Tat keine Endung, wogegen andere (vor allem selbstdefinierte) Header meist ein .h besitzen. Also halt immer das jeweils passende.

    0
  • N

    C-reator schrieb:

    Hier werden konsequent gerne Funktionen und keine Methoden für die Klassen geschrieben 😕 Zum Beispiel bei der Operatorenüberladung schreibt man sich hier eine non-klassengebundene Funktion und keine Methode der respektiven Klasse.

    Viele Operatoren wie +, * etc. werden üblicherweise als globale Funktionen implementiert; nicht zwangsläufig sind Memberfunktionen besser. Allerdings heisst das weder, dass das Buch gut ist, noch dass es in jenem Punkt Recht hat.

    C-reator schrieb:

    Im Übrigen verwirrt mich dieses Buch ein wenig ... ich sehe das hier in den C++-Codes meistens anders:
    Muss ich jetzt #include <something.h> schreiben oder reicht #include <something> ? 😕

    Für sämtliche Header der C++-Standardbibliothek musst du die Endung ".h" weglassen. Header der C-Standardbibliothek haben unter C++ ein vorgestelltes "c".

    // C++-Header
#include <iostream>
#include <string>
#include <iterator>

// C-Header
#include <cstdio>
#include <cstring>
#include <cctype>
    0
  • C

    Ah, okay. Und wo wird gerade dabei sind ... ich finde es wesentlich übersichtlicher, Klassen großzuschreiben - Java-Konvention.
    In C++ sind aber scheinbar String, Ifstream usw. alle kleingeschrieben.
    Kann ich dann auch z.B. String anstelle von string schreiben, also den Klassennamen doch groß?

    0
  • N

    C-reator schrieb:

    Kann ich dann auch z.B. String anstelle von string schreiben, also den Klassennamen doch groß?

    Wenn du die Klasse std::string aus der Standardbibliothek meinst, natürlich nicht. C++ ist case-sensitive. Bei eigenen Bezeichnern hast du die Freiheit, zu wählen.

    Hier fängts schon an mit dem Umgewöhnen. Die Standardbibliothek und Boost verwenden durchgängig unter_striche , freunde dich besser gleich mit ihnen an. Lös dich von Java und sei offen für Neues, sonst wird dir C++ massiv Mühe bereiten. Es wird auch so schon genügend schwierig. 😉

    0
  • N

    C-reator schrieb:

    Ah, okay. Und wo wird gerade dabei sind ... ich finde es wesentlich übersichtlicher, Klassen großzuschreiben - Java-Konvention.
    In C++ sind aber scheinbar String, Ifstream usw. alle kleingeschrieben.
    Kann ich dann auch z.B. String anstelle von string schreiben, also den Klassennamen doch groß?

    C++ unterscheidet zwischen Groß- und Kleinschreibung, also kannst du das nicht ohne weiteres. Aber du kannst dir natürlich einen typedef basteln (dient aber wohl nur dazu, andere Leute zu verwirren, die deinen Code lesen).
    Dass Klassennamen in der Standardbibliothek kleingeschrieben werden (dementsprechend wird das auch von Bibliotheken wie boost imitiert) halte ich für einen Designfehler, aber man gewöhnt sich dran (du kannst dir z.B. string wie int als "eingebauten" Typen denken, auch wenn std::string (davon abgesehen auch keine anderen Klassen) in C++ anders als String in Java keinerlei Sonderbehandlung genießt).
    Auch verspüre ich selten das Bedürfnis, meine Objekte string, vector oder ofstream zu nennen, das Problem von Namenskonflikten zwischen (Standard-)Klassen- und Objektnamen gibt es daher trotzdem nicht.

    0
  • C

    So eine Hilfsbereitschaft um die Uhrzeit ... find ich echt gut (:

    Ah gut, typedeffen (:

    Nach meinem Wissen wird ja der Inhalt einer .h-Datei, wenn ich sie inkludiere, an genau dieser Stelle eingefügt.
    Könnte man jetzt z.B. auch eine typedefs.h schreiben, in der für sämtliche Klassen, die man benutzt, typedefs wären, und sie dann in den jeweiligen anderen Headern/in der Main-Datei benutzen?

    Und mal wieder eine andere Frage:
    Warum ist C/C++ so extrem kryptisch, was Funktionen/Methoden und Klassen angeht?
    Wieso schreibt man denn bitte Input_Stream nicht aus? Wieso muss man die Funktion fgetc nennen?
    Was ist, wenn nun jemad Fremdes sich den Code durchliest, woher soll er vll. wissen, was die Methode ccbuf macht? create_char_buffer wäre da doch viel einleuchtender.
    Ich weiß nicht so recht, wie das "hier in C++" so abläuft, bei Java (nur ein Vergleich :D) haben sich die meisten an meines Erachtens nach meistens sinnvolle Konventionen gehalten (:

    Und jetzt genug der Regime-Kritik^^

    0
  • V

    C-reator schrieb:

    Ah gut, typedeffen (:

    Das klappt nicht gut.
    Die nächste Monate wirst Du am besten damit leben, daß std::- und boost::-Sachen einfach kleingeschrieben sind, fürchte ich. Weil das mit den typedefs sich nicht noch nicht lecker mit den Templates verträgt.
    Aber es ist überhaupt kein Problem, daß Du deine Klassen javaisch schreibst. Das ist dann auch eine nette Trenneung zwischen Anwendungscode und Bibliothekscode.

    0
  • N

    Nanyuki schrieb:

    Auch verspüre ich selten das Bedürfnis, meine Objekte string, vector oder ofstream zu nennen, das Problem von Namenskonflikten zwischen (Standard-)Klassen- und Objektnamen gibt es daher trotzdem nicht.

    Gerade bei vector muss ich dir da widersprechen. Die Bedeutung des Begriffs ist ja nicht auf Container, die ihren Speicher als dynamisches Array verwalten, beschränkt. Und über den Nutzen von Namensräumen müssen wir glaube ich nicht diskutieren. 😉

    Nanyuki schrieb:

    [...] auch wenn std::string (davon abgesehen auch keine anderen Klassen) in C++ anders als String in Java keinerlei Sonderbehandlung genießt).

    Mir fällt da gerade std::type_info als Gegenbeispiel ein.

    C-reator schrieb:

    Ah gut, typedeffen (:

    Nach meinem Wissen wird ja der Inhalt einer .h-Datei, wenn ich sie inkludiere, an genau dieser Stelle eingefügt.
    Könnte man jetzt z.B. auch eine typedefs.h schreiben, in der für sämtliche Klassen, die man benutzt, typedefs wären, und sie dann in den jeweiligen anderen Headern/in der Main-Datei benutzen?

    Mach das, wenn du auf wahnsinnigen Aufwand, totale Verwirrung bei anderen Programmierern, verunmöglichten Austausch, erhöhte Kompilierzeiten und einen zusätzlichen Header stehst, den du ständig mitschleppst.

    C-reator schrieb:

    Warum ist C/C++ so extrem kryptisch, was Funktionen/Methoden und Klassen angeht?
    Wieso schreibt man denn bitte Input_Stream nicht aus? Wieso muss man die Funktion fgetc nennen?

    Ähm, fgetc ist C. std::istream wäre der Input-Stream.

    C-reator schrieb:

    woher soll er vll. wissen, was die Methode ccbuf macht? create_char_buffer wäre da doch viel einleuchtender.

    Sag mir bitte, wo ich die Funktion ccbuf finde...

    C-reator schrieb:

    Ich weiß nicht so recht, wie das "hier in C++" so abläuft, bei Java (nur ein Vergleich :D) haben sich die meisten an meines Erachtens nach meistens sinnvolle Konventionen gehalten (:

    Du mit deinen Vergleichen. Du kannst das schon machen, wenn du dich allerdings ständig an solchen Kleinigkeiten störst, wirst du nicht weiterkommen. Du solltest auch bedenken, dass Java viel jünger als C++ ist, sich sehr viele Dinge dort abgeschaut hat und davon einen Teil besser gelöst hat, einen Teil schlechter. 😃

    Aber eine andere Frage: Warum bleibst du nicht bei Java? Ich hab das Gefühl, dort bist du besser aufgehoben.

    0
  • C

    Nexus schrieb:

    Aber eine andere Frage: Warum bleibst du nicht bei Java? Ich hab das Gefühl, dort bist du besser aufgehoben.

    Wie fies von dir ;P
    Weil ich auch mehr sehen möchte, als nur die Java-Welt. Ich mag das Programmieren und habe mit VB angefangen, über ein paar Nischensprachen bishin zu Java. Und jetzt, nachdem ich meiner Meinung nach genug Zeit mit Java verbracht habe, zumal wir das jetzt selbst in der Schule abhandeln, möchte ich meinen Horizont erweitern, einen Schritt weitergehen und mich C++ zuwenden; natürlich weiß ich, dass es nichts Einfaches ist, aber ich habe mir gedacht, wenn ich die Java-Grundlagen beherrsche, wird es für mich mit Sicherheit nicht so schwer sein, als würde ich ganz von 0 bei C++ anfangen - wobei es ja noch genug Neues zu lernen gibt.
    Und genau deshalb - womöglich auch, weil ich erst gestern mit C++ angefangen habe - schwirren bei mit immer noch so ein paar Javagedanken herum, die ich versuche, auf C++ überzuleiten.
    Noch Fragen? ;P

    0
  • N

    Ein typedef.h finde ich nicht verkehrt, verwende ich auch in all meinen Projekten.
    Wenn auch nur für uint, ulong und byte. Früher oder später wird man es leid, unsigned (int) und unsigned char auszuschreiben (und behindert manchmal auch einfach die Leserlichkeit - std::map<unsigned int,std::pair<unsigned int,unsigned int> >?).

    Mir fällt da gerade std::type_info als Gegenbeispiel ein.

    Ach stimmt, so völlig frei von Sonderbehandlungen ist C++ in der Richtung doch nicht.

    0
  • N

    C-reator schrieb:

    Wie fies von dir ;P

    Ich habe das nicht böse gemeint, aber bei deiner Einstellung ist es mir wirklich so vorgekommen, als wäre Java besser für dich. Ich meine, es ist nunmal nicht möglich, Java in C++ zu programmieren. Klar wird man anfangs viele neue Dinge nicht verstehen und Mühe haben - aber man sollte vorerst darüber hinwegsehen und auch die Chancen erkennen, die einem eine neue Programmiersprache bieten. Meiner Meinung nach behindert eine negative, voreingenommene Sichtweise diesen Vorgang eher. Kritik ist zweifellos nicht daneben - aber viele Dinge klären sich von selbst, wenn man sich bereits eine Weile mit der Sprache beschäftigt hat.

    Nanyuki schrieb:

    Ein typedef.h finde ich nicht verkehrt, verwende ich auch in all meinen Projekten.
    Wenn auch nur für uint, ulong und byte. Früher oder später wird man es leid, unsigned (int) und unsigned char auszuschreiben (und behindert manchmal auch einfach die Leserlichkeit - std::map<unsigned int,std::pair<unsigned int,unsigned int> >?).

    Solche Container schreibe ich eigentlich nie aus. Ich habe immer mehrere typedef s:

    typedef std::pair<unsigned int, unsigned int>    coordinate;
typedef std::map<unsigned int, coordinate>       index_map;

    Oder:

    typedef std::set<anything, my_compare, my_alloc> anything_set;
typedef anything_set::iterator                   anything_iterator;

    Hat den zusätzlichen Vorteil, dass man vom eigentlichen Typen abstrahiert und diesen bei Bedarf sehr leicht auswechseln kann. Aber uint und solche allgemeinen Typdefinitionen kann ich nachvollziehen (was ist mit size_t ?). Und byte gegenüber char verwendest du wahrscheinlich, wenns um abstrakte Bytefolgen und nicht um Zeichen geht, richtig? Sonst sehe ich nicht gerade einen Vorteil.

    0
Anmelden zum Antworten