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

you can't use an auto_ptr in a stl container. You should use a boost::shared_ptr instead.

Originally Posted by yezaim

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.

Originally Posted by yezaim

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.

Originally Posted by yezaim

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.

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

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