Re: to const or not to const

From:

"Alf P. Steinbach" <alfps@start.no>

Newsgroups:

comp.lang.c++

Date:

Fri, 09 Apr 2010 09:49:40 +0200

Message-ID:

<hpmm6l$49c$1@news.eternal-september.org>

* Balog Pal:

"Alf P. Steinbach" <alfps@start.no>

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.

Interesting that this pop/top 'problem' is mentioned so much. In
practice I can't recall a single case -- the stuff I held in queues and
stacks just never had a throwing ctor. It was either some simple POD or
the equivalent of the unique_ptr. Even for single threaded stuff, but in
MT definitely the latter.

I do not want a fat copy inside a critical section. Let alone one that
calls system functions for memory and/or may throw.

Yah, the practical solution may just be to require non-throwing copying for the
items.

Anyway, I feel utterly stupid.

I'm looking at <url:
http://code.google.com/codejam/contest/dashboard?c 4113#s=a&a=2>, and they
say, "Behold, the Aha moment ..." -- and there's no Aha in my brain at all.

I'm assuming those colored lines are meant to be directional, after all it's a DAG.

But DAnG!

Cheers,

- Alf