Re: [boost] bad_lexical_cast
>From: "Alisdair Meredith" <[EMAIL PROTECTED]> > I see that this has been the topic of much discussion lately, but just > confirming this little warning from the regressions has not snuck by > unnoticed: > > # 'boost::bad_lexical_cast::what()' hides inherited virtual function > 'std::exception::what() const' > > [const missing, to state the obvious] > > This apparently only affects 3 compilers on Windows, haven't > cross-checked the other platforms. Thanks for pointing this out. It's fixed now. Yeah, oddly enough, this gave no warning, even when running on the highest warning level, and strict mode, on Intel C++ 7, and MSVC 6/7. Also, the tests only checks that the exception is thrown when it's supposed to, it doesn't check what(). Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] bad_lexical_cast
I see that this has been the topic of much discussion lately, but just confirming this little warning from the regressions has not snuck by unnoticed: # 'boost::bad_lexical_cast::what()' hides inherited virtual function 'std::exception::what() const' [const missing, to state the obvious] This apparently only affects 3 compilers on Windows, haven't cross-checked the other platforms. -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bad_lexical_cast
Christoph Kögl <[EMAIL PROTECTED]> writes: > You might want to read > http://www.objectmentor.com/resources/articles/lsp.pdf for > a rationale of the LSP. It says: FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES WITHOUT KNOWING IT . The above is a paraphrase of the Liskov Substitution Principle (LSP). Barbara Liskov first wrote it as follows nearly 8 years ago What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. The problem is that if the top statement allows overriding virtual functions in derived classes with different behavior, then it says something very different from the bottom one (the actual LSP). > A somewhat different view is expressed in > http://alistair.cockburn.us/crystal/articles/cdos/constructivedesconstructionofsubtyping.htm. That discussion leaves a lot more room for correct interpretations, by presenting lots of different viewpoints. I like that one. I was just saying that the LSP doesn't really apply well to common well-founded C++ software engineering practices, so arguments based on the LSP don't hold much water with me. Note that it also seems to fail to cover abstract base classes (which don't have a behavior in and of themselves). -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bad_lexical_cast
You might want to read http://www.objectmentor.com/resources/articles/lsp.pdf for a rationale of the LSP. A somewhat different view is expressed in http://alistair.cockburn.us/crystal/articles/cdos/constructivedesconstructionofsubtyping.htm. Am Son, 2003-03-23 um 14.00 schrieb David Abrahams: > LSP is weird anyway. What's the point of polymorphism if you're not > going to change the behavior of the class in some observable way? If > the derived class were transparently substitutable for the base class > it wouldn't be much good, would it? > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bad_lexical_cast
Dave Gomboc <[EMAIL PROTECTED]> writes: Yes. Since type_info objects can't be copied, one might instead store pointers or references to them. >>> >>> Pointers would be better because, for better or for worse (mostly for >>> worse), standard exceptions support assignment as part of their >>> interface. >> >>Why should boost exception classes behave like std:: exception >>classes in this regard? > > Since you advocate elsewhere that exception classes be derived from > std::exception, the answer is because otherwise LSP would be violated. You can't access the derived class' assignment operator through a pointer/reference to a polymorphic base, so that point is moot. LSP is weird anyway. What's the point of polymorphism if you're not going to change the behavior of the class in some observable way? If the derived class were transparently substitutable for the base class it wouldn't be much good, would it? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] bad_lexical_cast
>>>Yes. Since type_info objects can't be copied, one might instead store >>>pointers or references to them. >> >> Pointers would be better because, for better or for worse (mostly for >> worse), standard exceptions support assignment as part of their >> interface. > >Why should boost exception classes behave like std:: exception >classes in this regard? Since you advocate elsewhere that exception classes be derived from std::exception, the answer is because otherwise LSP would be violated. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
