Re: [sigc] Unwanted pass-by-value behavior with MSVC++ 7.1



On Tue, 2004-07-06 at 16:17 -0700, James Lin wrote:
> Hi,
> 
> A couple weeks ago, I posted a problem with unwanted pass-by-value behavior I
> ran into with libsigc++ 2.0.3 and MSVC++ 7.1. (I'm not sure if that message
> ever got past the moderation system.)
> 
> Basically sigc::bind somehow was causing arguments to be passed by value even
> when explicitly told to pass by reference. (I verified this by passing an
> object by reference that had a private copy-constructor and getting a
> compile-time error.  Also, test_lambda was producing incorrect results
> (unrelated to the compiler optimization problem I mentioned earlier today).)

A test case for this would be really useful. We could add it to the
tests directory. In bugzilla please.

> I'm not exactly sure why, but sun_forte_workaround appears to be the culprit.
> (To get libsigc++ to compile at all with the MSVC++ 7.1 compiler, I need to
> disable the LIBSIGC_TEMPLATE_PREFIX macro.  However, both
> LIBSIGC_TEMPLATE_PREFIX and sun_forte_workaround are controlled by the
> existence of SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD; disabling
> LIBSIGC_TEMPLATE_PREFIX means enabling sun_forte_workaround.)
> 
> Anyhow, in adaptor_trait.h, changing:
> 
>   #ifdef SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD
>     #define SIGC_WORKAROUND_OPERATOR_PARENTHESES operator()
>   #else
>     #define SIGC_WORKAROUND_OPERATOR_PARENTHESES sun_forte_workaround
>   #endif
> 
> to:
> 
>   #if    defined(SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD) \
>       || defined(WIN32)
>     #define SIGC_WORKAROUND_OPERATOR_PARENTHESES operator()
> 
>   // ...
> 
> seems to fix my problem.  I guess the comment in adaptor_trait.h is correct:
> 
>   // TODO: This should have its own test, without using operator()
>   #ifdef SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD
>     #define LIBSIGC_TEMPLATE_PREFIX template
>   ...
> 
> and that SIGC_WORKAROUND_OPERATOR_PARENTHESES and LIBSIGC_TEMPLATE_PREFIX
> really do need their own, independent tests.

Yes, and I guess you are the best person to implement them. It's really
quite simple, because there is already an example. You need to 

1. Add an .m4 macro in scripts/cxx.m4. Copy the existing one and change
it.
2. Add an #undef line for the new C macro to sigc++config.h.in.
3. Call the .m4 macro from configure.ac. Just add it after the existing
call to SIGC_CXX_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD()
4. Use the new C macro in the C++ code, instead of WIN32.

Please tell me if you have any problems. Unfortunately, I don't think a
check for WIN32 will be good enough, because there are now several
versions of the MSVC++ compiler in common use, each with different
capabilities.
 
> On a related note, all of the SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD
> preprocessor conditionals test only for existence, not for value.  In
> aclocal.m4, however, there's a line:
> 
>   AC_DEFINE([SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD],[0])
> 
> I'm not familiar with m4 or with autoconf, but I assume that this generates a
> line:
> 
>   #define SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD 0
> 
> which would be wrong.  Shouldn't the preprocessor conditionals use #if FOO
> instead of #ifdef FOO?

Thanks a lot for noticing this. It could explain some strange failures
with the SUN Forte compiler. In cvs, I have changed the macro in
scripts/cxx.m4 so that it just does not define that macro. Then, sigc+
+config.h has 

/* #undef SIGC_TEMPLATE_SPECIALIZATION_OPERATOR_OVERLOAD */

which I think is normal. I was able to test that by adding some nonsense
code into the test in cxx.m4.


Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]