Re: Throwing default constructors of containers - a 2nd attempt for Rani Sharoni
Hello,
unfortunately Rani Sharoni's most recent answer
disappeared in the darknesses of Google Groups,
which is a real pity (and happened the second time
in two days), so I contacted him personally and
asked for the answer, which he kindly provided to
me. For those interested in this thread I would
like to repost - with his permission - the last
answer below.
- Daniel
On Sep 18, 3:27 pm, Daniel Kr?gler <daniel.krueg...@googlemail.com>
wrote:
On 18 Sep., 20:02, rani_shar...@hotmail.com wrote:
Are there any STL implementations in which the default constructor of
std::string or std::vector can throw? Is there any good reason for
doing so (beside strict compliance)?
I have only a limited set of STL implementations available, namely
[...]
None of them has a failable std::string or std::vector, but
it seems that you already knew these libraries, so this
information is probably of little new interest for you.
It seems not so very unusual for me to think of a failable
vector default c'tor if you accept the design choice to
create a default-constructed vector with an initial non-zero
capacity (allocated via the free store), but I don't think
that this a overwhelming convincing argument (N.B.: Typical
Java libraries do have this approach).
I think that the application that you mentioned make sense but it can
be achieved even with having no-fail default constructor.
For allocation failures inside of default ctor the code can fallback
to zero capacity and avoid throwing.
Such approach make sense specifically for std::vector and std::string
for which zero capacity is not a special case.
I know that the VC-STL dinkumware based implementation of, for
example, std::list default constructor might throw but other
implementations don't (e.g. libstdc++ and Metrowerks). Is there any
reason to prefer the implementation that might throw (i.e. trying to
allocate the list's head)?
I don't think so.
Seems strange that there is such oversight in the dinkumware
implementation.
I'm sure that there is some reason.
In general, are there any STL implementations that try to enforce the
exception specifications of the standard library (e.g. in debug
builds) so that it will be possible to find incorrect usage during the
testing?
I'm not sure that I properly understood this point. What do you mean
with "try to enforce exception specifications" in this context?
Sorry for not being clear.
I meant that the implementation can have "strict mode" for testing in
which it calls some MightThrow() function in operations that might
throw even if the actual implementation can't throw.
For example, std::list default ctor will contain call to MightThrow()
since according to the specification it might throw.
In this way the code can be strictly tested according to the
specifications and therefore the implementation can avoid potential
behavioral backward compatibility issues (i.e. breaking changes).
I'm sorry for the little feedback, this is an interesting question.
Thanks for the feedback.
I'm not sure how far-reaching your thoughts are but I would not
like a basic guarantee that *every* container must have a non-failable
default c'tor (You did not say that, I just want to make sure this
point).
I explicitly conditioned the non throwing default ctor for cases in
which it "make sense".
It probably make sense for vector, deque, string and list. Maybe for
map and probably not for hash-table.
I was thinking about filing a defect report if it's reasonable to do
so.
Thanks,
Rani
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]