error - Undeclared identifier 'TRUE' after moving

[vedro-compota]

hm.....as i can judge by that fact that it's impossible to add  heder file (.h) to Pelles C  project ("add file to project" option ) -  so it seems to be right  to  conclude that header is not build by compiler separately  - so why it's not right to include (for example) common using <stdio.h> in all headers (with guards) - if this including is needed in all sources  - but not in the header itself (as in your example)?

[CommonTater]

You don't have to --and can't-- add headers to the project... put them in your files. 

The include files section of the tree is just a convenience for opening the files... POIDE parses them out of the source files for you.

It's done that way so that if you move the source to another compiler, your project will still build normally.

And... a compiler NEVER bulds header files... they're included into the source by the compiler as plain text when it reads the .c file.
 

[vedro-compota]

It's done that way so that if you move the source to another compiler, your project will still build normally.

ok . purpose is clear )

one more moment -
if we use #ifdef guard - we'll get only one header including in each source file (compiler builds it separately)  - but what about the final executed file  - will it be free from the several same including ?

[CommonTater]

It's done that way so that if you move the source to another compiler, your project will still build normally.

ok . purpose is clear )

one more moment -
if we use #ifdef guard - we'll get only one header including in each source file (compiler builds it separately)  - but what about the final executed file  - will it be free from the several same including ?

First it's not #ifdef ... look closely... it's #ifndef  ... if not defined.

Absolutely none of the text from source code makes it to the executable...  The executable is pure machine code, so that's not an issue.

[vedro-compota]

mechanism of compiler actions  is not clear for me  - if we in any vatiant won't have same parts of including in final .exe - why we need  #ifndef (yes - "if not") guards ?
you help me so much - but to don't spend your time - i understand know that i need to read something about compiler and preprocessor actions - some article may be....

to have one including in one source   - we simply should  once write   =

Code: [Select]

#include something.h
so - guards is needed for the final - result file.....as I  know think by my not so clever head without deep knowledge.....))

[CommonTater]

mechanism of compiler actions  is not clear for me  - if we in any vatiant won't have same parts of including in final .exe - why we need  #ifndef (yes - "if not") guards ?
you help me so much - but to don't spend your time - i understand know that i need to read something about compiler and preprocessor actions - some article may be....

to have one including in one source   - we simply should  once write   =

Code: [Select]

#include something.h
so - guards is needed for the final - result file.....as I  know think by my not so clever head without deep knowledge.....))

The compiler converts textual source code into machine code in objects... each object cones from one source page.
At this point there is no more source code.  It's all machine language.

The linker then comes along and combines ojects to make the executable.
Absolutely none of the textual source code makes it into the executable.

You need the include guards so that a header file, included in another header file... per my example... is not read twice causing the compiler to think you're redefining stuff you've already defined.

The best way for you to "get it"... is to open a .obj and a .exe file in POIDE and have a look.
 

 

[vedro-compota]

is not read twice

i'll continie your words  - .....so if such header (as in your example   - with #ifndef guard) was readed once  in one file - it won't be readed during building of  another one - or it won't be read more within the framework of each sourse file ? as i understand from your words - only second variant.

What is POIDE ? Google don't know in english - and i'm too))

[CommonTater]

POIDE is the editor you use with Pelles C...

No... include guards allow each header to be read once per source file.
 
Here's an example...
B_lanenum.h

Code: [Select]

// Local Area Network Enumerator
#ifndef B_NETENUM_H
#define B_NETENUM_H
#define UNICODE
#define _UNICODE
#include <windows.h>
And
B_listview.c

Code: [Select]

// List View Functions
#define WIN32_DEFAULT_LIBS
#define UNICODE
#define _UNICODE
// winapi
#include <windows.h>
#include <commctrl.h>
#include <shlwapi.h>
// C-99
#include <wchar.h>
// project
#include "B_Main.h"
#include "B_LanEnum.h"
Notice how both files include windows.h ... and the first file is included in the second one?
Without include guards windows.h would be read twice... But since it has include guards (go ahead, open it in the editor and look) it only gets processed once... preventing duplicate definition errors.
 
The separate source files you create and compile are just that... separate files. They are compiled individually and their content goes into individual .obj files (look in the output folder of your project).  These files remain completely separate entities until the final linking stage merges them into an executable file.
 
 
 




 

[vedro-compota]

These files remain completely separate entities until the final linking stage merges them into an executable file.

so finally  - linker only combine all .obj  into one .exe ? (without removing same functions from other .obj files )

[CommonTater]

These files remain completely separate entities until the final linking stage merges them into an executable file.

so finally  - linker only combine all .obj  into one .exe ? (without removing same functions from other .obj files )

Nope... the linker works on an object level... when you compile a source page, that creates 1 object.  The entire object is then linked into the executable with the only change being to connect up the remaining function calls. 

POLINK will not remove unused or duplicated code... that's your job, before compiling.

[AlexN]

ok . as I see - it's possible to use #include in header itself =

Code: [Select]

#ifndef  TASK1_H
#define  TASK1_H

#include "comlib.h"
int task1standard(void);
int task1custom(void);
int testme(void);

#endif

Or if you only use Pelles C you can use:

Code: [Select]

#pragma onceLook in the help for more information.

[CommonTater]

ok . as I see - it's possible to use #include in header itself =

Code: [Select]

#ifndef  TASK1_H
#define  TASK1_H

#include "comlib.h"
int task1standard(void);
int task1custom(void);
int testme(void);

#endif

Or if you only use Pelles C you can use:

Code: [Select]

#pragma onceLook in the help for more information.

Excellent suggestion Alex...

You can also make it portable like this...

Code: [Select]

#ifdef __POCC__
#pragma once
#endif
With your usual include guards below right below it.