differs in levels of indirection from...

Discussion in 'C++' started by blimeyoreilly, May 26, 2005.

  1. Hi
    I've a small problem .. can anyone figure it out?

    I am working in VS.NET in C++ with MFC. I have a CWinApp-based class
    called CTestHarnessApp. I keep getting the 'differs in levels of
    indirection from' error whenever I compile this:

    CTestHarnessApp theApp;
    //CTestHarnessApp* pTheApp = &theApp;
    CTestHarnessApp* pTheApp;
    pTheApp = &theApp;

    (missing storage-class or type specifiers)
    ('int' differs in levels of indirection from 'CTestHarnessApp *')
    ('initializing' : cannot convert from 'CTestHarnessApp *__w64 ' to
    'int' This conversion requires a reinterpret_cast, a C-style cast or
    function-style cast)


    But everything is okay when I compile this:

    CTestHarnessApp theApp;
    CTestHarnessApp* pTheApp = &theApp;
    //CTestHarnessApp* pTheApp;
    //pTheApp = &theApp;


    Me no understand!!!
    BOR
    blimeyoreilly, May 26, 2005
    #1
    1. Advertising

  2. blimeyoreilly wrote:
    > I've a small problem .. can anyone figure it out?
    >
    > I am working in VS.NET in C++ with MFC. I have a CWinApp-based class
    > called CTestHarnessApp.


    Just to let you know, MFC is not topical here by itself. You should not
    presume people here know MFC or care about discussing it. So, next time
    if you have MFC-specific question (I am not saying this one is) you
    should consider posting to microsoft.public.vc.mfc. Back to your problem.

    > I keep getting the 'differs in levels of
    > indirection from' error whenever I compile this:
    >
    > CTestHarnessApp theApp;


    This declares an object, supposedly.

    > //CTestHarnessApp* pTheApp = &theApp;
    > CTestHarnessApp* pTheApp;


    This, supposedly, declares a pointer to an object of the same type.

    > pTheApp = &theApp;


    And here you're just assigning the address of 'theApp' object to a pointer
    to an object of the same type. Shouldn't give you any problem.

    >
    > (missing storage-class or type specifiers)
    > ('int' differs in levels of indirection from 'CTestHarnessApp *')
    > ('initializing' : cannot convert from 'CTestHarnessApp *__w64 ' to
    > 'int' This conversion requires a reinterpret_cast, a C-style cast or
    > function-style cast)


    Well, that suggests that 'pTheApp' is not declared as you claim it is.
    Are you sure you spelled everything correctly? Did you copy-and-paste
    from your actual program or did you type it in?

    > But everything is okay when I compile this:
    >
    > CTestHarnessApp theApp;
    > CTestHarnessApp* pTheApp = &theApp;


    You should always try to put those things in the same declaration
    statement to avoid typos:

    CTestHarnessApp theApp, *pTheApp = &theApp;

    > //CTestHarnessApp* pTheApp;
    > //pTheApp = &theApp;
    >
    >
    > Me no understand!!!


    Methinks there is more to it than you're telling. If I am wrong (and
    that is not unheard of), then there is something very screwed up with
    the compiler you're using.

    V
    Victor Bazarov, May 26, 2005
    #2
    1. Advertising

  3. Hi V,
    Okay, just dropped in the MFC ref for some context, but I cannot see
    how it really affects the issue here. I cut and pasted the code and
    the compiler errors.
    I am fairly new to c++, coming from a solid c background. Is there a
    need to declare a pointer operator function to the class
    CTestHarnessApp ?
    BOR
    BlimeyOReilly, May 26, 2005
    #3
  4. BlimeyOReilly wrote:
    > Okay, just dropped in the MFC ref for some context, but I cannot see
    > how it really affects the issue here. I cut and pasted the code and
    > the compiler errors.
    > I am fairly new to c++, coming from a solid c background. Is there a
    > need to declare a pointer operator function to the class
    > CTestHarnessApp ?


    No, there should be no need for that.

    There can be a problem with the compiler or with your understanding of
    some aspects of platform-specific programming. The error message mentions
    the '__w64' thing. If you're building a 64-bit target you should
    probably consider declaring your pointer in some platform-specific way
    (and I am guessing here):

    CTestHarnessApp * __w64 pTheApp;

    Consult with your compiler documentation on what the implications are for
    pointer types in a 64-bit mode. I remember how much pain 'near' and 'far'
    pointers gave the programmers of MS Windows 3.*.

    V
    Victor Bazarov, May 26, 2005
    #4
  5. I've had a look through the whole setup - compiler options and code.
    The only ref to 64-bit compilation (not something I was wanting!) was
    an option to warn about code that would be incompatible in 64-bit
    compilation. (the /Wp64 option). Removing this simply removed the last
    of the errors.
    Having another think about the whole problem though, there is only
    allowed a single CWinApp object - there must be one and one only. I am
    guessing that the declaration of the the CTestHarnessApp* was prefixed
    with 'const' by the preprocessor, but without an initialisation value
    it was a bit lost. This is the only reason I can think of...

    Is this because Windows knows I normally only use Linux???

    BOR
    ps Thanks for the help
    BlimeyOReilly, May 26, 2005
    #5
  6. blimeyoreilly

    Howard Guest

    "blimeyoreilly" <> wrote in message
    news:...
    > Hi
    > I've a small problem .. can anyone figure it out?
    >
    > I am working in VS.NET in C++ with MFC. I have a CWinApp-based class
    > called CTestHarnessApp. I keep getting the 'differs in levels of
    > indirection from' error whenever I compile this:
    >
    > CTestHarnessApp theApp;
    > //CTestHarnessApp* pTheApp = &theApp;
    > CTestHarnessApp* pTheApp;
    > pTheApp = &theApp;
    >
    > (missing storage-class or type specifiers)
    > ('int' differs in levels of indirection from 'CTestHarnessApp *')
    > ('initializing' : cannot convert from 'CTestHarnessApp *__w64 ' to
    > 'int' This conversion requires a reinterpret_cast, a C-style cast or
    > function-style cast)
    >
    >
    > But everything is okay when I compile this:
    >
    > CTestHarnessApp theApp;
    > CTestHarnessApp* pTheApp = &theApp;
    > //CTestHarnessApp* pTheApp;
    > //pTheApp = &theApp;
    >
    >
    > Me no understand!!!
    > BOR
    >


    Is this code inside a function? In the first instance, you're declaring a
    pointer, and then assigning a value to it. In the second, you're declaring
    the pointer and initializing it.

    If that code is outside of a function, then the problem is trying to execute
    an assignment statement. You can't do that outside a function. The second
    case would work because it's not an assignment, it's initialization of a
    variable, which *is* allowed outside of a function.

    If this is inside a function, then the problem lies elsewhere, most likely
    in code we haven't been shown.

    -Howard
    Howard, May 26, 2005
    #6
  7. This _is_ outside a function. It's not something I had really thought
    about before, but now it makes sense.
    That about wraps it up. Thanks
    BOR
    BlimeyOReilly, May 26, 2005
    #7
  8. blimeyoreilly

    Heinz Ozwirk Guest

    "Victor Bazarov" <> schrieb im Newsbeitrag
    news:r6kle.77119$01.us.to.verio.net...
    >> CTestHarnessApp theApp;

    >
    > This declares an object, supposedly.
    >
    >> //CTestHarnessApp* pTheApp = &theApp;
    >> CTestHarnessApp* pTheApp;

    >
    > This, supposedly, declares a pointer to an object of the same type.
    >
    >> pTheApp = &theApp;

    >
    > And here you're just assigning the address of 'theApp' object to a pointer
    > to an object of the same type. Shouldn't give you any problem.


    .... unless the assignment does not occure in the body of some function

    >> (missing storage-class or type specifiers)
    >> ('int' differs in levels of indirection from 'CTestHarnessApp *')
    >> ('initializing' : cannot convert from 'CTestHarnessApp *__w64 ' to
    >> 'int' This conversion requires a reinterpret_cast, a C-style cast or
    >> function-style cast)

    >
    > Well, that suggests that 'pTheApp' is not declared as you claim it is.
    > Are you sure you spelled everything correctly? Did you copy-and-paste
    > from your actual program or did you type it in?


    I guess he did copy (or at least type it without any major typos).

    >> But everything is okay when I compile this:
    >>
    >> CTestHarnessApp theApp;
    >> CTestHarnessApp* pTheApp = &theApp;

    >
    > You should always try to put those things in the same declaration
    > statement to avoid typos:
    >
    > CTestHarnessApp theApp, *pTheApp = &theApp;


    Some people think different about that.

    >> //CTestHarnessApp* pTheApp;
    >> //pTheApp = &theApp;
    >>
    >>
    >> Me no understand!!!

    >
    > Methinks there is more to it than you're telling. If I am wrong (and
    > that is not unheard of), then there is something very screwed up with
    > the compiler you're using.


    You might be wrong, but that does imply that something is wrong with the
    compiler (unless your wrote it ;-)

    Regards
    Heinz
    Heinz Ozwirk, May 26, 2005
    #8
  9. Heinz Ozwirk wrote:
    > "Victor Bazarov" <> schrieb im Newsbeitrag
    > news:r6kle.77119$01.us.to.verio.net...
    >
    >>>CTestHarnessApp theApp;

    >>
    >>This declares an object, supposedly.
    >>
    >>
    >>>//CTestHarnessApp* pTheApp = &theApp;
    >>>CTestHarnessApp* pTheApp;

    >>
    >>This, supposedly, declares a pointer to an object of the same type.
    >>
    >>
    >>>pTheApp = &theApp;

    >>
    >>And here you're just assigning the address of 'theApp' object to a pointer
    >>to an object of the same type. Shouldn't give you any problem.

    >
    >
    > ... unless the assignment does not occure in the body of some function


    But then the compiler (IMO) should *not* attempt to declare 'pTheApp'
    /again/ as an 'int' and give a more sensible error message, don't you
    agree?

    > [...]
    >>
    >>You should always try to put those things in the same declaration
    >>statement to avoid typos:
    >>
    >> CTestHarnessApp theApp, *pTheApp = &theApp;

    >
    >
    > Some people think different about that.


    There is probably another way to *avoid typos*, but I can't think of any
    at the moment, except typedefing 'CTestHarnessApp' to something shorter
    (and significantly shorter).

    V
    Victor Bazarov, May 27, 2005
    #9
  10. blimeyoreilly

    Howard Guest

    "Victor Bazarov" <> wrote in message
    news:miGle.77847$01.us.to.verio.net...
    > Heinz Ozwirk wrote:
    >> "Victor Bazarov" <> schrieb im Newsbeitrag
    >> news:r6kle.77119$01.us.to.verio.net...
    >>
    >>>>CTestHarnessApp theApp;
    >>>
    >>>This declares an object, supposedly.
    >>>
    >>>
    >>>>//CTestHarnessApp* pTheApp = &theApp;
    >>>>CTestHarnessApp* pTheApp;
    >>>
    >>>This, supposedly, declares a pointer to an object of the same type.
    >>>
    >>>
    >>>>pTheApp = &theApp;
    >>>
    >>>And here you're just assigning the address of 'theApp' object to a
    >>>pointer
    >>>to an object of the same type. Shouldn't give you any problem.

    >>
    >>
    >> ... unless the assignment does not occure in the body of some function

    >
    > But then the compiler (IMO) should *not* attempt to declare 'pTheApp'
    > /again/ as an 'int' and give a more sensible error message, don't you
    > agree?
    >


    I agree.

    I had this problem before, and the VC++ error message was no help at all!
    If I recall, CodeWarrior does something similar, but first precedes the
    error with another one about "implicit int" being deprecated. One learns to
    recognize such errors eventually, but it would be nice to have error
    messages that actually tell you the error!

    Assuming an int probably helps the parser continue, and then it's just a
    matter of trying to describe the error state correctly. That requires a bit
    of intelligence, something that can be difficult to add into a
    state-machine-based compiler. Now, no comments about the ability of M$ to
    add intelligence to anything, please! :)

    -Howard
    Howard, May 27, 2005
    #10
  11. blimeyoreilly

    Peter Julian Guest

    "blimeyoreilly" <> wrote in message
    news:...
    > Hi
    > I've a small problem .. can anyone figure it out?
    >
    > I am working in VS.NET in C++ with MFC. I have a CWinApp-based class
    > called CTestHarnessApp. I keep getting the 'differs in levels of
    > indirection from' error whenever I compile this:


    MFC is not C++. Ask a relevent newsgroup for that proprietary language. Code
    that only runs in Windows is off-topic here.

    >
    > CTestHarnessApp theApp;
    > //CTestHarnessApp* pTheApp = &theApp;
    > CTestHarnessApp* pTheApp;
    > pTheApp = &theApp;
    >
    > (missing storage-class or type specifiers)
    > ('int' differs in levels of indirection from 'CTestHarnessApp *')
    > ('initializing' : cannot convert from 'CTestHarnessApp *__w64 ' to
    > 'int' This conversion requires a reinterpret_cast, a C-style cast or
    > function-style cast)


    Isn't this expected and documented with MFC? Try...

    CWnd * p = theApp.m_pMainWnd; // if decade old memrory cells still work

    Last but not least, consider switching from MFC to WTL if you are going to
    do only Windows. Unfortunately for MS, WTL is not documented which in my
    humble opinion is a strategic blunder of infinite proportions. A very big
    boo-boo. It outdoes MFC so much so in every respect that the small community
    that supports WTL have finally convinced MS to release it as open-source
    (unfortunately, MS's ATL is still required to run it which means that you
    still have to have VC). Some organisations never learn. What a shame.
    http://sourceforge.net/projects/wtl/
    http://www.codeproject.com/wtl/

    Actually, here is an even better proposal, take a look at wxwindows, a cross
    platform GUI that is MFC-like which is quickly growing in popularity (you
    can't compete with open source):
    http://www.wxwindows.org/

    >
    >
    > But everything is okay when I compile this:
    >
    > CTestHarnessApp theApp;
    > CTestHarnessApp* pTheApp = &theApp;
    > //CTestHarnessApp* pTheApp;
    > //pTheApp = &theApp;
    >
    >
    > Me no understand!!!
    > BOR
    >
    Peter Julian, Jun 26, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. SL
    Replies:
    0
    Views:
    506
  2. Replies:
    2
    Views:
    659
  3. Tobias Erbsland
    Replies:
    2
    Views:
    15,659
    Tobias Erbsland
    Jun 18, 2004
  4. Angus
    Replies:
    6
    Views:
    1,286
    matevzb
    Feb 12, 2007
  5. Angus
    Replies:
    2
    Views:
    684
    Clark S. Cox III
    Feb 12, 2007
Loading...

Share This Page