Problem mit "placement new"

Shade Of Mine schrieb:

#include <new>
vorhanden?

Jetzt schon.
Danke für den Hinweis!

Fange ich mir mit <new> externe Abhängigkeiten, die der Linker auflösen muss, ein?

Grüße
Erik

Phoemuex

Shade Of Mine schrieb:

#include <new>
vorhanden?

Kann sein, dass es tatsächlich nötig ist, aber zumindest Wikipedia schreibt

Default placement does not require the inclusion of the Standard C++ library header <new> in the source code of a C++ program.

Ich werde mal morgen im Standard nachgucken, ob ich eine entsprechende Stelle finde.

Felix

volkard

statt <new> zu inkludieren, müßte es reichen,

inline void* operator new(std::size_t, void* p) throw() { return p; }

zu schreiben.

hustbaer

volkard schrieb:

statt <new> zu inkludieren, müßte es reichen,
inline void* operator new(std::size_t, void* p) throw() { return p; }
zu schreiben.

AAAAAAAAAAAAAH!

Hallo,

eigentlich möchte ich ja nur den Constructor einer Klasse aufrufen.
Dazu hab ich das gefunden :
http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/implementierung/articles/147116/
Leider mag der gcc nur den Destructor mit 'p->CLASS::~CLASS();' aufrufen. So das ich mich für den Constructor wohl auf dieses "placement new" einlassen muss.
Das resultierende Modul darf jedenfalls keine externen Abhängigkeiten besitzen.

Gibt es noch andere Wege (eventuell ISO-Konform) um den Constructor direkt aufzurufen?

Grüße
Erik

pumuckl

Erik.Vikinger schrieb:

Gibt es noch andere Wege (eventuell ISO-Konform) um den Constructor direkt aufzurufen?

Nein.

Doch die gibt es: Manipulation der vtable

volkard

Kenner des C++ schrieb:

Doch die gibt es: Manipulation der vtable

mit er manipulation des vptr kannste nur einen konstruktor simulieren, kannst ihn aber nicht aufrufen. die vtbl zu manipulieren bringt nix, denn der konstruktor kann nicht virtuell sein.

Hallo,

pumuckl schrieb:

Erik.Vikinger schrieb:

Gibt es noch andere Wege (eventuell ISO-Konform) um den Constructor direkt aufzurufen?

Nein.

Schade.

volkard schrieb:

statt <new> zu inkludieren, müßte es reichen,
inline void* operator new(std::size_t, void* p) throw() { return p; }
zu schreiben.

Ja, das reicht.
Aber erst nachdem ich 'std::size_t' mit 'uint' ersetzt hatte, ich binde nämlich keine Standard-Header ein (außer <inttype.h>).

Danke für Eure Hilfe!

Grüße
Erik

volkard

Erik.Vikinger schrieb:

Aber erst nachdem ich 'std::size_t' mit 'uint' ersetzt hatte, ich binde nämlich keine Standard-Header ein (außer <inttype.h>).

deswegen nehme ich ja auch

typedef typeof(sizeof(0)) size_t;

bzw. bald mit decltype
auf uint mag ich mich nicht verlassen, weils bei 64-bittern gleich wieder ein ulong ist.

pumuckl

Erik.Vikinger schrieb:

ich binde nämlich keine Standard-Header ein (außer <inttype.h>).

Gibts n Grund dafür?
inttype.h ist kein Standard C++-header. Wird nichtmal im Standard erwähnt.

Erik.Vikinger schrieb:

Fange ich mir mit <new> externe Abhängigkeiten, die der Linker auflösen muss, ein?

falls du meinst ob du damit gegen eine zusätzliche lib linken musst: nein. <new> ist ein Header und definiert lediglich ein paar inline-Funktionen.

Wie volkard es vorgeschlagen hat funktionierts allerdings nur, wenn weder dein anderer Code noch die libs die du verwendest noch anderer Code, der evtl. irgendwann mal deinen Code verwendet, <new> einbindet. Dann hat man nämlich ggf. zwei verschiedene Definitionen des placement new (seis auch nur durch exception-spezifikationen á la throw()) und verletzt die ODR.

Hallo,

volkard schrieb:

deswegen nehme ich ja auch
typedef typeof(sizeof(0)) size_t;

Auch ne interessante Lösung.

volkard schrieb:

auf uint mag ich mich nicht verlassen, weils bei 64-bittern gleich wieder ein ulong ist.

Das uint lass ich mir von einer zusätzlichen Header-Datei reinreichen die der User meiner Bibliothek selber anpassen darf/soll. Um zuverlässig eine bestimmte Bitbreite zu bekommen muss man wohl immer <inttypes.h> einbinden und z.B. uint32_t als Vorlage benutzen. In meinem Code stelle ich nur die Bedingung das 'uint' mindestens 32Bit und unsigned sein muss. Das prüfe ich auch immer gründlich ab. Ansonsten darf 'uint' ruhig größer sein.
Für viele Dinge, z.B. einfache Schleifen-Zähler, ist ein Integer in der nativen Größe der entsprechenden CPU am performantesten. Ich hab es nicht getestet aber ich denke das mein Code auch mit 64Bit oder 128Bit oder gar mit 73Bit für 'uint' uneingeschränkt funktioniert. Auf jeden Fall läuft mein Code mit Little-Endian und Big-Endian und auch auf CPUs die keine unausgerichteten Speicher-Zugriffe können und benutzt trotzdem immer das selbe Datenformat.

Ich vermute der Umstand das ein Integer/Long/... in C/C++ keine feste Größe hat ist u.a. die Ursache dafür das es keine Rotations-Primitiven gibt sondern nur simple Shifts und alles andere muss man sich passend zurechtbasteln.

Grüße
Erik

Hallo,

pumuckl schrieb:

Erik.Vikinger schrieb:

ich binde nämlich keine Standard-Header ein (außer <inttype.h>).

Gibts n Grund dafür?

Meine Bibliothek darf von nichts abhängig sein. Alles was ich benutzen darf wird als kleines Struct mit ner Hand voll Funktionspointern reingereicht.

pumuckl schrieb:

inttype.h ist kein Standard C++-header. Wird nichtmal im Standard erwähnt.

Wusste ich nicht, ist aber auch Okay. Die brauche ich nur um 'uint' und 'byte' exakt zu definieren.

pumuckl schrieb:

Erik.Vikinger schrieb:

Fange ich mir mit <new> externe Abhängigkeiten, die der Linker auflösen muss, ein?

falls du meinst ob du damit gegen eine zusätzliche lib linken musst: nein.

Gut. Ich darf aber auch nicht gegen Standard-Libs linken. Das ist ja der Grund warum ich noch nicht mal ein einfaches normales 'new' benutzen kann.

pumuckl schrieb:

Wie volkard es vorgeschlagen hat funktionierts allerdings nur, wenn weder dein anderer Code noch die libs die du verwendest noch anderer Code, der evtl. irgendwann mal deinen Code verwendet, <new> einbindet. Dann hat man nämlich ggf. zwei verschiedene Definitionen des placement new (seis auch nur durch exception-spezifikationen á la throw()) und verletzt die ODR.

Diese Funktion ist nur innerhalb meiner eigenen *.cpp-Dateien sichtbar. Es wird in meiner Header-Datei geprüft ob ein bestimmtes define existiert, wenn der User das auch setzt bevor er meine Header-Datei einbindet ist er selbst schuld.

Grüße
Erik

volkard

Erik.Vikinger schrieb:

Um zuverlässig eine bestimmte Bitbreite zu bekommen muss man wohl immer <inttypes.h> einbinden und z.B. uint32_t als Vorlage benutzen. In meinem Code stelle ich nur die Bedingung das 'uint' mindestens 32Bit und unsigned sein muss. Das prüfe ich auch immer gründlich ab. Ansonsten darf 'uint' ruhig größer sein.

du könntest zu diesem behufe mit wenigen zeilen template-metaprogrammierung sogar <inttypes.h> einsparen und das prädikat "ich benutze gar keinen standardheader" verdienen. das ist zwar nicht wirklich produktiv, aber auch nicht wirklich störend. ein kleiner scherz am rande halt, vor dem ich unmöglich die flossen lassen könnte.

Hallo volkard,

Da ich von Zeit zu Zeit mal für µC programmieren muss für die (noch) kein gcc und keine <inttype.h> existiert währe ich Dir (nahezu) unendlich dankbar wenn Du das ein ganz klein wenig ausführlicher Beleuchten könntest.
Um nicht zu weit vom Ursprungsthema dieses Threads abzuweichen würde ich auch den einen oder anderen interessanten externen Link oder ein treffendes Stichwort für die Eingabe in den Suchschlitz der Suchmaschine meines persönlichen Misstrauens akzeptieren.

Grüße
Erik

volkard

Erik.Vikinger schrieb:

währe ich Dir (nahezu) unendlich dankbar wenn Du das ein ganz klein wenig ausführlicher Beleuchten könntest.

habe leider keinen code, weil ich jedesmal zu faul war. aber in
http://www.c-plusplus.net/forum/viewtopic-var-t-is-239565-and-highlight-is-.html
bin ich fast sicher, daß heute noch eine perfekte lösung kommt. das ist nämlich eine tolle übung für alle, die mal eine neue template-meta-problemstellung suchen.
edit: krass, ist schon da.

Problem mit &quot;placement new&quot;

Problem mit "placement new"