policys design problem
-
ich möchte gerne ein klasse mit mehreren policys ausstatten, diese hat aber
schon einige template parameter. um nicht noch mehr zu machen und damit ich verschiedene poliyskombinationen (sind natürlich alle unabhängig voneinander, mir ist nur kein besseres wort eingefallen) anzubieten kann, dacht ich mir
einfach noch ne klasse einzuführen die nur die policys hält von von dieser erbt dann die hostklasse. wie findet ihr das? verbesserungen, meinungen etc ...// anmerkung: alle policys sind static template< class P1_, class P2_, class P3_, class P4_, class P5_, class P6_> struct FooPolicys : protected P1_, protected P2_ // usw { /*nothing*/ }; typedef FooPolicys<Bar1, Bar2, /*usw*/> StandardPolicy; typedef FooPolicys<Bar5, Bar6, /*usw*/> DebugPolicy; typedef FooPolicys<Bar8, Bar9, /*usw*/> FastPolicy; template< class T1_, class T2_, class Policys_> class Foobar : private Policys_ { /*irgendwas*/ };[edit]
ist jetzt nur uptopie:
wie würdet ihr das lösen falls eine policy einen template parameter von Foobar brauch. dann müsste ich ja wieder alle policys in foobar schreiben mit
template template parameter.
-
wie würdet ihr das lösen falls eine policy einen template parameter von Foobar brauch.
Als erstes würd ich mich fragen, ob es nicht eher so ist, dass foobar einen template-Parameter von policy braucht, ob also der Template-Parameter nicht eher zur Policy gehört.
Wenn der template-Parameter aber wirklich Teil von Foobar ist, kannst Du noch ne Indirektion einführen:
template< class P1_, class P2_, class P3_, class P4_, class P5_, class P6_> struct FooPolicyList { typedef P1_ P1; typedef P2_ P2; ... }; // anmerkung: alle policys sind static template< class PolicyList_, class FoosTemplate_> struct FooPolicy : protected PolicyList_::P1, protected PolicyList_::P2 // usw { /*nothing*/ }; typedef FooPolicyList<Bar1, Bar2, /*usw*/> StandardPolicy; typedef FooPolicyList<Bar5, Bar6, /*usw*/> DebugPolicy; typedef FooPolicyList<Bar8, Bar9, /*usw*/> FastPolicy; template< class T1_, class T2_, class PolicyList_> class Foobar : private Policys<PolicyList, T1_> { /*irgendwas*/ };
-
hallo m_miller
könntest du mir bitte erklären was policys sind?
vielen Dank
-
Ja, das hab ich auch noch nicht so ganz verstanden.
-
miller_m schrieb:
wie findet ihr das?
keine ahnung, was die klassen bedeuten. da man SmartPointers anders zusammenschaubt als Containerklassen und die anders als Factories und die anders als nen MemoryManager, ist jeder tip, den du anhand dieser frage bekommst, zu 75% wahrscheinlichkeit einer, der dich nur auf abwege führt.
ach, und sag mir doch mal schnell, ob ich lieber ++i oder i++ schreiben sollte.
-
Ein kleines bisschen zu viele Policies für meinen Geschmack. Mag ja sein, dass die alle sinnvoll sein mögen und gebraucht werden - aber zumindest in deinem Beispiel sieht es etwas übertrieben aus
volkard schrieb:
ach, und sag mir doch mal schnell, ob ich lieber ++i oder i++ schreiben sollte.
Du könntest operator++() und operator++(int) mit Policies ausstatten, um zu bestimmen, wie performant die beiden sind
-
volkard schrieb:
keine ahnung, was die klassen bedeuten. da man SmartPointers anders zusammenschaubt als Containerklassen und die anders als Factories und die anders als nen MemoryManager, ist jeder tip, den du anhand dieser frage bekommst, zu 75% wahrscheinlichkeit einer, der dich nur auf abwege führt.
in weit ändert die hostklasse das design der policy anbindung?
es ist mehr oder weniger ein container der daten sammelt und diese an eine andere lib mit entsprechenden policy weiterleitet.volkard schrieb:
ach, und sag mir doch mal schnell, ob ich lieber ++i oder i++ schreiben sollte.
:p ich denke du weisst wann du post- oder pre- inkrementieren solltest und wann nicht.
@kartoffelsack
keine schlechte idee@foo & hehejo
ich glaub ich schaffe es nicht in wenigen sätzen zu erklären, das überlasse ich lieber anderen
zb: mister google (erster hit schaut nicht schlecht aus) http://www.google.de/search?hl=de&q=policy+based+design&btnG=Suche&meta=lr%3Dlang_de
gutes buch wäre
Modern C++ Design | ISBN: 0201704315[edit1]
7H3 N4C3R schrieb:
Ein kleines bisschen zu viele Policies für meinen Geschmack. Mag ja sein, dass die alle sinnvoll sein mögen und gebraucht werden - aber zumindest in deinem Beispiel sieht es etwas übertrieben aus
ist nicht übertrieben, evtl. vielleicht irgendwann mal untertrieben.
[edit2]
verlesen
-
Dieses PDF hat mir viel erklärt:
http://www4.informatik.uni-erlangen.de/Lehre/SS04/HS_AspectOS/Ergebnisse/PBD-Folien.pdf
-
miller_m schrieb:
in weit ändert die hostklasse das design der policy anbindung?
vielleicht gibts statt einer künstlichen zusammenfassung ja zwei inhaltlich gerechtfertigte? vielleicht gibts policies, von denen man lieber nicht erben mag, die man nur haben (oder gar kennen) mag. ich weiß nicht, was los ist, ohne die verwendung zu sehen.
ist aber nicht schlimm. hast ja eine antwort, die dich zufrieden macht.:p ich denke du weisst wann du post- oder pre- inkrementieren solltest und wann nicht.
wer immer eine strukturierung vorschlägt, schlägt der nicht auch vor, immer ++i zu schreiben? ok, man muß verdammt lange suchen, um eine verwendung für i++ zu finden. das war irgendwo im zusammenhang mit da, wo der container die iteratoren invalidiert.
-
volkard schrieb:
vielleicht gibts statt einer künstlichen zusammenfassung ja zwei inhaltlich gerechtfertigte?
nein, alle sind komplett unabhängig voneinander.
volkard schrieb:
vielleicht gibts policies, von denen man lieber nicht erben mag, die man nur haben (oder gar kennen) mag.
eigentlich müsste ich gar nicht davon erben, die vererbung entstand nur damit ich zugriff auf die einzelen policys bekomme.
// so wäre das reine policy design template< class T1_, class T2_, class Policy1_, class Policy2_, class Policy3_> class Foobar { void MachWas() { Policy1_::StatischeMethode(irendein_wert); } void MachNochWas() { Policy2_::StatischeMethode(); // intere verarbeitung Policy3_::NochEineMethode(intere_daten); // weiterverarbeitung mit intere_daten } };volkard schrieb:
ich weiß nicht, was los ist, ohne die verwendung zu sehen.
ich hoffe das obrige hilft dir weiter, konkrete klassen kann ich dir nicht so richtig anbieten da diese noch in der planungsphase sind.
volkard schrieb:
hast ja eine antwort, die dich zufrieden macht.
ich möchte aber immer viele meinungen
-
Ich weiß nicht, ob ich deine Frage jetzt richtig verstehe (oder du sie schon beantwortet siehst), aber ich steh ja auf so generatoren:
template< class T, class P1, class P2, class P3, //... class Pn >class viele_policies { //... }; temnplate<class T> struct conventional_gen { typedef viele_policies<T,foo,bar,foobar,/* ... */,baz> result; };Kannst natürlich auch verschiedene generatoren oder mehrere typedefs je generator anbieten, je nach situation.
-
beantworten kann man sie auch glaub ich gar nicht da ich mehr meinungen und ideen sammele.
generatoren noch nie benutzt, wie greifst du dann auf einzelene policymethoden in der hostklasse zurück?
-
Um ehrlich zu sein, ich verstehe deine Frage nicht so recht. Die generatoren lösen prinzipiell das Problem, dass man keine einzelnen defaultparameter setzen kann.
template<class A = foo, class B = bar, class C = foobar> class test { //... };Wenn man hier nun C setzen will, muss man auch alle anderen parameter setzen. Das Problem tritt also meist bei gleichrangigen policies auf. Und meist hängen die policies ja auch zusammen, so dass nicht alle kombinationen sinn machen. Allgemein geht es darum, dem generator weniger template-parameter zu übergeben. Sie sind also kein allheilmittel. In meinem bsp. ist viele_policies dein eigentliches template, die generatoren erleichtern nur die instanzierung.
-
achso, dann wird es klar. trifft für mich dann nicht zu da alle unabhängig (beliebig kombinierbar) sind. somit sind generatoren eigentlich nicht das richtige dafür.