Boost logo

Boost :

From: jsiek_at_[hidden]
Date: 1999-12-08 12:02:07

Didn't have time to write this earlier...

Here's one last argument for operator[] for the property accessors.
So the main reason Dietmar does not like operator[] is that you need a
proxy class to implement the various semantic flavors that are needed.
And the requirements for this operator in iterators (containers too?)
rules out proxies. I would argue that the requirements for standard
iterators has nothing to do with property accessors (unlike the
adjacency iterators, which are iterators and should be usable with
existing STL algorithms). I've never claimed that property accessors
could be random_access_iterators or any kind of iterator, far from it.
They only have operator[] and none of the other ops (++,+=,+, etc.).
So there is no danger of people trying to use property accessors when
they should be using random access iterators. The use of proxies in
property accessors will not break any existing code, since there is
not any existing code currently using PropertyAccessor. As long as we
define PropertyAccessor in a strick enough fashion, there should be no
problem with the operator[] in future generic graph codes.

Now one of the nice things about operator[] is that going the other
way, using random_access_iterators for property accessors, will work
for free (at least when the node descriptor is an integral type).
Using arrays for property storage is one of the most common and also
efficient methods, so I see a real benefit in making this easy.

And lastly, the operator[] results in code that is intuitive and easy
to understand. We are all very use to the operator[] for mapping from
one thing to another. Furthermore, operator[] is commonly used in the
graph literature and textbooks.



 Jeremy Siek
 Ph.D. Candidate email: jsiek_at_[hidden]
 Univ. of Notre Dame work phone: (650) 933-8724
 and cell phone: (415) 377-5814
 C++ Library & Compiler Group fax: (650) 932-0127
 SGI www:

Boost list run by bdawes at, gregod at, cpdaniel at, john at