Design splice: Iteratorvoraussetzungen

camper

Bei der Erweiterung der Liste von hier ist mir beim Vergleich des Standards mit n3242 ein interessantes Detail aufgefallen:

C++03 schrieb:

void splice(iterator position, list<T,Allocator>& x);
void splice(iterator position, list<T,Allocator>& x, iterator i);
void splice(iterator position, list<T,Allocator>& x, iterator first, iterator last);

in n3242 findet sich hingegen

n3242 schrieb:

void splice(const_iterator position, list<T,Allocator>& x) noexcept;
void splice(const_iterator position, list<T,Allocator>&& x) noexcept;
void splice(const_iterator position, list<T,Allocator>& x, const_iterator i) noexcept;
void splice(const_iterator position, list<T,Allocator>&& x, const_iterator i) noexcept;
void splice(const_iterator position, list<T,Allocator>& x, const_iterator first, const_iterator last) noexcept;
void splice(const_iterator position, list<T,Allocator>&& x, const_iterator first, const_iterator last) noexcept;

Der Wechsel von iterator zu const_iterator ist etwas unerwartet. Da in C++0x in jedem Fall das zugehörige Listobjekt in modifizierbarer Form mit angegeben werden muss, stellt das hier kein Problem dar.

Da ich in meiner Liste bewusst mit O(N)-size (aber dafür O(1) splice) arbeite, benötige ich die List-Objekte gar nicht.
Gegenwärtig arbeite daher mit

void splice(iterator position, iterator first, iterator last);

als freier Funktion.

Frage: ist ein wichter Use-Case denkbar, in dem nur const_iteratoren zur Verfügung stehen aber ein splice mit diesen Iteratoren nicht die const-Korrektheit verletzt?

Shade Of Mine

Ich bin gerade perplex. Ein const_iterator splice macht für mich einfach keinen Sinn. Das verletzt nur const correctness und sonst nix.

camper

Shade Of Mine schrieb:

Ich bin gerade perplex. Ein const_iterator splice macht für mich einfach keinen Sinn. Das verletzt nur const correctness und sonst nix.

Nicht beim Standardcontainer.

Ich bin am Überlegen, obe eine dritte Iteratorkategorie sinnvoll wäre, solange mir kein besserer Name einfällt, nenne ich ihn mal permutable_iterator.
Das wäre ein Zwischending ziwschen iterator und const_iterator (mit hin sind die Konvertierungen iterator -> permutable_iterator -> const_iterator möglich): der Elementzugriff ist const, aber es ist möglich, die Anordnung von Elementen zu ändern; er könnte z.B. also überall dort eingesetzt werden, wo Positionsangaben veranlagt werden. Erzeugt würde er primär über eine zusätzliches non-const begin bzw. end (könnte also z.B. mbegin, mend heißen).

Werner Salomon

Ein const_iterator besagt doch, dass man das Element, auf das der Iterator zeigt, nicht verändern kann. Er besagt nicht, ob der Container const ist oder nicht. Insofern erscheint mir die Änderung plausibel.
Ein Iterator hat nach meinem Verständnis auch nichts mit der Anordnung der Elemente zu tun - daher sehe ich auch keinen Bedarf für eine dritte Iteratorkategorie zwischen const und mutable.

Ein ähnliches Ding wäre ja dann der std::iter_swap. Der sollte dann auch mit einem const_iterator möglich sein. Zumindest in einer std::list - oder?

camper schrieb:

Frage: ist ein wichter Use-Case denkbar, in dem nur const_iteratoren zur Verfügung stehen aber ein splice mit diesen Iteratoren nicht die const-Korrektheit verletzt?

Vorstellbar wäre das, wenn eine Funktion oder ein Algorithmus existieren würde, der als Input die Liste erfordert und als Output nur const_iteratoren auf eben diese Liste zurück gibt. Das wäre vielleicht nicht std-like, aber natürlich möglich.

Gruß
Werner