×

Discussion Board

Results 1 to 7 of 7
  1. #1
    Regular Contributor
    Join Date
    Nov 2008
    Posts
    138

    Allocating variable from the stack and passing the variable as a parameter to object

    Hello,

    I am fairly new to C++. Could someone tell me if following code is safe.

    Code:
    void MyView::myMethod()
    {
        QPixmap myPixmap(":/images/up.png");
    
        someButton = new MyCustomButton(myPixmap,this);
    }
    
    
    MyCustomButton::MyCustomButton(const QPixmap &pixmap, QWidget *parent)
        : QWidget(parent), m_pixmap (pixmap)
        {
        m_pixmap = pixmap;
        }
    
    class MyCustomButton: public QWidget
        {
    ..
        private:
            QPixmap m_pixmap;
    ...
    }

    I am worried that the pixmap data is corrupted, because it is allocated from the stack, not heap. Does the MyCustomButton instance make a copy of the pixmap when instance is constructed?

    -FoL

  2. #2
    Regular Contributor
    Join Date
    Nov 2008
    Posts
    138

    Re: Allocating variable from the stack and passing the variable as a parameter to obj

    It seems that it is safe, because reference counter is increased by one in MyCustomButton constructor.

    http://doc.qt.nokia.com/4.7/implicit-sharing.html

    Does anyone know if the QPixmap data is allocated from the heap or stack? I am worried that application run out of memory , if I create many QPixmap variables without allocation them *explicitly* from the heap.

  3. #3
    Registered User
    Join Date
    Jul 2004
    Posts
    166

    Re: Allocating variable from the stack and passing the variable as a parameter to obj

    as general practice, you should create it on heap, rather than on stack
    http://kunalmaemo.blogspot.com/

  4. #4
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Allocating variable from the stack and passing the variable as a parameter to obj

    Items like QPixmap have copy constructors, et al, and can be safely passed as ordinary parameters (reference or not) and copied with simple assignment. In reality they consist of a small anchor object that contains a reference-counted pointer to the heap-allocated "mother" object, so while assignment isn't extremely efficient, it's not all that inefficient either.

    Passing as a reference parameter (const if the parm won't be modified) is at least in theory more efficient than passing as a value parm (though the compiler may map value parms to const reference parms under the covers).

    I find the Qt documentation on this all to be woefully inadequate. Thankfully it all mostly works fine if you ignore most heap issues, so long as you at least "parent" objects you "new" yourself.

  5. #5
    Regular Contributor
    Join Date
    Nov 2008
    Posts
    138

    Re: Allocating variable from the stack and passing the variable as a parameter to obj

    Quote Originally Posted by danhicksbyron View Post
    Items like QPixmap have copy constructors, et al, and can be safely passed as ordinary parameters (reference or not) and copied with simple assignment. In reality they consist of a small anchor object that contains a reference-counted pointer to the heap-allocated "mother" object, so while assignment isn't extremely efficient, it's not all that inefficient either.

    Passing as a reference parameter (const if the parm won't be modified) is at least in theory more efficient than passing as a value parm (though the compiler may map value parms to const reference parms under the covers).

    I find the Qt documentation on this all to be woefully inadequate. Thankfully it all mostly works fine if you ignore most heap issues, so long as you at least "parent" objects you "new" yourself.
    I am not sure if I understood you correctly. Is the myPixmap allocated from the heap or stack?

    We are loading (QPixmap myPixmap(...)) like 50 images. We have realized out of memory issues. Does it occur because QPixmap isn't allocated from the heap? Thank you for your information.

    -FoL

  6. #6
    Registered User
    Join Date
    Aug 2009
    Posts
    173

    Re: Allocating variable from the stack and passing the variable as a parameter to obj

    You can try this kind of trick, but i am not sure, is calculation always true.
    Because of stack may increase when is getting too low and how system allocates
    space from stack. Yes, we are trying to check the current size of the stack.

    #include <iostream>

    //put local variable on the stack before bitmap allocation
    int top;
    //take the address of local stack variable
    std::size_t topOfStack = (std::size_t)&top;

    //allocate your bitmaps here

    //put local variable on the stack after bitmap allocation
    int bottom;

    //take the address of local stack variable
    std::size_t bottomOfStack =(std::size_t)&bottom;

    //calculate the space difference between to variables
    std::size_t stackSize = topOfStack - bottomOfStack;

    stackSize is in bytes (at least with x86 processor)

    But how this trick works with ARM processor, i do not know.
    And how ARM's stackpointer is counting. From higher address
    to lower address or vice versa.

  7. #7
    Super Contributor
    Join Date
    Nov 2009
    Location
    Minnesota, USA
    Posts
    3,209

    Re: Allocating variable from the stack and passing the variable as a parameter to obj

    myPixmap is located in the stack. (Everything you declare as automatic in your program is in the stack.) But myPixmap is only maybe four machine words -- the real pixmap is in something like "QPixmap_Private" and is stored in heap.

    You are getting out of memory because you're loading too many pixmaps, and each takes up a chunk of heap. Remember, each pixel of an image takes 2-8 bytes of storage when expanded internally.

Similar Threads

  1. Passing variable
    By amitgawali in forum Symbian
    Replies: 5
    Last Post: 2010-03-31, 08:51
  2. Passing a Variable to the Next View
    By Tadot in forum Symbian
    Replies: 6
    Last Post: 2009-07-23, 04:32
  3. Replies: 5
    Last Post: 2008-02-21, 19:04
  4. Replies: 4
    Last Post: 2007-12-08, 07:48
  5. Replies: 0
    Last Post: 2005-09-29, 00:54

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×