[C++] struct in class als Übergabe aus Klassen-Funktion

[Rene K. (xdraconix)]

Ich bin recht neu in CPP und probiere mich gerade ein wenig in Klassen. 
Jedoch fällt mir da so das eine oder andere etwas schwer. Momentan tue 
ich mich schwer mit einer struct, welche ich in einer Klasse definiere. 
In dieser Klasse möchte ich dieses Struct als Rückgabewert haben. Das 
funktioniert jedoch nicht so wie ich mir das denke. Woran könnte das 
liegen und vor allem warum?

// Header File:
class DraconixClass{

  public:
    DraconixClass(void);
    
    struct ConvBytes {
      uint8_t LByte;
      uint8_t HByte;
    };
    
    void begin(void);
    void handle(void);

  protected:
    ConvBytes From16Bit(uint16_t vari);
    uint16_t To16Bit(ConvBytes vari);
};

//CPP File:
ConvBytes DraconixClass::From16Bit(uint16_t vari)
{
  ConvBytes ByteArray;
  
  ConvBytes.LByte = vari & 0xff;
  ConvBytes.HByte = (vari >> 8) & 0xff;
  
  return ConvBytes;
}

Als Fehler gibt er mir zurück:

draconix.cpp:55:1: error: 'ConvBytes' does not name a type
   55 | ConvBytes DraconixClass::From16Bit(uint16_t vari)
      | ^~~~~~~~~

Kann mir das jemand erklären?

Liebe Grüße René

[Oliver S. (oliverso)]

https://en.cppreference.com/w/cpp/language/nested_types

Den Rückgabewerr deiner Funktion solltest du auch nochmal anschauen.

Oliver

[Rolf M. (rmagnus)]

Rene K. schrieb:
> Kann mir das jemand erklären?

ConvBytes ist in der Klasse definiert, also in deren Namensraum:

DraconixClass::ConvBytes DraconixClass::From16Bit(uint16_t vari)

Den Inhalt der Funktion solltest du auch nochmal genauer betrachten.

[Rene K. (xdraconix)]

Oh vielen Dank euch beiden - ja nested types lese ich mir mal durch. :-D



p.s.: Jaaaaaa... da schäme ich mich gerade ein wenig für den Variablen 
Namen - bzw. das falsche schreiben. x-D p.p.s.: So weit ist der Compiler 
garnicht vorgedrungen, zumindest hatte er es mir noch nicht als Fehler 
angekreidet.

[Wilhelm M. (wimalopaan)]

Auf den Inhalt der einen Funktion wurde ja schon hingewiesen ... der 
Rest der Klasse benötigt auch noch Aufmerksamkeit!

[Rene K. (xdraconix)]

Wilhelm M. schrieb:
> Auf den Inhalt der einen Funktion wurde ja schon hingewiesen ... der
> Rest der Klasse benötigt auch noch Aufmerksamkeit!

Ja ich hatte da nur noch "ConvBytes" im Kopf. :-D

Im übrigen funktioniert es nun tadellos.

Was mich nur so ein wenig irritiert hat, bzw. ich nur so halb 
nachvollziehen kann. Wenn ich die Funktion ja schon innerhalb der Klasse 
definiere und starte - das ich dann separat noch die Übernahme und 
Rückgabedefinitionen spearat der Klasse zuweisen muss.

Was aber im zweiten Blick wieder durchaus Sinn macht. Vielleicht will 
man ja auch Variablen Definitionen einer anderen Klasse nutzen...

Aber nun, ich danke vielmals. :-)

[Wilhelm M. (wimalopaan)]

Rene K. schrieb:
> Was mich nur so ein wenig irritiert hat, bzw. ich nur so halb
> nachvollziehen kann. Wenn ich die Funktion ja schon innerhalb der Klasse
> definiere und starte - das ich dann separat noch die Übernahme und
> Rückgabedefinitionen spearat der Klasse zuweisen muss.

Du sprichst wirr ;-)
Es wäre besser, wenn Du versuchst die richtigen Fachtermini zu 
verwenden.

Wie hast Du denn Deinen Quelltext nun verändert? Und was ist daran 
unklar?

[Rene K. (xdraconix)]

Wilhelm M. schrieb:
> richtigen Fachtermini

Ich kenne scheinbar die richtigen Fachtermini nicht. :-)

Wilhelm M. schrieb:
> Wie hast Du denn Deinen Quelltext nun verändert? Und was ist daran
> unklar?

Momentan sieht es so aus:

//Header

class DraconixClass{

  public:
    DraconixClass(void);

    struct ConvBytes {
      uint8_t LByte;
      uint8_t HByte;
    };
    
    void begin(void);
    void handle(void);
    
    ConvBytes From16Bit(uint16_t vari);
    uint16_t  To16Bit(ConvBytes vari);
    uint16_t  To16Bit(char LVari, char HVari);
};

//CPP File

DraconixClass::ConvBytes DraconixClass::From16Bit(uint16_t vari)
{
  ConvBytes ByteArray;
  
  ByteArray.LByte = vari & 0xff;
  ByteArray.HByte = (vari >> 8) & 0xff;
  
  return ByteArray;
}

uint16_t DraconixClass::To16Bit(DraconixClass::ConvBytes vari)
{
  uint16_t TempVar = (vari.HByte << 8) | vari.LByte;
  return TempVar;
}

uint16_t DraconixClass::To16Bit(char LVari, char HVari)
{
  uint16_t TempVar = (HVari << 8) | LVari;
  return TempVar;
}

So mich hat es nur gewundert das ich die Klasse an den Markierten 
stellen nochmal anweisen muss, obwohl ich die den Return der Funktion in 
der Klasse schon definiert habe.

//in HEADER

...
        
    ConvBytes From16Bit(uint16_t vari);
//      ^-- hier definiert
    uint16_t  To16Bit(ConvBytes vari);
//                        ^-- hier defniert
...

// CPP Datei:

..
//  Hier separat mit Klasse definiert obwohl die Funktion aus der Klasse ist  
DraconixClass::ConvBytes DraconixClass::From16Bit(uint16_t vari)
{
//..
}

[Wilhelm M. (wimalopaan)]

Rene K. schrieb:
> Wilhelm M. schrieb:
>> richtigen Fachtermini
>
> Ich kenne scheinbar die richtigen Fachtermini nicht. :-)

Ja.
Hast Du wenigstens ein C++-Buch? Welches?

> So mich hat es nur gewundert das ich die Klasse an den Markierten
> stellen nochmal anweisen muss, obwohl ich die den Return der Funktion in
> der Klasse schon definiert habe.
> //in HEADER
> ...
>
>     ConvBytes From16Bit(uint16_t vari);

Die Zeile stammt aus der Definition der Klasse und Du deklarierst damit 
die Elementfunktion From16Bit(...). Eine Elementfunktion ist wie der 
name sagt ein Element der Klasse. Deswegen ist der Name der Funktion 
auch <Klassenname>::<Elementfunktionsname>(...).

> DraconixClass::ConvBytes DraconixClass::From16Bit(uint16_t vari)
> {
> }

Diese Zeile steht sozusagen "auf der grünen Wiese", also außerhalb jeder 
Klasse (oder Namensraum). Damit muss Du den vollständigen Funktionsnamen 
angeben.

Der Rückgabetyp ist ein geschachtelter Typ. Hier gilt ähnliches: der 
vollständige Name ist <OuterClass>::<nestedClass>. Da Du eben auf der 
grünen Wiese bist, musst Du auch hier den vollständig qualifizierten 
Namen angeben.

BTW: Deine Funktionen sind "echte" Funktionen (im mathematischen Sinn), 
d.h. sie haben keinen internen Zustand bzw. hängen auch nicht vom 
Objektzustand ab. Daher kannst / solltest Du sie auch als freie 
Funktionen schreiben (oder als static-Elementfunktionen)

Wenn es doch non-static Elementfunktionen sein sollen aus irgendwelchen 
Gründen, dann sollten sie als Beobachterfunktionen d.h. const 
(read-only) qualifiziert werden.

Leere Parameterlisten in C++ sind einfach f() und nicht f(void) wie in 
C.

Primitive Datentypen sollten immer initialisiert werden, am besten durch 
in-class-initializer.

class DraconixClass{
  public:
    DraconixClass(); // Was soll der std-ctor machen?

    struct ConvBytes {
      uint8_t LByte{0};
      uint8_t HByte{0};
    };
    
    void begin(); // muessen wohl Mutatoren sein, daher non-const
    void handle(); // Welche Datenelemente sollen die ändern?
    
    // ggf. als freie Funktionen bzw. static
    ConvBytes From16Bit(uint16_t vari) const;
    uint16_t  To16Bit(ConvBytes vari) const;
    uint16_t  To16Bit(uint8_t LVari, uint8_t HVari) const;
};

und beispielhaft

DraconixClass::ConvBytes DraconixClass::From16Bit(const uint16_t vari) {
  return {vari & 0xff, (vari >> 8) & 0xff}; // Aggregat-Initialisierung
}

Das waren jetzt nur ein paar Hinweise und ggf- Tips zum Weiterlesen...

[Klaus (feelfree)]

Rene K. schrieb:
> (HVari << 8)

war da nicht was wie
"shift-operationen von signed typen -> implementation-defined?"

oder täusche ich mich?

[Rolf M. (rmagnus)]

Wilhelm M. schrieb:
> und beispielhaft
> DraconixClass::ConvBytes DraconixClass::From16Bit(const uint16_t vari) {
>   return {vari & 0xff, (vari >> 8) & 0xff}; // Aggregat-Initialisierung
> }

Da fehlt ein const.

Klaus schrieb:
> Rene K. schrieb:
>> (HVari << 8)
>
> war da nicht was wie
> "shift-operationen von signed typen -> implementation-defined?"

Nicht ganz. Bei einem a << b mit vorzeichenbehafteten a ist alles ok, 
wenn a positiv ist und das Ergebnis von 2 hoch b in den Zieltyp passt. 
Wenn nicht, ist es allerdings nicht nur implementation-defined sondern 
undefined behavior. Was allerdings implementation-defined ist, ist ob 
char signed ist oder nicht. Zu beachten ist noch die integer-promotion, 
die HVari erst mal auf int erweitert, bevor geshiftet wird.
Insgesamt heißt das, dass es tatsächlich in zwei Fällen zu undefiniertem 
Verhalten kommen kann, nämlich wenn HVari negativ ist (auf Compilern mit 
vorzeichenbehaftetem char) oder wenn das Ergebnis des Shifts nicht mehr 
in int passt (bei einem Compiler mit vorzeichenlosem char und einem 16 
Bit breiten int, wenn HVari > 127 ist).

[Wilhelm M. (wimalopaan)]

Rolf M. schrieb:
> Wilhelm M. schrieb:
>> und beispielhaft
>> DraconixClass::ConvBytes DraconixClass::From16Bit(const uint16_t vari) {
>>   return {vari & 0xff, (vari >> 8) & 0xff}; // Aggregat-Initialisierung
>> }
>
> Da fehlt ein const.

Das stimmt (ich hatte leider auf eine Compilation verzichtet).

>
> Klaus schrieb:
>> Rene K. schrieb:
>>> (HVari << 8)
>>
>> war da nicht was wie
>> "shift-operationen von signed typen -> implementation-defined?"
>
> Nicht ganz. Bei einem a << b mit vorzeichenbehafteten a ist alles ok,
> wenn a positiv ist und das Ergebnis von 2 hoch b in den Zieltyp passt.
> Wenn nicht, ist es allerdings nicht nur implementation-defined sondern
> undefined behavior. Was allerdings implementation-defined ist, ist ob
> char signed ist oder nicht. Zu beachten ist noch die integer-promotion,
> die HVari erst mal auf int erweitert, bevor geshiftet wird.

Deswegen hatte ich die Signatur der Funktionen auch gleich angepasst.

> Insgesamt heißt das, dass es tatsächlich in zwei Fällen zu undefiniertem
> Verhalten kommen kann, nämlich wenn HVari negativ ist (auf Compilern mit
> vorzeichenbehaftetem char) oder wenn das Ergebnis des Shifts nicht mehr
> in int passt (bei einem Compiler mit vorzeichenlosem char und einem 16
> Bit breiten int, wenn HVari > 127 ist).

Ab C++20 gibt es nur noch einen Fall von UB, nämlich wenn der rechte 
Operand größer ist als die Bitbreite des linken Operanden (nach ggf. 
Promotion) oder negativ ist.