In article <37CC152A.957A2DE6@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
>If it is a cost depends on the class.

Of course it does, but you were trying to lay down a general principle,
one that I disagreed with.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$2yb4hf$30j$1@firewall.thermoteknix.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>
>Francis Glassborow wrote in message ...
>>
>>I strongly disagree.  Once an object has been constructed it should be
>>in a stable state.  Preferably it should be in a usable state.  I can
>>see no reason why the members of a well-designed class should need, in
>>general, to check the state of the object.
>>
>>Perhaps I am plain stupid (and my mind is not fully functioning at the
>>moment) but I cannot see how any helper function will solve the problem.
>>Either an object is usable when it leaves a ctor, or every public member
>>function must check its usability.
>>
>>Francis Glassborow
>>
>>At 04.30 BST, August 24th, Anne Rowlingson, the brightest
>>light in my world, died from Cancer. May she find peace.
>>
>
>Members use the form helper()->

But there is your cost, helper()-> contains code and even if you are
using a block scope static the check is still being done.

> instead of data_ptr-> to access
>the array. No check is required. I assume that the class does not
>have dozens of members with long implementations, so this is a
>mild notational inconvenience.
>
>I think you are over-concerned by the apparent "incompleteness"
>of the initialisation done by the constructor. All that matters is that
>the constructor deliver an object with the correct invariant. This is
>an implementation choice, and I've chosen to allow the pointer to
>be NULL.

OK, but accept that there is a cost for this and the cost is paid
everywhere the data member is used.

>
>If the net effect is simply to transfer the risk of the exception onto all
>other member functions (even const members), then this is actually
>a bad idea. I'm not a big fan of "const" operations that throw. (I didn't
>ask the object to change anything, so what is it whinging about?)
>
>However, in most cases that I've seen the risk of the exception is
>only transferred to a small number of non-const functions. In the
>most common case, where the resource is memory, these functions
>might have to re-allocate anyway to change the amount.

It isn't just the risk of an exception but the overall cost everywhere.

>
>For a concrete example, both string and vector need re-allocate
>occasionally. I accept that these operations will have to advertise
>throw(std::bad_alloc). The classes do not need to throw anything
>in their default constructors. It is an implementation choice. The
>original poster thinks they would be more usable if this non-throwing
>behaviour were mandatory. I agreed, but I'm wobbling.

And my feeling is that making it mandatory overly constrains the
implementation for little gain.  As of now there is nothing to stop an
implementer providing versions whose default ctors guarantee not to
throw but there is nothing to require this and I believe this is
correct.

>
>I think it would be more important if exception specs were checked
>statically. I think *that* would be a good idea iff we had a way to
>"propogate" specifications through templates. (So, for example,
>std::copy would not throw if and only if the target type didn't throw
>when copied and the iterator didn't throw when dereferenced.)

Yes, we entirely agree here.  This is why I would like compilers to
provide a way to switch off exception specs.  At the moment there is a
real reason not to use them, but until they are regularly used there is
little motive to do the work required for static checking.  I would like
behaviour somewhat like that of assert in so far as it can be switched
on when debugging and off for production code.

>
>Since the committee chose to stop short of such a thing (probably
>wise; I think it is quite hard) the current standard does not have this
>feature. As things stand, putting throw specs on some library functions
>and not others would constrain implementations but deliver little benefit
>to programmers. Like const correctness, exception specs need to be
>applied universally before they become useful.

But they also need static checking and the ability to switch off dynamic
checking.

>
>

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <LSV3YWAVXxx3Ewcf@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <newscache$2yb4hf$30j$1@firewall.thermoteknix.co.uk>, Ken
> Hagan <K.Hagan@thermoteknix.co.uk> writes
> >
> >Francis Glassborow wrote in message ...
> >>
> >>I strongly disagree.  Once an object has been constructed it should
be
> >>in a stable state.  Preferably it should be in a usable state.  I
can
> >>see no reason why the members of a well-designed class should need,
in
> >>general, to check the state of the object.
> >>
> >>Perhaps I am plain stupid (and my mind is not fully functioning at
the
> >>moment) but I cannot see how any helper function will solve the
problem.
> >>Either an object is usable when it leaves a ctor, or every public
member
> >>function must check its usability.
> >>
> >>Francis Glassborow
> >>
> >>At 04.30 BST, August 24th, Anne Rowlingson, the brightest
> >>light in my world, died from Cancer. May she find peace.
> >>
> >
> >Members use the form helper()->

NO NO NO!  This is the wrong design approach.  If constructors that
throw exceptions are not permitted then they should initialise the
object to a statically allocated default implementation.

Thus members are always of the form:

return body->implementation(body, parm1, ...);

The default implementation "knows" a non-default body needs allocating
for mutating methods (which is why "body" is passed) and is guaranteed
safe for non-mutating methods.

The cost of this design is the blank stares of the maintenance
programmers who rightly (in most cases) say "but why not just allocate
the body in the constructor?"

--
Alan Griffiths (alan.griffiths@experian.com, +44 115 934 4517)
Senior Systems Consultant, Experian


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:

[...]

> >
> >If the net effect is simply to transfer the risk of the exception onto all
> >other member functions (even const members), then this is actually
> >a bad idea. I'm not a big fan of "const" operations that throw. (I didn't
> >ask the object to change anything, so what is it whinging about?)
> >
> >However, in most cases that I've seen the risk of the exception is
> >only transferred to a small number of non-const functions. In the
> >most common case, where the resource is memory, these functions
> >might have to re-allocate anyway to change the amount.
>
> It isn't just the risk of an exception but the overall cost everywhere.

If it is a cost depends on the class.

For vector, if the data pointer is NULL, the capacity and
size have both to be 0 (certainly).
Now _each_ action on the pointer has to check capacity or
size, unless it has undefined behaviour in the access case
anyway (in which case the pointer check is unnecessary).

If growing is needed (which is the case whenever you put
anything into the empty vector, or change the capacity),
the following happens:

- New memory is allocated (doesn't depend on the old pointer)
- size() objects are copied from the old to the new location
  (if the old location pointer is NULL, size() is NULL as well,
  so no object is copied, and therefore the old location pointer
  isn't used at all here)
- The old memory is deleted (works fine on a NULL pointer)

Now, if capacity is 0 (as is the case for "NULL pointer state"),
_everything_ accessing the pointer will find capacity being
too low, or the access being out of range. Therefore,
either the check of capacity or size is needed (and prevents
the NULL pointer to be accessed), or undefined behaviour
is invoked anyway (in which case the NULL check isn't
required either - it doesn't matter if the undefined
behaviour occurs through dereferencing a NULL pointer
or through accessing out of range).

As you see, no extra check for NULLness is required
(because the invariants cause the NULL pointer not to
be used anyway, except in cases of undefined behaviour).

Now, any class where the invariant guarantees anyway
that a NULL pointer is not used can use the "late allocation"
scheme without an extra check for NULL pointer
(except maybe as debugging aid, since accessing a NULL
pointer means a class invariant was broken), and therefore
without overhead.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ken Hagan wrote:
...
> Members use the form helper()-> instead of data_ptr-> to access
> the array. No check is required. ...

If no check is being peformed by the call to helper(), how does it help?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$b15zgf$s8e$1@firewall.thermoteknix.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>But what can a class contain as its members, except PODs? Sooner or
>later we have to boil down to raw data, and since this is the *default*
>constructor, our choice of the initial values is limited only by the
>physical
>invariants of the class implementation, which we can choose to suit our
>purpose.

Somewhere I must have lost the thread of what you are after.  Are you
confusing default ctor (one that needs no arguments) with the compiler
generated default ctor.

Consider:

struct X {
        int * data_ptr;
        X():data_ptr(new int[10]){};
        ~X()throw(){delete [] data_ptr;}
private:
        X(X const &);
        X& operator=(X const &);
};

not only do the ctors of this class throw but so do all ctors (including
compiler generated ones) for classes derived from X, or that have an X
member.




Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I made a specific exemption for classes that have to allocate
resources in their constructor. At the same time, I argued that
most classes don't have to, since they can set pointers/handles
to NULL and allocate on first use. Therefore, the majority of
argument-less constructors can have empty exception specs.

In my experience, this is rarely an inconvenience. The class
may well have checks for changing the size of the buffer, and
we can always write a private helper...

int * X::get_data_ptr()
{
   if (data_ptr==NULL)
      data_ptr = new int[10];
   return data_ptr;
}

Francis Glassborow wrote in message ...
>
>Somewhere I must have lost the thread of what you are after.  Are you
>confusing default ctor (one that needs no arguments) with the compiler
>generated default ctor.
>
>Consider:
>
>struct X {
>        int * data_ptr;
>        X():data_ptr(new int[10]){};
>        ~X()throw(){delete [] data_ptr;}
>private:
>        X(X const &);
>        X& operator=(X const &);
>};



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$2qk0hf$7wl$1@firewall.thermoteknix.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>In my experience, this is rarely an inconvenience. The class
>may well have checks for changing the size of the buffer, and
>we can always write a private helper...

I see, so you are proposing that every member function of a class with
dynamically allocated resources must check if they have been allocated?
Well every one to their own, but I prefer my ctors to provide usable
objects and limit change to a small subset of the member functions.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote in message ...
>I see, so you are proposing that every member function of a class with
>dynamically allocated resources must check if they have been allocated?

Er, no, that was the point of the helper. I write the check-and-allocate
code only once. In any case, many classes which deal in dynamic
resources do so because they may need to re-allocate, so the class
members will be checking stuff in any case.

>Well every one to their own, but I prefer my ctors to provide usable
>objects and limit change to a small subset of the member functions.


My object is usable too. The only differences are that the cost of that
dynamically allocated resource is only paid when it is needed, and that
any errors that result are associated with the operation that needed it.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$5lu2hf$apd$1@firewall.thermoteknix.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>Er, no, that was the point of the helper. I write the check-and-allocate
>code only once. In any case, many classes which deal in dynamic
>resources do so because they may need to re-allocate, so the class
>members will be checking stuff in any case.

I strongly disagree.  Once an object has been constructed it should be
in a stable state.  Preferably it should be in a usable state.  I can
see no reason why the members of a well-designed class should need, in
general, to check the state of the object.

Perhaps I am plain stupid (and my mind is not fully functioning at the
moment) but I cannot see how any helper function will solve the problem.
Either an object is usable when it leaves a ctor, or every public member
function must check its usability.

Francis Glassborow

At 04.30 BST, August 24th, Anne Rowlingson, the brightest
light in my world, died from Cancer. May she find peace.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote in message ...
>
>In article <newscache$qttwgf$bi2$1@firewall.thermoteknix.co.uk>, Ken
>Hagan <K.Hagan@thermoteknix.co.uk> writes
>>OK, I'll try again. It is easy for PODs. It is therefore easy for anything
>>built out of PODs.
>Agreed.
>>It is therefore easy for single classes.
>I do not understand this claim.  And I think it isn't true.
>

But what can a class contain as its members, except PODs? Sooner or
later we have to boil down to raw data, and since this is the *default*
constructor, our choice of the initial values is limited only by the
physical
invariants of the class implementation, which we can choose to suit our
purpose.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote in message ...
>A default ctor can only be known not to throw if the same condition
>applies to all the base ctors and all ctors for its member data.  IOWs
>it is hard to support the claim that nearly always default ctors can
>have empty throw specifications.
> OTOH destructors should not throw (OK, I accept there may be some rare
>exceptions)

OK, I'll try again. It is easy for PODs. It is therefore easy for anything
built out of PODs. It is therefore easy for single classes. It is therefore
easy for classes with non-POD embedded members or base classes.

The principal exceptions would be classes which had to acquire some external
resource (memory or files or whatever) and which could not be designed to
defer that step until later. I'm sure such examples exist, but they are a
minority.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$qttwgf$bi2$1@firewall.thermoteknix.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>OK, I'll try again. It is easy for PODs. It is therefore easy for anything
>built out of PODs.
Agreed.
>It is therefore easy for single classes.
I do not understand this claim.  And I think it isn't true.

>It is therefore
>easy for classes with non-POD embedded members or base classes.
>
>The principal exceptions would be classes which had to acquire some external
>resource (memory or files or whatever) and which could not be designed to
>defer that step until later. I'm sure such examples exist, but they are a
>minority.

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <newscache$tdwrgf$c8i$1@firewall.thermoteknix.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>I think specifying throw() is a good idea wherever it is easy to do.
>This is nearly always the case for default constructors (and most
>destructors).

A default ctor can only be known not to throw if the same condition
applies to all the base ctors and all ctors for its member data.  IOWs
it is hard to support the claim that nearly always default ctors can
have empty throw specifications.
 OTOH destructors should not throw (OK, I accept there may be some rare
exceptions)

Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <clou3.211$lF2.7202@nsw.nnrp.telstra.net>, "Richard Browne"
<richb@pobox.com.au> wrote:

> I'm curious to know whether the standard has anything to say about default
> constructors in the std library throwing exceptions. By this I simply mean
> could the following function throw an exception?
>
> #include <string>
> #include <vector>
>
> void my_func()
> {
>     std::string str;
>     std::vector<char> vec;
> }
>
> Obviously the following could throw std::bad_alloc, for example:
>
> void my_func2()
> {
>     std::string str("blah");
>     std::vector<char> vec(10);
> }
>
> However, in the case of "empty" constructors, it makes my code less
> cumbersome if I know that no exception will be thrown.

Example?

> Basically, it means I
> need to use less try/catch blocks.

I sense danger - why would you need try/catch blocks anywhere an exception
may be thrown?

> I know that my implementation's default
> constructors don't throw (MSVC), but I'm curious whether the standard
> mentions this.
>
> If, as I suspect, there is no such guarantee... does anyone else agree with
> me that it would be a useful addition to the standard?

Just don't create the object until you need it. Use a pointer to it, and
allocate it when you're ready to use it (and not before). That way, you
will be in a place where you can "handle" exceptions (whatever that means
- I don't have this problem in my code).


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Richard Browne wrote:

> I'm curious to know whether the standard has anything to say about default
> constructors in the std library throwing exceptions. By this I simply mean
> could the following function throw an exception?
>
> #include <string>
> #include <vector>
>
> void my_func()
> {
>     std::string str;
>     std::vector<char> vec;
> }
>
> Obviously the following could throw std::bad_alloc, for example:
>
> void my_func2()
> {
>     std::string str("blah");
>     std::vector<char> vec(10);
> }
>
> However, in the case of "empty" constructors, it makes my code less
> cumbersome if I know that no exception will be thrown. Basically, it means I
> need to use less try/catch blocks. I know that my implementation's default
> constructors don't throw (MSVC), but I'm curious whether the standard
> mentions this.
>
> If, as I suspect, there is no such guarantee... does anyone else agree with
> me that it would be a useful addition to the standard?
>

   I don't thing this is a good idea. Consider the following well-formed code
string s;
char c = s[0];

The standard says that after using the default constructor on a string, it's
size() is 0, and that for any string s, s[s.size()] is equal to '\n'.  The only
way to implement the default constructor without calling new[] would be to have
it set the char * inside the string to 0. This would mean that operator[],
operator==(), operator<(), and several other methods would have to test for
null.

Joe Gottman



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>Richard Browne wrote:
> I'm curious to know whether the standard has anything to say about default
> constructors in the std library throwing exceptions.

I think specifying throw() is a good idea wherever it is easy to do.
This is nearly always the case for default constructors (and most
destructors).

I think the standard has taken a very cautious line on whether various
library functions can throw or not. As a result, strictly conforming code
has to jump through lots of hoops for cases which will never occur if
the library author makes a little extra effort. I suppose such caution is
sensible, but hopefully in 5 years time we'll have enough experience to
know where we can tighten things up a bit.

Joe Gottman wrote in message <37BCA203.87AE63D9@worldnet.att.net>...
>I don't thing this is a good idea. Consider the following well-formed code
>   string s;
>   char c = s[0];
>The only way to implement the default constructor without calling
>new[] would be to have it set the char * inside the string to 0. This
>would mean that operator[], operator==(), operator<(), and several
>other methods would have to test for null.

The default constructor could point at a static location containing
a null character. This would then require no special handling for
those functions which read from the string. Functions which write
to the string would have to check for this special case, because
they mustn't try to "free" the character. However, these functions
typically have plenty to worry about in any case, especially if the
implementation chooses to have a reference counted string.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I'm curious to know whether the standard has anything to say about default
constructors in the std library throwing exceptions. By this I simply mean
could the following function throw an exception?

#include <string>
#include <vector>

void my_func()
{
    std::string str;
    std::vector<char> vec;
}

Obviously the following could throw std::bad_alloc, for example:

void my_func2()
{
    std::string str("blah");
    std::vector<char> vec(10);
}

However, in the case of "empty" constructors, it makes my code less
cumbersome if I know that no exception will be thrown. Basically, it means I
need to use less try/catch blocks. I know that my implementation's default
constructors don't throw (MSVC), but I'm curious whether the standard
mentions this.

If, as I suspect, there is no such guarantee... does anyone else agree with
me that it would be a useful addition to the standard?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <clou3.211$lF2.7202@nsw.nnrp.telstra.net>, Richard Browne
<richb@pobox.com.au> writes
>If, as I suspect, there is no such guarantee... does anyone else agree with
>me that it would be a useful addition to the standard?

I think I disagree.  The examples you quote are very limited and I am
generally against such special case dispensations.  In the cases you
give you will have to do something to catch exceptions caused by using
the containers so what real benefit is gained by your request?


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]