statische Klasse hässlich! (?)

Bevor das hier jetzt in wilde Spekulationen ausartet, hier der Header von ToolTip:

#ifndef QTOOLTIP_H
#define QTOOLTIP_H

#include <QtGui/qwidget.h>

QT_BEGIN_HEADER

QT_BEGIN_NAMESPACE

QT_MODULE(Gui)

#ifndef QT_NO_TOOLTIP

class Q_GUI_EXPORT QToolTip
{
    QToolTip();
public:
    static void showText(const QPoint &pos, const QString &text, QWidget *w = 0);
    static void showText(const QPoint &pos, const QString &text, QWidget *w, const QRect &rect);
    static inline void hideText() { showText(QPoint(), QString()); }

    static bool isVisible();
    static QString text();

    static QPalette palette();
    static void setPalette(const QPalette &);
    static QFont font();
    static void setFont(const QFont &);
#ifdef QT3_SUPPORT
    static inline QT3_SUPPORT void add(QWidget *w, const QString &s) { w->setToolTip(s); }
    static inline QT3_SUPPORT void add(QWidget *w, const QRect &, const QString &s)
    { w->setToolTip(s); }
    static inline QT3_SUPPORT void remove(QWidget *w) { w->setToolTip(QString()); }
#endif
};

#endif // QT_NO_TOOLTIP

QT_END_NAMESPACE

QT_END_HEADER

#endif // QTOOLTIP_H

Keine Member, einzig ein privater Konstruktor, der aber nirgendwo definiert ist.
Aber was ich nicht weiß, in wie weit man per Q_GUI_EXPORT einen namespace exportieren kann (da hab ich 0 Ahnung...). Vielleicht ist das der Grund (für alle Checker: Q_GUI_EXPORT ist definiert in <qt_src_root>/src/corelib/global/qglobal.h, in Version 4.5.1 ab Zeile 1121)

Badestrand schrieb:

aber schrieb:

also ist der einzige Grund, dass man es nicht so machen will wie in Java oder gibts noch nen richtigen?

Nein, mit Java hat das nichts zu tun. Wenn man eine Klasse entwickelt, sollte es für den Nutzer so wenig Möglichkeiten zum falsch-machen geben wie nur mögich. In den allermeisten Fällen sind Klassen dafür da, um Instanzen von ihnen erstellen zu können (oder sie abstrakter referenzieren zu können, im Fall von Basisklassen). Und Namensräume werden genutzt, um Funktionalitäten zu gruppieren. Die QToolTip-Klasse gruppiert mit einer Klasse, von der man keine Instanzen erstellen kann/soll. Das ist unintuitiv und deshalb verwirrend. Und Verwirrung will wohl keiner

Dann ist aber doch der Namensraum std ein schlechtes Beispiel für die Verwendung von Namensräumen. Im prinzip gruppiert er nichts, sondern wirft alles von Algorithmen über Container bis Streams in einen Topf. Warum gibts da keine unterschiedlichen Namensräume?

DStefan

aber schrieb:

Badestrand schrieb:

aber schrieb:

also ist der einzige Grund, dass man es nicht so machen will wie in Java oder gibts noch nen richtigen?

Nein, mit Java hat das nichts zu tun. Wenn man eine Klasse entwickelt, sollte es für den Nutzer so wenig Möglichkeiten zum falsch-machen geben wie nur mögich. In den allermeisten Fällen sind Klassen dafür da, um Instanzen von ihnen erstellen zu können (oder sie abstrakter referenzieren zu können, im Fall von Basisklassen). Und Namensräume werden genutzt, um Funktionalitäten zu gruppieren. Die QToolTip-Klasse gruppiert mit einer Klasse, von der man keine Instanzen erstellen kann/soll. Das ist unintuitiv und deshalb verwirrend. Und Verwirrung will wohl keiner

Dann ist aber doch der Namensraum std ein schlechtes Beispiel für die Verwendung von Namensräumen. Im prinzip gruppiert er nichts, sondern wirft alles von Algorithmen über Container bis Streams in einen Topf. Warum gibts da keine unterschiedlichen Namensräume?

Ich verstehe Namespaces ein bischen anders. Ihr primäres Ziel ist es, die Eindeutigkeit von C++-Bezeichnern zu gewährleisten. Es soll also beispielsweise gewährleistet werden, dass man problemlos Librarys zwei verschiedener Hersteller (oder meinetwegen die STL und eine weitere Library) verwenden kann, ohne dass man Ärger mit Compiler oder Linker kriegt, weil beide Libs denselben Namen, etwa einer Klasse, verwenden.

Man kann natürlich hergehen und Namespaces zur Gruppierung verwenden, wie etwa boost es macht. Vielleicht ist das sogar eine gute Idee, aber wichtig oder gar entscheidend ist das nicht. Eine Gruppierung per Klasse, wie mit dem gezeigten Beispiel ist in meinen Augen völlig in Ordnung und eine akzeptable Design-Entscheidung.

Stefan.