Opened 21 years ago
Closed 15 years ago
#928 closed Bugs (wontfix)
VC6: should __fastcall be defined? — at Version 7
Reported by: | chuckm | Owned by: | John Maddock |
---|---|---|---|
Milestone: | Component: | regex | |
Version: | None | Severity: | Problem |
Keywords: | Cc: |
Description (last modified by )
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.
Change History (7)
comment:2 by , 21 years ago
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?
comment:3 by , 21 years ago
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?
comment:4 by , 21 years ago
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?
comment:5 by , 21 years ago
Status: | assigned → closed |
---|
comment:6 by , 15 years ago
Resolution: | Rejected |
---|---|
Status: | closed → reopened |
I mix release and debug libraries all the time.
comment:7 by , 15 years ago
Description: | modified (diff) |
---|---|
Resolution: | → wontfix |
Severity: | → Problem |
Status: | reopened → closed |
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!