Re: to const or not to const
tonydee wrote:
On Apr 9, 12:53 pm, "Alf P. Steinbach" <al...@start.no> wrote:
value_type pop ( void );
// blocks until an item is available
This method is very interesting. In a single-threaded program it should
clearly not be the basic interface but just a convenience wrapper around
'top' and 'remove_top', because the copying of value_type may throw after
altering the fifo state, preventing sound exception guarantee. But in a
multi-threaded environment how does one use the more primitive operations
safely?
Yes, same thoughts came to me, but I was too lazy to address it at the
time....
I can imagine that 'top' and 'remove_top' would be accessed within a
block protected by a mutex.
I think that mutex thingy should be exposed as part of the interface, and
the 'pop' above an inline convenience method.
That sounds workable and clean from the perspective of this issue, but
doesn't a convenience function defeat the point? Sans pop(), it a bit
nasty from a usability perspective.
With a backyard hacker hat on, I might observe a great many copy
operations can't throw (especially if you ignore throws from new(),
discussed below), and pop() has an interesting characteristic: the
potential to "move" the object - which I think C++0x will facilitate
(?) - more efficiently than the Value& top() / void pop() semantics.
The simpler interface may become the better one in just a couple
years.
I was thinking along the same lines. Would it be possible in C++0X to write
pop() with a strong exception safety guarantee? Something like: it does the
copy-construction internally and outside a move happens?
I remember reading an interesting article about the practicality of
trying to catch exceptions from memory allocation (i.e. new()), which
pointed out that most modern operating systems will do sparse memory
allocation, so unless the address space is smaller than the RAM+swap
(reasonably common for 32-bit apps / not for 64-bit), it's sure to get
the address space, and new won't throw. But, if an attempt is made to
page-fault in some of the memory supposedly allocated, then the "real"
allocation against RAM/swap takes place, and the application may
SIGSEGV. Point was, benefits of doing try/catch around new are
platform specific, and in modern practice you'll probably get more
production issues from more complex/verbose code than you'll
successfully handle during resource exhaustion....
Still, excellent points to bring into the design discussion.
Well, one could have the following interface:
template < typename T >
class fifo {
public:
typedef T value_type;
typedef std::size_t size_type
fifo ( size_type n = -1 );
void push ( value_type const & value );
class reader {
reader ( fifo & );
~reader ();
value_type const & top ( void ) const;
void pop ( void );
};
bool available ( void ) const;
// returns true if the a call to pop() would not block
void wait_available ( void ); // should this be const ?
// blocks until a call to pop() will not block
};
Now, in the consumer thread, one would have:
...
event e;
{
fifo< event >::reader hold_onto ( buffer );
e = hold_onto.top();
hold_onto.pop();
}
e.handle();
update_screen();
...
The constructor of the reader object would lock the buffer and wait until an
item becomes available. The destructor would unlock.
For the use cases, I have in mind, the above is overkill and makes client
code too messy. So, I think (as Alf suggested) that a convenience function
for non-throwing copy-constructors should be kept.
Best
Kai-Uwe Bux