E
Du hast z.B. nicht dazugeschrieben dass du die Möglichkeit brauchst das "geproxyte" Objekt zur Laufzeit gegen ein anderes mit anderem Typ auszutauschen.
Ich habe das oft auf späteren Seiten der jeweiligen Threads formuliert. Aber Du hast Recht, ich habe die Threads durchsucht und im opening post steht das überhaupt nicht drin. Und in diesem Thread konnte ich es gar nicht finden. Auf Lösungsvorschläge habe ich es aber gesagt.
Was die Standardlösungen angeht: Sind das echt Standardlösungen? Ich finde es aber darüber hinaus auch ohnehin unsauber, denn eigentlich müsste man von const Interface erben, was nicht funktioniert. Oder meinst Du, dass genau das eigentlich kein Problem ist?
Was mich geärgert hat, war einfach, dass meine Lösung schlechtgeredet wurde und ich mir ständig anhören muss, wie bescheuert mein Design ist, um dann aber eine nicht fertig zu Ende gedachte Lösung zu erhalten, die angeblich so viel besser ist. Dann stehe ich da und versuche das umzusetzen, komme zu nichts und erhalte auf meine Nachfragen von entsprechenden Personen keine Antworten mehr. Das ist frustrierend. Dass die auch andres zu tun haben und ich generell überreagiert habe, steht natürlich außer Frage. Entschuldigung dafür nochmals.
Dieser Thread ist übrigens ein gutes Beispiel dafür worauf ich im "Signals" Thread hinaus wollte: es gibt keine Silver-Bullet, und wenn man sinnvoll anwendbare Antworten bekommen möchte, dann sollte man vielleicht auch die Anwendung beschreiben. Und zwar je konkreter desto besser.
In diesem Fall trifft das ohne jede Frage zu. Dann werden's halt lange Opening Postings, vielleicht schreckt das gar nicht so stark ab, wie ich dachte. In jedem Fall führt mein aktueller Posting-Stil bei konkreten Problem einfach zu nichts (beim signal-Thread fand ich es trotzdem zielführend :)).
Nagut, ich sehe, ich habe hier viel falsch gemacht. Ich gelobe Besserung.
Hat jemand Anmerkungen zu dieser Proxy-Lösung, die dann eben auch auf compiletime beruht? (ich mache einen neuen Thread dafür auf)
template<typename T>
class SomeClassProxyBase
{
struct ProxyImpl
{
T* someClass;
ProxyImpl(T& someClass) : someClass(&someClass) {}
void foo() {someClass->foo();}
void bar() const {someClass->bar();}
} proxyImpl; // und wenn T const ist, kann man proxyImpl jetzt const machen
public:
SomeClassProxyBase(T& someClass) : proxyImpl(someClass) {}
void SetSomeClass(T& someClass) {proxyImpl.someClass = &someClass;}
T& operator->() {return proxyImpl;} // wenn T const, muss natürlich noch const-Modifier hin via enable_if oder so
};
// jetzt geht:
typedef SomeClassProxyBase<const SomeClass> ConstSomeClassProxy;
typedef SomeClassProxyBase<SomeClass> SomeClassProxy;
// und auch die vier Varianten
const ConstSomeClassProxy proxy1(sc); // Bezugsobjekt nicht austauschbar, nicht änderbar
ConstSomeClassProxy proxy2(sc); // Bezugsobjekt austauschbar, nicht änderbar
const SomeClassProxy proxy3(sc); // Bezugsobjekt nicht austauschbar, doch änderbar
SomeClassProxy proxy4(sc); // Bezugsobjekt austauschbar, und änderbar
Man kann ProxyImpl eigentlich auch zum Template machen, dann braucht man darin kein enable_if-Gedöns.