policys design problem

hehejo

Ja, das hab ich auch noch nicht so ganz verstanden.

volkard

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.

7H3 N4C3R

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

miller_m

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

hehejo

Dieses PDF hat mir viel erklärt:
http://www4.informatik.uni-erlangen.de/Lehre/SS04/HS_AspectOS/Ergebnisse/PBD-Folien.pdf

volkard

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.

miller_m

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

ness

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.

miller_m

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?

ness

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.

miller_m

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.