Ich habe mal wieder zwei Designfragen.

1. Frage:
Ich habe mich nun ernsthaft mal mit den Boost.Operators beschäftigt, nachdem pumuckl die Artikel geschrieben hat. Dabei habe ich mir zum Beispiel ein Hilfsmittel für Iteratoren geschrieben, welche auf einen Zeiger verweisen. Bevor jemand mit Boost.PtrContainer kommt, es geht nicht darum, dass der Container die Zeiger auch besitzt
Dabei enstand folgende Klasse mit Basisklassen. Ist sowas überhaupt noch lesbar? Ich habe es programmiert, ich kann es lesen, aber ob es andere können, würde mich in diesem Fall schon ein wenig interessieren. Natürlich bevorzugt Leute, welche sich mit Boost.Operators auskennen.

template<typename IterT>
class PtrIterator
	: public std::iterator<
		std::random_access_iterator_tag,
		typename boost::remove_pointer<
			typename std::iterator_traits<IterT>::value_type
		>::type
	>
	, boost::totally_ordered<PtrIterator<IterT>
	, boost::additive<
		PtrIterator<IterT>,
		typename std::iterator_traits<IterT>::difference_type
	, boost::indexable<
		PtrIterator<IterT>,
		typename std::iterator_traits<IterT>::difference_type,
		typename std::iterator_traits<IterT>::reference
	, boost::unit_steppable<PtrIterator<IterT>
	> > > >
{
  // ...

Die Schreibarbeit erleichtert es jedenfalls extrem. Trotzdem habe ich nicht schlecht gestaunt, als ich fertig war mit allen Basisklassen und Templateparametern hinschreiben. ->

2. Frage:
Bei Operatoren wie operator += benutzt ihr da auch die Copy&Swap Technik wie bei operator = ? Also zum Beispiel:

MyClass& operator +=(MyClass const& obj)
{
  MyClass copy(*this);

  // Addition auf copy durchführen.

  copy.swap(*this);
  return *this;
}

Ursprünglich habe ich es einfach naiv auch hier übernommen. Bei einem Profilertest kam dann aber heraus, dass hier extrem viel Performance verloren geht. Vor allem auch weil z.B. der operator + über operator += implementiert ist.

Inzwischen ist es draussen. Grundsätzlich dürfte auch keine Exception hier auftauchen bis auf std::bac_alloc , aber da stürzt mein Programm sowieso ab
Wenn doch eine Exception auftritt dann eine std::out_of_range , aber dann liegt ein Bug vor. Und meine Unit-Tests haben eigentlich gezeigt, dass alles geht. Also kann ich hier wohl darauf verzichten.

Aber wie ist es sonst? Führt ihr hier auch ein Copy&Swap durch? Weil ein operator += , bzw. ein operator + , wird wohl deutlich öfter vorkommen bei einer Zahlenklasse, als ein operator = . Zudem erscheint mir die Exceptionsicherheit bei einem operator + ziemlich nutzlos, da hier sowieso auf einer Kopie gearbeitet wird.

Grüssli

Zu 2: "+=" implementiere ich "direkt".

template<typename IterT>
class PtrIterator : public boost::random_access_iterator_helper<
                      PtrIterator<IterT>,  //operand type
                      typename boost::remove_pointer<
                        typename std::iterator_traits<IterT>::value_type
                      >::type,             //value type
                      typename std::iterator_traits<IterT>::difference_type,
                      typename std::iterator_traits<IterT>::pointer,
                      typename std::iterator_traits<IterT>::reference
                    >
{ /* ... */ };

Zu 2.: ziemlich sicher nicht. Wenns um Exceptionsafety geht halte ich bei op+= die copy&swap-Technik in den meisten Fällen für etwas grobschlächtig, meistens sind da auch nicht so viele potentielle throw-Kandidaten bei den nötigen Operationen für +=. Schließlich sind die Operatoren meistens für Klassen mit value-semantics gedacht, und die sind in der Regel nicht so super komplex aufgebaut und die nötigen Operationen haben fast sämtlich nothrow-Garantie.
Was hast du denn da für ne Klasse wo du das anwenden möchtest? (Vor allem wo es einen bad_alloc und out_of_range geben kann).

zum Lesen können: Ja - ich kann es lesen, und habe da auch weiter kein Problem mit.
Es wäre aber wesentlich einfacher zu lesen, wenn Du den 'boost.random_access_iterator_helper' benutzt, das verkürzt das Ganze dramatisch und enthält die benötigten Funktionalitäten.

zum Copy&Swap bei operator+=: Ich sage mal im Prinzip ja. Meistens lege ich aber nicht das ganze Objekt an, sondern nur z.B. einen std::vector, dessen Typ mit dem Aggregat meiner Klasse übereinstimmt - und swappe anschließend den std::vector.
Wenn Du die Performance mit den operator+-Geschichten&Co ernsthaft verbessern willst, bleibt Dir wahrscheinlich sowieso nur die Expression-Template-Technik.

Gruß
Werner

@pumuckl,
Es geht hier um BCD Zahlen (Marke Pseudoeigenbau). Die haben intern eine std::deque . Wenn nun addiert wird, kann die std::deque grösser oder kleiner werden. Beim "grösser werden" wäre es theoretisch möglich, dass ein std::bad_alloc geworfen wird. Bei std::out_of_range bin ich mir gar nicht mal sicher, ob das Ding überhaupt geworfen wird, da ich grundsätzlich per Iteratoren oder operator [] zugreife, welche sowas eigentlich nicht werfen. Aber irgendwie hatte ich es noch im Kopf, dass es eine Möglichkeit gibt. Aber will das jetzt nicht nachprüfen gehen. Theoretisch, also wenn keine Bugs vorhanden sind, sollte nichts geworfen werden.

@Werner Salomon,
Expression-Template-Technik? Wie es zum Beispiel Boost.Spirit oder Boost.Lambda machen?
Glaub ich weniger, dass dies was bringen würde. Problem ist halt die teuren std::deque Kopien. Es wäre eher eine Überlegung wert, die Speicherverwaltung zu optimieren. Aber bisher funktioniert es ziemlich gut, wenn ich einfach die Copy&Swap Technik fallen lasse, welche mir, wie schon gesagt, in diesem Fall etwas unnötig erscheint.

Ich erweitere aus Interesse noch die Frage 2:
Wie exzessiv setzt ihr eigentlich die Copy&Swap Technik ein? Schreibt ihr jedesmal euren eigenen operator = , statt der vom Kompiler generierten?

Grüssli

Zu random_access_iterator_helper :
Ihr vergesst, worum es hier geht. PtrIterator ist da, um einen normalen Iterator zu kapseln, ähnlich wie ein reverse_iterator . Daher müssen operator *() und operator ->() spezialsiert werden, so dass sie den zurückgegebenen Typ nochmals dereferenzieren. Keine Chance sowas mit random_access_iterator_helper hinzubekommen, zumindest habe ich keine sinnvolle gefunden

Meinst du einen iterator, der, wenn man ihn dereferenziert, das objekt zurückgibt, auf das der Pointer zeigt?

Meinst du einen iterator, der, wenn man ihn dereferenziert, das objekt zurückgibt, auf das der Pointer zeigt?

Ehm, wenn ich dich richtig verstanden habe, dann ja.
Ach, ein wenig Code sagt mehr als 1000 Worte:

std::vector<Foo*> vec;
// füllen

// Bisher:
typedef std::vector<Foo*>::iterator Iter;

{
  Iter iter = vec.begin();
  Iter end = vec.end();

  for(; iter != end; ++iter)
  {
    // -> würde ein Foo** zurückgeben.
    // Daher zuerst dereferenzieren, für ein Foo*
    // und danach den operator -> verwenden.
    (*iter)->bar();
  }
}

// Mit PtrIterator:
typedef PtrIterator<Iter> PtrIter;

{
  PtrIter iter = vec.begin();
  PtrIter end = vec.end();

  for(; iter != end; ++iter)
  {
    // -> gibt kein Foo** zurück, sondern ein Foo*
    // Klammerung fällt weg.
    iter->bar();
  }
}

Grüssli

Rest sollte tun...

Zu random_access_iterator_helper :
Ihr vergesst, worum es hier geht. PtrIterator ist da, um einen normalen Iterator zu kapseln, ähnlich wie ein reverse_iterator . Daher müssen operator *() und operator ->() spezialsiert werden, so dass sie den zurückgegebenen Typ nochmals dereferenzieren. Keine Chance sowas mit random_access_iterator_helper hinzubekommen, zumindest habe ich keine sinnvolle gefunden

Hallo Dravere,

bei allen boost::*_iterator_helper-Konstruktionen muss operator*() selbst implementiert werden. operator->() wird aus operator*() generiert. Eine Kapselung eines Iterators, der als value_type einen T* hat, zu einem, der ein T als value_type hat, ist da wirklich eine leichte Übung:

#include <iostream>
#include <vector>
#include <boost/operators.hpp>
#include <boost/type_traits/remove_pointer.hpp>

struct Foo
{
    void bar() { std::cout << "bar gerufen .." << std::endl; }
};

template< typename T >
class PtrIterator : public boost::random_access_iterator_helper< PtrIterator< T >, 
    typename boost::remove_pointer< typename std::iterator_traits< T >::value_type >::type >
{
public:
    typedef typename boost::remove_pointer< typename std::iterator_traits< T >::value_type >::type value_type;

    /* implicit */ PtrIterator( T base )
        : m_base( base )
    {}
    PtrIterator& operator++()
    {
        ++m_base;
        return *this;
    }
    value_type& operator*() const
    {
        return **m_base;
    }
    bool operator==( const PtrIterator& b ) const
    {
        return m_base == b.m_base;
    }
    PtrIterator& operator+=( std::ptrdiff_t off )
    {
        m_base += off;
        return *this;
    }

    // usw. operator--, operator-=

private:
    T m_base;
};

int main()
{
    using namespace std;
    vector< Foo* > v;
    v.push_back( new Foo );

    typedef std::vector< Foo* >::iterator Iter;
    typedef PtrIterator< Iter > PtrIter;
    for( PtrIter i = v.begin(); i != v.end(); ++i )
        i->bar();

    return 0;
}

.. funktioniert einwandfrei

Dravere schrieb:

Expression-Template-Technik? Wie es zum Beispiel Boost.Spirit oder Boost.Lambda machen?

boost.ublas ist so gemacht .. das kommt dem am nächsten, was ich meine.

Dravere schrieb:

Glaub ich weniger, dass dies was bringen würde. Problem ist halt die teuren std::deque Kopien.

Umso eher bringen die Expression-Template was - da fällt das Kopieren von temporären Kopien vollständig weg.

Dravere schrieb:

Ich erweitere aus Interesse noch die Frage 2:
Wie exzessiv setzt ihr eigentlich die Copy&Swap Technik ein? Schreibt ihr jedesmal euren eigenen operator = , statt der vom Kompiler generierten?

.. natürlich nur, wenn es notwendig ist. Ich setze Copy&Swap vornehmlich beim operator= ein, aber auch nur dann, wenn es 'swap'-bare Inhalte habe - also std::container oder ähnliches.

Gruß
Werner

Ich erweitere aus Interesse noch die Frage 2:
Wie exzessiv setzt ihr eigentlich die Copy&Swap Technik ein? Schreibt ihr jedesmal euren eigenen operator = , statt der vom Kompiler generierten?

Copy&swap nur wenns was zu swappen gibt. Ggf. kann man auch die swap-baren member in ein struct kapseln, dessen op= entsprechend implementieren und den Rest dem compilergenerierten op= überlassen.

Werner Salomon schrieb:

boost.ublas ist so gemacht .. das kommt dem am nächsten, was ich meine.

Kenne mich mit Boost.uBLAS überhaupt nicht aus. Werde es mir aber dann mal anschauen. Danke für den Hinweis.

Werner Salomon schrieb:

.. natürlich nur, wenn es notwendig ist.

Und die Frage ist halt eben, wann ist es notwendig?
Ich meine, Coyp&Swap wird doch in erster Linie dazu eingesetzt, um Exceptionsicherheit zu erzielen. Also keine ungültige Objekte zu erhalten, weil mittem im Kopiervorgang abgebrochen wurde.

Wenn ihr nun davon ausgehen könnt, dass keine Exception geworfen werden kann, ihr aber trotzdem swap-bare Inhalte habt, was macht ihr dann? Geht ihr auf Nummer sicher, weil es vielleicht in Zukunft Änderungen geben könnte und dadurch Exceptions geworfen werden?

Grüssli

Zu random_access_iterator_helper :
Ihr vergesst, worum es hier geht. PtrIterator ist da, um einen normalen Iterator zu kapseln, ähnlich wie ein reverse_iterator . Daher müssen operator *() und operator ->() spezialsiert werden, so dass sie den zurückgegebenen Typ nochmals dereferenzieren. Keine Chance sowas mit random_access_iterator_helper hinzubekommen, zumindest habe ich keine sinnvolle gefunden

Das erklärt wieso du boost::remove_pointer verwendest. Das hab' ich mich nämlich grad ca. 2 Minuten lang gefragt, bevor ich auf die gute Idee gekommen bin, mal die restlichen Beiträge zu lesen. (*)

---

z.T. Lesbarkeit: er. Wie sag ich das jetzt. Ich würde es als "ausreichen lesbar" bezeichnen. Oder als "entzifferbar". Einfach mal schnell drüberlesen ist nicht drin, es sei denn man kennt die verwendeten Klassen schon gut. Ansonsten muss man zumindest halt machen um mal den einen oder anderen "educated guess" zu machen, was die Template-Klasse XYZ wohl machen wird. Allerdings würde ich sagen dass das vollkommen ausreichen ist, solange verständlich ist, was die Klasse tut. Dann muss ich den Code nämlich garnicht lesen können, es sei denn ich suche Fehler, und das braucht dann sowieso seine Zeit.

*:
Ich würde allerdings einen anderen Namen vorziehen. "PtrIterator" klingt für mich nach einem Iterator der mit Hilfe eines Pointers implementiert ist. Was du machst würde ich wohl eher "DereferencingIterator" nennen.

Was += angeht: kommt drauf an denke ich. Wenn es dir reicht dass dein "PtrIterator" die selben Garantien bezüglich += abgibt wie der "underlying" Iterator, dann sollte ein einfaches weiterreichen an den "underlying" Iterator vollkommen ausreichen, so wie es Werners Code auch macht. Und dann wäre es IMO ziemlich sinnlos hier copy & swap zu verwenden -- selbst wenn es kein Performance-Problem gäbe.

---

BTW: du könntest das ganze noch flexibler machen. Pack die "Transformation" (Dereferenzieren) in eine Traits-Klasse, und implementiere die "TransformingIterator" Klasse so, dass sie auch mit forward oder bidi Iteratoren funktioniert
Dann könnte man z.B. ganz einfach Iteratoren basteln, die das "first" eines std::pair zurückgeben. Oder einen vollkommen sinnfreien, aber sicher lustigen "ROT13" Iterator für Strings machen. Oder halt einfach irgendwas

BTW: du könntest das ganze noch flexibler machen. Pack die "Transformation" (Dereferenzieren) in eine Traits-Klasse, und implementiere die "TransformingIterator" Klasse so, dass sie auch mit forward oder bidi Iteratoren funktioniert

guter Hinweis, da hätte ich auch gleich drauf kommen können .. und wenn man jetzt noch weiß, dass boost sowas schon fix & fertig anbietet, wird's übersichtlich:

#include <algorithm>
#include <functional>
#include <iostream>
#include <vector>
#include <boost/iterator/transform_iterator.hpp>

struct Foo
{
    void bar() { std::cout << "bar gerufen .." << std::endl; }
};

template< typename T >
struct DeRef : std::unary_function< T*, T& >
{
    T& operator()( T* p ) const
    {
        return *p;
    }
};

int main()
{
    using namespace std;
    vector< Foo* > v;
    v.push_back( new Foo );

    typedef std::vector< Foo* >::iterator Iter;
    typedef boost::transform_iterator< DeRef< Foo >, Iter > PtrIter;
    const PtrIter iEnd( v.end() );
    for( PtrIter i( v.begin() ); i != iEnd; ++i )
        i->bar();

    // bzw.:
    for_each( boost::make_transform_iterator( v.begin(), DeRef< Foo >() ),
        boost::make_transform_iterator( v.end(), DeRef< Foo >() ),
        std::mem_fun_ref( &Foo::bar ) );

    // oder mal total einfach und ohne boost
    for_each( v.begin(), v.end(), std::mem_fun( &Foo::bar ) );

    return 0;
}

und wenn man noch bedenkt, dass die boost::bind-Konstrukte sowohl mit Pointern als auch mit Referenzen zusammenarbeiten (als Alternative zu std::mem_fun[ref]), dann braucht man so einen PtrIterator gar nicht mehr.

Gruß
Werner

Ich würde allerdings einen anderen Namen vorziehen. "PtrIterator" klingt für mich nach einem Iterator der mit Hilfe eines Pointers implementiert ist. Was du machst würde ich wohl eher "DereferencingIterator" nennen.

Über die Namenswahl reden wir hier nicht ...
Ich bin ein grauenhaft schlechter Namenswähler. Sieht man auch sehr gut an den Namen meiner Programme ...

hustbaer schrieb:

Dann könnte man z.B. ganz einfach Iteratoren basteln, die das "first" eines std::pair zurückgeben. Oder einen vollkommen sinnfreien, aber sicher lustigen "ROT13" Iterator für Strings machen. Oder halt einfach irgendwas

Das war aber nicht mein Ziel, mich hat nur dieses (*iter)-> gestört *g*
Die Idee ist aber wirklich gut.

Werner Salomon schrieb:

.. und wenn man jetzt noch weiß, dass boost sowas schon fix & fertig anbietet, ...

Was bietet Boost eigentlich nicht an? Ich habe das Gefühl ich lerne über Boost jedesmal was neues. Das ist noch schlimmer als mit C++ selbst

Werner Salomon schrieb:

und wenn man noch bedenkt, dass die boost::bind-Konstrukte sowohl mit Pointern als auch mit Referenzen zusammenarbeiten (als Alternative zu std::mem_fun[ref]), dann braucht man so einen PtrIterator gar nicht mehr.

Da liegst du falsch. Gut, ich hätte vielleicht irgendwie den einen Algorithmus umbauen können, so dass ich ihn über eine for_each Funktion nehmen kann, aber das wäre mir persönlich zu aufwendig gewesen. Manchmal tut es auch eine schöne altmodische for-Schleife. Man muss ja nicht immer auf Teufel komm raus die Algorithmen aus der Standardbibliothek einsetzen. Daher kann sowas schon sinnvoll sein. Wenn es auch nur zur "Verschönerung" dient. Ich wollte damit wirklich nur das (*iter)-> zu einem iter-> umwandeln.

Aber nochmals zurück zum Ursprung. Frage 1 wäre inzwischen wohl geklärt. Da hat meine Reaktion doch irgendwo was sinnvolles bewirkt und das Nachfragen war eine gute Idee

Die Antworten auf Frage 2 reichen mir irgendwie noch nicht so ganz. Zum einen wäre eine Antwort auf diese Fragen noch nett:

Dravere schrieb:

Wenn ihr nun davon ausgehen könnt, dass keine Exception geworfen werden kann, ihr aber trotzdem swap-bare Inhalte habt, was macht ihr dann? Geht ihr auf Nummer sicher, weil es vielleicht in Zukunft Änderungen geben könnte und dadurch Exceptions geworfen werden?

Auch begreife ich nicht ganz, wieso ihr kein Copy&Swap anwenden würdet, wenn es keine swap-baren Member hat. Oder arbeitet ihr dann einfach zuerst auf einer Kopie und weist die Member der Kopie dann einzeln zu, statt einen swap auszuführen? Ich meine, auch bei nicht swap-baren Inhalten kann eine Exception fliegen.

Grüssli

Dravere schrieb:

Wenn ihr nun davon ausgehen könnt, dass keine Exception geworfen werden kann, ihr aber trotzdem swap-bare Inhalte habt, was macht ihr dann? Geht ihr auf Nummer sicher, weil es vielleicht in Zukunft Änderungen geben könnte und dadurch Exceptions geworfen werden?

Auch begreife ich nicht ganz, wieso ihr kein Copy&Swap anwenden würdet, wenn es keine swap-baren Member hat. Oder arbeitet ihr dann einfach zuerst auf einer Kopie und weist die Member der Kopie dann einzeln zu, statt einen swap auszuführen? Ich meine, auch bei nicht swap-baren Inhalten kann eine Exception fliegen.

Aaalso.
Möglichkeit 1: Wenn ich ein simples struct mit nur wenigen Membern hab, also ein "bundle-of-data", lass ich den op= weg. Den Copy-Ctor auch. Ggf. kommt ein Kommentar hin damit offensichtlich ist, dass ich ihn nicht einfach vergessen hab.
Möglichkeit 2: Ich hab eine Klasse, die einen Copy-Ctor hat. Meist lohnt sich dann ein swap und damit ist C&S ein Dreizeiler.
Möglichkeit 3: Der Profiler sagt mir dass Copy&Swap zu komplex ist, dann kümmere ich mich persönlich drum.

Alles zusammen ist es Schema-F, und das ist auch gut so - Schema-F gibt beim späteren Lesen keine Überraschungen.

Irgendwie ist der meiste Code mit boost immer potthässlich.

Das hat Code mit Templates und vielen Templateparametern allgemein an sich.

hustbaer schrieb:

BTW: du könntest das ganze noch flexibler machen. Pack die "Transformation" (Dereferenzieren) in eine Traits-Klasse, und implementiere die "TransformingIterator" Klasse so, dass sie auch mit forward oder bidi Iteratoren funktioniert

guter Hinweis, da hätte ich auch gleich drauf kommen können .. und wenn man jetzt noch weiß, dass boost sowas schon fix & fertig anbietet, wird's übersichtlich:

Cool. Die Klasse kannte ich auch noch nicht. Hab aber schon halb damit gerechnet dass es sowas in der Boost gibt.