3. OOP Problem

OOP Problem

  • Z

    Hallo
    ich steige gerade von c auf c++ um und hab jetzt versucht mir die Objektorientierung näher anzusehen. Um zu testen wie man mit klassen und objekte umgeht hab ich mir mal kurz was gebastelt was mi aber nen Compilerfehler ausspuckt. Bin am verzweifeln.
    Ihr werdet den Fehler bestimmt gleich sehen aber ich hab da grad kein Blick für.
    Hier der Code:

    main.cpp

    #include <iostream>
#include "funktion.h"

using namespace std;

int main(void)
{
	funktion funk;
	cout<<"dieses Programm: ";
	funk.print();
	return 0;
}

    funktion.h

    class funktion
{
	public: void print(void);
};

    funktion.cpp

    #include <iostream>

using namespace std;

void print(void)
{
	cout<<"laeuft"<<endl;
}

    Das ist der Fehler den ich ständig bekomme:
    main.cpp:(.text+0x88): undefined reference to `funktion::print()'

    Compilieren tue ich das ganze mittels g++:
    g++ -o main main.cpp funktion.cpp

    Irgendetwas übersehe ich.
    Danke für Hilfe. Dreh fast durch.

    0
  • B
     

    void funktion::print(void)
{
    cout<<"laeuft"<<endl;
}

    🙂

    0
  • Z

    Danke für die schnelle Antwort
    aber immernoch fehler:

    funktion.cpp:5: Fehler: »funktion« wurde nicht deklariert

    Muss ich funktion.h noch in funktion.cpp includieren??

    0
  • Z

    Ok Danke hab zusatzlich noch funktion.h in funktion.cpp includiert
    Und jetzt nix Fehler mehr und das Programm sagt:
    dieses Programm: läuft

    🙂

    Danke nochmal

    0
  • U

    in C++ ist es eher unüblich void in die Parameter-Liste zu schreiben - wird vielerorts auch als schlechter Stil angesehen...

    außerdem ist es denke ich auch net sonderlich intuitiv ne klassen "funktion" zu nennen 😛

    und die include-guards in der header-Datei hast du nur nicht mitgepostet?!

    bb

    0
  • Z

    Ok danke.
    Aber wie gesagt war nurmal n kurzer test um mir die funktion von klassen näher zu bringen.
    Also in der header datei steht wirklich nix anderes drin als das was ich gepostet hab.
    Was sollte denn da noch rein??

    0
  • U

    google mal nach "include-guards"

    als kurze zusammenfassung:

    #infdef EINDEUTIGER_BEZEICHNER
#define EINDEUTIGER_BEZEICHNER

/*klassen/funktionen/... deklarieren*/

#endif //#ifndef EINDEUTIGER_BEZEICHNER

    mehrere IDEs stellen auch ein #pragma once bereit - das würde man dann so nutzen:

    irgend nen header den man überall einbindet sollte das enthalten:

    #if defined _MSC_VER
	#if _MSC_VER >= 1020
		#define PRAGMA_ONCE_ENABLED
	#endif
#elif defined __GNUC__
	#ifndef PRAGMA_ONCE_ENABLED
		#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)
			#define PRAGMA_ONCE_ENABLED
		#endif
	#endif
#endif

    und dann kann man den header entsprechend so schreiben:

    #if PRAGMA_ONCE_ENABLED
   #pragma once
#endif

#ifndef EINDEUTIGER_BEZEICHNER
#define EINDEUTIGER_BEZEICHNER

/*...*/

#endif //#ifndef EINDEUTIGER_BEZEICHNER

    #pragma once hat ein paar Vorteile (Datei wird nur ein einziges mal geöffnet und geparst - mit nur include-guards würde sie trotzdem jedes mal geöffnet werden wenn sie included wurde und erst beim parsen wird gemerkt, dass sie nicht gebraucht wird). Was den Compilier-Vorgang natürlich beschleunigt (wenn man #pragma once verwendet ^^).

    bb

    0
  • D

    Was würde denn passieren wenn #pragma once ohne makro dastehen würde? Außerdem darf #pragma once auch ruhig nach dem Includeguard kommen! 🙂

    0
  • Z

    ok jetzt bin ich schlauer 🙂
    vielen Dank
    Werd gleich mal n bisschen damit rumprobieren
    Wünsch euch noch nen schönen Tag 🙂

    0
  • U

    David_pb schrieb:

    Was würde denn passieren wenn #pragma once ohne makro dastehen würde?

    Hmm... Ich hab keine IDE hier, die #pragma once nicht versteht - aber vermutlich wird eine Fehlermeldung á la ungültige Präprozessor-Direktive kommen. Bei GCC weiß ich aber z.Bsp., dass er #pragma once geschluckt hat, als er es noch nicht kannte und einfach nur ignoriert hat ^^

    Ich jedenfalls würde keinen Code schreiben wollen der mit anderen IDEs evtl nicht funktioniert - und wenn der jenige dann x Dateien verändern muss ists für den au ne so doll ^^ lieber schreib ich dann immer 3 anstatt einer Zeile ^^

    David_pb schrieb:

    Außerdem darf #pragma once auch ruhig nach dem Includeguard kommen! 🙂

    Klar darf es das - es darf auch als allerletztes in der Datei stehen... Je nach dem, was man bevorzugt...

    bb

    0
  • D

    Ich meine im Standard steht, dass eine nicht erkannte #pragma Direktive ignoriert werden soll. Wenn die IDE sich also mehr oder weniger konform verhält dürfte das also eigentlich keine Probleme geben, oder?

    0
  • V

    ok, sie macht keinen fehler.
    aber die warning nervt ungemein.

    0
  • U

    volkard schrieb:

    ok, sie macht keinen fehler.
    aber die warning nervt ungemein.

    welche ide haste denn jz ausgekramt? ^^

    0
  • N

    Wenn man sich schon Gedanken wegen der Präprozessorgeschwindigkeit macht, sollte man auch die Performance der #if -Abfrage bedenken... 🙄

    0
  • U

    Nexus schrieb:

    Wenn man sich schon Gedanken wegen der Präprozessorgeschwindigkeit macht, sollte man auch die Performance der #if -Abfrage bedenken... 🙄

    sehr qualifizierter beitrag... außerdem hab ich mal gehört, dass ram und cpu um weiten schneller sind als festplatten... 🙄 deshalb wird es wohl ziemlich schwer so viele #if s zu verwenden, dass der Vorteil von#pragma once` wieder verschwindet...
    btw ging es auch net um die geschwindigkeit des präprozessors - sondern um die dauer des compilierens 😛

    bb

    0
Anmelden zum Antworten