Methoden in separater Datei definieren?

[Bjoern Strohstrumpf (Gast)]

Hallo guten Tag,
ich habe eine Klassenbeschreibung in einem Headerfile.
Unter dieser wollte ich eine Definition von einigen Methoden 
durchführen.
Aber es scheint nicht zu klappen.
Wenn ich die Definition in eine .cc Datei schreibe funktioniert es ...
Auch wenn ich einen Operator überladen möchte muss ich das in einer 
seperaten Datei machen.
Aber warum?

multiple definition of `CClass::extraFileWhy()';

Danke sehr

[Ein T. (ein_typ)]

Bjoern Strohstrumpf schrieb:
>

> multiple definition of `CClass::extraFileWhy()';
>

Wie sieht Dein Code denn aus?

[DerEinzigeBernd (Gast)]

Bjoern Strohstrumpf schrieb:
> ich habe eine Klassenbeschreibung in einem Headerfile.
> Unter dieser wollte ich eine Definition von einigen Methoden
> durchführen.

Meinst Du so etwas:

class bla
{
  bla();
  ~bla();

  int fusel();
}

int bla::fusel()
{
  return (1);
}

> Aber es scheint nicht zu klappen.

Richtig, denn das ist falsch. Die Implementierung der Funktionen 
("Methode" nennt man das nur in anderen Programmiersprachen) gehören in 
die Klassendeklaration oder eine getrennte Quelltextdatei (*.cpp oder 
was auch immer die Religion vorgibt)

Für ersteres also

class bla
{
  bla();
  ~bla();

  int fusel()
  {
    return (1);
  }
}

[Bjoern Strohstrumpf (Gast)]

DerEinzigeBernd schrieb:
> gehören

Weiß jemand warum?

[Thomas F. (tommf)]

Bjoern Strohstrumpf schrieb:
> Weiß jemand warum?

Weil bei der Definition der Funktion deren Code erzeugt wird. Dies ist 
im Gensatz zur Deklaration, wo nur angeben wird, dass es die Funktion 
mit bestimmten Parametern und Rückgabetyp gibt. Die Headerdatei wird 
i.d.R. in mehrere Sourcedateien eingebunden. Enthält sie 
Funktionsdefinitionen, werden diese dadurch auch in den verschiedenen 
Objektdateien erzeugt. Der Linker findet dann mehrere identische 
Funktionen und gibt den oben angegebenen Fehler aus.

[Bjoern Strohstrumpf (Gast)]

Thomas F. schrieb:
> Bjoern Strohstrumpf schrieb:
>> Weiß jemand warum?
>
> Weil bei der Definition der Funktion deren Code erzeugt wird. Dies ist
> im Gensatz zur Deklaration, wo nur angeben wird, dass es die Funktion
> mit bestimmten Parametern und Rückgabetyp gibt. Die Headerdatei wird
> i.d.R. in mehrere Sourcedateien eingebunden. Enthält sie
> Funktionsdefinitionen, werden diese dadurch auch in den verschiedenen
> Objektdateien erzeugt. Der Linker findet dann mehrere identische
> Funktionen und gibt den oben angegebenen Fehler aus.

Also ich deklariere in class.hpp meine Klasse. Diese wird dann bei 
class.cpp eingefügt wegen #include?

Dann wird die Deklaration wieder in main.cpp mit define eingefügt.

Dem Compiler mache ich über gcc main.c class.cpp bekannt welche Dateien 
es gibt.

Warum muss man eigentlich nicht die Headerdatei angeben? Findet der 
Linker die dann über den Pfad in include im Ordner ?

class.hpp

class class{
 class();
};

class.cpp

#include "class.hpp"
class::class(){}

main.cpp

include "class.hpp"
int main(){
 return 1;
}

[Bob the Belcher (Gast)]

Hallo

Thomas F. schrieb:
> Weil bei der Definition der Funktion deren Code erzeugt wird. Dies ist
> im Gensatz zur Deklaration, wo nur angeben wird, dass es die Funktion
> mit bestimmten Parametern und Rückgabetyp gibt. Die Headerdatei wird
> i.d.R. in mehrere Sourcedateien eingebunden. Enthält sie
> Funktionsdefinitionen, werden diese dadurch auch in den verschiedenen
> Objektdateien erzeugt. Der Linker findet dann mehrere identische
> Funktionen und gibt den oben angegebenen Fehler aus.

Leicht O.T.

Sicherlich sind deine Ausführungen korrekt und du scheinst dich auch 
angestrengt haben klar und deutlich zu erklären.

Aber:
Wenn man das (stellvertretend eigentlich für alle Texte und 
"Erklärungen" aus dem Umfeld)  so durchliest:

Wer wundert sich eigentlich ernsthaft das es gefühlt Ewigkeiten dauert 
bis man auch nur andeutungsweise durchblickt wie Programmierung, ganz 
unabhängig von der jeweiligen Sprache,  funktioniert - bis man 
andeutungsweise ein Bauchgefühl für Programmierung erlangt.

Das muss doch auch besser gehen - aber abgesehen von arg eingeschränkten 
"Kinderprogrammiersprachen" die meist auch noch Produkt bezogen sind und 
mit "echter" Programmierung wenig zu tun hat, habe ich bis jetzt noch 
keine Programmiersprache kennengelernt die man als erste "richtige" 
Programmiersprache einfach versteht und eine nachvollziehbare 
Alltagslogik hat sondern immer komische Konzepte, kryptische  und 
doppeldeutige Bezeichnungen, 1001 Verweise, Abhängigkeiten über 20 Ecken 
usw.

Wenn man einmal irgendwie einmal das Konzept verstanden hat dann sind 
neue Programmiersprachen auch nur noch keines Problem - nur es dauert 
und zumindest von mir kann ich es nicht sagen wie, warum  und wann ich 
die Konzepte und das komische "Denken dahinter" verstanden hatte.

(Bei mir hat es irgendwann mal Klick gemacht - aber was der Auslöser war 
kann ich nicht erklären -

Und was das Erklären angeht: Ich selbst könnte einen absoluten Anfänger 
auch nicht die Ideen und das komische Denken hinter "richtigen" 
Programmiersprachen erklären - scheinbar kann das wohl aber auch 
niemand wie ich es selbst erfahren musste)

[Luitpold (Gast)]

Bob the Belcher schrieb:
> Wer wundert sich eigentlich ernsthaft das es gefühlt Ewigkeiten dauert
> bis man auch nur andeutungsweise durchblickt wie Programmierung, ganz
> unabhängig von der jeweiligen Sprache,  funktioniert - bis man
> andeutungsweise ein Bauchgefühl für Programmierung erlangt.

Nein. Ernstgemeinte Werkzeuge erfordern, daß man sich mit ihnen länger 
als fünf Minuten auseinandersetzt. Es sind keine Kinderspielzeuge, und 
sie sind auch nicht dafür da, als Lernwerkzeuge genutzt zu werden, 
sondern zum Arbeiten.

Bob the Belcher schrieb:
> habe ich bis jetzt noch
> keine Programmiersprache kennengelernt die man als erste "richtige"
> Programmiersprache einfach versteht

Nicht jedem ist es gegeben, mit Programmiersprachen zu arbeiten. Das ist 
nicht weiter schlimm, nicht jeder kann Noten lesen, Bilder malen oder 
erträglich Geige spielen. Und nicht jeder hat das Zeug, mehrere 
Fremdsprachen zu erlernen, oder Mathematik, oder auch das Reiten.

Wieso sollten Programmiersprachen etwas sein, was man "einfach 
versteht"? Was ist das für ein merkwürdiges Anspruchsdenken?

[Ein T. (ein_typ)]

Bjoern Strohstrumpf schrieb:
> Also ich deklariere in class.hpp meine Klasse. Diese wird dann bei
> class.cpp eingefügt wegen #include?

Genau, #include kopiert den Inhalt der Datei einfach.

Deswegen verwendet man sogenannte Include Guards, um ein mehrfaches 
Einbinden derselben Deklarationen und Definitionen zu unterbinden.

> Warum muss man eigentlich nicht die Headerdatei angeben? Findet der
> Linker die dann über den Pfad in include im Ordner ?

Ja.

[DerEinzigeBernd (Gast)]

Ein T. schrieb:
>> Warum muss man eigentlich nicht die Headerdatei angeben? Findet der
>> Linker die dann über den Pfad in include im Ordner ?
>
> Ja.

Nein.

Der Linker bekommt keine dieser Dateien zu Gesicht, der sieht nur die 
vom Compiler aus diesen Dateien erzeugte Objektdatei. Die heißt oft *.o 
(aber das ist nicht standardisiert, manche Compiler verwenden auch 
*.obj).

Der Linker packt alle zum Projekt gehörenden Objektdateien und den 
Startup-Code zusammen und versucht, alle externen Referenzen dadurch 
aufzulösen, daß er in allen übergebenen Libraries* nach diesen 
Referenzen sucht und bei Treffern die jeweilige Objektdatei aus der 
Library herauslöst und zum Programm dazupackt.

*) oft *.a, bei manchen Systemen aber auch *.lib

[Wilhelm M. (wimalopaan)]

Bjoern Strohstrumpf schrieb:
> Also ich deklariere in class.hpp meine Klasse. Diese wird dann bei
> class.cpp eingefügt wegen #include?

Ja.
#include ist eine Präprozessor-Direktive. Und der Präprozessor ist ein 
nicht-interaktiver Editor.

> Dann wird die Deklaration wieder in main.cpp mit define eingefügt.

Ja.

> Dem Compiler mache ich über gcc main.c class.cpp bekannt welche Dateien
> es gibt.

Strenggenommen dem Compiler-Frontend, was (theoretisch) Präprozessor / 
Compiler für jede Übersetzungseinheit aufruft und am Ende den Linker.

> Warum muss man eigentlich nicht die Headerdatei angeben?

Die hat der Präprozessor ja schon in die Quelldatei "hinein editiert".

> Findet der
> Linker die dann über den Pfad in include im Ordner ?

Nein (s.o.).

Damit wir hier diese Grundlagen der Compilation bzw. was bedeutet 
Deklaration und was ist eine Definition inklusive der ODR wiederholen 
müssen, nimm einfach mal ein C++ Buch zur Hand ;-)