auto_ptr and const atributes in stl container

This is a discussion on auto_ptr and const atributes in stl container within the C++ Programming forums, part of the General Programming Boards category; Dear all, I'm having an issue using auto_ptr inside a container. I have a std::map with the following format: Code: ...

  1. #1
    Registered User
    Join Date
    Sep 2009
    Posts
    6

    auto_ptr and const atributes in stl container

    Dear all,

    I'm having an issue using auto_ptr inside a container. I have a std::map with the following format:
    Code:
    typedef  map<date, const MediatorEvent *> AtributeMap; // date is boost::gregorian
    typedef pair<date, const MediatorEvent *> AtributePair;
    typedef AtributeMap::iterator iAtributeMap;
    typedef AtributeMap::reverse_iterator rAtributeMap;
    These MediatorEvent classes are shared among a lot of clients through a Facade,
    that's why it's declared as "const".

    However, I would like to refer methods of this object, which is not possible since the g++ do not allow the reference to be a left parameter

    Code:
    MediaorEvent *m = _facade->getEvent(...); 
    m->c_scr(); // main.cpp:81: error: passing 'const MediatorEvent' as 'this' argument of 'const std::string MediatorEvent::c_str()' discards qualifiers
    If I remove the "const" on the container it works fine, but it allows any client to explicit delete the object, and this will bring a lot of inconsistencies in the code.

    Another possibilty to avoid this is to use auto_ptr, but I'm not sure how and neither where to use it.

    My question to you guys is: Is it possible to use it safetly inside a container, such as:

    Code:
    typedef  map<date, auto_ptr<MediatorEvent> > AtributeMap;
    typedef pair<date, auto_ptr<MediatorEvent> > AtributePair;
    typedef AtributeMap::iterator iAtributeMap;
    typedef AtributeMap::reverse_iterator rAtributeMap;
    ??

    My concern is to assure that the customers would share the object pointer but none of them would change the object or delete it. I tried to use a flyweight and even the Factory design pattern, but all of them introduces a lot of complexity in the architecture and in the code and I'm trying to avoid introducing new patterns for now.

    Any suggestions or ideas?

    Thanks & regards,
    yezaim

  2. #2
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,264
    you can't use an auto_ptr in a stl container. You should use a boost::shared_ptr instead.
    bit∙hub [bit-huhb] n. A source and destination for information.

  3. #3
    Registered User
    Join Date
    Jun 2005
    Posts
    6,646
    Quote Originally Posted by yezaim View Post
    However, I would like to refer methods of this object, which is not possible since the g++ do not allow the reference to be a left parameter

    Code:
    MediaorEvent *m = _facade->getEvent(...); 
    m->c_scr(); // main.cpp:81: error: passing 'const MediatorEvent' as 'this' argument of 'const std::string MediatorEvent::c_str()' discards qualifiers
    All you need to do is declare c_str() with a const attribute as well, so you honour the contract you have told the compiler to follow by declaring your container with const elements.
    Quote Originally Posted by yezaim View Post
    Another possibilty to avoid this is to use auto_ptr, but I'm not sure how and neither where to use it.
    Since auto_ptr is about managing lifetime of an object, not with allowing it to be shared, it is not what you need to use. A shared pointer of some form, maybe.

    Quote Originally Posted by yezaim View Post
    My question to you guys is: Is it possible to use it safetly inside a container, such as:
    It is not, because auto_ptr has copy semantics that are incompatible with how the standard containers work. In rough terms, the standard containers assume their elements will not be destroyed upon copying, and auto_ptr copy operations are all about destroying objects that are being managed.

    I'm not sure offhand if the standard forbids containers of auto_ptrs, or simply strongly discourages them. Either way, they are not a good idea, and don't address your problem anyway.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  4. #4
    Registered User
    Join Date
    Sep 2009
    Posts
    6
    Thanks grumpy!!

    I got the idea with containers. Adding the const in the c_str worked, I just had to change an internal iterator to a const_iterator. I'm still having a segmentation fault with the new mao, in this case only GDB saves

    thx again for the quickness and BTW, funny quote!!! kkk

  5. #5
    The larch
    Join Date
    May 2006
    Posts
    3,573
    My concern is to assure that the customers would share the object pointer but none of them would change the object or delete it.
    You can delete even const pointers, even though you can prohibit modifying the object:

    Code:
    int main()
    {
        const int* const n = new int(42);
        delete n;
    }
    I suppose, this is something not worth to worry about too much. If your library manages the lifetime of its objects, which should be clear to them, it is entirely their fault if they they try too hard and blow everything up:

    Code:
    int main()
    {
        std::auto_ptr<int> p(new int(42));
        delete p.get();
    }
    Any delete in user code should be an error
    Last edited by anon; 10-09-2009 at 04:35 PM.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

Popular pages Recent additions subscribe to a feed

Tags for this Thread


1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21