Adding iterators to a class template

This is a discussion on Adding iterators to a class template within the C++ Programming forums, part of the General Programming Boards category; I am trying to add an iterator to a class template. The class is not much more than an encapsulated ...

Adding iterators to a class template

I am trying to add an iterator to a class template. The class is not much more than an encapsulated standard library vector, which some added features. The compiler chokes pretty hard on the snippet below. Any tips appreciated, or just point me towards an online example of this somewhere. Much thanks!

That works much better. Thanks, although I actually don't understand what the addition of the typename keyword does.

Wouldn't returning a reference to a vector then be implementation dependent? If I want to be able to change my implementation to be, say, a linked list for a sparse polynomials, the caller's code could be in trouble if it assumed a vector.

That works much better. Thanks, although I actually don't understand what the addition of the typename keyword does.

Wouldn't returning a reference to a vector then be implementation dependent? If I want to be able to change my implementation to be, say, a linked list for a sparse polynomials, the caller's code could be in trouble if it assumed a vector.

typename tells the compiler that the name that follows it is a type rather than something else like a function or variable name...

I agree with you there; exposing the vector rather than typedefing it away makes it much harder to change to something else once other code starts using it.

That works much better. Thanks, although I actually don't understand what the addition of the typename keyword does.

Wouldn't returning a reference to a vector then be implementation dependent? If I want to be able to change my implementation to be, say, a linked list for a sparse polynomials, the caller's code could be in trouble if it assumed a vector.

Properly generic code won't care what the type is. In particular, this example doesn't care what the type is:

typename tells the compiler that the name that follows it is a type rather than something else like a function or variable name...

I assume that since I can figure out that it is a typename without the help of the extra keyword, this means that the compiler parser needs more than one token of look-ahead in order to figure out what is going on? Or is there some other meaningful interpretation of the code that I am missing when the typename keyword is omitted?

I assume that since I can figure out that it is a typename without the help of the extra keyword, this means that the compiler parser needs more than one token of look-ahead in order to figure out what is going on? Or is there some other meaningful interpretation of the code that I am missing when the typename keyword is omitted?

There are at least a few obscure cases where a code fragment could be syntactically correct whether the named entity is a typename or an identifier. These cases are why typename was invented. For consistency, it was decided that it should be required everywhere when looking up dependent typenames inside template scopes.

Consider this case:

Code:

typename A<X>::B foo() { }

Although it is obvious that A<X>::B can be nothing other than a typename (since an identifier is not legal as the return type of a function), we are required to use it anyway. Just how it is.

Wouldn't returning a reference to a vector then be implementation dependent? If I want to be able to change my implementation to be, say, a linked list for a sparse polynomials, the caller's code could be in trouble if it assumed a vector.

You just specify that the terms() method returns a reference to some container type. Make this type available to the caller as "typedef whatever terms_container_type" or some other name.

Then the caller understands that a terms_container_type is returned, whatever that happens to be.

This does force at least a recompile of client software if/when you change the implementation, but that's true whenever you change even the private details of a class (unless you are using the "pimpl" idiom).