Re: to const or not to const
On Apr 9, 10:42 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
Jonathan Lee wrote:
On Apr 9, 4:45 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
where the_data is a std::queue. The copy-constructor
initializing result comes before the_data.pop(). If we had
a guarantee that the compiler uses RVO in this case, maybe,
one would be back in business :-)
Why don't you use strict ownership semantics, like auto_ptr?
Thanks for the suggestion. I think, unique_ptr could be
slightly more appropriate for communication between threads:
internally, the fifo<T> uses a queue and I have the vague
recollection that auto_ptr<T> does not fare well in
containers.
It doesn't, but there's no law that the container has to use the
same type as the interface. My multithread queues all use
std::auto_ptr at the interface, and raw pointers internally,
with something like:
m_data.push_back(in.get());
in.release();
when writing (to ensure that the pointer actually is in the
deque before calling release). And:
std::auto_ptr<T> result(m_data.front());
m_data.pop();
when reading. Depending on the context, you can either delete
anything left in the queue in the destructor, or assert that the
queue is empty when the destructor is called.
(I have to admit, that I am not sure about unique_ptr
either:-)
I thought one of the goals was to allow it to be used in a
container. (But I've not looked into the details.)
However, it is somewhat unfortunate that you snipped the
context: the question has migrated and in this subthread
became "is it possible to implement pop() with strong
exception safety guarantee".
It's not a practical concern to _use_ fifo<T> in an exception
safe manner. Just make sure that the constructors of T don't
throw. But that we have ways of using fifo<T> in an exception
safe way is not the same as finding an implementation for
pop() that does that out of the box for any type.
Yes. I was just responding to the immediate question. In
practice, I've not found this to be an issue in interthread
communication, because you're not normally using types whose
copy constructor might throw.
--
James Kanze