To nest or not to nest...

[mtbusche]

I'm writing a container class (call it C) and trying to decide whether I want my Iterator and ConstIterator classes to be defined as inner classes of C or stand-alone classes. I would like to hear what others consider to be advantages and disadvantages of the two approaches.

Here are some considerations that are perhaps peculiar to my situation:

1) C is logically subordinate to another class X and it is highly tempting to declare C an inner class of X. And then everything sits inside a namespace N. So my fully qualified iterator class names (following nesting to its logical end) become N::X::C::Iterator and N::X::C::ConstIterator. Such deeply nested class names bother me: they lead to compiler messages that are more difficult to read and are just plain harder to type. (Yes, I know you can "using namespace N" and "typedef X::C::Iterator MyIter", but still...) This deep structure tempts me to flatten everything to just N::X, N::C, N::CIterator, and N::ConstCIterator.

2) I intend to port this container to Java as well. In that language it is more typical to have iterators declared as stand-alone classes. Also, it would be nice to minimize the syntactic differences in the usage of the two implementations of my container. This gives me more motivation to not nest.

3) I am not necessarily trying to mimic STL container design (as foolish as that may be) and am certainly not trying to mimic Java container design (which I find fraught with flaws).

It occurs to me that choosing any iterator class names other than C::iterator and C::const_iterator could limit folks ability to use my container as an argument to some generic algorithm, but it seems far more typical to pass iterators into generic algorithms rather than the containers themselves; so I'm not sure this is in practice important at all.

Thanks for any insights you can offer,
Matt Busche

[Disch]

Pros to nesting the iterator in the container class:
- association is more clear
- reduce the possibility of name conflicts

Cons to nesting:
- slightly more typing (maybe).


For an example of the name conflict issue. Take a look at STL. The iterator classes themselves are just called 'iterator', but they're all different. You can't use a vector::iterator to iterator over a list, for example. What's more, vector<int>::iterator doesn't even work with vector<float>::iterator.

So if you take the iterator out of the class and make it global, now you have dozens of classes named "iterator". So which goes with which container? The logical solution to this would be to change the names to something like: "vector_iterator", "list_iterator", etc.

But if you do that, you don't save on any typing. So it's pointless.

So yeah -- my vote goes for nesting.

[mtbusche]

Disch,

Thankyou for your reply. If you'll note in my original post I did actually rename my iterator from Iterator to CIterator (to address the potential for naming conflicts when you pull the Iterator class out of the container class declaration). In my case C is logically subordinate to another class X. I feel I should either nest Iterator inside of C and nest C inside of X, or not use nesting at all. So the comparison is really

X::C::Iterator vs. CIterator

(And of course X and C aren't my actual class names: they are a tad longer than that.)

The thing that's most driving me away from the use of the inner class approach is my desire to have my C++ and Java implementations look as much alike as possible. And the idea of using an inner class for a Java iterator just seems alien to me. To me this is a matter of syntax and it is therefore difficult for me to form a strong opinion. I guess I'm searching for people that DO have a strong opinion and for them to give me the reasons for their position.

Thanks again,
Matt

[mik2718]

If something is going to be used a lot - I try to give it a short name.

I think this aids code readability.

So I'm voting for CIterator

Any more votes?