By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,974 Members | 1,834 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,974 IT Pros & Developers. It's quick & easy.

Error C2040: ... differs in levels of indirection from ... MSVC++ Problem # 1

P: 4
I am posting two threads because I have two different problems, but both have the same background information.

Common Background Information:

I am trying to rebuild code for a working, commercially sold application with only partial build instructions. The previous maintainer of the code (a

mixture of C and C++) is no longer with the company, but when he built the code he used MSVC++, and though I am not certain of the version he was

using, I think it was either 4.0 or 6.0. I have only a little experience building with this environment (I am otherwise a seasoned developer) so I need

help getting past a couple of issues that I have encountered. Computers (and backups of those computers) previously used for running this build are

now completely unavailable.

I have set up the build on my system using MSVC++ 6.0. The source repository contained a workspace (.dsw) file that I am using for all of the projects. I

do not have specific instructions for this product on how to adjust the references to libraries, includes, etc. for a particular machine, but I am using

instructions for this from a similar (in terms of languages and tools used) product that was written around the same time. I have gotten 43 of 53 classes

(projects) to build, but am getting primarily two errors with the remaining 10 clases (projects).

Because I know this code base was building properly (for someone else who is no longer available on a machine that is no longer available), I would

strongly prefer adjustments to the build environment over code modification to get it to work, so please focus your assistance/suggestions in this area.

Thanks !

Problem #1: Error C2040: ... differs in levels of indirection from ...

Here are the exact error messages I am receiving:

Fxactn.cpp
\develop\3rdParty\xvtdsp45\w32_x86\include\xvt_typ e.h(54) : error C2040: 'LONG_PTR' : 'long *' differs in levels of indirection from 'long'
\develop\3rdParty\xvtdsp45\w32_x86\include\xvt_typ e.h(55) : error C2040: 'ULONG_PTR' : 'unsigned long *' differs in levels of indirection from 'unsigned

long'
Fxapifun.cpp
C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\basetsd.h(92) : error C2040: 'LONG_PTR' : 'long' differs in levels of indirection from 'long *'
C:\PROGRAM FILES\MICROSOFT SDK\INCLUDE\basetsd.h(93) : error C2040: 'ULONG_PTR' : 'unsigned long' differs in levels of indirection from 'unsigned

long *'
Guicinit.cpp
\develop\3rdParty\xvtdsp45\w32_x86\include\xvt_typ e.h(54) : error C2040: 'LONG_PTR' : 'long *' differs in levels of indirection from 'long'
\develop\3rdParty\xvtdsp45\w32_x86\include\xvt_typ e.h(55) : error C2040: 'ULONG_PTR' : 'unsigned long *' differs in levels of indirection from 'unsigned

long'
The first two errors and the last two errors come from the same include file. I put the errors twice simply to emphasize that I am receiving these errors

on multiple source files. The middle two errors are only occurring once.

Here are lines 41 through 58 of xvt_type.h (apparently a third party include file):

Expand|Select|Wrap|Line Numbers
  1. typedef unsigned short T_LNUM;
  2. typedef unsigned short T_PNUM;
  3. typedef unsigned long  XVT_COLOR_TYPE; /* Color Component Type (XVT_COLOR_* */
  4.  
  5. /* The following legacy "data types" are being phased out, as they cause    */
  6. /* problems with constness: "const int *x" is NOT same as "const INT_PTR x" */
  7. //typedef int           *INT_PTR;
  8. typedef BOOLEAN       *BOOLEAN_PTR;
  9. typedef char           XVT_BYTE;    /* raw data */
  10. typedef unsigned char  XVT_UBYTE;   /* raw data */
  11. typedef XVT_BYTE      *DATA_PTR;    /* ptr to arbitrary data - backwards compat. */
  12. typedef XVT_UBYTE     *UDATA_PTR;   /* unsigned ptr to arbitrary data */
  13. typedef XVT_UBYTE      DATA_BYTE;   /* for raw data */
  14. typedef long          *LONG_PTR;          /* THIS IS LINE 54 */
  15. typedef unsigned long *ULONG_PTR;        /* THIS IS LINE 55 */
  16.  
  17. /* define a point to function which will be used in xvt_win_enum_wins etc. */
  18. typedef XVT_CALLCONV_TYPEDEF( BOOLEAN, XVT_ENUM_CHILDREN, (WINDOW child, long data));
Here are the first 98 lines of the BaseTsd.h file:

Expand|Select|Wrap|Line Numbers
  1. /*++
  2.  
  3. Copyright (c) Microsoft Corporation.  All rights reserved.
  4.  
  5. Module Name:
  6.  
  7.     basetsd.h
  8.  
  9. Abstract:
  10.  
  11.     Type definitions for the basic sized types.
  12.  
  13. Author:
  14.  
  15. Revision History:
  16.  
  17. --*/
  18.  
  19. #ifndef _BASETSD_H_
  20. #define _BASETSD_H_
  21.  
  22. #if _MSC_VER > 1000
  23. #pragma once
  24. #endif
  25.  
  26. #ifdef __cplusplus
  27. extern "C" {
  28. #endif
  29.  
  30. typedef signed char         INT8, *PINT8;
  31. typedef signed short        INT16, *PINT16;
  32. typedef signed int          INT32, *PINT32;
  33. typedef signed __int64      INT64, *PINT64;
  34. typedef unsigned char       UINT8, *PUINT8;
  35. typedef unsigned short      UINT16, *PUINT16;
  36. typedef unsigned int        UINT32, *PUINT32;
  37. typedef unsigned __int64    UINT64, *PUINT64;
  38.  
  39. //
  40. // The following types are guaranteed to be signed and 32 bits wide.
  41. //
  42.  
  43. typedef signed int LONG32, *PLONG32;
  44.  
  45. //
  46. // The following types are guaranteed to be unsigned and 32 bits wide.
  47. //
  48.  
  49. typedef unsigned int ULONG32, *PULONG32;
  50. typedef unsigned int DWORD32, *PDWORD32;
  51.  
  52. #if !defined(_W64)
  53. #if !defined(__midl) && (defined(_X86_) || defined(_M_IX86)) && _MSC_VER >= 1300
  54. #define _W64 __w64
  55. #else
  56. #define _W64
  57. #endif
  58. #endif
  59.  
  60. //
  61. // The INT_PTR is guaranteed to be the same size as a pointer.  Its
  62. // size with change with pointer size (32/64).  It should be used
  63. // anywhere that a pointer is cast to an integer type. UINT_PTR is
  64. // the unsigned variation.
  65. //
  66. // __int3264 is intrinsic to 64b MIDL but not to old MIDL or to C compiler.
  67. //
  68. #if ( 501 < __midl )
  69.  
  70.     typedef [public] __int3264 INT_PTR, *PINT_PTR;
  71.     typedef [public] unsigned __int3264 UINT_PTR, *PUINT_PTR;
  72.  
  73.     typedef [public] __int3264 LONG_PTR, *PLONG_PTR;
  74.     typedef [public] unsigned __int3264 ULONG_PTR, *PULONG_PTR;
  75.  
  76. #else  // midl64
  77. // old midl and C++ compiler
  78.  
  79. #if defined(_WIN64)
  80.     typedef __int64 INT_PTR, *PINT_PTR;
  81.     typedef unsigned __int64 UINT_PTR, *PUINT_PTR;
  82.  
  83.     typedef __int64 LONG_PTR, *PLONG_PTR;
  84.     typedef unsigned __int64 ULONG_PTR, *PULONG_PTR;
  85.  
  86.     #define __int3264   __int64
  87.  
  88. #else
  89.     typedef _W64 int INT_PTR, *PINT_PTR;
  90.     typedef _W64 unsigned int UINT_PTR, *PUINT_PTR;
  91.  
  92.     typedef _W64 long LONG_PTR, *PLONG_PTR;
  93.     typedef _W64 unsigned long ULONG_PTR, *PULONG_PTR;
  94.  
  95.     #define __int3264   __int32
  96.  
  97. #endif
  98. #endif // midl64
My thoughts so far are as follows:
  1. One possibility is that the previous builder of this code precompiled these (and probably all 3rd party and MS) headers separately using a different

    environment or different settings prior to the build, and he had the pre-compiled headers available when he ran the main build, so he would not have

    gotten these errors.
  2. Another possibility is that the previous builder was using different settings for the compile than I am using -- perhaps a older version compatability

    flag or something like that. However, if this was on the main build (as opposed to a separate run to precompile header files) I would expect that setting

    to be in the saved workspace (.dsw) file.
  3. The only other possibility that I have been able to come up with is that the previous builder was using or pointing to a later version of these header

    files than I am. I will look into this possibility, but I wanted to go ahead and post to get the ball rolling first, in case someone else had other helpful

    ideas.

Any thoughts or suggestions from an experienced MSVC++ user would be greatly appreciated.
Jun 3 '09 #1
Share this Question
Share on Google+
3 Replies


100+
P: 687
according to googled (xvt_type, long_ptr ) info, new MS headers define LONG_PTR in the different way - they are no longer pointers , but longs.
Jun 3 '09 #2

Expert 100+
P: 2,401
Most likely you need earlier versions of the MS headers.

Failing that, you might try providing your own BaseTsd.h, thereby overriding the MS header.

Presumably the third party xvt_type.h contains conditional compilation directives to prevent it from being included twice. You could define the appropriate macro to suppress xvt_type, eliminating the conflict with the MS header. However, this would probably cause you lots of new problems as your code and the 3rd-party code try to dereference pointers that are actually integers.
Jun 4 '09 #3

P: 4
First of all, I want to clarify one item. I did not include all error messages in the original post. When I try to build some projects I only get the error involving xvt_type.h. There is only one project that gives me both the xvt_type.h error and the basetsd.h error, but even in that case it is trying to compile different source files. Thus, I don't think suggestions that the errors are caused by conflicts between xvt_type.h and basetsd.h hold water.

Secondly, in response to suggestions that I have received regarding changing the order of include and library directory searches... I have tried several different orders with no noticeable impact. The order I have right now is Microsoft SDK first, third party includes and libraries second, and VC98 includes and libraries last. This seems the safest, but again no order seems to work (trying every single permutation would take quite a while.)

Thirdly, in regards to the suggestion that I received that I might need older MS header files (and another that suggested that the basetsd.h that I quoted in my post looked like it might be from VC++ 2008 instead of from MSVC++ 6.0), let me say that the basetsd.h file I put in the post was definitely from the Microsoft SDK directory and that the files on my machine in that directory are all dated March 2003 and earlier. I am pretty sure I am using the right age SDK (but I may not be using the SDK for/from the right system... see next paragraph.)

Lastly, and most importantly, it has come to my attention that the product that I am building is sold only for Server 2000 and Server 2003 and that the previous building of this code base was running on a Server 2003 system. Since I have been trying my builds on an XP machine, I am leaning towards setting up a virtual machine running Server 2003 in which to compile to see if this helps. However, since that will take a while to set up, I was hoping someone out there might have thoughts about whether or not this is likely to help.
Jun 4 '09 #4

Post your reply

Sign in to post your reply or Sign up for a free account.