|
Boost : |
From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2003-03-23 00:25:13
>From: "David Abrahams" <dave_at_[hidden]>
> Terje Slettebø <tslettebo_at_[hidden]> writes:
>
> >> What I meant (though sorry I was probably too blunt about it) was that
> >> it's irrelevant whether you actually observed termination or not,
> >> unless you're intending for lexical_cast to work just on that compiler.
> >
> > That's correct, and I meant nothing else, either.
>
> If you understood all along that the copy ctor of your exception class
> could cause termination when the exception was thrown, I don't
> understand why I went through this long twisty discussion just to have
> you tell me so.
What happened was:
1. You told me it could cause termination.
2. I made a test case, and observed that it didn't cause termination on
construction, and that due to the implementation, no copy was made, so it
didn't test the copying (which may cause termination).
3. You said it was irrelevant that no termination was observed.
4. I said that I hadn't claimed the test proved there would be no
termination, since on that platform, the copying wasn't tested.
As you can see, I agreed with you from the beginning. It just seems that you
thought I claimed that since it didn't terminate, it wouldn't do that on any
platform. I didn't mean that, and it seems this misunderstanding was the
cause of this long discussion.
> > I wouldn't have made this such a big issue had you not claimed the
> > implementation didn't do what was requested, when both that and your
> > suggestion implements the request.
>
> I think there's a stronger argument for type_info being a
> representative of the type, because among other things an
> implementation is allowed to have type_info::name() return the empty
> string for all types.
I don't disagree with that. I merely made the point that my implementation
also fulfilled the request, which it seems you now agree to, as well.
I also think returning the type as type_info is better.
Regards,
Terje
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk