none
VC++ 2008: __thiscall and __cdecl regarded as identical

    Question

  • I have a VC++ project that until now have been developed in VS2005, but now is to be developed in VS2008. Somehow it includes the C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xxresult header (it is a huge project so I have not yet traced through which headers it is included).
     
    When I compile the project I get one error C2953 for each of the eight class templates defined with both __thiscall and __cdecl in xxresult. E.g.

    ........
    089 template<class _Rx,
    090  _CLASS_ARG0
    091  _C_CLASS_FARG0>
    092  struct _RESULT_OF<_Rx (__thiscall _Arg0::*)(_ARG1_ARG2),
    093    _Farg0& _C_FARG1_FARG2>
    094  { // pointer to member fn
    095  typedef _Rx _Type;
    096  };

    098 #ifdef _M_IX86
    099 template<class _Rx,
    100  _CLASS_ARG0
    101  _C_CLASS_FARG0>
    102  struct _RESULT_OF<_Rx (__cdecl _Arg0::*)(_ARG1_ARG2),
    103    _Farg0& _C_FARG1_FARG2>
    104  { // pointer to member fn
    105  typedef _Rx _Type;
    106  };
    ........

    generates the following output:

    c:\Program Files\Microsoft Visual Studio 9.0\VC\Include\xxresult(106) : error C2953: 'std::tr1::_Result_of1<_Rx(__thiscall _Arg0::* )(void),_Farg0&>' : class template has already been defined
            c:\Program Files\Microsoft Visual Studio 9.0\VC\Include\xxresult(94) : see declaration of 'std::tr1::_Result_of1<_Rx(__thiscall _Arg0::* )(void),_Farg0&>'

    Somehow it seems like VC++ does not distinguish between __thiscall and __cdecl. But since the xxresult is part of the VC2008 installation I guess that it is some project settings that are wrong.

    Has anyone got an idea what can cause the compiler to regard __thiscall and __cdecl as identical?

    Wednesday, October 29, 2008 10:00 AM

Answers

  • After re-installation of VS2008 on both server and PC with VS2008 SP1 applied after installation of the Platform SDK the project did not compile on any of the setup. But at least they behaved similar...

    I have now located the problem:
    One of our header files had a
    #define __cdecl

    When I removed that line the project could compile.

    Hans Passant,  David Wilkinson and ildjarn: Thank you for your attention.

    Best regards,
    Sverre
    • Marked as answer by SverrePV Monday, November 03, 2008 10:09 AM
    Monday, November 03, 2008 10:08 AM

All replies

  • Doing a x64 compile and still have _M_IX86 defined?  x64 doesn't have calling conventions.
    Hans Passant.
    Wednesday, October 29, 2008 11:05 AM
    Moderator
  • Thanks Hans,

    Currently we are using x86 in all our projects without problems except from the one above.
    I would prefer to stay with x86 and find the solution for now.
    - Our nightly build has more than 400 projects, mainly VC++ but also C# and Fortran...

    SverrePV

    Wednesday, October 29, 2008 1:04 PM
  • Can you create a minimal example of this error?

    Or do you really not know how <xxresult> is being #include'd? This shouldn't be too hard to figure out. It seems very strange that VS2005 code (presumably not using tr1) could make this happen.




    David Wilkinson | Visual C++ MVP
    Wednesday, October 29, 2008 1:23 PM
  • I will try to extract a minimal example...

    But it seems like it is something with the compiler configuration or installation, since I have now found out that I can build the project on my own XP PC without the error, but every night it fails on our 2003 Server. However, the compiler can not be completely twisted since all other projects build fine during our nightly build?

     

    Wednesday, October 29, 2008 2:15 PM
  • I have not managed to make an exampel yet, but I have found out how the xxresult is included:
    #include <map>
    =>
    #include <xtree>
    =>
    #include <functional>
    =>
    #if _HAS_TR1
    #...
    #include <xrefwrap>
    =>
    #define _INCL_FILE <xxresult>

    How _HAS_TR1 happens to be defined I can not say. The only place I can find it mentioned is in yvals.h which is not included anywhere? However, if I add an
    #undef _HAS_TR1
    before the
    #include <map>
    it compiles...

    I will not say that my question has been answered but there seems to be a workaround.
    Wednesday, October 29, 2008 2:35 PM
  • I guess I would start by testing for _HAS_TR1 at the end of "stdafx.h" and work backward or forward from there.


    David Wilkinson | Visual C++ MVP
    Wednesday, October 29, 2008 2:50 PM
  • You are right, that must be the way. I will try that later today or tomorrow and post the answer if I manage to locate the problem.
    Wednesday, October 29, 2008 2:57 PM
  • Well, _HAS_TR1 is actually defined by yvals.h as follows:
    #include "stdafx.h"
    =>
    #include <cassert>
    =>
    #include <yvals.h>
    =>
    #if !defined(_HAS_TR1)
     #define _HAS_TR1  1 /* enable TR1 extensions */

    So, now the question remains: Why is it a problem on our build server, and not on my PC?
     
    Does anyone have an idea?
    Wednesday, October 29, 2008 8:39 PM
  • One possibility is that the SP1 update didn't go well.  Leaving one or more header files un-updated.  In Explorer, sort the include folder by date on both machines and compare the lists.
    Hans Passant.
    • Marked as answer by SverrePV Wednesday, October 29, 2008 9:20 PM
    • Unmarked as answer by SverrePV Monday, November 03, 2008 9:54 AM
    • Unmarked as answer by SverrePV Monday, November 03, 2008 9:54 AM
    • Unmarked as answer by SverrePV Monday, November 03, 2008 10:08 AM
    • Unmarked as answer by SverrePV Monday, November 03, 2008 10:08 AM
    • Unmarked as answer by SverrePV Monday, November 03, 2008 10:09 AM
    Wednesday, October 29, 2008 8:49 PM
    Moderator
  • I guess you are right. Some header files are different. The _HAS_TR1 section is not present in the yvals.h on my PC.
    I will try to reinstall the SP1 on out build server.

    Thanks for your attension.

    Best regards,
    Sverre
    Wednesday, October 29, 2008 9:20 PM
  • The _HAS_TR1 section is supposed to be in yvals.h if you have SP1 installed. It sounds as though SP1 (or possibly the VC++ 2008 Feature Pack) is installed on the build server but not on your PC. I.e., your PC has it wrong, not the build server.
    Wednesday, October 29, 2008 9:30 PM
  • You are right. It seems like the build server has the newest yvals.h:

    012 #define _CPPLIB_VER 505
    013
    014 #if !defined(_HAS_TR1)
    015  #define _HAS_TR1 1 /* enable TR1 extensions */
    016 #endif /* !defined(_HAS_TR1) */

    The same section on my PC version of yvals.h reads:

    013 #define _CPPLIB_VER 503

    And with no _HAS_TR1 lines ...

    So, chances are that if I upgrade my PC I will not be able to compile the project on neither my PC nor the server:-(

    BTW: What should the right version be on VC++?
    Then server installation reads 91904-270-0683641-60485
    My PC installation reads 91904-270-1420365-60115
    - judging from that the PC should have the newest.

    I am confused, but I will try to re-install Visual Studio on both my PC and the build server and see what happens.

    Thursday, October 30, 2008 9:48 AM
  • Did you upgrade the Platform SDK on the server after upgrading to SP1? This is known to cause problems, because the PSDK install will replace some SP1 files with the original ones. A reinstall of SP1 should fix this.


    David Wilkinson | Visual C++ MVP
    Thursday, October 30, 2008 11:05 AM
  • After re-installation of VS2008 on both server and PC with VS2008 SP1 applied after installation of the Platform SDK the project did not compile on any of the setup. But at least they behaved similar...

    I have now located the problem:
    One of our header files had a
    #define __cdecl

    When I removed that line the project could compile.

    Hans Passant,  David Wilkinson and ildjarn: Thank you for your attention.

    Best regards,
    Sverre
    • Marked as answer by SverrePV Monday, November 03, 2008 10:09 AM
    Monday, November 03, 2008 10:08 AM