3. Linker: Templates + .cpp Datei = böse?

Linker: Templates + .cpp Datei = böse?

  • M

    ipsec schrieb:

    Kleine Anmerkung zum Code: statt InputIterator::value_type solltest du besser std::iterator_traits<InputIterator>::value_type verwenden.

    weshalb ?

    Meep Meep

    0
  • C

    Weil auch reine Pointer als Iteratoren verwendet werden könnten - und die haben keine Typedefs für Werttyp etc. (iterator_traits<> sammelt diese Hilfstypen je Iteratorklasse - die Standardversion verwendet It::value_type etc, aber eine Spezialisierung für Pointer überschreibt die Angaben)

    0

  • Der Standard schreibt vor dass std::iterator_traits<InputIterator>::value_type funktionieren muss.
    Er schreibt nicht vor dass InputIterator::value_type funktionieren muss (und funktioniert auch nicht, z.B. für Zeiger wie CStoll schon geschrieben hat).

    Und man sollte sinnvollerweise das verwenden, was laut Standard funktionieren muss, und nicht das, was bloss zufälligerweise manchmal funktioniert.

    EDIT: sollte man nicht überhaupt std::iterator_traits<InputIterator>::pointer statt std::iterator_traits<InputIterator>::value_type* verwenden?

    0
  • P

    hustbaer schrieb:

    EDIT: sollte man nicht überhaupt std::iterator_traits<InputIterator>::pointer statt std::iterator_traits<InputIterator>::value_type* verwenden?

    Ja, sollte man 🙂

    0
  • 3

    Gibts dafür einen Grund? In der Funktion selbst werfe ich ja sowieso Zeiger rein.

    0
  • P

    314159265358979 schrieb:

    Gibts dafür einen Grund? In der Funktion selbst werfe ich ja sowieso Zeiger rein.

    Wenn du irgendwo in dem Funktionstemplates etwas machst, das nur mit rohen Zeigern funktioniert, dann kannst du auch value_type* lassen. Wenn (rein theoretisch) InputIterator::pointer auch ein anderer pointer-Typ sein kann und das dem Funktioniere des Templates keinen Abbruch tut, dann wäre es unnötig, durch Einschränkung des Typen auf value_type* die Verwendbarkeit einzuschränken.

    0

  • std::iterator_traits<InputIterator>::pointer kommt doch ursprünglich von dem ganzen near/far Gedöns, nicht?
    Wobei man natürlich auch Smart-Pointer erlauben könnte.

    0
  • O

    Der Standard erlaubt gar keine proxies in den Containern (mal vom Beschiss in vector<bool> abgesehen). Daher muss eigentlich(!) pointer_type = value_type* sein, genauso wie reference_type = value_type* (wie gesagt, bis auf den beschiss in vector<bool>). Ausserdem gibt kein container irgendwo pointer_type zurück. von daher...

    0
  • C

    Hast du schonmal daran gedacht, daß auch Dinge außerhalb des C++ Standards existieren, die in der Lage sind, STL-taugliche Iteratoren zu liefern?

    (PS: Wenn schon, dann ist reference == value_type& ;))

    0
  • N

    314159265358979 schrieb:

    pimpl kommt nicht in Frage, dafür ist eine Heap-Allokation erforderlich, und die ist zu teuer.

    Manchmal kommst du um Pimpl nicht herum, wenn du Abhängigkeiten verringern willst. Verwende in diesen Fällen einen speziellen Allokator.

    pumuckl schrieb:

    Das war "export", was das Gegenteil von neu, nämlich deprecated ist.

    "removed" triffts besser, export ist bald Geschichte 🙂

    0

  • otze schrieb:

    Der Standard erlaubt gar keine proxies in den Containern (mal vom Beschiss in vector<bool> abgesehen). (...)

    Wer spricht denn von Proxies?

    Referenz != Zeiger
    std::iterator_traits<T>::reference != std::iterator_traits<T>::pointer

    IIRC gibt es keine Container-Funktionen die einen Zeiger zurückliefern würden. Von daher kann es auch keine "Proxy-Zeiger" geben.
    Trotzdem ermöglicht std::iterator_traits<T>::pointer es z.B. einen T __far* statt eines einfachen T* zu verwenden.

    0
Anmelden zum Antworten