ich hoffe ich bin hier richtig, aber meiner Meinung nach hat mein Fehler nichts mit Qt zu tun... Falls doch bitte ich um Entschuldigung und Verschiebung...

Zu meinem Problem, ich habe eine kleine Qt Anwendung aus bis jetzt 3 Fenstern gemacht, die ich alle über ein Signal/Slot Konzept öffne und schließe.
Folglich habe ich den Slot zusammen mit einem Zeiger auf die andere Klasse in der Klasse deklariert. Im Konstruktor initialisiere ich dann den Zeiger und dort ist auch mein Problem... Sobald ich namlich den Zeiger nicht mehr ausklammere (siehe unten) bekomme ich kein Fenster mehr, obwohl das Programm im Hintergrund laut Debugger läuft, oder habe ich da was falsch gemacht? Aber normalerweise kommt doch bei Fehlern ein PopUp... Ich habe keinen Schimmer woran das liegt.

registration.h
[cpp]class Registration : public QDialog
{
          ...
    class Check *ptr;
    class Startfenster *ptr1;
};[/cpp]

registration.cpp
[cpp]Registration::Registration(QWidget *parent) :
    QDialog(parent),
    ui(new Ui::Registration)
{
           ...
    ptr = new Check(); //aber warum funktioniert es hier?
    ptr1 = new Startfenster(); //hier ist der Fehler, denn beim Ausklammern funktioniert es
          ...
}[/cpp]

check.h
[cpp]class Check : public QDialog
{
        ...
    class Registration *ptr2;
};[/cpp]

check.cpp
[cpp]Check::Check(QWidget *parent) :
    QDialog(parent),
    ui(new Ui::Check)
{
      ...
    ptr2 = new Registration(); //hier ist der selbe Fehler nochmal, denn beim Ausklammern funktioniert es}[/cpp]

}
Die Zeiger brauche ich für die Slots und das connecten zwischen den Ui´s... - ich kann sie also nicht weglassen...
Desweiteren dachte ich dann, dass es ganz schlau wäre ich sie dann im Destruktor delete?

Bitte um Hilfe und es würde mich sehr freuen, wenn ihr mir auch andere Fehler mitteilen könnt, die euch auffallen, da ich nämlich keinen Ansprechpartner habe und alles aus Google und Büchern lerne.
Danke im Vorraus

PS: Das ist mein erster Beitrag, ich hoffe das passt so - und nochmal sorry wegen falschem Forum

Kann das sein?

Registration::Registration()
->
ptr = new Check();

.....

Check::Check()
->
    ptr2 = new Registration();

Die rufen sich dann immer wieder gegenseitig auf, bis alles zerberstet.
Wird einer von beiden ausgeklammert, gehts natürlich.

Lösung:
Verlager das "new"'n der beiden Objekte ("new Registration()" und "new Check()") ganz woanders hin, un bau die Klassen so um, dass sie im Konstruktor gleich einen Zeiger zur jeweils anderen Instanz übergeben bekommen.
brauchst code dafür?

class Registration *ptr;

mal ein

Registration *ptr;

das class lässt man in dem fall weg.

1. Sobald ich die class ´s in den "h."´s wegmache kommt folge Fehlermeldung: ISO C++ forbids declaration of 'Registration' with no type; expected ';' before '*' toke

2. weiß ich nicht wohin ich das new umbauen soll, denn wir befinden uns ja im Konstruktor also bleibt nur main und Klasse selbst
2.1 Klasse selbst, bekomm ich lauter Fehlermeldungen:
..\ProjektPD Sicherung\/registration.h:32: error: 'new' cannot appear in a constant-expression
..\ProjektPD Sicherung\/registration.h:32: error: ISO C++ forbids declaration of 'ptr' with no type
..\ProjektPD Sicherung\/registration.h:32: error: ISO C++ forbids initialization of member 'ptr'
..\ProjektPD Sicherung\/registration.h:32: error: making 'ptr' static
..\ProjektPD Sicherung\/registration.h:32: error: ISO C++ forbids in-class initialization of non-const static member 'ptr'
..\ProjektPD Sicherung\/registration.h:32: error: declaration of 'int Registration::ptr'
..\ProjektPD Sicherung\/registration.h:29: error: conflicts with previous declaration 'Check* Registration::ptr'
- da mach ich definitiv was ganz falsch

2.2 oder in die main und dann gehen alle connects (weil ich sie im Konstruktor habe) und slots nicht mehr, habe ich desweiteren schon vor einer Woche ohne Erfolg ausprobiert

3. Meinst du hiermit: " un bau die Klassen so um, dass sie im Konstruktor gleich einen Zeiger zur jeweils anderen Instanz übergeben bekommen. ", dass ich in einer Klasse eine Instanz auf die andere machen soll und darauf einen Zeiger?
Falls ja macht man das initialisieren bei new ja dann mit dieser Klammer "()", da QtKlassen aber für gewöhnlich einen default Zeiger auf 0 haben greif ich dann immer auf den zu und es funktioniert wieder nich

Wenn ich alles posten soll, dann sagt es aber ich wollte niemanden verschrecken und es wie in der Anleitung machen...

@manni66: Ich hab dich am Anfang leider falsch verstanden,nämlich dass ich nicht soviel ... machen soll und mein Posting gefälligst besser formulieren soll

Nun heute geht halt alles schief

zu 1: Such mal nach "forward-declaration" und versuch zu verstehen, was das ist.
zu 2: "Klasse selbst" wäre schon der Konstruktor. der Konstruktor gehört zur Klasse.
zu 3: puhhhh. grad echt keine ahnung, wo ich da anfangen soll. hab auch nicht super krass viel ahnung von qt.
mein satz: "bau die Klassen so um, dass sie im Konstruktor gleich einen Zeiger zur jeweils anderen Instanz übergeben bekommen." war streng genommen aber auch falsch, fällt mir grad auf.
ich glaub, du brauchst einfach 2 neue methoden:

Registration::setCheckObject(Check *inCheck)
{
   this->ptr = inCheck;
}
...
Check::setRegistrationObject(Registration *inRegistration)
{
   this->ptr2 = inRegistration;
}

weisst du was ich meine?

startfenster.h
[cpp]#ifndef STARTFENSTER_H
#define STARTFENSTER_H

#include <QDialog>
#include "ui_startfenster.h"
#include "registration.h"

class Startfenster : public QDialog
{
    Q_OBJECT

public:
    explicit Startfenster(QWidget *parent = 0);
    ~Startfenster();

private slots:
    void setUpR();

private:
    Ui::Startfenster *ui;
    class Registration *ptr;
};

#endif // STARTFENSTER_H[/cpp]

registration.h
[cpp]#ifndef REGISTRATION_H
#define REGISTRATION_H

#include <QDialog>
#include "ui_registration.h"
#include "check.h"
#include "startfenster.h"

class Registration : public QDialog
{
    Q_OBJECT

    friend class Startfenster;
    friend class Check;

public:
    explicit Registration(class QWidget *parent = 0);
    ~Registration();

private slots:
    void setUpS();
    void setUpC();

private:
    Ui::Registration *ui;

    class Check *ptr;
    class Startfenster *ptr1;
};

#endif // REGISTRATION_H[/cpp]

check.h
[cpp]#ifndef CHECK_H
#define CHECK_H

#include <QDialog>
#include "ui_check.h"
#include "registration.h"

class Check : public QDialog
{
    Q_OBJECT

    friend class Registration;

public:
    explicit Check(class QWidget *parent = 0);
    ~Check();

private: signals:
    void deliver();

private slots:
    void setUpR();

private:
    Ui::Check *ui;

    class Registration *ptr2;
};

#endif // CHECK_H
[/cpp]

startfenster.cpp
[cpp]#include "startfenster.h"
#include "ui_startfenster.h"

Startfenster::Startfenster(QWidget *parent) :
    QDialog(parent),
    ui(new Ui::Startfenster)
{
    ui->setupUi(this);

    ptr = new Registration();

    connect(ui->Registration, SIGNAL(clicked()), this, SLOT(setUpR()));
    connect(ui->Nachname, SIGNAL(textEdited(QString)), ptr->ui->Nachname, SLOT(setText(QString)));
}

Startfenster::~Startfenster()
{
    delete ui;
    delete ptr;
}

void Startfenster::setUpR()
{
    ptr->show();
    ptr->raise();
    ptr->activateWindow();
}
[/cpp]

registration.cpp
[cpp]#include "registration.h"
#include "ui_registration.h"

Registration::Registration(QWidget *parent) :
    QDialog(parent),
    ui(new Ui::Registration)
{
    ui->setupUi(this);

    ptr = new Check();
    //ptr1 = new Startfenster();

    connect(ui->Zurueck, SIGNAL(clicked()), this, SLOT(setUpS()));
    connect(ui->Weiter, SIGNAL(clicked()), this, SLOT(setUpC()));

    //Werte übergeben
    connect(ui->Vorname, SIGNAL(textChanged(QString)), ptr->ui->Vorname, SLOT(setText(QString)));
    connect(ui->Nachname, SIGNAL(textChanged(QString)), ptr->ui->Nachname, SLOT(setText(QString)));
    //connect(ui->dateEdit, SIGNAL(), ptr->ui->Geburtsdatum, SLOT(setText(QString))); //muss ich mir erst noch was überlegen
    connect(ui->Geburtsort, SIGNAL(textChanged(QString)), ptr->ui->Geburtsort, SLOT(setText(QString)));
    connect(ui->Geschlecht, SIGNAL(currentIndexChanged(QString)), ptr->ui->Geschlecht, SLOT(setText(QString)));
    connect(ui->Farben, SIGNAL(currentIndexChanged(QString)), ptr->ui->Farben, SLOT(setText(QString)));
    connect(ui->Groesse, SIGNAL(valueChanged(QString)), ptr->ui->Groesse, SLOT(setText(QString)));
    connect(ui->Gewicht, SIGNAL(valueChanged(QString)), ptr->ui->Gewicht, SLOT(setText(QString)));
    connect(ui->PLZ, SIGNAL(textChanged(QString)), ptr->ui->PLZ, SLOT(setText(QString)));
    connect(ui->Adresse, SIGNAL(textChanged(QString)), ptr->ui->Adresse, SLOT(setText(QString)));
    connect(ui->Festnetz, SIGNAL(textChanged(QString)), ptr->ui->Festnetz, SLOT(setText(QString)));
    connect(ui->Handynr, SIGNAL(textChanged(QString)), ptr->ui->Handynr, SLOT(setText(QString)));
    connect(ui->Job, SIGNAL(textChanged(QString)), ptr->ui->Job, SLOT(setText(QString)));
    connect(ui->Beziehung, SIGNAL(currentIndexChanged(QString)), ptr->ui->Beziehung, SLOT(setText(QString)));
}

Registration::~Registration()
{
    delete ui;
    delete ptr;
    delete ptr1;
}

void Registration::setUpC()
{
    ptr->show();
    ptr->raise();
    ptr->activateWindow();
}

void Registration::setUpS()
{
    ptr1->show();
    ptr1->raise();
    ptr1->activateWindow();
}[/cpp]

check.cpp
[cpp]#include "check.h"
#include "ui_check.h"

Check::Check(QWidget *parent) :
    QDialog(parent),
    ui(new Ui::Check)
{
    ui->setupUi(this);

    //ptr2 = new Registration();
}

Check::~Check()
{
    delete ui;
    delete ptr2;
}

void Check::setUpR()
{
    ptr2->show();
    ptr2->raise();
    ptr2->activateWindow();
}
[/cpp]

Was ich damit machen will Ich habe ein Startfenster mit 4 Buttons: Close, Bearbeiten, Einlesen, Registration
Registration: registrieren -> check überfrüfen -> speichern
Einlesen: Die gespeicherten Daten ausgeben, also wie Check
Bearbeiten: Registrationfenster bereits ausgefüllt zum Bearbeiten -> Check -> speichern
Close ist close
und da man bei normalen Fenstern immer vor und zurück geht die "Doppel"-Zeiger

Startfenster.h
[cpp]
#ifndef STARTFENSTER_H
#define STARTFENSTER_H

#include <QDialog>

#include "ui_startfenster.h"
#include "Registration.h"

class Registration; // das is die forward declaration

class Startfenster : public QDialog
{
    Q_OBJECT

public:
    Startfenster(Registration *inRegistration, QWidget *parent = 0); // <<< probier das ma umzusetzen. anstatt ptr=new Registration(); bei den anderen klassen entsrepchend.
    ~Startfenster();

private slots:
    void setUpR();

private:
    Ui::Startfenster *ui;
    Registration *ptr;

};

#endif // STARTFENSTER_H[/cpp]

am besten, du verlagerst diese ganzen new geschichten dahin, wo das erste fenster kreiert wird (in deinem fall wahrscheinlich wirklich die main.c*)

nenn die dateien besser genau exakt so, wie die klassen heissen, also auch gross/klein-schreibung,etc. hier vlt ein denkanstoss:

Das ist reine Konventionssache und sonst ziemlich irrelevant. Man sollte es nur einheitlich machen, damit keine Verwirrung entsteht. Ob die Dateien jetzt der Groß-/Kleinschreibung der Klassen folgen oder nicht, ob Header nun mit .h oder .hpp enden usw., ist von Projekt zu Projekt unterschiedlich. Für privaten Gebrauch sollte man sich angewöhnen, womit man selbst am Besten zurecht kommt - da gibts keine Vorgaben.

(Anders ist das mit der Rechtschreibung...)

Zu meinem Problem die connects kann ich ohne weiteres verschieben, aber z.B. bei diesen Slot, ist irgendeiner:

[cpp]void Check::setUpR()
{
    ptr2->show();
    ptr2->raise();
    ptr2->activateWindow();
}[/cpp]

Weie mach ich das dann mit den ptr´n ist ja aus der Klasse?
mit extern irgendwie, obwohl ich nicht wüsste wie das gehen soll von Abhängigkeiten ganz zu schweigen
Wenn ich einen ptr hier deklariere bekomme ich Speicherlecks on Maß...
Auf den Stack kann ich in der Funktion auch nicht deklarieren habe ich gerade ausprobiert stürtzt das ganze Programm ab... - was glaube ich daran liegt, dass sobald die Funktion/Slot durch ist, der namespace gelöscht wird ich das Fenster aber noch brauche, genau wie bei delete...

Ich stehe in Rätseln

Danke schon mal für die Hilfe bis jetzt!!!

...denn laut dem Erklärer dauert Allokieren auf Heap deutlich länger als auf den Stack, ich aber dachte bis jetzt immer, dass wenn ich den Zeiger öfter brauche als einmal und ich so die Klasse immer wieder neu auf dem Stack allokieren muss aufgrund von endenden Namespaces es mit Zeigern dann schon schneller geht???

Häääh? Entweder ist deine Beschreibung einfach wirr oder schlicht unsinnig.

Grundsätzlich ist eine Variable auf dem Stack in der Regel vorzuziehen (und etwas schneller), aber es kommt auch immer darauf an was man erreichen will. Wenn ein Objekt über einen Scope (nicht Namespace, das ist etwas ganz anderes) hinweg überdauern muss, so eignet sich eine Stackvariable nicht. Allgemein würde ich sagen: verwende eine Stackvariable immer wenn es geht, und sonst Heapvariablen.

Nun lässt sich aus deiner Beschreibung aber nicht ablesen was du eigentlich sagen willst.

Gero_Programmierstil_de schrieb:

nenn die dateien besser genau exakt so, wie die klassen heissen, also auch gross/klein-schreibung,etc. hier vlt ein denkanstoss:

Das ist reine Konventionssache und sonst ziemlich irrelevant. Man sollte es nur einheitlich machen, damit keine Verwirrung entsteht. Ob die Dateien jetzt der Groß-/Kleinschreibung der Klassen folgen oder nicht, ob Header nun mit .h oder .hpp enden usw., ist von Projekt zu Projekt unterschiedlich. Für privaten Gebrauch sollte man sich angewöhnen, womit man selbst am Besten zurecht kommt - da gibts keine Vorgaben.

(Anders ist das mit der Rechtschreibung...)

Joaaaa, allerdings sind doch folgende konventionen am weitverbreitesten, oder?
* dateinamen exakt so benennen wie die enthaltenden klassen.
* KlassenName.hpp, wenn sich um eine template-klasse handelt, ansonsten KlassenName.h

(hachja, ich hab den hans ja trotzdem lieb .oO)

@wit:
hau mal alles was du jetzt in den konstruktoren hast in jeweils eine zusätzliche init() methode.
dann kannst du die konstruktoren aufrufen, ohne das jemals irgentwas schief geht, dannach versuch ma, den konstruktor so umzubauen wie in meinen voherigen post.
dann kannst du erst die objekte erzeugen mittels new(), dann ham sie auch alle jeweils ihre zeiger richtig gesetzt, und erst dannach rufst du jeweils die init()'s auf.
weisst du, was ich meine?

wit schrieb:

...denn laut dem Erklärer dauert Allokieren auf Heap deutlich länger als auf den Stack, ich aber dachte bis jetzt immer, dass wenn ich den Zeiger öfter brauche als einmal und ich so die Klasse immer wieder neu auf dem Stack allokieren muss aufgrund von endenden Namespaces es mit Zeigern dann schon schneller geht???

Häääh? Entweder ist deine Beschreibung einfach wirr oder schlicht unsinnig.

Grundsätzlich ist eine Variable auf dem Stack in der Regel vorzuziehen (und etwas schneller), aber es kommt auch immer darauf an was man erreichen will. Wenn ein Objekt über einen Scope (nicht Namespace, das ist etwas ganz anderes) hinweg überdauern muss, so eignet sich eine Stackvariable nicht. Allgemein würde ich sagen: verwende eine Stackvariable immer wenn es geht, und sonst Heapvariablen.

Nun lässt sich aus deiner Beschreibung aber nicht ablesen was du eigentlich sagen willst.

joa die sätze sind en bisel unsinnig, aber ich glaub, wit meint folgendes:
er braucht in den klassen ja nicht ein komplettes objekt der anderen klassen, sondern halt jeweils nur einen zeiger. die schlussfolgerung, die objekte auf dem heap (oder auf dem stack, besser halt: überhaupt) zu kreieren, is allerdings falsch, die objekte brauchen jeweils nur zeiger, keine kompletten objekte, weder auf dem stack noch auf den heap.

zusätzlich zu der bedingung mit "scope überdaeuern" für heap speicher kommt btw noch der fall hinzu, dass man nicht genau weiss, wie groß die variable is, die man braucht.

Joaaaa, allerdings sind doch folgende konventionen am weitverbreitesten, oder?
* dateinamen exakt so benennen wie die enthaltenden klassen.
* KlassenName.hpp, wenn sich um eine template-klasse handelt, ansonsten KlassenName.h

Wäre mir unbekannt, dass die allzu verbreitet sind, geschweige denn weitverbreitet. Dateinamen im CamelCase kenne ich eigentlich nur aus Java, die .hpp/.h-Mix-Regel ist mir ehrlich gesagt noch nie untergekommen. Hast du irgendeine Quelle für diese Konventionen, am Besten mit Statistiken, die zeigen, wie häufig sie vorkommen? Nach allem, was ich bisher in verschiedenen Projekten und Beispielen (online und in Büchern) sehen konnte, sind Konventionen einfach unterschiedlich, einige etwas öfter vertreten als andere, aber keine so prominent, dass man sie jetzt als die allgemeingültige Konvention verkaufen könnte.
Ich wollte Hans eigentlich schön in seiner Ecke lassen, hab mich nur gewundert, dass jemand mit einem etwas "schnoddrigen" Schreibstil so penibel bei so unwichtigen Dingen wie der Schreibweise von Sourcedateinamen ist

Gero_Programmierstil_de schrieb:

Joaaaa, allerdings sind doch folgende konventionen am weitverbreitesten, oder?
* dateinamen exakt so benennen wie die enthaltenden klassen.
* KlassenName.hpp, wenn sich um eine template-klasse handelt, ansonsten KlassenName.h

Wäre mir unbekannt, dass die allzu verbreitet sind, geschweige denn weitverbreitet.

Also die erste Regel kenne ich definitiv auch so, und wurde in der Regel so auch an allen Firmen, bei denen ich tätig war gehandhabt (Alles Firmen die hauptsächlich im MS-Umfeld tätig waren, die Hälfte davon rein auf C++ Basis). Auch in einigen Büchern wurde diese Notation verwendet (aber nicht explizit erwähnt). Ich würde sie zumindest zu einer nicht ganz unüblichen Regel zählen, aber ob sie sehr häufig ist steht auch auf einem anderen Blatt..

Die zweite Regel ist mir wiederum noch nie über den Weg gelaufen (Weder in Büchern noch irgendwo sonst).

Im wesentlichen ist es aber völlig egal wie eine Benennung erfolgt, und welche Regeln man sich selbst gibt, sofern sie konsistent sind. Wie hat auch schon Herb Sutter und Andrei Alexandrescru so passend geschrieben:

Buch: C++ Coding Standards schrieb:

0. Don't sweat the small stuff. (Or: Know what not to standarize)
...
Don't overlegislate naming, but do use a consistent naming convention:
...

Ich wollte Hans eigentlich schön in seiner Ecke lassen, hab mich nur gewundert, dass jemand mit einem etwas "schnoddrigen" Schreibstil so penibel bei so unwichtigen Dingen wie der Schreibweise von Sourcedateinamen ist

haha, gut gekontert ;).

pumuckl schrieb:

Gero_Programmierstil_de schrieb:

Joaaaa, allerdings sind doch folgende konventionen am weitverbreitesten, oder?
* dateinamen exakt so benennen wie die enthaltenden klassen.
* KlassenName.hpp, wenn sich um eine template-klasse handelt, ansonsten KlassenName.h

Wäre mir unbekannt, dass die allzu verbreitet sind, geschweige denn weitverbreitet. Dateinamen im CamelCase kenne ich eigentlich nur aus Java, die .hpp/.h-Mix-Regel ist mir ehrlich gesagt noch nie untergekommen. Hast du irgendeine Quelle für diese Konventionen, am Besten mit Statistiken, die zeigen, wie häufig sie vorkommen? Nach allem, was ich bisher in verschiedenen Projekten und Beispielen (online und in Büchern) sehen konnte, sind Konventionen einfach unterschiedlich, einige etwas öfter vertreten als andere, aber keine so prominent, dass man sie jetzt als die allgemeingültige Konvention verkaufen könnte.

ja würde mich jetz auch genauer interessieren.

ich forsch mal nen bisschen nach.

zu der .h/.hpp-geschichte liefer ich mal nen erklärungs-ansatz:
ich kenns von *.hpp datein halt so, dass sie nicht nur deklarationen enthalten, sondern auch defintionen oder besser gesagt: echten programm-code.
bei templates is halt genau das oft der fall.
erst die nutzung eines templates definiert es ja wirklich komplett (jetzt default-spezialiserungen,etc.. ma ausgenommen). bindet man ein template ein und nutz es nicht, entsteht auch kein echter programm-code.

und wenn man sich die endung jetz ma anguckt:
*.hpp

1. ist irgentwie ne vermischung aus *.cpp (code) und *.h (header).
code + header
-> templates? könnte sinn machen.

2. kann man natürlich auch sehen als:
pp-header
-> C++ header.
dann fände ich es aber auch sinnvoll grundsätzlich folgende paarungen zu verwenden: .hpp/.cpp für c++ code und .h/.c für c.

kann man natürlich anders sehen. was meinst du?

und wenn man sich die endung jetz ma anguckt:
*.hpp

1. ist irgentwie ne vermischung aus *.cpp (code) und *.h (header).

Und wird von einigen Softwareunternehmen und Entwicklern auch als Header für C++ Source verwendet (ist mir u.a. bei Firmen begegnet die sowohl C als auch C++ gleichzeitig im Projekt verwenden, und eine striktere Trennung haben wollten). Ebenso wirst du hpp u.a. im C++ Builder Umfeld recht häufig bei Komponentenheadern finden.

Ich würde die Kirche daher im Dorf lassen und nicht weitere Konventionen einführen. Wichtig ist wie gesagt eigentlich nur das man einheitlich bleibt.

Wenn man beruflich mit Programmierung zu tun hat und nicht nur bei einer Firma bleibt, wird man ohnehin immer wieder mit anderen Konventionen für Projekten zu tun haben. Teilweise hat jedes Projekt in einer Firma wieder abweichende Konventionen.

kann man natürlich anders sehen. was meinst du?

• boost hat afaik ausschließlich .hpp, egal was drin steht (ok, ist zu geschätzten 99,9% eh alles Template-Kram). Klassennamen und Header folgen beide Underscore-Konvention.
• Bei SFML (weniger templates) scheinen es auch nur .hpp's zu sein, Klassennamen und Header im CamelCase
• wxWidgets benutzt dagegen nur .h, Klassennamen als wxCamelCase, Headernamen als wx/lowercase.h
• Ich benutze persönlich auch .cpp und .h, Klassennamen im CamelCase, Header im lowercase. .hpp benutze ich nur sehr selten, wenn ich z.B. einen boost-Header für meine Bedürfnisse modifizieren muss und diese modifizierte Kopie irgendwo bei mir unterbringe. In dem Fall behalte ich auch Schreibweisen für Klassen und Header bei.
• Auf der Arbeit haben wir hauptsächlich .h, .c, weil unsere Codebase "organisch" gewachsen ist, im Original C war und bei der Umstellung einfach nur der Hebel am Compiler von C auf C++ umgelegt wurde. Neuere Dinge heißen häufig .cpp und .hpp, meistens heißt das im Klartext: ".h/.c" -> ursprünglich C-Code, der mit dem einen oder anderen C++-Feature notdürftig gepimpt wurde. ".cpp/.hpp" -> ursprünglicher C++-Code, bei dem man sich Mühe gegeben hat, objektorientiert zu arbeiten. Häufig auch C mit Klassen und ähnliches. Namen sind ähnlich gemischt, System gibts wenn man Glück hat immerhin innerhalb der einzelnen Module.

Andere habe ich gerade nicht zur Hand, aber ich denke man darf sich auf Regel 0 von Sutter/Alexandrescu einigen. Ist wahrscheinlich ein ähnlich müßiges Thema wie Klammersetzung und Tab/Einzugsgröße Hauptsache es bleibt lesbar.

B2T: wit, weitergekommen?

@gero: Ich glaube ich habe verstanden was du meinst, aber ich verstehe den Sinn nicht so ganz Könntest du es mir bitte nochmal erklären?

Edit: Ich mach jetzt erstmal alles in forward declarationen, bin vohin nimmer dazu gekommen...
Edit2: Obwohl was du mit der init methode meinst habe ich doch noch nicht gerafft... Sowas wie auf der 1 Seite, dumm frag
Edit 3: Das mit den Namen kann ich jetzt nimmer ändern werde ich aber in Zukunft machen
Desweiteren wollte ich noch sagen, auch wenn ihr das über gero amüsant findet, das ich sehr froh bin das er mir soetwas wie z.B. solche Namensgeschichten sagt, weil ich ja wie gesagt niemanden kenne

Edit: Hat jetzt doch funktioniert war nur zu blöd
Edit2: Wow, compiliert der jetzt schneller, das der Unterschied so groß ist hätte ich nicht gedacht

0. Don't sweat the small stuff.
Mach dir keine Sorger über die unwichtigen Sachen?

Don't overlegislate naming, but do use a consistent naming convention:
und hier was heißt das Wort "overlegislate"? - übertreiben?

Hoffe ich nerv euch nicht zu sehr aber wenn will ich schon alles wissen