2 questions

[pavel989]

does the order of the headers matter?

and in reference to pointers and dynamic memory, that is ram, right?

[Salem]

1. Sometimes it does. Though standard headers tend not to care so much.
2. Mostly true. You can point to constants in ROM, but dynamic memory (as the name suggests) is RAM.

[pavel989]

how do you know what the order is? for pointers?
and where would rom be located? never really thought about it. like hd? or what?

[CoolGamer48]

The code in header files is executed in the order you #include them. So if the code file1.h needs to be executed before the code in file2.h (for some reason), then they must be #included in that order.

[pavel989]

well yea but like is there a list of the necessary order?

[13L4D3]

well yea but like is there a list of the necessary order?

As CoolGamer48 said

The code in header files is executed in the order you #include them. So if the code file1.h needs to be executed before the code in file2.h (for some reason), then they must be #included in that order.

this is the most obvious answer bcoz the need of code that has to executed according to your coding/program decides the order in which header files are to be placed. As coolgamer already gave u the example of file1.h and file2.h the rest u can place relevantly.
eg.

#include <iostream>
#include <file1.h>
#include "crc.h"
#include <file2.h>
#include <conio.h>

etc.........etc...............;)

[Salem]

> how do you know what the order is? for pointers?
If the order is right, it compiles.
If the order is wrong, then you'll get "missing declaration" type errors when you compile.

> So if the code file1.h needs to be executed before the code in file2.h (for some reason)
But compiling is not executing. #include is all about declarations, not program execution order. In other words, this works.

#include "func1.h"
#include "func2.h"
int main ( ) {
  func2();
  func1();
}

> well yea but like is there a list of the necessary order?
Read the manual pages for the libraries you're using. If they have multiple headers, they should tell you the order.

> and where would rom be located?
An example would be a chip on your motherboard with "BIOS" written on it. Each CPU needs a small amount of ROM to get things going from a power up. A really simple BIOS in a PC for example only needs to load the boot sector from disk and then jump to the loaded RAM location.
But there are many varieties of persistent memory.
http://en.wikipedia.org/wiki/Non-volatile_memory

[CoolGamer48]

> So if the code file1.h needs to be executed before the code in file2.h (for some reason)
But compiling is not executing. #include is all about declarations, not program execution order. In other words, this works.

#include "func1.h"
#include "func2.h"
int main ( ) {
  func2();
  func1();
}

Ya - I thought I had used the wrong word.

[pavel989]

well i tried to do something like that with the standard headers, and wouldn't compile. And when i changed the order, it worked. also is it the same for all OS's, i wanna port my apps to linux too, and include python.

[CoolGamer48]

well i tried to do something like that with the standard headers, and wouldn't compile. And when i changed the order, it worked. also is it the same for all OS's, i wanna port my apps to linux too, and include python.

What errors did you get? What was the wrong order and what was the order that worked?

[Salem]

So 10 posts in, it becomes an actual problem rather than something theoretical.
Is it going to be another 10 posts before we see an actual example and some actual error messages?

Not the whole code, just the headers (and the error message(s) of course).

[pavel989]

What errors did you get? What was the wrong order and what was the order that worked?

this is a very simply code, im just learning about pointers and stuff, first time working with C++:

#include "iostream"
#include "stdafx.h"

int main()
{	
  float fl=3.14;
  int _addr;
  std::cout << "fl's address=" << (unsigned int) &fl << std::endl;
  std::cout << fl<<"\n";
  _addr=(unsigned int) &fl;
  std::cout << _addr <<std::endl;
  fl= 5.0;
	
  std::cout << * (float*) _addr;
  std::cin.get();

   return 0;
}

--failed

but if u switch the headers, it works. i wasn't sure why

[Salem]

OIC, the header in question is "stdafx.h".
Well, that's a completely different story.

The easy thing to do is simply delete that line from your source code, and then goto your project settings and turn OFF precompiled headers.

But if you're going to use precompiled headers, then EVERY source file needs to look like this

/* Every source file needs these headers */
#include <iostream>  // just an example
/* The precompiled header magic marker */
#include "stdafx.h"
/* any header files unique to a source file */
#include "myheader.h"

The point being that if every source includes the same thing before stdafx.h, then the compiler only has to do it once (hence, pre-compiled headers!). This (apparently) is a worthwhile performance improvement, but it really appears far too often as a question to be that useful IMO.

It should be off by default, because by the time it's useful, you should know what you're doing. For everyone else (newbies and the people who help them), it's just annoying.

Oh, and another reason for getting rid of it - you want to use Linux at some point.
It's only the microsoft compilers which use it AFAIK.

[Nick Evan]

But if you're going to use precompiled headers, then EVERY source file needs to look like this

/* Every source file needs these headers */
#include <iostream>  // just an example
/* The precompiled header magic marker */
#include "stdafx.h"
/* any header files unique to a source file */
#include "myheader.h"

You're actually wrong. The pre-compiled header should be the VERY FIRST line in every source file, else VS will start complaining that it can't find the pre-compiled header. So every source-file should look like this:

#include "stdafx.h" // very first line is the pre-comp-header
#include <iostream>  // just an example

/* any header files unique to a source file */
#include "myheader.h"

[Salem]

Only if you intend to turn the damn thing off by making sure there's nothing to accumulate.

[pavel989]

I've heard of pre-compiled headers before. i thought that it was like, system standard headers.

But now it makes a bit more sense. so i guess ill turn that off in VS. but y is stdafx.h so special?