VC STL - begin() for a container

Author

begin() for a container

Stephen Howe

2006-01-09, 11:10 pm

Assuming I have a container with at least 1 element:

Can calling begin() raise an exception?

In the standard under 23.1 it says

"no copy constructor or assignment operator of a returned iterator throws an
exception."

but that it talking about the returned iterator.
What if the main body of begin() raises an exception before the returned
iterator is got to?
If the standard says that begin() & end() do not raise exceptions - where
in chapter & verse?

Thanks

Stephen Howe

Doug Harrison [MVP]

2006-01-09, 11:10 pm

On Tue, 20 Dec 2005 16:38:49 -0000, "Stephen Howe"
<stephenPOINThoweATtns-globalPOINTcom> wrote:

>Assuming I have a container with at least 1 element:
>
>Can calling begin() raise an exception?

Just in case anyone's thinking begin() requires a non-empty container, note
that for an empty container, begin() == end().

>In the standard under 23.1 it says
>
>"no copy constructor or assignment operator of a returned iterator throws an
>exception."
>
>but that it talking about the returned iterator.
>What if the main body of begin() raises an exception before the returned
>iterator is got to?
>If the standard says that begin() & end() do not raise exceptions - where
>in chapter & verse?

I don't find it, either. On the one hand, if a function can throw an
exception, it's supposed to be explicitly noted; see 17.3.1.3/3. The only
descriptions of begin() and end() I find are in Table 65 and 23.1/7, and
neither says anything about exceptions. However, 17.4.4.8/3 allows
functions lacking exception-specifications to throw, and begin() and end()
both lack them. So I'd say it's permissible for begin() and end() to throw,
but I would consider this a bizarre and unfriendly thing to do. Oh wait, I
just thought of an example; a copy-just-in-case basic_string implementation
may unshare the string data and mark it unsharable whenever you call
non-const begin() or end(), and this obviously can throw. Fortunately, no
one is writing basic_string like this anymore; VC abandoned this approach
as of VC7.

--
Doug Harrison
Visual C++ MVP

Stephen Howe

2006-01-09, 11:10 pm

> >Can calling begin() raise an exception?
>
> Just in case anyone's thinking begin() requires a non-empty container,
note
> that for an empty container, begin() == end().

I think I unintentionally

people. Sorry about that.
Yes that is what I am getting at. But there is a difference between

vector<int> v;
vector<int>::iterator it;
int i;

it = v.begin(); // 1
i = *v.begin(); // 2

Statement 1 is okay regardless of whether container is empty or not.
Statement 2 is only okay for non-empty containers, undefined otherwise.
But you knew this :-)

What I am concentrating is just statement types like 1 - can an exception
occur?
In that case, it makes no difference whether the container is empty or not.
Sorry for the confusion.

> I don't find it, either. On the one hand, if a function can throw an
> exception, it's supposed to be explicitly noted; see 17.3.1.3/3. The only
> descriptions of begin() and end() I find are in Table 65 and 23.1/7, and
> neither says anything about exceptions. However, 17.4.4.8/3 allows
> functions lacking exception-specifications to throw, and begin() and end()
> both lack them.

Yes that is what I noted. Strange huh?

> So I'd say it's permissible for begin() and end() to throw,
> but I would consider this a bizarre and unfriendly thing to do.

Same here. But one of colleagues wondered if he needed try and catch clauses
everytime he used begin() and end(). I see nothing that says that doing this
is overkill so I can't advise him "don't do this". If this was oversight in
standard, I am amazed that no one did not submit a Defect Report for the
recent amendment.

I think I will raise this on comp.lang.c++.moderated

Thanks

Stephen Howe

Doug Harrison [MVP]

2006-01-09, 11:10 pm

On Tue, 20 Dec 2005 19:00:38 -0000, "Stephen Howe"
<stephenPOINThoweATtns-globalPOINTcom> wrote:

>Same here. But one of colleagues wondered if he needed try and catch clauses
>everytime he used begin() and end(). I see nothing that says that doing this
>is overkill so I can't advise him "don't do this". If this was oversight in
>standard, I am amazed that no one did not submit a Defect Report for the
>recent amendment.

FWIW, I think it would be overkill. Extreme overkill. Except for
basic_string, the possibility of begin() and end() throwing has never
occurred to me. If I ran into an implementation for which it could occur,
I'd run the other way. :)

>I think I will raise this on comp.lang.c++.moderated

It would be nice to get a definitive answer on this. I'll follow it
there...

--
Doug Harrison
Visual C++ MVP

Sponsored Links