change log for rtems (2011-02-17)

[Peter Dufault]

On Feb 21, 2011, at 7:40 , Sebastian Huber wrote:

> The Google C++ Style Guide has a nice rule for header files:
> 
> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Names_and_Order_of_Includes#Names_and_Order_of_Includes
My comments are "...":

#include "foo/public/fooserver.h"  // Preferred location.
... I always put this at the top of non-system public includes, out of alphabetical order.
... However, putting it at the top enforces Ralf's statement that all public headers are stand-alone, so it's a good idea.
... I do assume unistd.h is in scope, though, see below.

#include <sys/types.h>
#include <unistd.h>
... I consider unistd.h to be special and I always put <unistd.h> first.
... By definition it defines much of what you want in sys/types.
... On some systems its behavior can be tweaked by defining something before unistd.h, so I always put it first. 

#include <hash_map>
#include <vector>

#include "base/basictypes.h"
#include "base/commandlineflags.h"
#include "foo/public/bar.h"

... End of my comments

I almost agree with this, but I still like <unistd.h> first and in every program unit.  Consider that "foo/public/fooserver.h" does something nasty:

#ifndef _FOO_PUBLIC_FOOSERVER_H_
#define _FOO_PUBLIC_FOOSERVER_H_
#define __UNISTD_DOES_SOMETHING_UNEXPECTED 20110221
#include <unistd.h>
...
#endif /* _FOO_PUBLIC_FOOSERVER_H_ */

Yes, you'll maybe get a __UNISTD_DOES_SOMETHING_UNEXPECTED redefine warning or something.  Maybe it isn't important, I'm just used to it.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering