welche Reihenfolge bei #includes verwendet ihr?

Zuerst die eigenen Header und dann die Standard Header:

// Foo.cpp
#include "Foo.h"
#include "MyHeader.h"

#include <string>

Oder erst die Standard Header und dann die eigenen:

// Foo.cpp
#include <string>

#include "Foo.h"
#include "MyHeader.h"

Wie macht man das am besten?

0x0ERROR

Reasoning:
a) Jedes halbwegs klare und einfache System ist besser als gar kein System
b) Diese Reihenfolge unterstützt das Finden von fehlenden #include Anweisungen in eigenen Headers
c) Die Begründung von Mechanics ist auch gut

Standardlibrary gefolgt von externen Libraries gefolgt von eigenen. Header einer Gruppe alphabetisch.

+1.

Mechanics schrieb:

Die eigenen sind meist die interessanten.

Genau deshalb packt man sie ja nach unten, dann sind sie näher an dem Code an dem man arbeitet.

Eigenes Projekt, dann eigene Libs, dann Thirdparty Libs, dann Windows Zeugs, dann STL/... .
Also grob: von speziell/nicht-standard zu generisch/standard sortiert.

+1

Eigenes Projekt, dann eigene Libs, dann Thirdparty Libs, dann Windows Zeugs, dann STL/... .
Also grob: von speziell/nicht-standard zu generisch/standard sortiert.

Denn cooky451 hat hier nicht nur wegen dem Code recht, sondern es gibt ja auch noch die Präprozessordirektiven.
Die will ich auch nicht zerstückeln und da in manchen Headers auch Präprozessordirektiven drinstehen ist die einzige richtige Vorgehensweise die Folgende:

Header für das System, POSIX, Windows usw.
Header für die STL
Header für externe 3rd Party Libs
Header für das eigene Zeugs
Präprozessordirektiven
Quellcode

hustbaer und mechanics machen es falsch.

Denn cooky451 hat hier nicht nur wegen dem Code recht, sondern es gibt ja auch noch die Präprozessordirektiven.
Die will ich auch nicht zerstückeln und da in manchen Headers auch Präprozessordirektiven drinstehen ist die einzige richtige Vorgehensweise die Folgende:

Header für das System, POSIX, Windows usw.
Header für die STL
Header für externe 3rd Party Libs
Header für das eigene Zeugs
Präprozessordirektiven
Quellcode

Eigenes Projekt, dann eigene Libs, dann Thirdparty Libs, dann Windows Zeugs, dann STL/... .

Genauso mache ich es auch.

Ich hab eigentlich gar nie gross darüber nachgedacht, schien mir so am intuitivsten

sondern es gibt ja auch noch die Präprozessordirektiven.

Echt?

Also:
In der useful.h wird u.a. eine Funktion

double rnd_boxMuller(double sigma);

deklariert. Diese wird in der matrix.h verwendet. In der matrix.h wird die Klasse Matrix<T> deklariert. Außerderdem gibt es in der useful.h folgende Funktionsdeklaration:

Matrix<double> randomDoubleMatrix(int d1 = 5, int d2 = 5, double min = -1, double max = 1);

Wenn in beiden Headern nun die includes jeweils nach ganz oben schreibe, ergibt sich folgendes Problem: useful.h inkludiert matrix.h, der Kompiler trifft (in der matrix.h) auf den rnd_boxMuller-Aufruf und weiß damit nichts anzufangen (da ja der Funktionsname noch nicht deklariert wurde). Meine Lösung war, in der useful.h zunächst die "rnd_boxMuller" zu deklarieren, dann matrix.h zu inkludieren und anschließend die randomDoubleMatrix-Funktion zu deklarieren. Schön finde ich diese Lösung nicht.

Wie macht man das richtig?

// useful.h

// Deklaration
template <typename T>
class Matrix;

double         rnd_boxMuller(double sigma);
Matrix<double> randomDoubleMatrix(int d1 = 5, int d2 = 5, double min = -1, double max = 1);

// matrix.h
#include "useful.h"

// Definition
template <typename T>
class Matrix
{
    // ...
};

Und mach in Zukunft einen neuen Thread auf, dein Thema hat nichts mit dem hier zu tun!

Unfehlbarkeitscoder schrieb:

sondern es gibt ja auch noch die Präprozessordirektiven.

Echt?

Guckst du hier:

http://www.cpp-tutor.de/cpp/le08/include.html

Wenn der Fehler dagegen in meinem Code angezeigt wird, dann muss ich erstmal ausschliessen dass der Fehler wirklich dort ist wo er angezeigt wird, bevor ich anfange mir Dinge anzusehen die davor kommen.