Validität von Iteratoren



  • Beachte das dieses define vermutlich die ABI ändert. Wodurch man keinen objekt code/statische library mischen kann wo ein teil das define aktiv hatte und ein teil dieses define nicht hatte als der objekt code übersetzt wurde.

    Mir stellt sich da eher die Frage was möchtest du denn überhaupt erreichen?

    Bei MS ist das AFAIK auch eher ein Debug feature und nichts was man in produktion code nutzen sollte.



  • @firefly sagte in Validität von Iteratoren:

    Mir stellt sich da eher die Frage was möchtest du denn überhaupt erreichen?

    Eine von einem Kunden erstellte stdlib checken. Da gehört laut Standard halt auch die Gültigkeit von Iteratoren dazu.



  • @Tyrdal sagte in Validität von Iteratoren:

    Da gehört laut Standard halt auch die Gültigkeit von Iteratoren dazu.

    Kannst du mal den Abschnitt nennen, auf den du dich da beziehst?



  • @wob Es geht um C++14 und Iteratoren können zum Beispiel beim Einfügen invalide werden.

    23.3.3.4 deque modifiers [deque.modifiers]
    iterator insert(const_iterator position, const T& x);
    iterator insert(const_iterator position, T&& x);
    iterator insert(const_iterator position, size_type n, const T& x);
    template <class InputIterator>
    iterator insert(const_iterator position,
    InputIterator first, InputIterator last);
    iterator insert(const_iterator position, initializer_list<T>);
    template <class... Args> void emplace_front(Args&&... args);
    template <class... Args> void emplace_back(Args&&... args);
    template <class... Args> iterator emplace(const_iterator position, Args&&... args);
    void push_front(const T& x);
    void push_front(T&& x);
    void push_back(const T& x);
    void push_back(T&& x);
    1 Effects: An insertion in the middle of the deque invalidates all the iterators and references to elements
    of the deque. An insertion at either end of the deque invalidates all the iterators to the deque, but has
    no effect on the validity of references to elements of the deque.
    2 Remarks: If an exception is thrown other than by the copy constructor, move constructor, assignment
    operator, or move assignment operator of T there are no effects. If an exception is thrown while
    inserting a single element at either end, there are no effects. Otherwise, if an exception is thrown by
    the move constructor of a non-CopyInsertable T, the effects are unspecified.
    3 Complexity: The complexity is linear in the number of elements inserted plus the lesser of the distances
    to the beginning and end of the deque. Inserting a single element either at the beginning or end of a
    deque always takes constant time and causes a single call to a constructor of T



  • Hmmm, vielleicht eigenen operator new für die tests schreiben oder einen Allocator benutzen und dann tatsächlich die Addressen prüfen?



  • @Tyrdal sagte in Validität von Iteratoren:

    @wob Es geht um C++14 und Iteratoren können zum Beispiel beim Einfügen invalide werden.

    Ja schon, aber wo fordert der Standard, dass man das (zur Laufzeit) überprüfen können muss?


  • Mod

    Was willst du jetzt testen? Ob die Iteratoren gültig bleiben, solange du keine der Aktionen durchführst? Ist natürlich schwierig, einen Gegenbeweis zu führen, dass etwas nicht passiert. Es ist zwar feststellbar, wenn man auf freigegebenen Speicher zurück greift, mit so Sachen wie valgrind (was im Prinzip so etwas wie ein eigener Allocator ist, aber du brauchst ihn dann nicht selber zu erfinden), aber bloß weil ein gültiges Programm damit sauber durchläuft, ist ja noch nicht bewiesen, dass dies allgemein gilt.

    Ich würde diesen Aspekt auch nicht so kritisch sehen. Es gibt ja einen Grund, warum es eine Liste gibt von Aktionen, die Iteratoren ungültig machen können. Das sind halt gerade die, wo es algorithmisch schwierig bis unmöglich wäre, es anders zu haben. Aber beweisen, ob vector.operator[] Iteratoren nicht zufällig doch ungültig macht? Da müsste der Implementierer ja schon absichtliche Sabotage betreiben, um mit einem Indexzugriff Iteratoren ungültig zu machen. Und das findest du dann eigentlich nur durch Codelesen, wenn jemand absichtlich Fehler versteckt.



  • @wob sagte in Validität von Iteratoren:

    @Tyrdal sagte in Validität von Iteratoren:

    @wob Es geht um C++14 und Iteratoren können zum Beispiel beim Einfügen invalide werden.

    Ja schon, aber wo fordert der Standard, dass man das (zur Laufzeit) überprüfen können muss?

    Nirgends, aber wenn man prüfen will ob der Standard eingehalten wurde wäre das nützlich.



  • @SeppJ sagte in Validität von Iteratoren:

    Was willst du jetzt testen?

    Ich will testen ob der Standard eingehalten wurde. Ungültigkeit von Iteratoren würde ich nicht testen wollen, aber die Gültigkeit nach bestimmten Aktionen ist ja vorgeschrieben.



  • @Tyrdal sagte in Validität von Iteratoren:

    Eine von einem Kunden erstellte stdlib checken

    Wenn du eine Implementierung der c++-Runtime testen möchtest, dann hilft dir "_SECURE_SCL" auch nichts. Denn "_SECURE_SCL" ist eine Feature der C++-Runtime, welches von MS implementiert wurde.
    Und hat nichts mit dem compiler zu tun.



  • Iteriere doch dann einfach über den Container und vergleiche mit dem zuvor verwendeten Iterator.
    Für bestimmte Container (wie z.B. vector<T>) reicht auch einfach:

    bool isValid = it >= begin(vec) && it < end(vec);
    


  • @Tyrdal: Hast du jetzt einen Test implementiert?



  • @Th69 sagte in Validität von Iteratoren:

    @Tyrdal: Hast du jetzt einen Test implementiert?

    Nein, weil ich sollte nur Hinweise liefern wie man das implementieren könnte. Das hab ich getan.


Anmelden zum Antworten