VC6: should __fastcall be defined?

[chuckm]

In regex_config.hpp, we have:

   #ifndef __WIN32__
      #define BOOST_RE_CALL
      #define BOOST_RE_CCALL
   #else
      #define BOOST_RE_CALL __fastcall
      #define BOOST_RE_CCALL __stdcall
   #endif

I see the need for __stdcall begin defined, since 
sometimes you need this for a system call (such as 
starting a thread, if I recall correctly). 

But why __fastcall?  When I'm doing a debug build, I 
don't want __fastcall protocol.  I want the slower, 
easier-to-debug protocol.  When I want __fastcall, I 
turn on the /Gr option.

As it stands, I get a compiler warning when I build 
with the /Ge option for run-time stack checking (which 
I always do in development/debug mode).  It's 
complaining that __fastcall doesn't work work nicely 
with /Ge.  So, I'd like to have BOOST_RE_CALL defined 
to be empty during debug builds.

During release builds, BOOST_RE_CLAL can also be 
defined to be empty: I use the /Gr compiler option, 
which makes all functions use __fastcall by default.

In short, I see no reason why anyone would want 
__fastcall to be defined in regex_config.hpp, while 
it's easy (for me) to see why it shouldn't be there.

Suggested fix: remove the BOOST_RE_CALL macro 
altogether.

[John Maddock]

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]

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]

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]

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?

[anonymous]

I mix release and debug libraries all the time.

[John Maddock]

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!