Vergeleich von Pointer auf Struct

[Steffen Graap (Gast)]

Hallo

Der folgende Code wird so ähnlich in einem Programm für einen ARM 
benutzt. Compiliert wird der Code mit Keil, und dieser hat keine Fehler.

Für automatisierte Test's wird der selbe Code nun mit einem GCC 
compiliert, um in CUTE dann die Teste auszuführen.
Der GCC hat aber mit dem Vergeleich der beiden Pointer ein Problem und 
endet mit der Fehlermeldung "Could not find operator>= for type bool".

Hier soll aber nicht Verglichen werden ob Klasse pWritePosition >= 
Klasse pEndPosition ist, sondern ob die Speicherposition pWritePosition 
die Speicherposition pEndPosition überschritten hat.
Wie bekomme ich den GCC dazu dies zu machen? Gibt es eine 
Compileroption? Eine Codeänderung möchte ich nicht machen, da der 
Keilcompiler ja kein Problem hat.
Danke schon ma im Vorraus.

#pragma pack(1)
typedef struct  /**< Struktur eines TLV Kopfes ( T & L & 1.V) */
{
unsigned short  tag;       /**< Der Tag   */
unsigned short  length;    /**< Die Längel  */
char     startValue;       /**< 1. Char des Inhaltes  */
} TLVHead_Def;
#pragma pack()


void foo(void)
{
   TLVHead_Def* pWritePosition, pEndPosition;

   if(pWritePosition >= pEndPosition)
   {
      mach was;
   }
}

Gruß Steffen

[Thomas W. (thomas100)]

Hallo Steffen,

bist du dir sicher, dass das 100% der gleiche Code ist?

TLVHead_Def* pWritePosition, pEndPosition;

pEndPosition ist kein Pointer auf TLVHead_Def, sondern eine Variable vom 
Typ TLVHead_Def.

Also entweder

void foo(void)
{
   TLVHead_Def *pWritePosition, *pEndPosition;

   if(pWritePosition >= pEndPosition)
   {
      mach was;
   }
}

oder

void foo(void)
{
   TLVHead_Def *pWritePosition, EndPosition;

   if(pWritePosition >= &EndPosition)
   {
      mach was;
   }
}

VG
Thomas

[Steffen Graap (Gast)]

Alaso ich meine es so:

void foo(void)
{
   TLVHead_Def* pWritePosition;
   TLVHead_Def* pEndPosition;

   if(pWritePosition >= pEndPosition)
   {
      mach was;
   }
}

entspricht deiner ersten Variante, ist mir bei der Abänderung des Codes 
für das Forum ein kleiner Fehler unterlaufen. Die beiden Variablen sind 
eigentlich private Variablen der Klasse in der der Code ausgeführt wird.

Ändert aber an der Fehlermeldung nichts.

Wenn ich einen der beiden Pointer auf void caste, dann läuft es.
In etwa so:

void foo(void)
{
   TLVHead_Def* pWritePosition;
   TLVHead_Def* pEndPosition;

   if((void* )pWritePosition >= pEndPosition)
   {
      mach was;
   }
}

Aber wie gesagt, möchte ich nichts am Code ändern.

Gruß Steffen

[Peter II (Gast)]

Ich bin mir zwar nicht sicher, aber es kann durchaus sein das das 
überhaupt nicht zulässig ist.

Es macht ja auch überhaupt keinen Sinn pointer auf größer zu 
vergleichen. Nur weil wir es uns immer als Adresse vorstellen muss es 
noch lange keine wirkiche zahl sein.

Auf == prüfen ist klar definiert. Aber größer oder kleiner? Wozu 
brauchst du soetwas denn?

(Mich wird bestimmt gleiche jemand korrigieren wenn es falsch ist)

[Karl H. (kbuchegg)]

Steffen Graap schrieb:
> Alaso ich meine es so:

Dann schreibs auch so, wie du es meinst.
Wenn du dir nicht sicher bist, was du tust, dann schreib pro 
Variablendefinition nur EINE Variable.

>    TLVHead_Def* pWritePosition;
>    TLVHead_Def* pEndPosition;

Ganz genau so.



> Ändert aber an der Fehlermeldung nichts.

Dann zeig deinen richtigen Code.
Denn das diese Fehlermeldung mit dem gezeigten Code nichts zu tun hat, 
zeigt sich schon darin, dass der Compiler einen Datentyp 'bool' 
anspricht, in deinem Codefetzen aber weit und breit von einem bool 
nichts zu sehen ist.

> Wenn ich einen der beiden Pointer auf void caste, dann läuft es.

und ist ziemlich sicher falsch.
Mit einem derartigen Cast sagst du dem Compiler hauptsächlich eines: 
Halt die Klappe!

[Karl H. (kbuchegg)]

Peter II schrieb:

> Es macht ja auch überhaupt keinen Sinn pointer auf größer zu
> vergleichen. Nur weil wir es uns immer als Adresse vorstellen muss es
> noch lange keine wirkiche zahl sein.

Doch, das ist so definiert, dass es auch auf Pointer eine größer/kleiner 
Relation gibt.
Was nicht definiert ist ist, das man einfach beliebige Pointer nehmen 
kann.
Aber solange die Pointer in das gleiche Array zeigen, muss es eine 
größer/kleiner Relation geben.
Wobei: genau genommen ist IMHO noch nicht mal von Arrays die Rede, 
sondern von Datenobjekten, wobei man mich jetzt bitte nicht auf den 
genauen Wortlaut festnageln möge. D.h. auch in einer Struktur gilt für 
die Strukturmember eine größer/kleiner Beziehung in Adress- und damit 
Pointerdingen.

[Thomas W. (thomas100)]

Peter II schrieb:
> Wozu
> brauchst du soetwas denn?


Erlaubt ist es. Ob es sinnvoll eingesetzt wird, kommt auf den 
Programmierer an.
Es macht z.B. dann Sinn, in einem Array zu prüfen, ob man die Grenzen 
erreicht hat.

Einfach zwei Pointer zu vergleichen, ohne dass sie einen Bezug 
zueinander haben, ist natürlich fatal.

VG
Thomas

[Steffen Graap (Gast)]

Das ganze Konstrukt dient um einen Speicher, in dem eine TLV-Nachricht 
(Tag, Length, Value) liegt zu durchsuchen und 
auseinanderzunehmen/zusammenszustellen. In diesem Fall sind die Pointer 
Zeiger in einen Speicher, und dem zufolge sollten sie auch vergeleichbar 
sein.
Ursprünglich waren die Pointer vom Typ "unsigned char* ".
Zur besseren Verarbeitung wurde die Struktur eingefügt, um so einfacher 
und definierter auf Tag, Länge und den Wert drauf zuzugreifen. Sieht 
einfach besser aus wenn man mit pWritePosition->startValue als mit 
*(pWritePosition + 4) arbeitet.

Gruß Steffen

[Karl H. (kbuchegg)]

Steffen Graap schrieb:

> und definierter auf Tag, Länge und den Wert drauf zuzugreifen. Sieht
> einfach besser aus wenn man mit pWritePosition->startValue als mit
> *(pWritePosition + 4) arbeitet.

Alles schön und gut.
Trotzdem ist in

void foo(void)
{
   TLVHead_Def *pWritePosition;
   TLVHead_Def *pEndPosition;

   if(pWritePosition >= pEndPosition)
   {
      mach was;
   }
}

abgesehen davon, dass die Pointer uninitialisiert sind, erst mal nichts 
falsch.

Wenn du also noch immer eine Fehlermeldung kriegst, dann hat die nichts 
mehr mit dem Vergleich zu tun, sondern damit, dass du irgendwo anders 
noch eine Verschlimmbesserung eingebaut hast.

[Steffen Graap (Gast)]

Karl Heinz Buchegger schrieb:
> Denn das diese Fehlermeldung mit dem gezeigten Code nichts zu tun hat,
> zeigt sich schon darin, dass der Compiler einen Datentyp 'bool'
> anspricht, in deinem Codefetzen aber weit und breit von einem bool
> nichts zu sehen ist.

genau das ist ja das Problem, es gibt hier kein bool.

hier noch mal der ungefilterte Code, einer Fehlermeldung. In anderen 
Methoden tritt der Fehler auch auf. Der a b Vergleich dient zum Test, 
der Vergleich ein stückchen tiefer mit den beiden void casts war der 
ursprüngliche der jetzt so läuft.

bool TLV_Support::ifActualTagLastOfMessage (void)
{
TLVHead_Def* nextTag;
TLVHead_Def* a;
TLVHead_Def* b;

//Test Start
if(a >= b)  //hier tritt jetzt der Fehler auf
{
  nextTag = NULL;
}
//Test Ende

nextTag = (TLVHead_Def*)  (&_pReadPosition[_hierarchieLevel]->startValue + _pReadPosition[_hierarchieLevel]->length);

if ( (nextTag->tag == ParamNothing) || ((void*)nextTag >= (void*)_pEndOfBufferPosition) )
{
  return true;
}

return false;
}

[Thomas K. (muetze1)]

Immernoch nicht der gesamte Code. Wie ist das Array _pReadPosition und 
_pEndOfBufferPosition deklariert?

[Thomas W. (thomas100)]

Kann es sein, dass du nicht den C, sondern den C++-Compiler benutzt?

In C++ ist das so nicht erlaubt.
Da muss deiner Klasse (Struktur) der => Operator hinzugefügt werden!

Das würde erklären, warum er den "operator =>" anmeckert. Der Operator 
=> gibt namlich einen bool zurück.

Steht da noch ne Fehlernummer vor dem Fehlertext?


VG
Thomas

[Steffen Graap (Gast)]

ihr habt es ja nicht anders gewollt

class TLV_Support
{
  #pragma pack(1)
    typedef struct          /**< Struktur eines TLV Kopfes ( T & L & 1.V). !!! ACHTUNG, das Pack Pragma muss sein !!!  */
    {
      unsigned short  tag;    /**< Der Tag   */
      unsigned short   length;    /**< Die Längel  */
      char       startValue;  /**< 1. Char des Inhaltes  */
    } TLVHead_Def;
  #pragma pack()

  public:      //Methoden

    TLV_Support();
    TLV_Support(char * TLVBuffer, unsigned short length);

    void openMessage(char * TLVBuffer, unsigned short length);
    void closeMessage(void);

    bool appendComplexTag (TagDefinition complexTag);
    bool appendTag (TagDefinition tag, signed long long value);
    bool appendTag (TagDefinition tag, char *stringValue, unsigned short length);

    bool openActualComplexTag (void);
    bool openComplexTag (TagDefinition complexTag);
    bool closeComplexTag (void);

    TagDefinition getFirstTag (void);
    TagDefinition getActualTag (void);
    TagDefinition getNextTag (void);

    bool getActualValue (char * pValue);
    bool getActualValue (unsigned char * pValue);
    bool getActualValue (short * pValue);
    bool getActualValue (long * pValue);
    bool getActualValue (unsigned long * pValue);
    bool getActualValue (long long * pValue);
//    bool getActualValue (char * stringValue, unsigned short length);
    bool getActualValue (char* stringValue, long* pLength);

    bool getTagValue (TagDefinition tag, char * pValue);
    bool getTagValue (TagDefinition tag, unsigned char * pValue);
    bool getTagValue (TagDefinition tag, short * pValue);
    bool getTagValue (TagDefinition tag, unsigned short * pValue);
    bool getTagValue (TagDefinition tag, long * pValue);
    bool getTagValue (TagDefinition tag, unsigned long * pValue);
    bool getTagValue (TagDefinition tag, long long * pValue);
//    bool getTagValue (TagDefinition tag, char * stringValue, unsigned short length);
    bool getTagValue (TagDefinition tag, char* pValue, unsigned short* pLength);
    bool getTagLengthValue (TagDefinition tag, char** ppValue, unsigned short* pValueLength);

    void clearTLVMesssage (void);
    void clearTLVMesssageRestoreHierarchie(void);

    void getHierarchie(TagDefinition pTaglist[HIERARCHIE_DEEP]);
    long getTLV_Length(void);
    short getLengtOfValue(signed long long value);
    bool ifActualTagLastOfMessage(void);
    bool patchActualHirachieToLength (unsigned short length);
    long getRelativReadposition (void);

  private: //Methoden

    bool getTagValueBasis (TagDefinition tag, long long * pValue, unsigned char valueLength);
    bool getValueBasis (TLVHead_Def* pHead, long long * pValue, unsigned char valueLength);
    bool openThisComplexTag (TLVHead_Def* pHead);
    bool findTagHead (TagDefinition tag, TLVHead_Def** ppHead);

  private: // Variablen

    unsigned char _hierarchieLevel;        //!< aktuelle Hierarchieebene
    unsigned char _lastHierarchieLevel;      //!< die letzte Hierarchieebene vor Close Compplex wird bei Append Tag (Comp/prim) auf den Aktuellen gesetzt
    bool     _isPatch;

    TLVHead_Def* _pHierarchieStart[HIERARCHIE_DEEP];  //!< Startpositionen der Hierarchieebene im Speicher. ebene 0 = Start der Message
    TLVHead_Def* _pReadPosition[HIERARCHIE_DEEP];    //!< Positionen des zulesenden Tag der Hierarchieebene im Speicher
    TLVHead_Def* _pWritePosition;            //!< Positionen andem ein neuer Tag geschrieben wird. Momentan nur Anhängen möglich!
    TLVHead_Def* _pEndPosition[HIERARCHIE_DEEP];    //!< Positionen hinter dem letzten Tag der Hierarchieebene im Speicher
    TLVHead_Def* _pEndOfBufferPosition;          //!< Positionen hinter dem letzten Byte des Speicher
    TagDefinition _TagHierarchieLevel[HIERARCHIE_DEEP];    //!< Array zur Speicherung des Tags der Hierarchieebene
};

Gruß Steffen

[Steffen Graap (Gast)]

Thomas Weyhrauch schrieb:
> Kann es sein, dass du nicht den C, sondern den C++-Compiler benutzt?
>
> In C++ ist das so nicht erlaubt.
> Da muss deiner Klasse (Struktur) der => Operator hinzugefügt werden!
>
> Das würde erklären, warum er den "operator =>" anmeckert. Der Operator
> => gibt namlich einen bool zurück.
>
> Steht da noch ne Fehlernummer vor dem Fehlertext?

Ja es is C++

Der Keil-Compiler compiliert den Code Fehlerfrei und er läuft auch schon 
seit einem halben Jahr richtig auf der Hardware.

Fehlernummer sehe ich keine.

Steffen

[Thomas W. (thomas100)]

Thomas Weyhrauch schrieb:
> Kann es sein, dass du nicht den C, sondern den C++-Compiler benutzt?
>
> In C++ ist das so nicht erlaubt.
> Da muss deiner Klasse (Struktur) der => Operator hinzugefügt werden!
>
> Das würde erklären, warum er den "operator =>" anmeckert. Der Operator
> => gibt namlich einen bool zurück.

Vergiss den Beitrag. Da bin ich eben falsch abgebogen. Klar geht das 
auch in C++ kopfschüttel

[Karl H. (kbuchegg)]

    TLVHead_Def* _pWritePosition;            //!< Positionen andem ein neuer Tag geschrieben wird. Momentan nur Anhängen möglich!
....

    TLVHead_Def* _pEndPosition[HIERARCHIE_DEEP];    //!< Positionen hinter dem letzten Tag der Hierarchieebene im Speicher

....

   if(pWritePosition >= pEndPosition)

Das eine ist ein Array von Pointern, das andere ist ein einzelner 
Pointer.
Sei froh, dass dich der Compiler angemotzt hat. Das kann nicht richtig 
sein.

(Die fehlenden _ zur 100% Übereinstimmung mit dem geposteten Code denke 
ich mir jetzt mal dazu)


> ihr habt es ja nicht anders gewollt

Es ist die EINZIGE Möglichkeit, um dubiosen Fehlern auf die Spur zu 
kommen!

[Karl H. (kbuchegg)]

Im übrigen

    TLVHead_Def* _pHierarchieStart[HIERARCHIE_DEEP];  //!< Startpositionen der Hierarchieebene im Speicher. ebene 0 = Start der Message
    TLVHead_Def* _pReadPosition[HIERARCHIE_DEEP];    //!< Positionen des zulesenden Tag der Hierarchieebene im Speicher
    TLVHead_Def* _pWritePosition;            //!< Positionen andem ein neuer Tag geschrieben wird. Momentan nur Anhängen möglich!
    TLVHead_Def* _pEndPosition[HIERARCHIE_DEEP];    //!< Positionen hinter dem letzten Tag der Hierarchieebene im Speicher
    TLVHead_Def* _pEndOfBufferPosition;          //!< Positionen hinter dem letzten Byte des Speicher
    TagDefinition _TagHierarchieLevel[HIERARCHIE_DEEP];    //!< Array zur Speicherung des Tags der Hierarchieebene

derartig parallel geführte Arrays sind ein klares Indiz, dass dir hier 
eine weitere Klassenebene, die der Hierarchie, fehlt. Anstatt 4 (oder 
5?) paralele Arrays, sollte das nur 1 Array sein, wobei jedes 
Arrayelement einen Hierarchielevel komplett beschreibt.

class TLVLevel
{
  TLVHead_Def* pStart_;
  TLVHead_Def* pReadPosition_;
  TLVHead_Def* pEndPosition_;
  TagDefinition Level_;
};

und in deiner Klasse dann eben

  ....
    TLVLevel      Levels_[HIERARCHIE_DEEP];
    TLVHead_Def* _pWritePosition;            //!< Positionen andem e
    TLVHead_Def* _pEndOfBufferPosition;          //!< Positionen hinter dem letzten Byte des Speicher

ob jetzt die WritePosition mit zu einem HierarchyLevel gehört oder nicht 
kann ich mangels Code bzw. Gesamtüberblick nicht beurteilen.

Und ja. Alles Level-spezifische gehört dann in diese neue TLVLevel 
Klasse.

[Steffen Graap (Gast)]

Sch... mir ist gerade nach 15min schreiben der Browser abgestürzt und 
das ganze Posting ist weg, also noch mal von vorne

das Ganze driftet mir hier ein wenig ab.

TLVHead_Def* a;
TLVHead_Def* b;

if(a >= b)

Diese if-Abfrage führt zu dem genannten Fehler. Dies habe ich auch so 
compiliert, gerade um Problemem mit anderen Zusammenhängen (z.B. Array) 
auszuschließen. In meinen ersten Posting habe ich nur a und b gegen 
pWritePosition und pEndPosition um für das Posting einen Bezug zu zwei 
Zeigern in einen Speicher herzustellen.

Das Problem was ich habe, ist, das der GCC-Compiler meint ich möchte 
zwei Klassen vergelichen, also gar nicht die Pointer miteinander 
vergelicht, sondern die Klassen (TLVHead_Def), und die können natürlich 
nicht >= sein. Der Keil Compiler hat mein Vorhaben richtig erkannt und 
vergelicht die beiden Adressen auf den die Pointer zeigen. Mit den cast 
auf void* bekomme ich den GCC davon auch überzeugt, weil jetzt die 
Pointer nicht mehr auf Klassen, sondern auf Speicher zeigen.
Ich suche jetzt einen andere Möglichkeit den Compiler von diesen 
Vorhaben zu überzeugen (z.B. einenen Optionsparameter beim 
Compileraufruf)

Gruß Steffen

[Steffen Graap (Gast)]

Karl Heinz Buchegger schrieb:
> class TLVLevel
> {
>   TLVHead_Def* pStart_;
>   TLVHead_Def* pReadPosition_;
>   TLVHead_Def* pEndPosition_;
>   TagDefinition Level_;
> };

Den Tip nehm ich dankend zur Kenntniss, so wird das ganze nochmals 
übersichtlicher. Hat aber mit dem aktuellen Problem nichts zu tun.

[Karl H. (kbuchegg)]

> Diese if-Abfrage führt zu dem genannten Fehler.

Diese Abfrage

TLVHead_Def* a;
TLVHead_Def* b;

if(a >= b)

führt ganz sicher NICHT zu diesem Fehler.
Das Problem istr, dass du eben NICHT eine derartige Abfrage hast.

Du hast offenbar

TLVHead_Def* a[10];
TLVHead_Def* b;

if(a >= b)

und DAS ist tatsächlich ein Fehler.

[Karl H. (kbuchegg)]

> Ich suche jetzt einen andere Möglichkeit den Compiler von diesen Vorhaben zu 
überzeugen

Ich kann mich nur wiederholen:

Zeig deinen richtigen Code und nicht irgendwas, was du fürs Forum 
zurecht gemacht hast.

Wenn du etwas für das Forum zurecht machst, dann erstelle ein 
vollständiges Beispiel, das man auch als solches durch den Compiler 
jagen kann.

ABer Problemcode-Präsentation in homöopathischen Dosen führt zu nichts.

[Hmm (Gast)]

Was mir nicht klar geworden ist, ob das Programm nun ein C++ Programm 
ist oder ein C-Programm.

Weiter würde ich im Zweifel eher dem GCC trauen als dem Keil. Lange, 
schmerzvolle Erfahrung. Leider.

Hast Du schon mal ein Lint probiert? Nur mal so als Gegenprüfung zum 
Keil und GCC.

Karl Heinz Einwand ist jedenfalls sicher kein "Abdriften". Ein Vergleich 
eines Zeigers auf ein struct mit einem Zeiger auf ein Array mit Zeigern 
auf ein solches struct ist ziemlich sicher ein Fehler; mindestens ein 
konzeptioneller - auch wenn's dann "irgendwie" läuft.
Jedenfalls lohnt sich, das mal in Frage zu stellen.

[Hmm (Gast)]

Unser Wahnsinns-Schnelltipper wieder. :-)

[Rufus Τ. F. (rufus)]

Hmm schrieb:
> Was mir nicht klar geworden ist, ob das Programm nun ein C++ Programm
> ist oder ein C-Programm.

Das ist sehr eindeutig C++. Der Doppelpunkt-Operator :: und das 
Schlüsselwort class sind so kleine, aber deutliche Hinweise darauf.

[Hmm (Gast)]

Uuups. Das war dann die "ungefilterte Variante" von 18:34. Habe ich 
übersehen. Danke, Karl Heinz.

[Hmm (Gast)]

Noch Uuups. Das war ja Rufus. Danke Dir Rufus.

[Yalu X. (yalu) (Moderator)]

Steffen Graap schrieb:
> TLVHead_Def* a;
> TLVHead_Def* b;
>
> if(a >= b)
>
> Diese if-Abfrage führt zu dem genannten Fehler.

Bei mir nicht (GCC 4.8.1). Für den Test habe ich der Klasse eine Methode 
hinzugefügt, die die obigen Codezeilen und eine leere Anweisung nach der 
If-Abfrage enthält.

Vielleicht machst du den Vergleich in einem anderen (illegalen) Kontext.

Versuch doch mal, deinen kompletten Code auf eine nicht allzu große 
C++-Datei reduzieren, die beim Kompilieren genau den von dir 
beschriebenen Fehler erzeugt. Nur so kann er evtl. von anderen 
reproduziert werden.

Edit:

Nach etwas Recherche bin ich fast zum Schluss gekommen, dass der GCC 
generell keine Fehlermeldungen der Art "Could not find operator>= for 
type bool" ausgibt. Eine Fehlermeldung mit ähnlicher Aussage lautet beim 
GCC "no match for 'operator>=' in ...". Bist du sicher, dass du 
tatsächlich den GCC und nicht irgendeinen anderen Compiler benutzt?

[Steffen Graap (Gast)]

Yalu X. schrieb:
> Versuch doch mal, deinen kompletten Code auf eine nicht allzu große
> C++-Datei reduzieren, die beim Kompilieren genau den von dir
> beschriebenen Fehler erzeugt. Nur so kann er evtl. von anderen
> reproduziert werden.

Die komplette hpp ist ja oben zu sehen. Und wie auch schon etwas weiter 
oben gezeig, hier nochmal eine komplette Methode die so Compiliert wird

bool TLV_Support::ifActualTagLastOfMessage (void)
{
TLVHead_Def* nextTag;
TLVHead_Def* a;
TLVHead_Def* b;

//Test Start
if(a >= b)  //hier tritt jetzt der Fehler auf
{
  nextTag = NULL;
}
//Test Ende

nextTag = (TLVHead_Def*)  (&_pReadPosition[_hierarchieLevel]->startValue + _pReadPosition[_hierarchieLevel]->length);

if ( (nextTag->tag == ParamNothing) || ((void*)nextTag >= (void*)_pEndOfBufferPosition) )
{
  return true;
}

return false;
}

Und in dieser Methode tritt der Fehler bei if (a >= b) auf.

Gruß Steffen

[Steffen Graap (Gast)]

Yalu X. schrieb:
> Nach etwas Recherche bin ich fast zum Schluss gekommen, dass der GCC
> generell keine Fehlermeldungen der Art "Could not find operator>= for
> type bool" ausgibt. Eine Fehlermeldung mit ähnlicher Aussage lautet beim
> GCC "no match for 'operator>=' in ...". Bist du sicher, dass du
> tatsächlich den GCC und nicht irgendeinen anderen Compiler benutzt?

Das kann schom möglich sein. Ich benutze eclipse und stoße darüber den 
Compiler an. Das Resultat steht dann unter Problems, ob es vom Compiler 
kommt oder woanders her, muss ich morgen auf Arbeit mal nachschauen.

Steffen

[Yalu X. (yalu) (Moderator)]

Steffen Graap schrieb:
> Die komplette hpp ist ja oben zu sehen. Und wie auch schon etwas weiter
> oben gezeig, hier nochmal eine komplette Methode die so Compiliert wird

Wenn ich deinen Code vom 05.08.2013 18:44 und den vom 05.08.2013 20:50 
zusammenfüge und für die undefinierten Symbole HIERARCHIE_DEEP, 
TagDefinition und ParamNothing halbwegs sinnvolle Definitionen 
hinzufüge, erhalte ich beim Kompilieren keinen Fehler, nur Warnungen, 
dass a und b uninitialisiert benutzt werden, was ja auch zu erwarten 
ist.

Steffen Graap schrieb:
> Ich benutze eclipse und stoße darüber den Compiler an. Das Resultat
> steht dann unter Problems, ob es vom Compiler kommt oder woanders her,
> muss ich morgen auf Arbeit mal nachschauen.

Verwendest du vielleicht ein Unit-Test-Tool namesn CUTE? Das scheint 
Fehlermeldungen ähnlich der von dir beschriebenen zu generieren und das 
mitunter auch bei korrektem Code:

http://cute-test.com/issues/72

[Mark B. (markbrandis)]

Es sollte ja nun nicht so schwer sein, mal an der Kommandozeile mittels

g++ -Wall <input_datei> -o <output_datei>

zu kompilieren.

[Steffen Graap (Gast)]

Yalu X. schrieb:
> Verwendest du vielleicht ein Unit-Test-Tool namesn CUTE? Das scheint
> Fehlermeldungen ähnlich der von dir beschriebenen zu generieren und das
> mitunter auch bei korrektem Code:

Ja, deshalb compiliere ich ja mit GCC, hab ich im ersten Post auch so 
beschrieben. Das Compilat für die Hardware wird ja mit dem Keil erzeugt.

Nach den Hinnweisen von gestern Abend und heute Morgen, konnte ich das 
Problem tatsächlich in den Einstellungen von eclipse für das CUTE-Plugin 
festmachen. Das CUTE-Plugin hat eigenen Einstellung für die 
Code-Analyse, welche den Fehler feststellt.
Warum ich fälschlicherweise den GCC als Fehlerquelle im verdacht hatte, 
liegt wohl daran, das ich nach compilieren die Fehlermeldungen das erste 
mal war genommen hatte. Ein Irtum meiner seits.

Danke für eure Unterstützung, für mich ist das Thema abgeschlossen.

Gruß Steffen