[vietjtnguyen]

Quick typo under OMG-CODEORG-2:

    #pragma once

    #ifdef __cpluspus // <-- should be __cplusplus
    extern "C" {
    #endif

    #include "api_types.h"

    // ...

    #ifdef __cplusplus
    }
    #endif

Can't say I'm a fan of OMG-CODEORG-3, however, it sounds like compilation time is a key metric for them.. I prefer a John Lakos style "physical components" set up which emulates a type-as-module inclusion style. At least OMG-CODEORG-3 clearly states that include order becomes important as a result.

[niklasgray]

Thank you for noticing the typo.

I wasn't sure about OMG-CODEORG-3 in the beginning either, but after using it for over a year and a half now, I'm strongly in favor.

The only situation where inclusion order matters is when there's (pseudo-) inheritance, and we don't use that a lot, so in practice it is not a big issue.

Actually, I've had MORE problems with inclusion order in previous projects that didn't use this rule. What would happen is that some header (included from some other header, included from some other header) would include <windows.h>. Then some other header (from some other header, etc) would include something that conflicts with the (many) #defines in <windows.h>.

Trying to sort out this mess was always a PITA. First you have to figure out where the include is coming from. Then you have to figure out how to fiddle with the include order and the defines to fix it. When using OMG-CODEORG-3, this is pretty simple, because all the includes happen in the .c file, so it is easy to rearrange them to fix include order problems. Not so easy when the includes are scattered all over multiple .h files.

Another big win with OMG-CODEORG-3 is that you see exactly what other pieces of code the .c file is dependent on, you don't need to follow multiple header chains to figure it out. You also only depend on the things you really need which is nice. In projects with liberal header inclusion, dependencies can grow as O(n^2) which increases complexity.

[midnightclubbed]

Agree, CODEORG-3 adds a bunch of pain. There's a reason other languages don't have headers but since C programmers have to live with them can't I just include the single relevant header and move on with writing my code. Yes there is a shared cost to that (compile time) but '#pragma once' is well supported and futzing with header order is a non trivial time-sink too.

On the same lines the template 'cute tricks' are where you get your performance, stability and readability from C++. I definitely agree that you should drop into assembly to see what the compiler is doing with your code but that can and should apply to heavily templated code too.

[bobdobbs666]

Pragma once only prevents double inclusion within the translation unit.

On large projects bad header hygiene can cause significant compilation overhead.