If this has be hashed over already please ignore...

Are there any concerns about Borland unilaterly introducing their extension
to the pure virtual?  It is apparently a means of introducing a jump table
ability in C++, mainly to speed up Windows.  It's interesting but will it
become standard?  Any comments?

See you in Pittsburgh...

In article <om5iNB1w164w@cellar.org> rpost@cellar.org (hamilton) writes:
|Are there any concerns about Borland unilaterly introducing their extension
|to the pure virtual?  It is apparently a means of introducing a jump table
|ability in C++, mainly to speed up Windows.  It's interesting but will it
|become standard?  Any comments?

As recently as a week ago I would have argued against such vendor-specific
extensions which tend to lock programmers into one or another vendor's
compilers, prevent C++ programmers from using C++ software on the compiler
of their choice.  But, with committee members themselves arguing that
such vendor-specific extensions are a good thing, who am I to complain?
Kind of begs the issue why do we need this standard anyway, if compiler
vendors aren't suppose to follow it?

Note that when Microsoft addressed this same issue on its MFC software,
the decision was to follow the ANSI-C++ draft, and not use extensions
to the virtual dispatch syntax that would prevent the MFC software from
compiling on other people's compilers, such as cfront, zortech, borland, etc.
Given the committee members' attitude that vendor specific extensions
are a good thing, I now would have to question that decision.  Maybe
Microsoft *should* just "do their own thing" and lock programmers into
the Microsoft compiler, rather than giving programmers the choice?
I mean if that's the attitude of the other compiler vendors and their
committee members, then who am I to complain?

Note also that there ARE "legitimate" ways of adding such support to
one or more compilers and to C++ programmers without deviating from
the standard -- if anybody actually plans to implement the standard.
Namely a compiler could implement some kind of sparse vtable dispatch
scheme [Borland's linear search approach being one such technique]
and then programs could tell the compiler when small vtables are preferred
over fast vtables by using either a compile time switch, or by using
a #pragma around a particular region of virtual function declarations.
That way no new syntax would be required, and the C++ programs involved
would continue to run on all vendor's C++ compilers -- its just that
compilers that understood the needs of Windows programming and supported
the #pragma or the compile-time switch would offer more appropriate
speed/time tradeoffs.