Re: STL (boost) and copies of iterator
On 4 Mai, 10:47, Thomas Mang <noth...@provided.com> wrote:
Daniel Kr?gler wrote:
You refer to the fact that not much can be done to those iterators.
Fine, as long as it stores a copy, bad enough for me. You refer to the
fact that destruction is problematic. Well, compilers are clever
nowadays. Very clever. It can find out that the underlying container
will be deleted almost at the end of the program. And still the present
implementation if it stores the iterators for a limited time only.
I try to shorten the discussion: A compiler is allowed to do
as much of transformations it likes, but it is not allowed to
change so-called (observable) side effects of the abstract
machine (1.9/5). These restrictions have only a small legal
loophole in cases of object copies in some *dedicated* (but
not arbitrary!) situations described in section 12.8. Some of
the relevant quotes concerning "conservation of observable
behaviour" are:
3.7.1/2:
"If an object of static storage duration has initialization or a
destructor with side effects, it shall not be eliminated even if
it appears to be unused, except that a class object or its copy
may be eliminated as specified in 12.8."
3.7.2/3:
"If a named automatic object has initialization or a destructor
with side effects, it shall not be destroyed before the end of its
block, nor shall it be eliminated as an optimization even if it
appears to be unused, except that a class object or its copy
may be eliminated as specified in 12.8."
5.2.2/8 [Function call]
"[..] All side effects of argument expression evaluations
take effect before the function is entered [..]"
Search for "side effect" in the standard and you will find
much more. The special copy guarantees can be found
in 12.8/15 and can simplisticly be summarized as relating
to situations where copies can be elimanted, that is
- function return values
- copies of temporaries
Your example of an iterator myIterator with a static
copy-counter member is a class which has non-trivial
copy assignment, copy constructor, and destructor
and the compiler is not allowed to remove their
invocations in your described situation at there
corresponding "code positions". In short: a fully-
optimizing compiler is allowed to do everything it
likes, *if* it also obeys the law. So, yes, the
compiler is allowed to make wild copies in static
(or non-static) variables, if it can prove that the
above mentioned triad of operators is trivial (e.g.
pure pointers). And if it would indeed take advantage
of these properties, you cannot observe that (Note:
assembler code itself or the debugger is not an
observable restriction, so don't tell me that you were
able to "see" these changes!)
That all your arguments so far can be shot down by as-if
As others have already mentioned: assert exhibits
observable behaviour *if* NDEBUG is not defined
before #include <assert.h> and if it's argument is
false, because according to C99 7.2.1.1/2 it is required
to write on the standard error stream which *is*
observable behaviour according to the current C++
standard (1.9/7).
case I would take the pragmatic point of view, that
we can *implicitely* exclude the validity of a non-pointer
local static holding a copy of it's arguments.
The pragmatic point of view is no problems occurred so far ;-)
But frankly I don't like implicit assumptions, especially if they can be
all shot down by as-if (in my eyes, at least).
The description "pragmatic view" was actually wrong. I
wanted to say that my conclusions are basically a
deduction from requirements on the compiler, which
are indirectly implied by the standard. If conclusions
can be deduced and thus are *implied* by the
standard, these are not less valuable as a corresponding
explicit statement.
I wonder if - from pure std point of view - an iterator relying on the
container to be in valid state once the iterator's destructor is called
is actually relying on too much. Where does it give us this "freedom" to
assume so?
The standard does not explicitely forbid non-trivial destructors
of iterator's and so they are feasible because there is no
other requirement which would contradict this assumption.
Since the standard requires that base class and member
d'tor of class objects have to be invoked *after* the d'tor of
such object has finished (12.4/6), these can be accessed
only controlled by the individual state requirements of this
class. That is: Programmers have to follow these
requirements, otherwise everything is lost.
[Note that this issue is kind of tied to the above issue - if all
iterators are destroyed at the end of an algo-call, then there is hardly
any fear since the input range must be valid anyway. It just extends the
issue to your destruction problem].
Both copy-c'tor and d'tor have to be considered in your
situation because both have side-effects and are thus
non-trivial.
Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]