#include "stdafx.h"

  • Follow


I've tried this:

#ifdef SOMETHING
 #include "stdafx.h"
#endif

but I got following error:

Compiling...
MyApp.cpp
C:\Projects\VS\MyApp\MyApp.cpp(4) : fatal error C1020: unexpected #endif
Error executing cl.exe.

It seems it is impossible to put this include into ifdef block, or I'm doing
something wrong?


0
Reply blah1280 (59) 6/1/2004 1:36:32 PM

"Miki Peric" <blah@ccc.com> wrote in message
news:Onsnz19REHA.1208@TK2MSFTNGP09.phx.gbl...
>
> I've tried this:
>
> #ifdef SOMETHING
>  #include "stdafx.h"
> #endif
>
> but I got following error:
>
> Compiling...
> MyApp.cpp
> C:\Projects\VS\MyApp\MyApp.cpp(4) : fatal error C1020: unexpected #endif
> Error executing cl.exe.
>
> It seems it is impossible to put this include into ifdef block, or I'm
doing
> something wrong?

I think the compiler ignores or considers as comment everything before the
pch #include line.
-- 
Jeff Partch [VC++ MVP]


0
Reply jeffp (1711) 6/1/2004 1:48:05 PM

--- cut ---
Jeff Partch [MVP] wrote:
 > I think the compiler ignores or considers as comment everything 
before the
 > pch #include line.
--- cut ---

I HOPE NOT!  Why should the compiler disciminate on the contents of an 
#ifdef block when deciding if it is to obey the directives?  It would be 
an absolute disaster for transportability.

I noticed that the line refers to line 4
C:\Projects\VS\MyApp\MyApp.cpp(4) : fatal error C1020: unexpected #endif
We see three lines, so, what's on line 1?

Another possibility could be that one of the lines is much longer and 
has some off-screen text.

Balboos

>> --- cut ---
>>#ifdef SOMETHING
>> #include "stdafx.h"
>>#endif
>> --- cut ---

0
Reply balboos (139) 6/1/2004 5:59:19 PM

Miki Peric wrote:

> I've tried this:
> 
> #ifdef SOMETHING
>  #include "stdafx.h"
> #endif

This probably won't really do what you want it to do anyway. If you
want to add stdafx.h to some files and not others by defining something,
it will still confuse the compiler and cause stdafx pre-compiled header
to be built unnecessarily. It really doesn't like defines before the
stdafx.h header.

> 
> but I got following error:
> 
> Compiling...
> MyApp.cpp
> C:\Projects\VS\MyApp\MyApp.cpp(4) : fatal error C1020: unexpected #endif
> Error executing cl.exe.
> 
> It seems it is impossible to put this include into ifdef block, or I'm doing
> something wrong?

I'd still guess that there is something wrong with your stdafx.h file.
I don't believe it is special, and I've certainly tried to do what I
think you are trying to do. It just doesn't work quite like you might
hope.

Jonathan Arnold
0
Reply jdarnold_online (67) 6/1/2004 7:11:28 PM

"Balboos" <balboos@masonicbrother.com.No.Spam> wrote in message
news:Xt3vc.14444$eU6.2931914@news4.srv.hcvlny.cv.net...
> --- cut ---
> Jeff Partch [MVP] wrote:
>  > I think the compiler ignores or considers as comment everything
> before the
>  > pch #include line.
> --- cut ---
>
> I HOPE NOT!  Why should the compiler disciminate on the contents of an
> #ifdef block when deciding if it is to obey the directives?  It would be
> an absolute disaster for transportability.

Transportability? AFAIK, you cannot conditionally include the pch. If the cl
command line contains the use pch directive you must include the pch.
Anyway...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_the_.2f.yu_.28.use_precompiled_header.29_.option.asp

"...the compiler assumes that all code occurring before filename is
precompiled. The compiler skips to the [pch] #include directive, uses the
code contained in the precompiled header file, and then compiles all code
after filename".

-- 
Jeff Partch [VC++ MVP]



0
Reply jeffp (1711) 6/1/2004 7:11:28 PM

But . . .  and this is what I find a transportability problem:

The compiler SHOULD not see the #include <stdafx.h> directive any 
differently than if it was any other directive in the block.  And that 
means it should not see it at all.
That's what it's supposed to do, isn't it?

Otherwise, meaning of the #if ... #endif family of directives becomes 
ambiguous.  And then, what good are they?

If MS changed the rules, that doesn't make it logical or correct.
As to whether it's good practice, within the MS environment, is a 
different issue.

Balboos



Jeff Partch wrote:
> "Balboos" <balboos@masonicbrother.com.No.Spam> wrote in message
> news:Xt3vc.14444$eU6.2931914@news4.srv.hcvlny.cv.net...
> 
>>--- cut ---
>>Jeff Partch [MVP] wrote:
>> > I think the compiler ignores or considers as comment everything
>>before the
>> > pch #include line.
>>--- cut ---
>>
>>I HOPE NOT!  Why should the compiler disciminate on the contents of an
>>#ifdef block when deciding if it is to obey the directives?  It would be
>>an absolute disaster for transportability.
> 
> 
> Transportability? AFAIK, you cannot conditionally include the pch. If the cl
> command line contains the use pch directive you must include the pch.
> Anyway...
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_core_the_.2f.yu_.28.use_precompiled_header.29_.option.asp
> 
> "...the compiler assumes that all code occurring before filename is
> precompiled. The compiler skips to the [pch] #include directive, uses the
> code contained in the precompiled header file, and then compiles all code
> after filename".
> 

0
Reply balboos (139) 6/1/2004 8:38:52 PM

"Balboos" <balboos@masonicbrother.com.No.Spam> wrote in message
news:wP5vc.15794$eU6.3375866@news4.srv.hcvlny.cv.net...
> But . . .  and this is what I find a transportability problem:
>
> The compiler SHOULD not see the #include <stdafx.h> directive any
> differently than if it was any other directive in the block.  And that
> means it should not see it at all.
> That's what it's supposed to do, isn't it?

No, stdafx.h (or whatever the name of the pch is) is special. The compiler
ignores everything that preceeds it. If it were to recognize the
conditional, and then not see the #include "stdafx.h", then it would quit
with the error that the pch file could not be found. Either you use the /Yu
switch or you don't. I haven't tested it, but I suspect that if you compile
without /Yu then the compiler will recognize the conditional and happily not
include it.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.yu.asp

>
> Otherwise, meaning of the #if ... #endif family of directives becomes
> ambiguous.  And then, what good are they?

Use of pch trumps it in this case.

>
> If MS changed the rules, that doesn't make it logical or correct.
> As to whether it's good practice, within the MS environment, is a
> different issue.

I don't know what the rules are, but IIRC the MS C\C++ compilers have always
worked this way.

-- 
Jeff Partch [VC++ MVP]


0
Reply jeffp (1711) 6/1/2004 8:56:00 PM

I don't argue with your knowledge, and that the pch holds the trump.
I just think it would be logically handled by simply issuing an error 
that the PCH was missing (or not, depending upon how it evaluates).

The error given in the original post is just plain wrong!  The mechanism 
used, non-sequential processing, defies the logic of the directives that 
"any reasonable user" would expect to obtain.

That doesn't make you wrong.  I'll try to keep this in mind so I don't 
get trapped at some future point (heretofore, my pch file was always the 
first to be declared).

On the other hand, the more mysterious the operation, the more difficult 
it will by for the VB folks to take our jobs.

Balboos

Jeff Partch wrote:

> "Balboos" <balboos@masonicbrother.com.No.Spam> wrote in message
> news:wP5vc.15794$eU6.3375866@news4.srv.hcvlny.cv.net...
> 
>>But . . .  and this is what I find a transportability problem:
>>
>>The compiler SHOULD not see the #include <stdafx.h> directive any
>>differently than if it was any other directive in the block.  And that
>>means it should not see it at all.
>>That's what it's supposed to do, isn't it?
> 
> 
> No, stdafx.h (or whatever the name of the pch is) is special. The compiler
> ignores everything that preceeds it. If it were to recognize the
> conditional, and then not see the #include "stdafx.h", then it would quit
> with the error that the pch file could not be found. Either you use the /Yu
> switch or you don't. I haven't tested it, but I suspect that if you compile
> without /Yu then the compiler will recognize the conditional and happily not
> include it.
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.yu.asp
> 
> 
>>Otherwise, meaning of the #if ... #endif family of directives becomes
>>ambiguous.  And then, what good are they?
> 
> 
> Use of pch trumps it in this case.
> 
> 
>>If MS changed the rules, that doesn't make it logical or correct.
>>As to whether it's good practice, within the MS environment, is a
>>different issue.
> 
> 
> I don't know what the rules are, but IIRC the MS C\C++ compilers have always
> worked this way.
> 

0
Reply balboos (139) 6/1/2004 9:36:39 PM

Actually, Jeff is right. That is EXACTLY how the compiler behaves. That is what it is
SUPPOSED to do. 

Transportability of Windows code is rarely an issue. But when you are including subroutine
libraries that are designed for non-Windows platforms, the simplest method is to go into
the project | settings, C/C++ tab, Precompiled Headers option, and in the left pane select
the offending file, and in the right pane click "Do not use precompiled headers". Then
ideally, you will not need stdafx.h anyway, because the code, being portable, would not
require anything defined in Windows.
					joe

On Tue, 01 Jun 2004 17:59:19 GMT, Balboos <balboos@masonicbrother.com.No.Spam> wrote:

>--- cut ---
>Jeff Partch [MVP] wrote:
> > I think the compiler ignores or considers as comment everything 
>before the
> > pch #include line.
>--- cut ---
>
>I HOPE NOT!  Why should the compiler disciminate on the contents of an 
>#ifdef block when deciding if it is to obey the directives?  It would be 
>an absolute disaster for transportability.
>
>I noticed that the line refers to line 4
>C:\Projects\VS\MyApp\MyApp.cpp(4) : fatal error C1020: unexpected #endif
>We see three lines, so, what's on line 1?
>
>Another possibility could be that one of the lines is much longer and 
>has some off-screen text.
>
>Balboos
>
>>> --- cut ---
>>>#ifdef SOMETHING
>>> #include "stdafx.h"
>>>#endif
>>> --- cut ---

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
Reply newcomer (15982) 6/2/2004 2:35:16 AM

No, the mechanism works as it is designed to work. You are applying the wrong analysis.
Precompiled headers are an engineering decision, which means that to gain certain benefits
you pay certain costs. In this case, the cost is that stdafx.h (or some other designated
header file, but by default, stdafx.h) is treated specially by the compiler, and
everything up to it is treated as a comment. If you don't want this feature, you disable
the precompiled headers feature, and the problem goes away. But the most common instance
of this I see is when someone is trying to incorporate non-Windows code (e.g., some C or
C++ library from some external source) and gets the error message that stdafx.h was not
found. Their natural reaction is to put it in. However, if the code is in a shared source
location, and used by many programmers, such as Unix, Linux, Solaris, or whatever, then
this solution will not work. The next natural reaction is to do as to OP did, which is to
put conditionals around it. This is heading down the garden path. The non-obvious, but
correct, solution, is to mark that file as not using precompiled headers.
				joe

On Tue, 01 Jun 2004 21:36:39 GMT, Balboos <balboos@masonicbrother.com.No.Spam> wrote:

>I don't argue with your knowledge, and that the pch holds the trump.
>I just think it would be logically handled by simply issuing an error 
>that the PCH was missing (or not, depending upon how it evaluates).
>
>The error given in the original post is just plain wrong!  The mechanism 
>used, non-sequential processing, defies the logic of the directives that 
>"any reasonable user" would expect to obtain.
>
>That doesn't make you wrong.  I'll try to keep this in mind so I don't 
>get trapped at some future point (heretofore, my pch file was always the 
>first to be declared).
>
>On the other hand, the more mysterious the operation, the more difficult 
>it will by for the VB folks to take our jobs.
>
>Balboos
>
>Jeff Partch wrote:
>
>> "Balboos" <balboos@masonicbrother.com.No.Spam> wrote in message
>> news:wP5vc.15794$eU6.3375866@news4.srv.hcvlny.cv.net...
>> 
>>>But . . .  and this is what I find a transportability problem:
>>>
>>>The compiler SHOULD not see the #include <stdafx.h> directive any
>>>differently than if it was any other directive in the block.  And that
>>>means it should not see it at all.
>>>That's what it's supposed to do, isn't it?
>> 
>> 
>> No, stdafx.h (or whatever the name of the pch is) is special. The compiler
>> ignores everything that preceeds it. If it were to recognize the
>> conditional, and then not see the #include "stdafx.h", then it would quit
>> with the error that the pch file could not be found. Either you use the /Yu
>> switch or you don't. I haven't tested it, but I suspect that if you compile
>> without /Yu then the compiler will recognize the conditional and happily not
>> include it.
>> 
>> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.yu.asp
>> 
>> 
>>>Otherwise, meaning of the #if ... #endif family of directives becomes
>>>ambiguous.  And then, what good are they?
>> 
>> 
>> Use of pch trumps it in this case.
>> 
>> 
>>>If MS changed the rules, that doesn't make it logical or correct.
>>>As to whether it's good practice, within the MS environment, is a
>>>different issue.
>> 
>> 
>> I don't know what the rules are, but IIRC the MS C\C++ compilers have always
>> worked this way.
>> 

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
Reply newcomer (15982) 6/2/2004 2:39:23 AM

> But the most common instance
> of this I see is when someone is trying to incorporate non-Windows code
(e.g., some C or
> C++ library from some external source) and gets the error message that
stdafx.h was not
> found. Their natural reaction is to put it in. However, if the code is in
a shared source
> location, and used by many programmers, such as Unix, Linux, Solaris, or
whatever, then
> this solution will not work.
Yes, this is my case.

> The next natural reaction is to do as to OP did, which is to
> put conditionals around it. This is heading down the garden path. The
non-obvious, but
> correct, solution, is to mark that file as not using precompiled headers.
I didn't know I can exclude some files from using pch. I'll try it.

Thank you.


0
Reply blah1280 (59) 6/2/2004 6:10:40 AM

> I'd still guess that there is something wrong with your stdafx.h file.
> I don't believe it is special, and I've certainly tried to do what I
> think you are trying to do. It just doesn't work quite like you might
> hope.
There is nothing wrong with my stdafx.h file. You may create simple project
and try to do what I have done and you will get same results.


0
Reply blah1280 (59) 6/2/2004 6:13:40 AM

> I noticed that the line refers to line 4
> C:\Projects\VS\MyApp\MyApp.cpp(4) : fatal error C1020: unexpected #endif
> We see three lines, so, what's on line 1?
The first line is empty.


0
Reply blah1280 (59) 6/2/2004 6:14:04 AM

Project | Settings | C/C++, Precompiled Headers. Select the file name in the left pane,
select "Do not use precompiled headers" on the right.
					joe

On Wed, 2 Jun 2004 08:10:40 +0200, "Miki Peric" <blah@ccc.com> wrote:

>> But the most common instance
>> of this I see is when someone is trying to incorporate non-Windows code
>(e.g., some C or
>> C++ library from some external source) and gets the error message that
>stdafx.h was not
>> found. Their natural reaction is to put it in. However, if the code is in
>a shared source
>> location, and used by many programmers, such as Unix, Linux, Solaris, or
>whatever, then
>> this solution will not work.
>Yes, this is my case.
>
>> The next natural reaction is to do as to OP did, which is to
>> put conditionals around it. This is heading down the garden path. The
>non-obvious, but
>> correct, solution, is to mark that file as not using precompiled headers.
>I didn't know I can exclude some files from using pch. I'll try it.
>
>Thank you.
>

Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
0
Reply newcomer (15982) 6/2/2004 4:52:51 PM

13 Replies
399 Views

(page loaded in 0.499 seconds)


Reply: