compile order ms vs c++

[Onno Garms]

And what happens if variable on enum type is used, mem will be allocated (on local scope?), or not ?

Depends on what use you have in mind.

Code: Select all

enum X {x=0};
int main ()
{
  X var = x;
  return var;
}

will allocate memory for var, if not optimized away.

Code: Select all

enum X {X=0};
int main ()
{
  if (x)
    return 0;
  else
    return 1;
}

will be translated into

Code: Select all

if (0)

so no allocation is necessary.

Code: Select all

At the end i am only interested, of how the compile ordering can be changed in visual studio ?

This is a strange desire IMHO. Nonetheless
- Did you already ask Google? There are many results that might be related to that, e.g. http://en.csharp-online.net/Visual_Stud ... ld_Manager
but I don't have the time to check them for you.
- Other forums might have better answers for you as this is not related to chess programming.
- Did you already try to close VStudio and change the order in the .vcproj file manually with a text editor? Does VStudio really compile in alphabetical order or does it compile in the order in the vcproj file which happens to be alphabetical?
- I think Visual Studio also has something like makefiles that can be used optionally. In a standard makefile, it would be easy to enforce compilation order by making modulex.obj depend on desperado.obj.
- Put desperado.cpp in a separate project and create desperado.lib. Make your main project depend on the desperado.lib-project. This will enforce desperado.cpp to be compiled before all files in your main project, but I'm not sure if VStudio then still remembers the constants.

[Onno Garms]

- if(p==wp) -> wp isnt a variable it is a constant (normally here the compiler should put in the value, and if so this statement also dont has to work)

If the compiler cannot see the value of the constant as in your case, it cannot put in the value. All it can do is to make the assembly access the memory to retrieve the value at runtime. Knowing that the value is constant does not help, the assembly has to do the same like if it was variable.

- the compile order "should" not matter, but it does.

Maybe, but you should not write your code in a way that relies on that.

- does extern declared data is really forgotten after compiled a xxx.cpp?

In gcc definitely yes. You start a new process for each xxx.cpp and there is no non-transient cache on the disk or so. I don't know the interna of the M$ compiler.

And one more question, now a discussion is running on that topic.
Anywhere at any time there will be memory allocated for a enum-variable
or not ?

See my previous post.

Each standard datatype has maximal modulscope except for "extern" declared data.(so there would be different allocations for different moduls ?)

extern variables exist only once in memory. All modules access the same address. How else should non const extern variables work?

[Desperado]

thx,onno!

well it is not only because the topic we discussed here, i am just
interested how in the jungle-world of microsoft something simple
like the compile-order can be managed . Perhaps i will never
use it. and perhaps there comes a time it is necessary to know.

Of course the "enum-style" is easy way, and there are other simple and propper ways that will work fine. That wasnt the point.

The problem at the end is, that the compiler doesnt detect,remembers or whatever an extern declared constant, apart from compile state.
(This was/is my dissapointment, so it seems the compiler is really forgetful ) thx

[Desperado]

thx for all replies, nxt topic will be more chess-programming topic ...

[Aleks Peshkov]

You unoptimized trivial constants to global unmodified variables using tricky macros and blame Microsoft.

There is now "compiler state". C/C++ designed to compiler each source file independently.

[wgarvin]

thx,onno!

well it is not only because the topic we discussed here, i am just
interested how in the jungle-world of microsoft something simple
like the compile-order can be managed . Perhaps i will never
use it. and perhaps there comes a time it is necessary to know.

Of course the "enum-style" is easy way, and there are other simple and propper ways that will work fine. That wasnt the point.

The problem at the end is, that the compiler doesnt detect,remembers or whatever an extern declared constant, apart from compile state.
(This was/is my dissapointment, so it seems the compiler is really forgetful ) thx

There's no legitimate reason to want to do what you are asking for.

C and C++ use separately-compiled modules. Everything needed to compile a module (declarations, definitions, etc.) must be #included (or made available from the command line with something like -Dfoo=bar). It doesn't matter what order you compile them in, that doesn't affect anything. If it did, it would be a compiler bug!

I can only think of two exceptions to this rule, and probably neither of them applies to your situation. (1) some compilers support a feature called "pre-compiled header files" and if they do, they might require the precompile module to be compiled before all of the other ones. (Microsoft's compiler needs this, but most of the time you don't need to know anything about it because it handles it for you automatically). (2) if you are trying to manipulate the object files yourself in some fashion, e.g. to extract debug information from them or symbol names, and embed them in another source file and then compile that. This is very platform- and compiler-specific, so you shouldn't do it unless you absolutely have to. Almost nobody actually needs to do this kind of thing.


There are several "acceptable" ways to share constants between modules in C and C++... like some of the other replies, I would suggest using enums in a header file, which you then #include in each of the modules (or else #include it inside another header file which is itself #included in the modules).

[Harald]

once again, more simply...

Code: Select all

//----------------------------------------------------------
MODUL1:

//============DESPERADO.H=======

#define PIECE_H

#include "piece.h"

//==============================

//----------------------------------------------------------

MODUL2:

//===========ANY_OTHER_MODUL.H==

#include "piece.h"

//==============================

//----------------------------------------------------------

STANDALONE HEADER:

//===========PIECE.H============

#ifndef PIECE_DEC

	#define PIECE_DEC

	extern const UI_08 c_val; //no definition
#endif



#ifdef PIECE_H

	extern const UI_08 c_val = 0; //definition

#endif

//==============================

//----------------------------------------------------------

so pls marco, let me know the dubious tricks here (i simplified a little bit) ?

You should look up a C/C++ book to learn more about the right use
of header files and implementation files. The bad news is that many books
do not provide you with very much information about this topic.
I assume you are not very experienced with C/C++ programming.
Please do not be angry if some of my advices are boring.

- Every module (*.h header file or *.c, *.cpp implementation file) should
include the declarations of everything it needs, and that is also needed
in other modules, by including the right header files. In some rare cases
it is also allowed to repeat the declaration.

- Header files should not include any definition.

- Header files shall not contain any using namespace xxx, but this is not
the problem in your case.

- Header files should use include guards around them to avoid parsing
them again and again. Use
#ifndef HEADERNAME_H
#define HEADERNAME_H
...
#endif // HEADERNAME_H

- Implementation (definitions) of constants, variables and functions
should be placed in the c/cpp files. Do not forget to tell the compiler that
you need all modules.

- The C/C++ files should include the related header files.

In your case:

Code: Select all

//===========PIECE.H============

#ifndef PIECE_H
#define PIECE_H
#include "the_header_that_contains_UI_08.h"
extern const UI_08 c_val; // declaration
// other declarations of piece here.
#endif // PIECE_H

//==============================


//===========PIECE.CPP============

#include "piece.h"
#include "the_header_that_contains_UI_08.h"   // optional but i would do it.
const UI_08 c_val = 0; // definition
// other definitions of piece here.

//==============================


//============DESPERADO.H=======

#ifndef DESPERADO_H
#define DESPERADO_H
#include "piece.h"      // if needed
// other declarations of desperado here.
#endif // DESPERADO_H

//==============================


//============DESPERADO.CPP=======

#include "desperado.h"
#include "piece.h"      // if needed
// other definitions of desperado here.

//==============================


//===========ANY_OTHER_MODUL.H==

#ifndef ANY_OTHER_MODUL_H
#define ANY_OTHER_MODUL_H
#include "piece.h"      // if needed
#include "desperado.h"  // if needed
// other declarations of any_other_module here.
#endif // ANY_OTHER_MODUL_H

//==============================

//===========ANY_OTHER_MODUL.CPP==

#include "any_other_module.h"
#include "piece.h"      // if needed
#include "desperado.h"  // if needed
// other definitions of any_other_module here.

//==============================

Hope that helps. It is important to have this code structure right. Do not
use dirty tricks with #defines around #includes and #ifdefs inside headers.

If you have restructured your code it is also easier to give you more help
since now you use a typical structure that everybody can understand.

Harald

[Bo Persson]

- if(p==wp) -> wp isnt a variable it is a constant (normally here the compiler should put in the value, and if so this statement also dont has to work)

If the compiler cannot see the value of the constant as in your case, it cannot put in the value. All it can do is to make the assembly access the memory to retrieve the value at runtime. Knowing that the value is constant does not help, the assembly has to do the same like if it was variable.

In this particular case, the VC compiler has a "whole program optimization" mode, where it actually CAN see constants defined in another module. The compilation is finalized AFTER the linker has collected all modules in the program!

For a switch statement there is a language requirement that the case labels must be known when compiling the statement, so the compiler cannot use this feature there.


On the whole, it is generally futile to try to trick the compiler into producing better code by doing some "smart" transformations of the source code. The best idea is to express your ideas as cleanly as possible, and let the compiler do the optimizations. It has a much better chance of doing that if your code is "normal", and not containing any unusual tricks.

You can think of it this way: At least some of the compiler writers are PhDs who have done this full time, for decades. How easy is it for us to come up with some small trick that they have missed? Trust your compiler!

[Bo Persson]

hi Onno,

enum cannot get the "extern" statement...

So it would be necessary to put the enum-statement in each header, or
to have one header with the enum(constants), which then is included by each modul(like Robert mentioned).

now for my explanation enum and constants are handled equal...

That would mean, that each modul creates its own instances of the
constants(enums), so 5 moduls 5xwp= 5byte (not much,but not necessary !, it is a principal thing now).

This isn't so.

If you have an enum or a constant with a fixed value, it works exactly the same as if you had the number inside your code.

For example:

const int back_rank = 8;

if (rank == back_rank)
// some code


works EXACTLY the same as if you had written

if (rank == 8)
// some code


Why do you think the compiler would store the number 8 in an additional place, just because you have given it a name? It doesn't!


In C++ (somewhat unlike C), integer-like constants that are initialized only by other constants ("an integral constant expression") can be put in header files at no extra cost. In C++ you get a new constant (with an identical value) in each compilation unit, but as they are not really stored, that doesn't matter. Rather it improves their usefulness, as you can now use them in your switch statement!

[mcostalba]

Hi Michael,

you already got plenty of high valuable answers, so I will not repeat them.

The only thing I would like to further highlight is that the complier order SHOULD (or I would say MUST) not matter.

If and when it does it is ONLY because of poor programming, so you should handle to rewrite your code in a way that compiler order does not matter.

A tipical case in C++ is initalization of global (or static) variables. In this case C++ standard states that NO assumption should be made by the programmer on the initialization order of such a variables in different transltion units.

This is somewhat a tricky subject and you will find plenty of literature on this on the net.

The bottom line is that C++ designers choose to not give the programmer a way to specify the compilation order, but instead to give the programmer the possibility to write code in such a way that translation unit's compilation order does not matter anymore.

This is more then a single case recipe, it is a design philosphy that it is important to have clear: anytime you need to tweak the compilation order then it means there is something bad (or at least very tricky and not portable) with you code.

Marco