2016-07-19 9 views
12

Rozumiem, że standard pozwala, aby std::vector<int, A> miał ten sam typ iteratorów dla różnych alokatorów A. Nazywa się to SCARY iterators.Czy super-SCARY iteratory są legalne?

Teraz pytanie brzmi, czy standard pozwala std::vector<int, A>::iterator być po prostu typedef z A::pointer, czyniąc go po prostu int* dla domyślnego przydziału?

Czy jest jakiś wymóg (domyślny), aby był oddzielnym typem klasy dla kontenera? Jeśli nie ma takiego wymogu, to dlaczego wszystkie główne wdrożenia (w tym SCARY) nie korzystają z tego podejścia? Prawdopodobnie zredukuje to pracę kompilatora, ale teraz kod, który zostanie przeciążony na int* i vector<>::iterator, nie zostanie skompilowany.

+11

Być może niektóre nie wiedzą o [SCARY iterators] (http: // stackoverflow.com/questions/14391705/what-are-scary-iterators) i głosują, zakładając, że tak naprawdę nie istnieją? To jedyna rzecz, o której mogę pomyśleć ... – jaggedSpire

+2

Co sprawia, że ​​jest "super" STRASZONY? – zneak

+1

@zneak: "typowe" iteratory SCARY oznaczają, że nadal są tradycyjną klasą, która jest po prostu zdefiniowana poza klasą szablonową. Przez "super" mam na myśli to, że jest to jeden poziom SCARYer niż te :) Zasadniczo oznacza to, że 'std :: vector',' std :: array' oraz 'std :: initializer_list' mogą współdzielić ten sam typ iteratora ... – ybungalobill

Odpowiedz

5

Teraz pytanie brzmi, czy średnia pozwalają std::vector<int, A>::iterator być po prostu typedef z A::pointer, co czyni go tylko int* dla domyślnego podzielnika?

Nie na podstawie jakiejkolwiek implementacji, tak myślę.

24,2 wymagania Iterator [iterator.requirements]

24.2.1 W ogólnym [iterator.requirements.general]

11 W poniższych rozdziałach a i b oznaczają wartości typ X lub const X, [...]

24.2.7 Losowe dojścia S iteratory [random.access.iterators]

 
Expression | Return type | Operational | Assertion/note 
      |    | semantics | pre-/post-condition 
-----------+----------------+-------------+-------------------------------- 
[...] 
-----------+----------------+-------------+-------------------------------- 
a < b  | contextually | b - a > 0 | < is a total ordering relation 
      | convertible to |    | 
      | bool   |    | 

Należy zauważyć, że w przeciwieństwie do wcześniejszych wymagań w -, nie jest to warunkiem koniecznym <a i b są iteratory w tym samym pojemniku. < jest wymagany, aby utworzyć całkowitą relację zamawiania dla dowolnych iteratorów. < nie jest wymagany, aby utworzyć całkowitą relację zamawiania dla dowolnych wskaźników. Chociaż implementacje mogą rozszerzać definicję < dla typów surowych wskaźników, aby umożliwić porównywanie niepowiązanych wartości wskaźników, popularne popularne implementacje w świecie rzeczywistym tego nie robią, ponieważ takie rozszerzenie uniemożliwiłoby pewne możliwości optymalizacji.

+0

Hmm, ale wskaźniki mają zawsze spełniać te same wymagania co Iteratory dostępu swobodnego. Czy oni nie są? Być może wymóg "całkowitego zamówienia" jest błędem w standardzie? – ybungalobill

+3

Uważam, że wymóg "całkowitego zamówienia" jest błędem w standardzie –

+0

Z jednej strony, jeśli nie było to wymagane, powinno być przynajmniej wymagane dodatkowe wymaganie dotyczące 'std :: less', które tworzy całkowita kolejność dla iteratorów i wskaźników, ale to tylko dla wskaźników. Z drugiej strony tekst zdecydowanie sugeruje, że typ wskaźnika może implementować wymagania dla iteratorów dostępu swobodnego. Nie wierzę, że to błąd. Nie wierzę, że to nie jest błąd. Po prostu nie wiem, co to jest zamiar. Mogę tylko wyciągnąć wnioski na temat tego, co zostało napisane, a nie tego, co zostało pomyślane. – hvd

7

Re

robi średnia pozwalają std::vector<int, A>::iterator być po prostu typedef z A::pointer

O ile mi wiadomo, tak. Ale nie std::vector<bool, A>, ponieważ jest to specjalizacja, w której iterator z dereferencjami jest obiektem proxy, który uzyskuje dostęp do dowolnej reprezentacji, z zamiarem wspierania jednego bitu na bool.

+0

+1 dla catch 'vector ', chociaż jest to oczywiście nie-ciekawy przypadek z perspektywy pytania :) – ybungalobill

Powiązane problemy