void do_smth_with_me(type_t *p, size_t s)
  ...

Also eine klare Situation: Hier soll über ein Array iteriert werden. Jetzt die Frage, wie macht man das in C++? Genau so? Das wäre aber doof, da inkompatibel mit vielen Standard-Containern. Aber macht eine generische Schnittstelle mit Iteratoren Sinn? Denn im Endeffekt sollen die Iteratoren zwar egal sein, aber die Dereferenzierung muss ja ein bestimmter Typ sein. Also ist die Funktion irgendwie doch kein "richtiger" Template-Kandidat. Wie macht ihr das?

Deine Einwände gegen Iteratoren und Templates verstehe ich nicht.

Deine Einwände gegen Iteratoren und Templates verstehe ich nicht.

struct Good
{
  void FooBar()
  {
    std::cout << "Hallo!\n";
  }
};

struct Bad
{
  void FooBar()
  {
    std::cout << "Fail!\n";
  }
};

template<class InputIterator>
void foo(InputIterator first, InputIterator last)
{ // Ist nur für Good gedacht.
  for (; first != last; ++first);
    first->FooBar();
}

int main()
{
  std::vector<Bad> v(10);
  foo(v.begin(), v.end()); // Fail. Und es gibt nicht mal einen Compiler-Fehler.
}

Oder übersehe ich da was?
Und auch wenn man bei diesem Beispiel schon Pech haben muss, mein Problem mit dieser Methode ist einfach, dass man der Funktion quasi jeden "Mist" übergeben kann, wäre es nicht schöner, wenn man irgendwie von außen zeigen könnte, dass sie nur für eine bestimmte Klasse ist?

[...] aber die Dereferenzierung muss ja ein bestimmter Typ sein.

Ist ja nicht schlimm. Das wäre eine Sache für die Dokumentation. Da sagst Du dann, "Iteratoren für eine type_t-Sequenz" oder so. Wenn man das Funktionstemplate dann anders benutzen wollen würde, gibt es eben einen Fehler zur Cmopile-Zeit (duck typing zur compile zeit).

Wenn Du das Funktionstemplate allerdings schon vor der Überladungsauflösung wegschmneißen willst, wenn eine bestimmte Bedingung nicht erfüllt ist (constraining), dann könntest Du das per enable_if machen:

[b]template<class Iter>[/b]
typename boost::enable_if<
  boost::is_same< typename iterator_traits<Iter>::value_type, type_t >
,[b]void[/b]>::type [b]do_smthing(Iter beg, Iter end)
{
  ___
}[/b]

[...]
int main()
{
  std::vector<Bad> v(10);
  foo(v.begin(), v.end()); // Fail. Und es gibt nicht mal einen Compiler-Fehler.
}

Oder übersehe ich da was?

Was soll denn sonst passieren? Was gibt es denn besseres als einen Fehler zur Compile-Zeit?

vll schrieb:

Und auch wenn man bei diesem Beispiel schon Pech haben muss, mein Problem mit dieser Methode ist einfach, dass man der Funktion quasi jeden "Mist" übergeben kann,

Geht ja nicht. Hast Du selbst gezeigt.

vll schrieb:

wäre es nicht schöner, wenn man irgendwie von außen zeigen könnte, dass sie nur für eine bestimmte Klasse ist?

Dafür ist Dokumentation gut. In Form von selbstdokumentierenden C++ Code lässt sich das noch nicht ausdrücken -- es sei denn, du zählst das "SFINAE" constraining dazu (siehe mein vorheriges Beispiel). Aber so leserlich ist das nicht wirklich. Man kann es aber dazu verwenden, Compiler-Fehlermeldungen zu kürzen und Überladungs-Mehrdeutigkeiten zu entfernen.

Du bist aber nicht der einzige, der diese Bedingungen "nativ" ausdrücken können möchte. Beispiel:

template<[b]InputIterator[/b] Iter>
[b]requires SameType<Iter::value_type,type_t>[/b]
void do_smthing(Iter beg, Iter end)
{
___
}

So eine Spracherweiterung ist aber noch nicht 100% zu Ende gedacht. Vielleicht kommt das irgendwann nochmal beim nächsten Sprachstandard.

Was soll denn sonst passieren? Was gibt es denn besseres als einen Fehler zur Compile-Zeit?

Einen Fehler vor der Template-Auflösung. Aber ich glaube, dir ist nicht bewusst, dass das Beispiel oben anstandslos kompiliert?

krümelkacker schrieb:

Was soll denn sonst passieren? Was gibt es denn besseres als einen Fehler zur Compile-Zeit?

Einen Fehler vor der Template-Auflösung. Aber ich glaube, dir ist nicht bewusst, dass das Beispiel oben anstandslos kompiliert?

Richtig. Ich habe es nur überflogen und Deinen "Fail"-Kommentar als Compile-Zeit-Fehler interpretiert. Nächste Frage: Ist es schlimm, dass es kompiliert?

Wie gesagt: Constraining geht -- aber eben mit Tricks statt direkter Sprachunterstützung.

struct type_t
{
  void smth()
  {
    std::cout << "I am a type_t\n";
  }
};

struct something_like_type_t
{
  int smth() const
  {
    std::cout << "No type_t, but can do smth, too\n";
    return 1;
  }
};

template <class Iterator>
void do_smth_with_me(Iterator first, Iterator last)
{
  while (first != last)
    (first++)->smth();
}

int main()
{
  std::vector<type_t> real(3);
  std::deque<something_like_type_t> fake(2);

  do_smth_with_me(real.begin(), real.end());
  do_smth_with_me(fake.rbegin(), fake.rend());
}

Alternativ, wenn du wirklich nur type_t als value_type zulassen willst, kannst du das je nach C++-Version absichern:

#include <iterator>
#if defined(HAS_0X_TYPE_TRAITS)
  #include <type_traits> //C++0x
  using std::is_same; //C++0x
#elif defined(HAS_TR1_TYPE_TRAITS)
  #include <type_traits> //TR1
  using std::tr1::is_same; //TR1
#endif

#ifdef HAS_NO_0X_STATIC_ASSERT
  #include <boost/static_assert.hpp> //boost
#endif

void do_smth_with_me(Iterator first, Iterator last)
{
  const static bool is_type_t = is_same<type_t,std::iterator_traits<Iterator>::value_type>::value;
  static_assert(is_type_t, "must be type_t"); //C++0x
  BOOST_STATIC_ASSERT_MSG(is_type_t, "must be type_t"); //boost
  while (first != last)
    (first++)->smth();
}

Die HAS_xy-Makros hab ich frei erfunden, es gibt aber z.B. in Boost.Configuration ähnliches.

void do_something(any_input_iter<const type_t> begin, any_input_iter<const type_t> end);

wobei dann "any_inut_iter" ein Klassen-Template ist, was den tatsächlichen Iterator-Typ versteckt. Für Iteratoren ist das aber recht unpopulär. Bei Funktionsobjekten sieht das schon anders aus:

void function_sink(boost::function<double(double,double)> func)
{
  double x = func(2.7,3.1);
  ...
}

template<class InputIterator>
void foo(InputIterator first, InputIterator last)
{ // Ist nur für Good gedacht.
  for (; first != last; ++first);
    Good(*first).FooBar();
}

Die Fehlermeldung ist auch gut:

cannot convert from 'Bad' to 'Good'

Edit:
Wobei man Annahmen über den Konstruktor machen muss..

Dein Beispiel:

struct Good
{
  void FooBar()
  {
    std::cout << "Hallo!\n";
  }
};

struct Bad
{
  void FooBar()
  {
    std::cout << "Fail!\n";
  }
};

// myclass.hpp
class MyClass
{
public:
  template<class InputIterator>
  void foo(InputIterator first, InputIterator last)
  { // Ist nur für Good gedacht.
    for (; first != last; ++first);
      foo(*first);  // geht nur mit Good
  }
  template<class InputIterator>
  void add(InputIterator first, InputIterator last)
  { // Ist nur für Good gedacht.
    myGoods.insert(myGoods.end(), first, last);  // geht nur mit Good
  }
private:
  void foo(Good&);
  std::vector<Good> myGoods;
};

template<class InputIterator>
  void foo(InputIterator first, InputIterator last)
  { // Ist nur für Good gedacht.
    for (; first != last; ++first);  // <-- hier!
      foo(*first);  // geht nur mit Good
  }

... Das wäre dann ein Fall von statischer Polymorphie.

struct type_t
{
  void smth()
  {
    std::cout << "I am a type_t\n";
  }
};

struct something_like_type_t
{
  int smth() const
  {
    std::cout << "No type_t, but can do smth, too\n";
    return 1;
  }
};

template <class Iterator>
void do_smth_with_me(Iterator first, Iterator last)
{
  while (first != last)
    (first++)->smth();
}

int main()
{
  std::vector<type_t> real(3);
  std::deque<something_like_type_t> fake(2);

  do_smth_with_me(real.begin(), real.end());
  do_smth_with_me(fake.rbegin(), fake.rend());
}

(Info: bin noch nicht so lange mit C++ zu gange, komme aus der C#-Welt)
Ist das überhaupt ein guter Programmier-Stil? Auf den ersten Blick sah das für mich nach Duck Typing aus und statische-polymorphie war vorher für mich noch nicht einmal ein begriff.
Also, meine eigentliche frage: Gilt sowas überhaupt als Schnittstelle? eigentlich ist das doch nur ein Compiler-Feature, welches bei nicht 100% Know-How nur zu solch unnötig komplizierten Fehlern/Fragen kommt?!
Meiner Meinung nach (lasse mich natürlich übereden!) ist die Verwendung durch dynamische Polymorphie (sprich, die Verwendung von "richtigen" Schnittstellen) die bessere Variante, oder nich?

Mir ist noch etwas eingefallen. Es gibt auch "polymorphe" Iteratoren. Das, was da per type-eraures versteckt wird, ist der Container-Typ, nicht aber der Element-Typ.

void do_something(any_input_iter<const type_t> begin, any_input_iter<const type_t> end);

(...)

Was mich dabei stört, ist, dass die Performance gröber darunter leidet.
Iteratoren werden überall als "cheap to copy" verwendet, da normale Iteratoren eben auch billig zu kopieren sind.

Bloss polymorphe Iteratoren sind nicht billig zu kopieren. Zumindest dann nicht, wenn sie keine "Small Object Optimization" ala boost::function enthalten, und die ist leider gar nicht trivial korrekt zu implementieren.

Ich hab' daher in meinen Projekten bisher immer abstrakte "Enumeratoren" verwendet:

template <class T>
class AbstractEnumerator
{
public:
    virtual void Reset() = 0;
    virtual void MoveNext() = 0;

    virtual bool HasCurrent() const = 0;
    virtual T& GetCurrent() const = 0;
};

template <class T, class I>
class IteratorPairEnumerator
{
    // ...
};

void do_something(AbstractEnumerator<const type_t>& enumerator);

Das ist jetzt nicht so "C++ig", aber ist einfach umzusetzen und funktioniert.

Wenn ich mich richtig erinnere, müsste ich mal zum Spaß eine "any_range" nach dem range-Konzept von Alexandrescu geschrieben haben.

Sicher, man kann nicht alles haben. Ich bin da jetzt auch kein Fan von solchen Iteratoren. Spätestens der Vergleich current!=end wird ekelig, wenn man erstmal per typeid testen muss, ob die überhaupt kompatibel sind.

Wieso, der type_info Vergleich ist ja kein Problem.

Ich gehe davon aus, dass alle vernünftigen Compiler erstmal checken ob die Adresse der beiden type_info Instanzen gleich ist, "succeed fast" sozusagen. Und dann erst anfangen die Namens-Strings oder was auch immer zu vergleichen.

Falls man wirklich ein System hat wo der Vergleich zu lange dauert, kann man den "succees fast" Teil selbst basteln: Type-ID-Helper-Template das ne statische Variable hält, die Adresse dieser verwendet man als "fast typeid". Normalerweise würde das schon ausreichen, aber da man vermutlich auch Systeme unterstützen will die sowas wie DLLs kennen, macht man im "Adressen ungleich" Fall noch einen zusätzlichen Test über typeid().

Da der "Adressen gleich" Fall der interessante ist (weil genau der am häufigsten vorkommen wird), sollte das reichen.

Ganz abgesehen davon dass es AFAIK sowieso UB ist zwei Iteratoren zu vergleichen die nicht vom selben Container kommen. D.h. man müsste diese Tests nur in Debug-Builds machen - Release-Builds lässt man einfach schön in UB reinlaufen.