3. Elementfunktion sei in Klasse nicht deklariert

Elementfunktion sei in Klasse nicht deklariert

  • X

    verzeiht bitte meinen fehler
    405 und 406 meinte ich

    0
  • M

    Xx_Mephisto_xX schrieb:

    uint16 long

    Was soll das denn sein?

    0
  • S

    Naja, erstens meinte ich, dass du den Inhalt der Funktionen ruhig rauslassen kannst, statt

    IMAGE::IMAGE(const IMAGE & img){
// image = TIFFOpen("newFile.tif", "w");
 bps = new uint16;
 *bps = *(img.bps);
 spp = new uint16;
 *spp = *(img.spp);
 rowsps = new unsigned long;
 *rowsps = *(img.rowsps);
 width = new uint32;
 *width = *(img.width);
 height = new uint32;
 *height = *(img.height);
 scanlineSize = new int;
 *scanlineSize = *(img.scanlineSize);
 bufferSize = new unsigned long;
 *bufferSize = *(img.bufferSize);

 buffer = new uint16[*bufferSize+1];
 for(unsigned int i=0; i < *bufferSize; i++) buffer[i] = img.buffer[i];
}

    also

    IMAGE::IMAGE(const IMAGE & img)
{
}

    Aber was falsches kann ich nicht erkennen. Mein Compiler zeigt mir (zu Recht) tausende Fehler, weil er die Hälfte von deinen Funktionen und Klassen (der Tiff kram) natürlich nicht kennt.

    0
  • X

    UInt16 sind ganze Zahlen ohne Vorzeichen mit Werten zwischen 0 und 65535

    habe ich irgendwo "uint16 long" stehen? 😮

    0
  • S

    Nein eigentlich nicht. Ich weis nicht wie er daauf kommt

    0
  • M

    Zeile 310. Seh ich schon Ufos?

    0
  • X

    @Skym0sh0:

    Tut mir leid, als ich deinen Beitrag gelesen hatte, war es schon zu spät 😞
    Ja ich benutze die Libtiff

    0
  • X

    @MFK

    Vielen Dank, dass habe ich gleich mal geändert 😉
    (weiß garnicht, warum da nicht mal eine Warnung kam)

    Damit änderte sich aber leider nicht mein Problem 😞

    0
  • S

    MFK schrieb:

    Zeile 310. Seh ich schon Ufos?

    Möp. oO

    Ich hab per Textsuche das dezent überlesen 😣

    0
  • ?

    Nur mal so aus der Luft gegriffen:

    Könnte es sein, dass du dein Projekt kompiliert hast, bevor du test() und invert() implementiert hast?

    Ansonsten kann ich mir nichts anderes vorstellen was an dem Code falsch sein könnte, sodass der Compiler eine derartige Fehlermeldung ausspuckt.

    0
  • X

    @hmhmhm:

    Also ich habe jetzt jede einzelne Komponente (ob .h oder .cpp) gespeichert und alles nochmal versucht zu kompilieren. Aber die Fehlermeldung ist leider nach wie vor noch die selbe. 😞

    0
  • ?

    'tschuldigung, umgekehrt:

    *könnte es sein, dass du test() und invert() implementiert hast, bevor du sie in der klasse deklariert hast?

    Und "uint16 long" hat echt keine Fehlermeldung rausgeworfen? Welche Compiler-Version von G++ hastn?

    0
  • ?

    Xx_Mephisto_xX schrieb:

    Damit änderte sich aber leider nicht mein Problem 😞

    Wenn ich Header und Implementierung in ein File kopiere, kann ich (nachdem ich einen c'tor nach hinten in der Datei verschoben habe) alles kompilieren.

    Kompilierst Du das richtige? 🙂

    0
  • X

    Also meine gxx-Version:
    g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3

    und ich kompiliere wie folgt:

    g++ -Wall main.cpp image.cpp hist.cpp -ltiff -o ausgabe

    0
  • ?

    Das ist zwar ein wenig wie Schnitzeljagd, aber bau doch mal einen ganz offensichtlichen Fehler ein.
    Z.B. ein unmotiviertes

    SCHIRSCHADENDUDEL

    mitten im Quelltext des Headers. Wenn das wirklich der Header ist, der eingebunden wird, fällt Dir das auf die Füsse.
    (Und ich denke der gepostete Header ist nicht der, den der Compiler sieht.)

    0
  • X

    g++ meinte ich statt gxx ^^

    Kann es sein, dass ich beim includieren etwas falsch mache?
    ich includiere "image.h" sowohl in der main.cpp als auch in der hist.h

    hier die hist.h:

    #ifndef HIST_H
#define HIST_H

#include "image.h"

class HIST{
public:

HIST(IMAGE&);

 unsigned int GetHistBufferValue(int);
 unsigned int GetHistSize();
 int FindMax();

 void PrintHist();

 void test();

private:
 IMAGE* img;
 unsigned long histSize;
 unsigned long *histBuffer;
};

#endif

    und die main.cpp (besteht mittlerweile aus auskommentierten Quelltexten)

    #include <iostream>
#include <stdio.h>
//#include <string.h>

#include "image.h"
#include "hist.h"

using namespace std;

int main(){
return 0;
}
    0
  • X

    SCHIRSCHADENDUDEL springt nun mitten aus meiner classIMAGE hervor 😉

    g++ -Wall main.cpp image.cpp hist.cpp -ltiff -o ausgabe
In file included from main.cpp:5:0:
image.h:83:1: Fehler: »SCHIRSCHADENDUDEL« bezeichnet keinen Typ
image.cpp:405:20: Fehler: keine Elementfunktion »void IMAGE::invert()« in Klasse »IMAGE« deklariert
image.cpp:406:18: Fehler: keine Elementfunktion »void IMAGE::test()« in Klasse »IMAGE« deklariert
In file included from hist.h:4:0,
                 from hist.cpp:1:
image.h:83:1: Fehler: »SCHIRSCHADENDUDEL« bezeichnet keinen Typ
make: *** [all] Fehler 1
    0
  • S

    Solange du Includeguards hast, sollte beim Inkludieren nichts falsches passieren, und die hast du ja.

    Hast du zyklische Abhängigkeiten?
    A inkludiert B und umgekehrt (eventuell über mehrere Indirektionen)

    0
  • X

    Leider kommt jetzt meine c++-Unkenntnis zum tragen.
    Was versteht man unter einer Indirektion?
    Ich hatte mal etwas von einer Überladung des -> Operators gelesen. Ist es das?

    folgende include-beziehungen habe ich derzeit:

    main includiert : - image - hist
    hist includiert : - image

    Also wäre die Antwort A includiert B aber nicht umgekehrt

    0
  • K

    Mal abgesehen vom eigentlichen Problem (wo man im Moment nur raten kann, weil du kein vollständiges aber reduziertes Beispiel zeigst, was dieses Problem noch hat) möchte ich ein paar Takte zum Stil/Design sagen.

    Verwende Bezeichner wie "IMAGE", die nur aus Großbuchstaben bestehen, nur für Makros. Dann besteht auch keine Verwechslungsgefahr zwischen Makros und nicht-Makros. Das ist eigentlich Konvention so.

    class IMAGE
{
public:
  ...
private:
  TIFF* image;
 
  char *imageName;
  uint16 *buffer;
 
  uint32 *width, *height;
  uint16 *bps, *spp;
 
  unsigned long *rowsps, *bufferSize;
  int *scanlineSize;

    Das ist sehr ungeschickt. Du musst mit deiner Klasse per eigenem Kopierkonstruktor, Destruktor und Zuweisungsoperator schon das dynamisch allozierte TIFF-Dingen verwalten. Das reicht eigentlich schon. Klassen zu bauen, die gleich ganz viele verschiedene Resourcen verwalten, sind fehleranfällig. Es besteht auch überhaupt keine Notwendigkeit in Deinem Fall den Rest auch per new anzulegen:

    class TiffImage
{
public:
  ...
private:
  void* image;

  std::string filename;
  std::vector<uint16> buffer;

  uint32 width, height;
  uint16 bps, spp;

  unsigned long rowsps, bufferSize;
  int scanlineSize;

    Hier musst du dich im Prinzip nur noch um 'image' kümmern bzgl Freigabe/Kopieren. Die Typen der restlichen Datenelemente haben jetzt schon von Haus aus das richtige Kopierverhalten.

    Aus 'image' habe ich hier noch einen void*-Zeiger gemacht, damit du in diesem Header nicht den Tiff-Header inkludieren musst. In image.cpp brauchst du dann aber einen static_cast.

    Was ich nicht ganz so schön finde, ist, dass du all die möglichen Bildverarbeitungsalgorithmen als Elementfunktion in diese Klasse gepackt hast. Der C++-Weg sieht eher anders aus. Da verwendest du eine solche Klasse nur dazu, um Bilder per Objekte zu speichern. Die Algorithmen kann man dann als Funktionstemplate aufschreiben. Als Bindeglied muss man ggf andere Konzepte einführen, so ähnlich wie es in der Standardbibliothek die Iteratoren gibt. Aber das ist nur ein Tipp für die Zukunft.

    0
Anmelden zum Antworten