3. PIMPL, boost::intrusive + generischer refcounter

PIMPL, boost::intrusive + generischer refcounter

  • P

    Hi,
    Hab ein etwas komplexeres Problem, suche eine Lösungsiddee. Das Problem existiert unabhängig von intrusive_ptr, aber läßt sich daran am besten erklären:

    Ich habe versucht, für boost::intrusive_ptr den "intrusive part" generisch zu schreiben:

    - eine Klasse ptr_intrusion, die den Referenzzähler kapselt und als Basisklasse verwendet werden soll
    - überladene intrusive_ptr_add_ref und intrusive_ptr_release für Zeiger auf diese Klasse

    "reduzierter" code etwa so (der echte code ist natürlich etwas sauberer 😃 )

    struct ptr_intrusion
{
  int refcount;
};
void intrusive_ptr_add_ref(ptr_intrusion * p) { ++(p->refcount); }
void intrusive_ptr_release(ptr_intrusion * p) { if (--(p->refcount) == 0) delete p; }

class CMyClass : public ptr_intrusion {}  // *1*
typedef boost::intrusive_ptr<CMyClass> CMyClassPtr;  // *2*

    das geht wunderbar, wenn die definition von CMyClass (*1*) zum zeitpunkt des smart pointer - typedefs (*2*) bekannt ist (der compiler weiß, das MyClass von ptr_intrusion abgeleitet ist und intrusive_ptr_add_ref(ptr_intrusion * p) verwenden kann.
    Geht natürlich nicht ( 😞 ) wenn der Compiler nur eine forward-deklaration hat (class CmyClass;)

    Damit verliere ich aber den schönen Vorteil der boost-Zeiger, und das PIMPL-Idiom läßt sich nicht mehr anwenden.

    Ideen?

    0
  • R

    das Problem kannst du nicht umgehen, da Template Parameter dem Compiler bekannt sein müssen. Mit eine forward-decl kommst du da nicht weiter.

    btw. mach doch *bitte bitte* kein C vor deine Klassennamen

    0
  • P

    Ich grüble ja noch üebr einen "weiter weg"-Ausweg nach...

    btw. mach doch *bitte bitte* kein C vor deine Klassennamen

    Und wieso net?

    0
  • C

    Das wurde z.B. hier schon lang und breit diskutiert.

    0
  • P

    Weiß zwar nicht ob C Newbie noch ein C Newbie ist, aber wegen Kommentaren wie "Das ist MS Scheiß und verwirrt nur" schmeiß ich nicht die Namenskonventionen eines 500KLoc - Projektes über den Haufen. Und bis seite 5 hab ich in dem angegebenen Thread nix brauchbares gefunden.

    [edit]auf seite 5 kommt ein Autoritätsbeweis, dann ertmall wieder Trollkot[/edit]

    0
  • O

    es stehen ein paar wichtige sachen dadrin, zb,dass c++ es drauf anlegt, dass klassen und strukturen sich wie jeder andere standardtyp verhalten können(Bruchklassen wie zahlen, komplexklassen wie zahlen,iteratoren wie pointer, vectoren wie arrays und noch viele andere Beispiele)
    der punkt ist, dass ein C_ oder sonst ein typ-präfix aus oben genannten gründen keinen platz mehr in c++ hat, typ-präfixe sind einfach überholt.
    andererseits kann man jetzt den "mehr platz" der im variablennamen entsteht, wenn die präfixe wegfallen dazu nutzen, endlich wirklich aussagekräftige Namen zu benutzen.

    ein weiterer grund sind die neuen namespaces,funktions überladung(ein name für x funktionen),die viel bessere Kapselung etc.
    Präfixe sind einfach eine altlast der programmierer aus früheren Tagen.

    0
  • C

    Hallo,

    die Tatsache, dass der Thread 11 Seiten hat, zeigt doch, dass da nicht so viel Einigkeit besteht.

    Präfixe sind einfach eine altlast der programmierer aus früheren Tagen.

    Ein Programm ist nicht besser oder schlechter, weil da ein C vor den Klassennamen steht. Es ist doch einfach eine Stilfrage, oder wer da so machen möchte, soll es doch in Gottes Namen tun.

    0
  • R

    C als Namensprefix ist schlecht weil:

    a) wird es bereits von einer großen und verbreiteten Library als Namespace Ersatz benutzt (ja, ich meine die MFC)
    b) gibt es in C++ Namespaces, mit der man so etwas lievber ersetzen sollte, wenn man Namenskonflikte vermeiden will
    c) ist ein Buchstabe nicht wirklich hilfreich dabei Namenskonflikte zu vermeiden, sonst wäre man nach 26 Librarys ja am Ende der Programmier Evolution 😉
    d) bringt es keinen Mehrwert, also auch keinen Grund, die oben genannten Probleme in kauf zu nehmen.

    Aber das wird hier gerade ziemlich OT

    0
  • O

    @CarstenJ
    wo hab ich geschrieben, dass programme mit nem C_ präfix schlechter sind?

    0
  • P

    ist ja mein topic 🙄
    Hab nochmal drin rumgestochert und so halbwegs ne Idee, was ich machen kann, ist aber etwas aufwendiger 😕

    und zum ot: if verwende 'C' nicht als namespace-ersatz, sondern als Klassen-Kennzeichnung. (reduzierte ungarische, sozusagen).

    Ich hab nunmal mit genug externem/existierendem Code (recht wenig MFC 🙂 ) zu tun, bei dem sich die "Klassen" nicht wie ein Standardtyp verhalten (un die Anforderungen sind auch hinreichend hoch...)

    0
Anmelden zum Antworten