Checken ob ptr im Heap oder stack[closed]



  • Jo hi,

    sagt mal, gibts ne "einfache" möglichkeit, zu prüfen ob n ptr im Process/private heap ist, oder ob der ptr auf den stack zeigt??

    (HeapWalk wollte icke jetzt gerade nicht nehmen..)

    greetz



  • Man,.. google 👍

    http://www.codeproject.com/Articles/35206/Pointer-pointing-to-Stack-or-Heap.aspx

    "In the Thread information block, there are two members, the "StackTop"( located at FS[4] ) and "StackBase" ( located at FS[8] )."

    // This function will return true if the pointer points to stack. Other wise false
    
    bool IsMemoryOnStack( LPVOID pVoid )
    {
        LPVOID dwStackTop = 0;
        LPVOID dwStackLowCurrent = 0;
        __asm
        {
            mov EAX, FS:[4]
            mov dwStackTop, eax
                mov EAX, FS:[8]
                mov dwStackLowCurrent, eax
        }
        if( pVoid <= dwStackTop && pVoid >= dwStackLowCurrent )
        {
    
            // The memory lie between the stack top and stack commited.
            return true;
        }
    
        // Pointer dosen't point to the stack
        return false;
    }
    

    fast close... 😃


  • Mod

    Schau Dirmal die grundsätzliche Diskussion in "Effective C++, Item 27" an.

    Grundsätzlich halte ich den Versuch dies zu unterscheiden schon "für gefährlich" 😉



  • Hi Martin,
    jo, da haben wir wieder das thema Multible derivate (page 3),..
    ich lese mal weiter,.. 😉 thx

    -------------------------------------------------------------------

    So, ich benutze meistens Funktionscast des Alten stils oder halt C-Cast style die in dem Object per operator doube() o.ä. deklariert und definiert sind, also von daher ist das alles in ordnung.

    Das worum es hier geht ist,
    das ich eine Methode habe, in der entweder die addresse eines externes Object per ptr übergeben wird, oder dieses Object innerhalb der Methode (auf dem ProcessHeap) erstellt wird.

    Meine Schnittstellendefinition sieht vor, das beim Call des Dtor, alle hinterlegten Objekte "deleted" werden, egal ob extern oder nicht.

    Nun kommt aber der Fall, das einfach nur eine referenz eines Objectes vom Stack übergeben wird, und darauf ein delete, naja, du kannst Dir ja vorstellen das das nicht gut ausgehen würde.

    Um das Prob zu lösen, rufe ich halt nun explicit den Dtor der externen und internen referencen auf.

    Vlt. gibt es noch eine elegantere Lösung, aber diese fällt mir gerade nicht ein.

    Sag mal, noch ne andere frage:
    Global definierte Objecte, wo wird der Ctor aufgerufen?? Kann das gerade nicht im CallStack nachvollziehen,..

    Sei gegrüßt und hab dank 🕶


  • Mod

    Und warum verwendest Du hierfür nicht eine Container-Klasse, die funktioniert wie ein Smart-Pointer und das Objekt entsprechend behandelt?



  • Jo Martin

    Prinzipiell hast Du recht,
    ich denke aber das bei mir an der stelle es wohl auch eine einzelne flag
    das nötige tut (Sonstige sicherheitsmechanismen sind ja vorhanden, bin bloß
    gerade an der Schnittstelle+ späteres handling hängen geblieben..).
    Es ist schneller in meinem Source zu implementieren.

    Vereinfacht habe ich dieses Konstrukt: (Hier mit flag...)

    class a {}; //polymorphical
    
    class b: public a {}; //polymorphical
    
    class c
    {
    private:
    
    a* fooVar; //eigentlich ne dynamische anzahl,.. hier vereinfacht
    bool flag;
    
    public:
    void Method(a* aPtr=0)
    {
      if(aPtr)
       {
         fooVar=aPtr;
    }
    else
       {
         fooVar= new a;
         flag= true;
    }
    
    };
    
    ~c()
    {
       if(flag)
        {
          delete fooVar;
    }
    else
        {
           fooVar->~a(); /*wird ohne c so oder so nicht benötigt, bin gerade am 
     überlegen, wenn jemand das von aussen anlegt, kann dieser sich auch um das weitere handling kümmern... hmm*/
    };
    
    };
    

    Nette erklärung plus unten ein paar weiterführende referencen zum Thema Smart_ptr's
    http://en.wikipedia.org/wiki/Smart_pointer

    Danke für den tipp mit den smart_ptr,.. ich werde mich mal mit der STL variante
    später genauer beschäftigen,...

    BüS später Martin..


Anmelden zum Antworten