Reply to thread

Message

[QUOTE="James Kanze, post: 3492158"]
[Nothing to do with your question, but...]

More usual would be:

struct MyContainer
    {
        //  ...
        Iterator begin() ;
        Iterator end() ;
    } ;

One of the goals of a naming convention should be to distinguish
typenames from all other symbols.

If you have generic function templates designed to work with
containers, you haven't quite caught philosophy of the standard
library.  Generic functions should be designed to work with
iterators.  Where the names of the critical functions are *, ++
and ==; it's blatant abuse of operator overloading, but it does
avoid any argument about naming conventions.

Certainly, when you want a name required by an external (to your
code) element, you conform to its requirements.  The standard is
just one example; you don't call pthreadCreate, either.

I actually find this one (very small) advantage of camel case:
the reader knows immediately, from the way the name is formed,
whether the intent is to conform with some external convention
or not.

Exactly.  The naming convention is part of the interface.
Without the interface requirements, you certainly wouldn't
overload ++ for an iterator, and without the interface
requirements, you might prefer the name ValueType, rather than
value_type.
[/QUOTE]

Verification