Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2002-08-18 19:09:54


I don't recall the standard mentioning anything about calling conventions.
Would you cite a section of the standard which mentions this in any way ? I
was under the impression that calling conventions were a subject which
existed outside of the C++ standards. When using calling conventions with
C++ Builder or VC++, one can use keyword extensions such as __cdecl and
__stdcall etc., and I always thought, by its very nature, that double
underscore extensions were implementation-defined keyword extensions to the
standard.

Perhaps I misread your statement below and what you are really saying is
that calling conventions are not part of the standard, period.

I do agree that if standard-conforming code does not compile using a
compiler option ( or a #pragma which sets a compiler option ) that another
solution should be found to get the code to compile properly for that
compiler. However, if standard-conforming code can be compiled using a
compiler option ( or the appropriate #pragma ) I think it should be used, as
you have done in the Regex++ library, without fearing that the compiler
option ( or #pragma ) is somehow not dealt with in the C++ standard.

"John Maddock" <jm_at_[hidden]> wrote in message
news:019b01c246a8$c8404360$fa6a87d9_at_1016031671...
> > From: "John Maddock" <jm_at_[hidden]>
> > >
> > > On the issue of exception classes: why would you think that the
derived
> > > class could possibly use a different calling convention to the base
> class
> > > for a virtual function?
> >
> > The problem is that standard-conforming code (a class that derives from
> > std::exception) does not compile under bcc 5.5.1 -ps.
>
> Accepted, but -ps is a non standard-conforming calling convention, so
again
> what do you expect? Don't get me wrong, I'm not saying that we shouldn't
> protect our code against this, just that users shouldn't be surprised if
> things break when the compiler is in a non-standard mode.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk