CE 12: constructor und Free vertragen sich nicht mit den destructor ?

[himitsu]

Zitat von jaenicke:

Dafür gibt es RawByteString,

Oder man nimmt z.B. TBytes.

Zitat von paule32.jk:

Delphi-Quellcode:

    constructor Create(c: Char); overload;  // hier
    constructor Create(c: AnsiChar); overload;  // und da: entspricht Char
    constructor Create(c: WideChar); overload;  // und nu ? - kein Char, kein AnsiChar, nur Wide ?

Bis Delphi 2006/2007 Char=AnsiChat und seit Delphi 2009 Char=WideChar, da Delphi standardmäßig auf Unicode umgestellt wurde.
Ebenso ist nun MessageBox ein alias für MessageBoxW und früher war es ein MessageBoxA.

Also ich würde einfach das Char weglassen ... oder das WideChar, aber ohne Char wäre es eindeutiger.



Delphi 12 prüft einige Typen anders/genauer,
darunter vor allem nun Alias, welche eigentlich "identisch" sind, aber nun doch nicht mehr.

Drum wird z.B. bei SendMessage nun auch LPARAM und WPARAM als Typ angezeigt, welche früher als LongInt im CodeInsight standen.



PChar ist seit 2009 ein PWideChar,
so wie auch Char ein WideChar
und String ein UnicodeString.

Vor 2009 waren sie Alias zu den ANSI-Typen.

WideString ist der BSTR vom OLE32, siehe SysAllocString


Früher gingen Overloads mit "gleichen" Typen garnicht, also Char und WideChar sind ja "eigentlich" gleich, bzw. das Eine ist nur ein Alias des Anderen und keine eigenständigen Typen,
aber solche Typen lassen sich JETZT dennoch unterscheiden (Fluch und Segen zugleich).



Bei Lazarus/FreePascal muß man aufpassen, denn die sind bei ANSI geblieben, bzw. nutzen an vielen Stellen nun UTF8String, welches einen AnsiString entspricht.



Es gibt ShortString (bis 255 Zeichen) bzw. String[x] (ein ShortString mit definierter Maximallänge)
die LongString (AnsiString und UnicodeString)
den WideString (der OLE32-API-Wrapper)
und irgendeinen UCS4-String (4 Byte pro Char, aber da ist nichts richtig implementiert)

Und mit AnsiString(x) ein paar Ableitungen des AnsiString, mit definierter Codepage.
der normale AnsiString mit CP_ACP (in einer ConsolenApp könnte es auch CP_OEM sein, jenachdem wie die WinAPIs konfiguriert sind)
UTF8String mit CP_UTF8
RawByteString mit CodePage $FFFF, wobei hier die Chars von #0 bis #255 einfach 1:1 konvertiert/kopiert werden.

die WideString und UnicodeString sind normal UTF-16 (PS, man kann auch einen AnsiString mit der UTF-16-Codepage definieren, in BigEndian oder LittleEndian)

Und beim Zuweisen der verschiedenen Stringtypen untereinander, konvertiert Delphi dann automatisch, entsprechend ihrer "aktuellen" CodePages.

[paule32.jk]

wäre denn der VARIANT eine bessere Lösung ?
also, das man noch die ctor's hat, aber für den Typ dann einen Variant ?

weil, ich nutze im Moment verschiedene Typen in C++, die nach Delphi, und von Delphi nach C++ wandern.
C++ kennt ja uint8_t, uint16_t, uint32_t, und uint64_t.

komischerweise entspricht dann ein uint64_t einen void*
und uint64_t in Delphi, der gleiche Typ UInt64.

Jetzt wirds lustig:
diesen UInt64 kann ich auch in einen String konvertieren, den man dann wieder durch
reinterpret_cast<QChar*>(addr) zu einen Pointer der erstellten Klasse QChar konvertieren kann.

Also das ist zwar möglich.
Aber in meinen Augen recht umständlich, weil man sich sehr genau an ein Protokoll, das man vorher ausarbeiten sollte, halten muss, damit die Konvertierung nicht in AMV endet.
Aber wie soll man das auch machen, wenn man unterschiedliche Systeme hat.

Ich weiß, jetzt kommt wieder ein Artikel von Interfaces und .NET
Aber: der GNU C/C++ Compiler ist da ein wenig Eigen, und man muss sich was anderes einfallen lassen (für mich zumindest).

Wie das gerade jetzt funktioniert, ist gut (Delphi -> GNU C/C++ > Delphi).
Allerdings müsste ich noch weiter testen mit (FPC -> GNU C/C++ -> FPC).

[himitsu]

Kommt drauf an.

Variant kennt "direkt" kein RawByteString, aber es kennt Byte-Arrays, allerdings handhabt man das schon bissl umständlicher.
AnsiString und UnicodeString kennt er nur innerhalb des Delphi
und sonst kennt es halt nur noch den BSTR (WideString) und PAnsiChar, sowie PWideChar.

Ja, man kann Variant/OleVariant für Binärdaten nutzen, aber es gibt auch Einfacheres.

C++ kennt Variant OleVariant, aber es kennt auch den BSTR
und ansonsten halt z.B. PAnsiChar oder "statische" ByteArray usw.

Wenn C-seitig nur gelesen wird, kann man auch AnsiString und UnicodeString als Funktionsparameter verwenden,
welche drüben als PAnsiChar und PWideChar behandelt werden, da die LongString intern kompatibel dazu sind.
(Zeiger auf ersten Char, nicht auf die davorliegenden Verwaltungsdaten, und hinten immer gefolgt von zwei #0#0)


Erstmal Variant versus OleVariant.
* Variant kann auch einige delphi-spezifische Typen enthalten, wie z.B. LongStrings ala AnsiString und UnicodeString
* der OleVariant kennt nur die standardmäßigen Typen des OLE32/OLEAuth, also so, wie Windows einen "Variant" definiert hat
* die Übergabe an externe Funktionen, welche Delphi nicht kennen, sollte somit nur via OleVariant erfolgen (nicht Variant)

Variant hat definitiv keine Referenzzälung (selbst wenn es einige interne Typen könnten).

Die LongStrings haben eine Referenzzählung, also Kopieren/Zuweisen von Variablen, sowie Übergabe an Property und Nicht-Const-Parameter geht extrem schnell und ressourcenschonend (CPU-Last und Arbeitsspeicher).

WideString (BSTR) bietet seit XP eine Referenzzälung, aber Delphi hat das nicht implementiert,
somit wird immer der komplette Inhalt kopiert, über einem fremden Speichermanager.

OleVairant nutzt intern nur den WideString, wenn man ihm z.B. einen String bzw. UnicodeString zuweist.

[paule32.jk]

ich weiß auch gerade nicht so recht, ob FPC auch supported werden soll.
Auf der einen Seite kann man mit FPC kommerzielle Anwendungen credenzen - allerdings ist FPC so nen gefukkel aus allem möglichen Platformen (und natürlich richtig fätte .Exe cutables erzeugend).

Mit Delphi CE 12 kann ich auch Programme erstellen, aber hier habe ich auch ein gefukkel (also erstmal in der Anfangsphase).
Aber: es werden DLL Bibliotheken besser unterstützt.
Aber: die CE ist restriktiv - Du kannst sie als Testversion einsetzen, soll aber keine Testversion sein ?
Ich kann aber diese Version nicht einsetzen, da ich 80 Euro pro Monat bekomme (für Schnukkelkram und Körperpflege).
im Jahr würde das 960 Euro bedeuten.
Aber: wenn ich damit 5000 Euro Umsatz machen würde, werden die:

Code:

  5.000
-   960
-------------
= 4.040 Euro

Aber: dieser Rest wird angerechnet ? - auf was ?

Ich bin nicht direkt angestellt, sondern nur untergebracht.
Muss ich da dann den Umsatz meiner Firma mit einfließen lassen ?

Worauf ich aus bin:
- lohnt sich der "unentgeltliche" Aufwand: also kann man solche Gedanken gebrauchen - also die Anbindung Delphi/FPC => GNU C++ => FPC/Delphi ?