3. Zeigerproblem (kein Compilerfehler) in QtÜbung [close]

Zeigerproblem (kein Compilerfehler) in QtÜbung [close]

  • W

    Hallo All,

    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

    0
  • S

    was heisst denn ausklammern?

    0
  • W

    als Kommentar verwenden, so suche ich meine Fehler meistens

    0
  • ?

    Der Fehler liegt wohl in einem der vielen "...".
    Für ein connect brauchst du keine Zeiger als Member, und das connect könnte sogar völlig außerhalb der beteiligten Klassen stattfinden.

    0
  • ?

    Ich sehe gerade, der Konstruktor von Check ruft den Konstruktor von Registration auf, der den Konstruktor von Check aufruft, der den Konstruktor von Registration aufruft ...

    Kann das sein?

    0
  • G

    Die Konstruktoren der Klasse Registration und von Check rufen sich gegenseitig auf. Das ist zumindest eins deiner Problem.

    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?

    0
  • G

    und mach in den .h files aus den

    class Registration *ptr;

    mal ein

    Registration *ptr;

    das class lässt man in dem fall weg.

    0
  • W

    ok vielen Dank für deinen konstruktiven Beitrag, weil ich hab mir Mühe gegeben das möglichst gut zu kürzen 👍
    das class mach ich gleich mal weg...
    Aber das Andere würde ich gerne erstmal selber ausprobieren, schließlich will ich ja was lernen 😃
    und dann melde ich mich nochmal ob es jetzt geklappt hat

    0
  • W

    also ich war grad beim Essen und habe dabei über deinen Lösungsvorschlag nachgedacht, nur leider verstehe ich es noch nicht 😞

    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

    0
  • G

    Ich glaub, das praktischste ist, du lädst mal dein komplettes projekt hier hoch.
    ich weiss schon, was du nicht verstehst, aber ich glaub, per code is einfachste weg, das zu vermitteln.

    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?

    0
  • W

    also ich lade jetzt mal mein Projekt hoch, aber denken kann ich heut nimmer. Morgen werd ich dann deinen Post versuchen zu verstehen und Vorwärtsdeklaration googlen, schade nur das in meinem Programmierbuch (C++ Kompendium von Dirk Louis) nichts dazu drinsteht

    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

    0
  • G

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

    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*)

    0
  • P

    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...)

    0
  • W

    also ich habe grad forward declarition gegoogelt und eine wirklich tolle Seite gefunden, wenn mal wer das selbe Problem hat: http://www.computerbase.de/forum/showthread.php?t=166913 (Post 3)
    Allerdings hat sich mir da eine neue Frage aufgetan, 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???

    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!!!

    0
  • A

    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.

    0
  • G

    pumuckl schrieb:

    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?

    0
  • G

    asc schrieb:

    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.

    0
  • P

    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.
    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 😉

    0
  • A

    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.

    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:
    ...

    0
  • G

    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?

    0
Anmelden zum Antworten