Re: [boost] [GTL] - geometric template library - determininginterest

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2007-10-10 19:51:11

Martin wrote:
>I still don't think the standard makes the guarantees you think it
does,
>but in practise, you are much less likely to run into problems with
that
>limitation.

In practice, I have ported it to icc, gcc and visual studio, linux and
windows operating systems, x86 and itanium instruction sets, 32 and 64
bit platforms.  I am tempted to think that demonstrating portability
should count for more than a theoretical argument about what the
standard says or doesn't say.  I've asked Gyuszi to weigh in on this
issue, since his knowledge of C++ exceeds mine.

>If the types are inherited (rather than composed) I still think you
have
>problems if the derived class overrides virtuals in the base.

You are correct, and I am impressed by your knowledge, since I learned
this one the hard way.  I was syntactically unable to override the base
class virtual declaration of an assignment operator because it was
incorrectly returning void:

virtual void operator=(const UglyPolygon &poly);

The problem was that the overriding function differed only by return
type, which was a problem only because the function being overridden was
virtual, despite the fact that the function overriding it was
non-virtual.  The error the compiler gave was rather cryptic, but I
eventually resolved it by removing the assignment operator in the
derived class that accepts the base class type as the rvalue.  Switching
to composition might be preferable to prevent these problems and give me
the effect of private inheritance, working around the Microsoft
compiler's shortcoming.  

Luke