Ich habe eine relativ umfangreiche Klasse Graphics mit DirectX9 geschrieben.

Nun möchte ich einzelne Memberfunktionen gruppieren.

Im moment habe ich z.B. 3 Memberfunktionen
CreateLightSource_Point(...)
CreateLightSource_Directional(...)
CreateLightSource_Spot(...)

und möchte daraus sowas wie

CreateLightSource.Point(...);
CreateLightSource.Directional(...);
CreateLightSource.Spot(...);

machen. Damit mir unter anderem Intellisense nur noch CreateLightSource anzeigt.

enum LightSourceType
{
    Point,
    Directional,
    Spot,
};

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

314159265358979 schrieb:

Hier stand Müll

Kommt bei dir in letzter Zeit öfter vor... Vielleicht nicht immer so übereifrig drauf los posten

Ich bekomm das einfach nicht gebacken.

Ich habe es jetzt so innerhalb der Graphics geschrieben:

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;
	};
public:
	CreateLightSource createLightSource;

und so sieht es in der .cpp aus:

const HRESULT CGraphics::SCreateLightSource::directional(const D3DXVECTOR3& direction, float r, float g, float b, float a) const {
	//...

	D3DDevice->SetLight(0, &light);//Hier mault der compiler, weil D3DDevice nicht deklariert ist...dann so probiert:
	CGraphics::D3DDevice->SetLight(0, &light);//so geht es auch nicht, ich nehme an weil D3DDevice nicht static ist.
	return D3D_OK;
}

Ich komme also nicht an die privaten member von CGraphics ran...

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.

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)

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

Geht da nicht was mit Namespaces?

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

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.

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.

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.

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.

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"?

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