differs in levels of indirection from...

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

re: differs in levels of indirection from...

blimeyoreilly wrote:[color=blue]
> 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.[/color]

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.
[color=blue]
> I keep getting the 'differs in levels of
> indirection from' error whenever I compile this:
>
> CTestHarnessApp theApp;[/color]

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

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

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.
[color=blue]
>
> (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)[/color]

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?
[color=blue]
> But everything is okay when I compile this:
>
> CTestHarnessApp theApp;
> CTestHarnessApp* pTheApp = &theApp;[/color]

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

CTestHarnessApp theApp, *pTheApp = &theApp;
[color=blue]
> //CTestHarnessApp* pTheApp;
> //pTheApp = &theApp;
>
>
> Me no understand!!![/color]

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

re: differs in levels of indirection from...

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

re: differs in levels of indirection from...

BlimeyOReilly wrote:[color=blue]
> 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 ?[/color]

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

re: differs in levels of indirection from...

"blimeyoreilly" <mark_s_howie@hotmail.com> wrote in message
news:1117108430.493286.117610@g49g2000cwa.googlegr oups.com...[color=blue]
> 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:[/color]

MFC is not C++. Ask a relevent newsgroup for that proprietary language. Code
that only runs in Windows is off-topic here.
[color=blue]
>
> 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)[/color]

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/
[color=blue]
>
>
> But everything is okay when I compile this:
>
> CTestHarnessApp theApp;
> CTestHarnessApp* pTheApp = &theApp;
> //CTestHarnessApp* pTheApp;
> //pTheApp = &theApp;
>
>
> Me no understand!!!
> BOR
>[/color]

re: differs in levels of indirection from...

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

re: differs in levels of indirection from...

"blimeyoreilly" <mark_s_howie@hotmail.com> wrote in message
news:1117108430.493286.117610@g49g2000cwa.googlegr oups.com...[color=blue]
> 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
>[/color]

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

re: differs in levels of indirection from...

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

re: differs in levels of indirection from...

"Victor Bazarov" <v.Abazarov@comAcast.net> schrieb im Newsbeitrag
news:r6kle.77119$NC6.65268@newsread1.mlpsca01.us.t o.verio.net...[color=blue][color=green]
>> CTestHarnessApp theApp;[/color]
>
> This declares an object, supposedly.
>[color=green]
>> //CTestHarnessApp* pTheApp = &theApp;
>> CTestHarnessApp* pTheApp;[/color]
>
> This, supposedly, declares a pointer to an object of the same type.
>[color=green]
>> pTheApp = &theApp;[/color]
>
> 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.[/color]

.... unless the assignment does not occure in the body of some function
[color=blue][color=green]
>> (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)[/color]
>
> 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?[/color]

I guess he did copy (or at least type it without any major typos).
[color=blue][color=green]
>> But everything is okay when I compile this:
>>
>> CTestHarnessApp theApp;
>> CTestHarnessApp* pTheApp = &theApp;[/color]
>
> You should always try to put those things in the same declaration
> statement to avoid typos:
>
> CTestHarnessApp theApp, *pTheApp = &theApp;[/color]

Some people think different about that.
[color=blue][color=green]
>> //CTestHarnessApp* pTheApp;
>> //pTheApp = &theApp;
>>
>>
>> Me no understand!!![/color]
>
> 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.[/color]

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

Regards
Heinz

re: differs in levels of indirection from...

Heinz Ozwirk wrote:[color=blue]
> "Victor Bazarov" <v.Abazarov@comAcast.net> schrieb im Newsbeitrag
> news:r6kle.77119$NC6.65268@newsread1.mlpsca01.us.t o.verio.net...
>[color=green][color=darkred]
>>>CTestHarnessApp theApp;[/color]
>>
>>This declares an object, supposedly.
>>
>>[color=darkred]
>>>//CTestHarnessApp* pTheApp = &theApp;
>>>CTestHarnessApp* pTheApp;[/color]
>>
>>This, supposedly, declares a pointer to an object of the same type.
>>
>>[color=darkred]
>>>pTheApp = &theApp;[/color]
>>
>>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.[/color]
>
>
> ... unless the assignment does not occure in the body of some function[/color]

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?
[color=blue]
> [...][color=green]
>>
>>You should always try to put those things in the same declaration
>>statement to avoid typos:
>>
>> CTestHarnessApp theApp, *pTheApp = &theApp;[/color]
>
>
> Some people think different about that.[/color]

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

re: differs in levels of indirection from...

"Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:miGle.77847$NC6.31733@newsread1.mlpsca01.us.t o.verio.net...[color=blue]
> Heinz Ozwirk wrote:[color=green]
>> "Victor Bazarov" <v.Abazarov@comAcast.net> schrieb im Newsbeitrag
>> news:r6kle.77119$NC6.65268@newsread1.mlpsca01.us.t o.verio.net...
>>[color=darkred]
>>>>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.[/color]
>>
>>
>> ... unless the assignment does not occure in the body of some function[/color]
>
> 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?
>[/color]

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