Klasse einbinden - !

[torsten_156]

@Dravere Es liefert einen Zeiger auf den Datentyp Reader zurück. Dabei wird auch der benötigten Speicher reserviert. Dieser muss nach Beendigung dann mit delete wieder freigegeben werden. Soweit richtig?

Gruß
Torsten

[SeppJ]

@torsten_156 sagte in Klasse einbinden - !:

@Dravere Es liefert einen Zeiger auf den Datentyp Reader zurück. Dabei wird auch der benötigten Speicher reserviert. Dieser muss nach Beendigung dann mit delete wieder freigegeben werden. Soweit richtig?

Soweit richtig. Nun denk noch einmal scharf nach, wieso manni66 wohl folgendes sagte:

@manni66 sagte in Klasse einbinden - !:

@torsten_156 sagte in Klasse einbinden - !:

Reader myReader = new Reader();

Der Unterschied zwieschen Reader und Reader*ist dir klar?

Da hat er bestimmt einen Grund für gehabt.

Über den von manni66 angesprochenen syntaktischen Fehler hinaus, sollte man noch unbedingt erwähnen, dass man in C++ ohnehin niemals new im Anwendungscode benutzt. Das würde ich fast schon als krassen Fehler bezeichnen. Zu viel Java gemacht?

[Th69]

@torsten_156 sagte in Klasse einbinden - !:

@Th69 Ja diese meine ich. Der MultiBarcodeReader hört sich ja gut an. Aber wie binde ich diesen in mein Projekt ein???

Du bist wahrscheinlich durch die VCL daran gewöhnt, Objektinstanzen per new anzulegen, aber der Standard ist die direkte Erstellung eines Objekts (auf dem Stack):

MultipleBarcodeReader multipleBarcodeReader;

s.a. cli/src/main.cpp (auch wenn hier ein GenericMultipleBarcodeReader angelegt wird)

[DocShoe]

@SeppJ
Nö, vermutlich zuviel Embarcadero VCL Scheiß gemacht. Deren Framework erfordert, dass alles, was von TObject erbt, auf dem Heap angelegt werden muss. Ausnahmslos. Um das weiter zu erschweren funktionieren auch make_shared und make_unique nicht mit dem VCL Framework zusammen, da bleibt nur noch die Konstruktion über new.

[SeppJ]

@DocShoe sagte in Klasse einbinden - !:

@SeppJ
Nö, vermutlich zuviel Embarcadero VCL Scheiß gemacht. Deren Framework erfordert, dass alles, was von TObject erbt, auf dem Heap angelegt werden muss. Ausnahmslos. Um das weiter zu erschweren funktionieren auch make_shared und make_unique nicht mit dem VCL Framework zusammen, da bleibt nur noch die Konstruktion über new.

Leute wissen davon und benutzen das trotzdem?

[Th69]

Ist ja bei Qt nicht anders, alle visuellen Elemente werden als Childobjekte einem Parent zugewiesen und bei Zerstörung des Parents werden automatisch alle Unterelemente (rekursiv) per delete entfernt.

[DocShoe]

@SeppJ
Ich könnte mich jetzt lange über den Mist auskotzen, aber ich belasse es mal bei der Kurzfassung:
Wenn du (aktuell am 19.09.2019) €2628,90 für die Suite ausgegeben hast und dann beim ersten Projekt feststellst, dass das halt so ist, dann findet man sich damit ab.

[Leon0402]

@Th69 Durchaus grausam Versuche mir da nichts falsches anzugewöhnen ... auf der anderen Seite hat es mir aber auch geholfen, mich nicht vor pointern zu fürchten

[DocShoe]

@Th69
Bei GUI Elementen kann ich das noch verstehen, aber es gibt keinen, aber auch wirklich gar keinen Grund, warum eine TStringList (eine Art std::vector für Strings) auf dem Heap erzeugt werden muss.

[Th69]

Wären diese VCL-Komponenten nicht alle von TObjectabgeleitet, könnte man keinen Code zwischen C++ und Delphi austauschen (also in einem gemeinsamen Projekt verwenden). Einzig wohl die Klassen AnsiString und UnicodeString wurden für C++ neu implementiert (und können daher direkt ohne new benutzt werden).