Precompiled headers on C

  • Thread starter Thread starter Bonj
  • Start date Start date
B

Bonj

Is it possible to avoid using precompiled headers on files that don't
#include "stdafx.h".
I have an ATL project,which has got a lot of ATL #includes in its stdafx.h.
I now need to add some .c files to this project, that compile as hard raw
C - not C++.
The .c files obviously won't understand the <atlbase.h> etc that are in the
stdafx.h.
But if I leave the precompiled headers switch on, it complains that fatal
end of file was found looking for precompiled header directive, obviously in
the .c files. I though precompiled headers were just so that when it *did*
get included, it knew that if the .obj file was newer than the .h file, it
didn't have to recompile it.... is this not so?
I was going to put the .c files in a static library project, but it turns
out that it's more messy that way as the purpose of the .c files is to
access resource data.
Any ideas?
 
Bonj said:
Is it possible to avoid using precompiled headers on files that don't
#include "stdafx.h".
I have an ATL project,which has got a lot of ATL #includes in its stdafx.h.
I now need to add some .c files to this project, that compile as hard raw
C - not C++.
The .c files obviously won't understand the <atlbase.h> etc that are in the
stdafx.h.
Click to expand...

Right-click on the file in the Solution Explorer, then Properties. You'll
probably want to select 'All Configurations' followed by: C/C++>Precompiled
Headers>Create/Use Precompiled Header = Not Using Precompiled Headers.
 
Yes I know, that's exactly what I have done. But it doesn't exactly take the
benefit of using the stdafx.h.
I was wondering if there was some way you could still use the advantage of
precompiled headers while using .c files.
 
Bonj said:
Yes I know, that's exactly what I have done. But it doesn't exactly take the benefit of using the stdafx.h.
I was wondering if there was some way you could still use the advantage of precompiled headers while using .c files.
Click to expand...

There is. You can setup a build where several different
groupings of headers are precompiled, then use any one
precompilation for different sources as you see fit. To
see how that works, study the docs on compiler options
relating to precompilation.

I may be wrong about this, but getting it to happen with
the IDE's semi-brainless automatic build system could be
a difficult process. You would then be facing creation of
an alternative build process. Many such exist and many
have found them atractive for various reasons, generally
because they allow such flexibility.

For your situation, I expect you would be better off
getting your .c files to compile as C++. Usually, the
changes necessary to do that are all improvements.
 
Bonj said:
Yes I know, that's exactly what I have done. But it doesn't exactly take the
benefit of using the stdafx.h.
I was wondering if there was some way you could still use the advantage of
precompiled headers while using .c files.
Click to expand...

Oh, you can set one *.c file to create another *.pch for all your other *.c
files to use.
 
There is. You can setup a build where several different
groupings of headers are precompiled, then use any one
precompilation for different sources as you see fit. To
see how that works, study the docs on compiler options
relating to precompilation.
Click to expand...

Mmmm... it usually gets its knickers in a twist whenever I try to modify the
build settings, normally.
I may be wrong about this, but getting it to happen with
the IDE's semi-brainless automatic build system could be
a difficult process. You would then be facing creation of
an alternative build process. Many such exist and many
have found them atractive for various reasons, generally
because they allow such flexibility.
Click to expand...

I think it would be better if you could set different build settings for
different files, this would allow you to compile managed and unmanaged ones
separately (separate issue, but...), then you could be sure they were
compiling the way you want.
For your situation, I expect you would be better off
getting your .c files to compile as C++. Usually, the
changes necessary to do that are all improvements.
Click to expand...

Nah, I wouldn't dream of doing that. I love my C files, I want to keep them
that way - and I won't be forcing them to compile as C++. I'd do it in
assembly language if I knew it, but I don't! I generally think C to be good
for memory and such functions as manipulating resources, whereas all the
high-level ATL stuff is taken care of by the C++ side. The C files are the
only ones that are going to be modifying the global memory of the
application (well, DLL) - all of the stuff in the C++ ones is localized in
the ATL -based classes. It doesn't use any heap either - all of the memory
is in a resource file loaded into global namespace.



Cheers
 
"Bonj" <benjtaylor at hotpop d0t com> wrote in message
[Brasfield once wrote:]
Nah, I wouldn't dream of doing that. I love my C files, I want to keep them that way - and I won't be forcing them to compile as
C++. I'd do it in assembly language if I knew it, but I don't! I generally think C to be good for memory and such functions as
manipulating resources, whereas all the high-level ATL stuff is taken care of by the C++ side. The C files are the only ones that
are going to be modifying the global memory of the application (well, DLL) - all of the stuff in the C++ ones is localized in the
ATL -based classes. It doesn't use any heap either - all of the memory is in a resource file loaded into global namespace.
Click to expand...

You seem to suffer under the misapprehension that
you would have to change the nature of your C code
in order to compile it as C++. That is not what I was
suggesting. If your C files are already ANSI C (rather
than the ancient K&R C), then with just a little work,
and no changes to the way the code operates, they
can be made acceptable to the C++ compiler. This
means a little less sloppiness with respect to typing,
and a few casts to make explicit what was implicit
in the C version, but the sequence of assignments
and calls, the data structures, and the form of
expressions can remain as they were. You need
not add any classes, use namespaces, or emply
any other purely C++ features. This usage is
commonly known as "using C++ as a better C".
(Of course, some C diehards quibble with this!)
Cheers
Click to expand...

OK.
 
Bonj said:
Yes I know, that's exactly what I have done. But it doesn't exactly take the
benefit of using the stdafx.h.
I was wondering if there was some way you could still use the advantage of
precompiled headers while using .c files.
Click to expand...

Could you hack up the stdafx.h into two sections separated by
#ifdef _cplusplus
...
#else
...
#endif

Norm
 
Norm Dresner said:
Could you hack up the stdafx.h into two sections separated by
#ifdef _cplusplus
...
#else
...
#endif

Norm
Click to expand...

I just looked at the M/S on-line documentation for precompiled headers and
found this statement
"Although you can use only one precompiled header (.pch) file per source
file, you can use multiple .pch files in a project"

Would this accomplish some of what you want?

Norm
 
You seem to suffer under the misapprehension that
you would have to change the nature of your C code
in order to compile it as C++.
Click to expand...

No, I don't - I suffer the apprehension (mis~ or otherwise) that there would
be no advantage in performance in converting it to C. The way I see it, it
is the same compiler backend that is building my program, but in C, it is
doing simpler things when compiling and having to conform to a stricter set
of rules about what it can do than when doing C++.
I personally very much doubt that there is any way of using the C++-only
features or the way C++ compiles that C doesn't, in order to increase the
speed of the program. But if this is what you meant by "using C++ as a
better C", then please tell me what they are - because I don't know them!
What I mean is, when I compile C, it is an old language that has been around
since the seventies or something. But the compiler I'm using hasn't been
around since the seventies, so the only advantages in using C++ would be in
what functionality I could use, not performance.
My C files would be acceptable to the C++ compiler, apart from the 'extern
"C" ...' bit. But without the precompiled headers, they're acceptable to the
C compiler aswell. It's like in a web application, if you're not using the
session state, you might aswell turn it off.
That is not what I was
suggesting. If your C files are already ANSI C (rather
than the ancient K&R C),
Click to expand...

Oh god yes, they're standard, modern C. They compile with the MS 7.1
compiler just like the C++ files do, it's just they've got a .c extension.
No ancient compilers that use weird specifics or anything.
then with just a little work,
and no changes to the way the code operates, they
can be made acceptable to the C++ compiler. This
means a little less sloppiness with respect to typing,
and a few casts to make explicit what was implicit
in the C version,
Click to expand...

I never do implicit casts anyway. I always use, for instance:
HMODULE hMod = (HMODULE)hInstance
 
I did try that.
However, when linking, it complained that I had attempted to link a C .obj
file to a C++ .pch file or vice versa.
The trouble is I don't know how to set these things at the file level, they
only seem to be settable at the project level.
Is there some way you can specify which .pch file each .c / .cpp file is to
use?
 
Yes, it probably would if I knew how to do it...
(also see other reply to higher up post)
I think the basic thing is... can you set the .pch file each compilation
unit is to use, or divide them up into distinct groups?
 
Bonj said:
Can you? How?
Click to expand...

You add an *.h file...

// cpch.h
#define WIN32_LEAN_AND_MEAN
#define NONAMELESSUNION
#include <Windows.h>
#include <TChar.h>
#include <CommCtrl.h>

....and an *.c file that includes it...

// cpch.c
#include "cpch.h"

....to your project, and in this *.c file Properties, you set it to Create
the *.pch and give it a name. Then set all your other *.c files to Use this
*.pch, and start them off with...

// Other.c
#include "cpch.h"
#include "Other.h"
 
Oh, and FWIW you can also use #pragma hdrstop. With it you can just elect an
existiong *.c file to be the creator (set its pch property to Create no file
name), and ...

// Some.c
#define WIN32_LEAN_AND_MEAN
#define NONAMELESSUNION
#include <Windows.h>
#include <TChar.h>
#include <CommCtrl.h>
#pragma hdrstop ("cpch.pch")
// Everything above this line precompiles into cpch.pch
#include "Some.h"

BOOL _cdecl SomeFunc(IN CONST HWND hWnd)
{
return IsWindow(hWnd);
}

....and set the other *.c files Properties to Use (no filename) and...

// Other.c
#pragma hdrstop ("cpch.pch")
#include "Other.h"

EXTERN_C BOOL _cdecl OtherFunc(IN CONST HWND hWnd)
{
return DestroyWindow(hWnd);
}
 
Bonj said:
No, I don't - I suffer the apprehension (mis~ or otherwise) that there would be no advantage in performance in converting it to C.
Click to expand...

Assuming you meant "converting it to C++", one advantage
of doing so would be to let you use a single precompilation
for all compiles. After the trivial modifications needed to
get your .c files past the C++ compiler, the code generator
would see the same intermediate form as before.
The way I see it, it is the same compiler backend that is building my program, but in C, it is doing simpler things when compiling
and having to conform to a stricter set of rules about what it can do than when doing C++.
Click to expand...

When you write an essentially C program and compile it
with the C++ compiler, the meaning is the same as if you
compile it with the C compiler.
I personally very much doubt that there is any way of using the C++-only features or the way C++ compiles that C doesn't, in order
to increase the speed of the program.
Click to expand...

That was never the point. My point was that you could
sidestep the whole problem you are having with the
precompilation feature.
But if this is what you meant by "using C++ as a better C", then please tell me what they are - because I don't know them!
Click to expand...

The C++ compiler is better about enforcing type safety.
What I mean is, when I compile C, it is an old language that has been around since the seventies or something. But the compiler
I'm using hasn't been around since the seventies, so the only advantages in using C++ would be in what functionality I could use,
not performance.
Click to expand...

Again, the advantage of my suggestion is to solve your
original problem (see subject line) and potentially catch
a few errors heretofore unnoticed.
My C files would be acceptable to the C++ compiler, apart from the 'extern "C" ...' bit.
Click to expand...

If that is so, then there is little work involved in taking
the solution path I suggested. I cannot see why you
should prefer to go futzing around with precompiled
header options and to struggle with the IDE's build
system.
But without the precompiled headers, they're acceptable to the C compiler aswell. It's like in a web application, if you're not
using the session state, you might aswell turn it off.
Click to expand...

The difference is that the features you do not use
do not cost anything.

....
I never do implicit casts anyway. I always use, for instance:
HMODULE hMod = (HMODULE)hInstance
Click to expand...

The C++ compiler can prove or disprove that
contention, at least regarding your .c files it sees.
I'm presuming this is faster than the static_cast<type> thingy or other?
Click to expand...

There is no difference in performance. The effect
with respect to generated code is identical.
 
and in this *.c file Properties

That's the bit I'm having trouble with - I can't find a property editor that
changes the settings of just a single file - where is it?
 
Bonj said:
I personally very much doubt that there is any way of using the
C++-only features or the way C++ compiles that C doesn't, in order to
increase the speed of the program. But if this is what you meant by
"using C++ as a better C", then please tell me what they are - because
I don't know them!
What I mean is, when I compile C, it is an old language that has been
around since the seventies or something. But the compiler I'm using
hasn't been around since the seventies, so the only advantages in
using C++ would be in what functionality I could use, not performance.
Click to expand...

Have you seen this paper by Bjarne Stroustrup, where he shows an example
of just how much faster C++ can be ?

http://www.research.att.com/~bs/new_learning.pdf


:-)


Bo Persson
 
That's in a situation where c++ actually *would* be faster. I've got
sections of my program that are written in C++ because there's no way they
could be written in C, namely, they involve ATL. What with ATL being faster
and smaller than MFC I'm happy with that, but don't get me wrong, I can't
see how using C++ for the part of my program that manages the resource data
could actually be faster. It's pointless pointing me to *one example* of how
C++ can be faster in some particular tests, because someone else could point
me to another example of how a C version would be faster than a C++ version
in their own particular tests. It just proves that that particular piece of
code was a candidate for object oriented programming, so was faster in C++,
but it doesn't prove anything with respect to my own scenario.
In my scenario, the data is in a collection of nodes, but they are
explicitly arranged into a 'flat' format by the program that generates them,
in order that they can be arranged in one contigious block in the resource
file. To write a C++ class or even struct and to try to rearrange them into
a non-flat structure would be both time consuming for me and for the
program - as it would have all this work to do at start-up time. Not
counting the fact that it would use bags more heap memory, 400KB more to be
precise. And what's more, far from being faster to access, I can't even be
sure that it would be *as quick* to access. If this is left in global
namespace and accessed with just one pointer that traverses back and forth
through the structure as and when it needs to, there is going to be minimal
overhead.
No offence, but I really wish people would ask the question that has been
asked, rather than trying to take a step back and look at the bigger picture
and pick apart the questionner's motives and before trying to answer the
question they think should have been asked.
Example: the question that's been asked was "How do I use precompiled
headers in a project with .c files?". The question you answered was 'Mmmm...
I've got this project that's got some .c files in it.... I get a precompiled
header error when I try to compile it now. I need it to be fast but I'll go
for anything that seems to be the flavour of the month/year/decade, how
should I proceed ? "
I also don't really like people that point to a web resource not authored by
them that isn't at all relevant to the question been asked.

But I'm sure you're good at what you do and you mean well, and you are a
fellow programmer and did take the bother of answering at all, so I thank
you for that and hope you don't take offence.
 
Back
Top