Boost C++ Libraries: Ticket #928: VC6: should __fastcall be defined?

John Maddock — Thu, 10 May 2001 10:50:48 GMT

Logged In: YES
user_id=14804
Past experience suggests that not defining the calling
convention leads to all kinds of problems and a *lot* of
technichal support messages (because the libraries as built
by the makefile no longer work when the user changes the
compiler options in their program).  You are quite right
about debug builds though, I'll get that fixed,
Thanks for the feedback.
JM

chuckm — Thu, 10 May 2001 13:23:04 GMT

Logged In: YES
user_id=28026
> (because the libraries as built by the makefile no longer
work when the user changes the compiler options in their
program).
I guess what you're saying is that, since the the -Gr
compiler option is used in the regex .mak files, it is
necessary to call the regex functions with the __fastcall
convention.  That's the reasoning for putting __fastcall in
the libraries, I take it?
So what do you propose, then?  That if NDEBUG is defined,
you hardwire the __fastcall calling convention; otherwise,
you don't hardwire any calling convention?
I would think the user of the library would want to link to
the library which matched the calling convention they're
using.  It seems to me the perfect place to cause this to
happen is in regex_library_include.hpp.  I propose that in
the release builds (i.e. the ones where you currently use
the /Oityb1 flags), that you also specify the /Gr flag.
That will cause the __fastcall calling convention to be
used throughout, but only for release builds.  Leave the
debug builds as they are.  Take out the BOOST_RE_CALL macro.
This should fix everything.
If you try linking to the release build when you're not
using /Gr, you'll get linker errors.  The answer to this
is: good!  You apparantly made a mistake.  Why would you
want to link your debug build with a release library?  Or
your release build with a debug library?

chuckm — Thu, 10 May 2001 13:27:20 GMT

Logged In: YES
user_id=28026
(Hmmm -- annoyingly, there's no way to edit a posting after
you've submitted it.  I changed my thoughts mid-stream, so
my previous post doesn't make alot of sense.  Here's the
corrected version...)
> (because the libraries as built by the makefile no longer
work when the user changes the compiler options in their
program).
It looks like the problem is that you need to specify the -
Gr option in the mak files, for release builds.  I think
that will clear up all the problems.  The -Gr option causes
all functions to use the __fastcall calling convention by
default.
Specifically, I propose that in the release builds (i.e.
the ones where you currently use the /Oityb1 flags), that
you also specify the /Gr flag.  Leave the flags for the
debug builds as they are.  Take out the BOOST_RE_CALL macro.
This should fix everything.
If you try linking to the release build when you're not
using /Gr, you'll get linker errors.  The answer to this
is: good!  You apparantly made a mistake.  Why would you
want to link your debug build with a release library?  Or
your release build with a debug library?

chuckm — Thu, 10 May 2001 13:30:49 GMT

Logged In: YES
user_id=28026
(Let's try this ONE MORE TIME!  I _hate_ not being able to
edit my postings!)
> (because the libraries as built by the makefile no longer
work when the user changes the compiler options in their
program).
It looks like the problem is that you need to specify
the /Gr option in the mak files, for release builds
(specifically, for all builds which currently
use /Oityb1).  I think that will clear up all the
problems.  The -Gr option causes all functions to use the
__fastcall calling convention by default.  Then you can
take out the BOOST_RE_CALL macro.
This should fix everything.
If you try linking to the release build when you're not
using /Gr, you'll get linker errors.  The answer to this
is: good!  You apparantly made a mistake.  Why would you
want to link your debug build with a release library?  Or
your release build with a debug library?

status changed

John Maddock — Sat, 19 May 2001 11:04:53 GMT

status assigned → closed

status changed; resolution deleted

anonymous — Thu, 16 Aug 2007 20:54:08 GMT

status closed → reopened
resolution Rejected

I mix release and debug libraries all the time.

status, description changed; resolution, severity set

John Maddock — Thu, 23 Aug 2007 08:26:46 GMT

status reopened → closed
resolution → wontfix
description modified (diff)
severity → Problem

Just to be clear about the current situation:

The function call types used by the regex lib are designed to always match the call types used in the binaries. Further, you absolutely can not mix a release binary in a debug build or vice versa - they use different runtime libraries.

As I said previously, this prevents an awful lot of support calls for me, so it's not going to change unless *lots* of people complain, and at present I don't see that.

Regards, John Maddock

PS, if this gets opened again, please don't do so anonymously, it makes my life much harder!