C
ness schrieb:
nein nein, das ganze funktioniert wie gewollt, aber "delete reinterpret_cast<help<T>*>(p);" ist natürlich ser wenig portabel (der rest sollte es doch sein, oder?)
/edit: und das verpacken in ner struktur gefällt mir auch nicht, der compiler könnte ja padden
wenn T ein POD ist, garantiert dir der standard sogar, dass das funktioniert. und wenn T kein POD ist, kannst du ohnehin nur beten (allerdings bin ich mir ziemlich sicher, dass padding niemals löcher am anfang einer struktur verursacht) - etwas anderes wäre, wenn du deine klasse so gestaltest, dass potentielle klienten davon öffentlich erben sollen... (dann entfällt logischerweise T und die template-funktionen, align müsste dann eine konstante sein). Eleganter fände ich es, diese funktionalität in einen allokator zu packen - damit machst du sie für mehr Ts zugänglich, und die integration mit containern ist auch kein problem (bloss dumm, das container mit verschied. allokatoren inkompatibel sind )
unportabel ist an dem gesamten projekt grundsätzlich das ziel, nähmlich eine bestimmte ausrichtung für objekte zu erreichen. das macht sich in unportablen konstrukten bemerkbar:
- reinterpret_cast von void* nach char* - muss nichts sinnvolles ergeben (denn die interne representation verschiedener pointer kann sich durchaus unterscheiden), besser ist static_cast
- cast von pointer auf integer - das ist zwar erlaubt, aber niemand garantiert, dass size_t gross genug ist (etwas portabler ist intptr_t aus C99)
- mit dem integer zu rechnen und das ganze in einen pointer zurückzuverwandeln ist gänzlich unportabel, hier musst du die repräsentation von pointern kennen, das ist unterschiedlich von plattform zu plattform
alles nat. kein problem, wenn alles auf einem rechner, den du auf deinen tisch stellen kannst, laufen soll...
ein fehler ist es im übrigen, align + sizeof(std::ptrdiff_t) zu addieren statt
align + sizeof(std::ptrdiff_t) - 1
bedenke was passiert, wenn align 1 ist... nicht alle plattformen erlauben unausgerichtete zugriffe auf integer
