Memberfunktionen gruppieren

CStoll

Da müsstest du deinem Hilfs-Struct einen Verweis auf das umgebende Objekt mitgeben und im Konstruktor füllen:

class CGraphics
{
    CGraphics(...) : createLightSource(this), ... {}
    struct CreateLightSource {
        const HRESULT directional(const D3DXVECTOR3& direction, float r, float g, float b, float a) const;
        const HRESULT spot() const;
        const HRESULT point() const;

        CreateLightSource(CGraphics* pUser) : User(pUser) {}
    private:
        CGraphics* User;
    };
public:
    CreateLightSource createLightSource;
}

(allerdings braucht die Klasse dann auch angepasste Kopier-Operationen, wenn die hier überhaupt sinnvoll sind)

Nexus schrieb:

Nochmals zum Sicherstellen:

Du machst dir den ganzen Aufwand nur, weil dir die Syntax nicht passt bzw. IntelliSense die Funktionen nicht ideal darstellt? Oder gibt es auch gute Gründe für die Umstellung?

Ich würde meinen Code nicht primär nach IntelliSense ausrichten. Vor allem nicht, wenn er dadurch komplexer und weniger wartbar wird.

Ja, der Grund ist die "End-Benutzer"-Syntax. Ich finde Struktur in die Funktionen Rein zubringen sinnvoll...

Zudem bin ich davon ausgegangen, dass die Gruppierung nicht so kompliziert ausfällt.
Geht da nicht was mit Namespaces?

@CStoll, danke ich benutze es mal testweise, aber wenn das so umständlich ist Memberfunktionen zu gruppieren, dann überleg ich mir das nochmal..

EOutOfResources

Amino schrieb:

Geht da nicht was mit Namespaces?

Namensbereiche sind zum Modularisieren da. Und innerhalb von Klassen sowieso nicht.

314159265358979

Nexus schrieb:

Wenn die Schnittstelle gleich ist, kannst du die Methoden auch zu einer zusammenfassen.
enum LightSourceType
{
    Point,
    Directional,
    Spot,
};

/* Rückgabetyp */ CreateLightSource(LightSourceType type, /* andere Parameter */);

Selbiges stand in meinem Post, aber wegen des selben Interfaces habe ich es herausgelöscht.

Artchi

EOutOfResources schrieb:

Namensbereiche sind zum Modularisieren da.

Nö, die sind dafür da Namenskonflikte zu vermeiden. Modularisierung unterstützen oder gar erzwingen tun sie erst recht nicht.

Nexus

Artchi schrieb:

Nö, die sind dafür da Namenskonflikte zu vermeiden.

Nein. Zur Vermeidung von Namenskonflikten reichen auch Präfixe. Namensräume können mehr als das.

CStoll

@Amino: Mir ist noch ein anderer Gedanke gekommen: Wenn du die Parameter sinnvoll zuordnen kannst, wäre auch Funktions-Überladung eine Alternative. D.h. du hast mehrere Funktionen CreateLightSource(...) und kannst an den Parametern erkennen, welche davon verwendet werden soll.

Artchi

Nexus schrieb:

Artchi schrieb:

Nö, die sind dafür da Namenskonflikte zu vermeiden.

Nein. Zur Vermeidung von Namenskonflikten reichen auch Präfixe. Namensräume können mehr als das.

Dann erzähl mal.

Eisflamme

namespaces können auch kapseln, wenn sie anonym sind.

Wieso muss CGraphics eigentlich die Lichter erstellen? Ich fände so was intuitiv:

CGraphics cg;
cg.AddLight(SpotLight(a, b, c));

Oder gibt es keine Lichtklassen? Fänd ich aber nicht unlogisch. Was macht denn "CreateLightOfKindWhatsoever"?

Nexus

Artchi schrieb:

Dann erzähl mal.

Fällt dir kein Vorteil von Namensräumen gegenüber Präfixen ein?

Ein paar Stichworte: ADL, using -Deklaration und -Direktive, Namespace Aliases, Unnamed Namespaces, saubere Bezeichner innerhalb des Namensraums.

Artchi

Nexus schrieb:

Artchi schrieb:

Dann erzähl mal.

Fällt dir kein Vorteil von Namensräumen gegenüber Präfixen ein?

Ein paar Stichworte: ADL, using -Deklaration und -Direktive, Namespace Aliases, Unnamed Namespaces, saubere Bezeichner innerhalb des Namensraums.

Ehm, ich wollte gerne was zum Beitrag der Modularisierung durch Namespaces wissen. Die Namenskonfliktvermeidung habe ich ja selber genannt. Vielleicht Unnamed Namespaces würde ich eine minimale Rolle in der Modularisierung zusprechen. Alles andere hat nur was mit Namen zu tun.

Aber ich wollte bzgl. Modularisierung wissen. Weil da fällt mir nichts ein, wo Namespaces was dafür tun.