On 8 oct, 23:29, waba
> Eh, would you mind to provide a quote for that? I have no idea what you
> are talking about.
You wrote this as an argument in favor of inheritance versus
templates:
- A
classes at run-time. This means that there is no std::vector that
could store pointers to both kinds, for example. Depending on your
application, this may or may not be an issue.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Policy-based class design or inheritance?
catch match
gutenev@gmail.com wrote:
> Thanks to everyone who replied.
>
> Geert-Jan Giezeman, anon and Jiang, looks like you are correct.
> 15.3/3 literary says: unambiguous *public* base class
>
> However, the code outputs 1 on MSVC. It outputs 2 when foo is made non-
> member and not friend of my_exception. So, a catch is a match in MSVC
> when the conversion is accessible, regardless to inheritance kind.
>
Obviously a bug in the MSVC
> Also anon wrote "accessible base class".
> I think it is intuitive to expect matching based on accessiblity, like
> with static_cast and implicit conversion.
>
> So here's another question:
> Is it a problem in standard, or word "public" was put there on purpose ?
> The same question applies to dynamic_cast at 5.2.7/8.
>
I am not quite following you.
Try next example with and without a public inheritance:
#include
#include
class my_exception : public std::exception
{
};
int main()
{
const my_exception a;
const std::exception &b( a );
}
If you don't get the error, change the compiler (or better yet, change
the os)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
stringstream misunderstanding
Why won't this work?
stringstream ss;
ss.str() = "have a nice day.";
cout << ss.str() << endl;
I know that
ss << "have a nice day.";
works, but I thought the str() function would permit me to read to
write to the ss buffer.
Thanks,
Joe
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Why the decision to leave typeinfo::name() out of the standard?
Hi,
Basically, this little string right here, could be extremely helpful
if it was portable. Couldn't the standard committee just come up with
a simple scheme for this? namespace::classname? I'm writing a
serialization lib and it's damn hard to make it portable without it.
Does anyone know why it never got to be in the standard?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Compiler allowed to "simplify" floating-point expressions?
Jiang wrote:
> On Oct 7, 5:59 am, Marco Manfredini
>> Alan McKenney wrote:
>> > Does the C++ standard allow a compiler to
>> > "simplify" floating-point expressions in the way
>> > we learned in Algebra class?
>>
>> No. The simplification rules of algebra class do not apply here,
>> because computer floating point arithmetic is (usually) neither
>> commutative nor associative.
>
>
> Maybe this is not the main point for this discussion, but I
> must say the above statement is not true.
>
> You did not mention what is the model for the floating point
> arithmetic, generally speaking, floating point arithmetic for
> addition and multiplication *are always* commutative.
Unfortunately no. For example the x87 coprocessor architecture (found in
Pentiums etc.) has 80 bit intermediate results, which means that a
temporary result which is spilled into memory will lose precision
against an operand which remains in the FPU. This effectively makes
commutative ops non-commutative.
Here is a nice writeup which ponders the algebraic properties of
computer floating point arithmetic:
http://zuras.net/FPFallacies.html
> The bullet you quoted (1.9/15) is borrowed from the C
> language (C89, IIRC). Although no explicit words but
> this rule is considered to be applied to integer
> arithmetic to prevent the possible overflow issues. It
> was not designed to handle the floating point arithmetic.
>
> I say this because it is well known that C++, together
> with C language, do not have a specification for floating
> point arithmetic. Without such a specification, this
> rule can not be applied to floating point arithmetic.
The rule says that you cannot apply algebraic transformations if the
underlying types lack certain algebraic properties. The actual type of
the operands is completely irrelevant. (Which is btw. the whole point
of Algebra anyway.) A FP-specification is not necessary: If the FP
implementation is commutative, then the compiler may apply commutative
transformations. If the compiler can prove (for example by range
analysis) that an operation is associative, it may apply associative
transformations and possibly constant folding.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Compiler allowed to "simplify" floating-point expressions?
> But a compiler that assumes that adding 1.0 and
> then subtracting it again will result in the
> original value, and optimizes code on that
> assumption, is almost useless for serious
> (floating-point) numerical work.
Why?? Who would ever write a program that relies on the fact that ((x +
y) - y) possibly doesn't equal x? After all, the error cannot be bigger
than without this optimisation, or can it?
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Compiler allowed to "simplify" floating-point expressions?
On Oct 7, 8:22 pm, Greg Herlihy
> On Oct 5, 2:24 pm, Alan McKenney
>
> > For example, is it standard-conformant for a
> > compiler to implement
>
> > double x;
> > ....
> > if ( ( x + 1.0 ) - 1.0 )
> > as
> > double x;
> > ....
> > if ( x )
>
> Yes. Adding and subtracting an exactly-represented constant value
> (such as 1.0) has the same net result as adding 0.0.
Not so. Consider x has value epsilon/1.E20 (the large constant is to
avoid problems with extended precision registers). x+1.0 will (on
almost all platforms) be identically equal to 1.0. (x+1.0)-1.0 will
then be identically equal to 0.0. To repeat what has been said
elsewhere in this thread - floating point arithmetic is *NOT*
associative.
I know enough about numerical analysis to know that experts care
greatly about such details.
> Moreover, the C++
> compiler can assume that the interim result "x+1.0" will not overflow
> (because if the result were to overflow, then the value of the sum
> would be undefined. Therefore returning "x" as the undefined value of
> the sum, would be just as valid as returning any other value).
Overflow is not the problem - rounding is the problem (particulary
rounding when adding numbers of very different magnitude).
> The meaning of the code is not changed by optimizing the +1.0 and -1.0
> away.
Yes it is.
> On the contrary, by avoiding the possibility of overflow, the
> program's result now matches the mathematical result of the
> expression.
Depends what you think the mathematical result of the expression is.
If you are dealing the mathematics of real numbers (the maths you
learned in school), then yes; if you are dealing with the mathematics
of floating point numbers (which are /much/ more bizarre), then no.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
