Objekt auf dem Heap oder Stack?

Shade Of Mine

Dravere schrieb:

Mir ist einfach nicht klar, wie ich eine von der Bibliothek erstellten Baumstruktur mit optionalen "Elementen", dem Benutzer der Bibliothek übergeben kann, so dass die Biliothek sich dann immer noch um den womöglich allozierten Speichern kümmert, welcher durch Speicher, bzw. NULL-Pointern, vom Benutzer ersetzt wird, ohne dass im nachhinein dann, der Speicher des Benutzers auch berührt wird.

Beschreib einfach mal genauer was du willst. Die Baumstruktur koennte zB den Ownership selber uebernehmen. Du koenntest es ueber Templates loesen und somit garnicht erstmal eine dynamische Allokierung provozieren.

scoped_ptr/auto_ptr bieten sich auch immer an wenn es um owner ship transfer geht.

Uebrigens braucht man Zeiger/Referenzen nur dann wenn man laufzeit polymorphie verwendet - ansonsten kannst du immer kopien ziehen.

Schau dir auch mal Libraries an die aehnlich zu deiner sind. uU die C++ streams (auch wenn sie nicht die schoensten sind): du kannst bei einem stream dynamisch den buffer bestimmen.

Badestrand

Shade Of Mine schrieb:

Uebrigens braucht man Zeiger/Referenzen nur dann wenn man laufzeit polymorphie verwendet - ansonsten kannst du immer kopien ziehen.

Naja, bei Baumstrukturen oder verketteten Listen ja nicht (oder?:)).

Dravere schrieb:

Mir ist einfach nicht klar, wie ich eine von der Bibliothek erstellten Baumstruktur mit optionalen "Elementen", dem Benutzer der Bibliothek übergeben kann, so dass die Biliothek sich dann immer noch um den womöglich allozierten Speichern kümmert, welcher durch Speicher, bzw. NULL-Pointern, vom Benutzer ersetzt wird, ohne dass im nachhinein dann, der Speicher des Benutzers auch berührt wird.

Wie Shade schon meinte, eine gute Möglichkeit wäre es, dem Baum zu überlassen, wie er seinen Speicher verwaltet. Also im Prinzip so (um konkret zu sein):

class TreeNode
{
public:
    void setLeft( const string& v )
    {
        if ( left != NULL )
            // Kaputt machen
        left = // Allokieren
        left->val = v;
    }

private:
    string   val;
    TreeNode *left, *right;
};

Das hat auch den großen Vorteil, dass du im Baum einen eigenen Speichermanager einbauen kannst. Wenn's z.B. ein spezieller Baum ist, der eigentlich immer ziemlich groß wird, kannst du im Vorhinein schon 1 MB (oder so) an Speicher holen und die Nodes/Knoten mit "placement new" auf diesem Speicher unterbringen; so musst du nicht so oft Speicher anfordern.

edit2: Und das läuft auch unter dem OOP-Prinzip des Information-versteckens: Von außen ist es dir völlig egal, wie der Baum den Speicher verwaltet, er macht's selbst und du brauchst dich nicht drum zu kümmern. Und wenn der Programmierer des Baums sich entscheidet, einen (anderen) Speichermanager einzubauen, bekommst du davon genau null mit

edit3: Shade, hättest du vielleicht Lust, einen Artikel über GCen für's Magazin zu schreiben? Das Thema ist auf jeden Fall hochinteressant!

Shade Of Mine

Badestrand schrieb:

Shade Of Mine schrieb:

Uebrigens braucht man Zeiger/Referenzen nur dann wenn man laufzeit polymorphie verwendet - ansonsten kannst du immer kopien ziehen.

Naja, bei Baumstrukturen oder verketteten Listen ja nicht (oder?:)).

Warum nicht?

std::list<std::string> l;
l.push_back(std::string("test"));

klappt wunderbar

edit3: Shade, hättest du vielleicht Lust, einen Artikel über GCen für's Magazin zu schreiben? Das Thema ist auf jeden Fall hochinteressant!

gib mir zeit und ich machs :p aber gregor und optimizer und die ganzen kollegen wissen da dimensionen mehr als ich... frag die mal.

Dravere

So, ich glaub mir ist ein Licht aufgegangen und habe mal was kleines auf Papier gekritzelt. Eigentlich bin ich nun einfach von der Idee von Simon2 ausgegangen. So erscheint es mir, zumindest jetzt, tatsächlich deutlich benutzerfreundlicher:

class CMetaDataXYZ
{
    // Daten in der grösse von ca. 4 Bytes.
    // Konstruktoren und all das Zeug.
};

class CMetaDataABC
{
    // Attributes //
private:
    unsigned char m_uc1;
    unsigned short m_us1;

    CMetaDataXYZ* m_pMetaDataXYZ;

    // Constructors & Destructor //
public:
    CMetaDataABC(unsigned char uc1, unsigned short us1, CMetaDataXYZ* pMetaDataXYZ)
        : m_uc1(uc1)
        , m_us1(us1)
        , m_pMetaDataXYZ(pMetaDataXYZ ? new CMetaDataXYZ(*pMetaDataXYZ) : NULL)
    { }
    ~CMetaDataABC() { delete m_pMetaDataXYZ; };

    // Methods //
public:
    const CMetaDataXYZ* get_metadataxyz() const { return m_pMetaDataXYZ; };
    void set_metadataxyz(const CMetaDataXYZ* pMetaDataXYZ) { delete m_pMetaDataXYZ; m_pMetaDataXYZ = (pMetaDataXYZ ? new CMetaDataXYZ(*pMetaDataXYZ) : NULL); }

    // Weitere getter und setter
};

Das wäre dann wohl besser, oder?
Es wird zwar immer noch intern der Heap benutzt. Aber über ein Template-Parameter für einen Allokator könnte man zusätzliche Funktionalität dem Benutzer übergeben, korrekt?

@Shade Of Mine,
Ich glaube Badestrand meinte die Verlinkung zwischen den Listenelementen. Die werden intern wohl auch Zeiger oder Referenzen sein.

Und trommele mal Gregor und Optimizer zusammen. Ihr kennt euch so gut in GCs aus, dann wird es wohl möglich sein, dass eure GCs ein bisschen Zeit frei machen können, damit ihr über die GCs was schreiben könnt

Grüssli

Shade Of Mine

du verlierst hier Laufzeitpolymorphie - warum also nicht auf new/delete verzichten?

Dravere

Shade Of Mine schrieb:

du verlierst hier Laufzeitpolymorphie - warum also nicht auf new/delete verzichten?

1. Es gibt hier keine Polymorphie.
2. Wie sollte ich auf new/delete verzichten?

Grüssli

Shade Of Mine

Dravere schrieb:

Shade Of Mine schrieb:

du verlierst hier Laufzeitpolymorphie - warum also nicht auf new/delete verzichten?

1. Es gibt hier keine Polymorphie.
2. Wie sollte ich auf new/delete verzichten?

Sorry, mein Fehler.
Hab übersehen dass es den Zustand "metaData existiert nicht" gibt.
Dann ist die Lösung gut.

Badestrand

Dravere schrieb:

Das wäre dann wohl besser, oder?
Es wird zwar immer noch intern der Heap benutzt. Aber über ein Template-Parameter für einen Allokator könnte man zusätzliche Funktionalität dem Benutzer übergeben, korrekt?

Absolut korrekt

Kleine eventuelle Stilverbesserung: Du könntest auch eventuell mit Referenzen arbeiten, z.B. so:

class CMetaDataABC
{
    ...

    CMetaDataABC(unsigned char uc1, unsigned short us1)
        : m_uc1(uc1)
        , m_us1(us1)
        , m_pMetaDataXYZ(NULL)
    { }

    CMetaDataABC(unsigned char uc1, unsigned short us1, const CMetaDataXYZ& pMetaDataXYZ)
        : m_uc1(uc1)
        , m_us1(us1)
        , m_pMetaDataXYZ( new CMetaDataXYZ(pMetaDataXYZ) )
    { }

    ~CMetaDataABC() { delete m_pMetaDataXYZ; };

    // Methods //
public:
    // Und statt dem hier:
    const CMetaDataXYZ* get_metadataxyz() const { return m_pMetaDataXYZ; };
    // Eventuell (Geschmackssache, will es nur als Möglichkeit in den Raum stellen):
    bool has_metadataxyz() const { return m_pMetaDataXYZ!=NULL; }
    const CMetaDataXYZ& get_metadataxyz() const { assert(m_pMetaDataXYZ); return *m_pMetaDataXYZ; }
    // Denn in den meisten Fällen ruft man wahrscheinlich eh erst "if (get_meta()!=NULL)" auf, bevor man
    //   mit "get_meta()->bla()" drauf zugreift :)

    // Und statt:
    void set_metadataxyz(const CMetaDataXYZ* pMetaDataXYZ) { delete m_pMetaDataXYZ; m_pMetaDataXYZ = (pMetaDataXYZ ? new CMetaDataXYZ(*pMetaDataXYZ) : NULL); }
    // Eventuell (wieder Geschmackssache, Raum stellen und so):
    void clear_metadataxyz() { delete m_pMetaDataXYZ; m_pMetaDataXYZ=NULL; }
    void set_metadataxyz( const CMetaDataXYZ& meta ) { clear_metadataxyz(); m_pMetaDataXYZ=new CMetaDataXYZ(meta); }
};

Fellhuhn

Versuch doch mal folgende Methode:

bool isOnStack(void *x){
    int a;
    return (void*)&a < x;
}

Unter der Annahme das der Anfang des Heaps immer hinter dem maximalen Bereich des Stacks liegt (und du keine Threads verwendest), dürfte das funktionieren.

EDIT:
Aber wenn du den Nutzern solche Einschränkungen aufbrummst, ist das nicht gerade "nett". Vor allem wenn er von diesen nichts weiß.

Dravere

@Badestrand,
Das war das erste, was ich gemacht habe. Bin mir aber noch nicht sicher, welches besser ist, muss das noch genau durchdenken.

Das schöne an meinem oben geschriebenen Code ist, das eigentlich das gleiche, was du mit vielen Funktionen machst, bei mir auch mit weniger geht.

// get_metadataxyz() liefert einen den Zeiger zurück
// und abc ist ein Objekt von CMetaDataABC

if(abc.get_metadataxyz())
{
}

// genau das gleiche, wie bei deiner Funktion
if(abc.has_metadataxyz())
{
}

// Aber bei mir kann man auch das machen:
const CMetaDataXYZ* pMDxyz = abc.get_metadataxyz();

if(!pMDxyz)
{ pMDxyz = new CMetaDataXYZ(); }

// Mit pMDxyz arbeiten.

// Das dürfte bei deine Lösung etwas schwerer werden

Naja, mal schauen

Danke für die Hilfe!

@Fellhuhn,
Lies den Thread durch

Grüssli

Fellhuhn

Bei vier Seiten? Da poste ich doch lieber arrogant einfach rein.

Simon2

Hi Dravere,

das ist die eine Möglichkeit (Lib hält Kopie).
Vorteil: Die Objekte sind entkoppelt (so kann z.B. der Anwender die Lib nicht durch ein vorzeitiges delete zu Fall bringen).
Nachteil: Die Objekte sind entkoppelt (Lib bekommt Änderungen am Anwenderobjekt nicht mit).

Eine andere wäre tatsächlich der "Verantwortungsübergang":

class CMetaDataABC
{
    // Attributes 
private:
   // ...
   bool m_myObj;
public:
    CMetaDataABC(unsigned char uc1, unsigned short us1)
        : // ...
        , m_pMetaDataXYZ(new CMetaDataXYZ)
        , m_myObj(true)   
    { }
    ~CMetaDataABC() { if(myObj) delete m_pMetaDataXYZ; };

    // Methods //
public:
    const CMetaDataXYZ* get_metadataxyz() const { return m_pMetaDataXYZ; };
    void set_metadataxyz(const CMetaDataXYZ* pMetaDataXYZ) { if(myObj) delete m_pMetaDataXYZ; m_pMetaDataXYZ = pMetaDataXYZ; myObj = false;}

    // Weitere getter und setter
};

Ist aber eine Designalternative, die nicht unbedingt besser/schlechter ist als die obige.... nur eben anders.

Gruß,

Simon2.

Phoemuex

Fellhuhn schrieb:

Versuch doch mal folgende Methode:
bool isOnStack(void *x){
    int a;
    return (void*)&a < x;
}
Unter der Annahme das der Anfang des Heaps immer hinter dem maximalen Bereich des Stacks liegt (und du keine Threads verwendest), dürfte das funktionieren.

EDIT:
Aber wenn du den Nutzern solche Einschränkungen aufbrummst, ist das nicht gerade "nett". Vor allem wenn er von diesen nichts weiß.

In der Praxis wird das zwar (mit deinen Einschränkungen) funktionieren, aber der Standard sagt ganz klar:

If two pointers p and q of the same type point to different objects that are not members of the same object or elements of the same array or to different functions, or if only one of them is null, the results of p<q, p>q, p<=q, and p>=q are unspecified.

Felix

Außerdem wurde ja schon auf den anderen Seiten festgestellt, dass das Herausfinden, ob ein Objekt auf dem Stack, oder dem Heap liegt einfach schlechtes Design ist...