Comments solicited about stylistic preference

[phdscholar80]

I have the habit of using the scope resolution operator whenever I use
global functions. My premise is that it improves readability by
helping someone who is looking at the code for the first time to grasp
at once that the function has global scope. I stretch this habit to
using the operator on C library functions as well. So I write ::memset
instead of memset and ::abs instead of abs. I vaguely remember hearing/
reading somewhere that it is encouraged practice to use fully
qualified names of STL elements, e.g. std::vector instead of vector.
Can someone verify this? All constructive comments are welcome.

 

[Victor Bazarov]

I have the habit of using the scope resolution operator whenever I use
global functions. My premise is that it improves readability by
helping someone who is looking at the code for the first time to grasp
at once that the function has global scope. I stretch this habit to
using the operator on C library functions as well. So I write ::memset
instead of memset and ::abs instead of abs.

According to the Standard, if you (and the implementors) do the right
thing (which is rare, BTW), you're not supposed to use the global names,
but instead use 'std::' prefix.

I vaguely remember
hearing/ reading somewhere that it is encouraged practice to use fully
qualified names of STL elements, e.g. std::vector instead of vector.
Can someone verify this?

It's really difficult for me to verify whether you remember hearing
or reading something somewhere, you understand this, don't you?

All constructive comments are welcome.

Well, not giving into the desire to reduce having to type too many
characters by inserting 'using namespace std' or a using declarations
with standard names, is a good habit. Of course, you're going to
eventually run into this situation:

std::deque<
SomeRatherLongTypeName,
OtherLongNameOfTheAllocator> myRatherLongTypeNameCollection;

and then you want to iterate of it using 'const_iterator'... How
bad is that? Then you resort to

typedef std::deque<
SomeRatherLongTypeName,
OtherLongNameOfTheAllocator> myTypeCollection_t;

and iteration becomes realtively easy then

myTypeCollection_t::const_iterator ...

Doing all that does *hide* the fact that the collection is, in fact,
a standard container. Well... I say, so? Bid deal!

Now, with some old (and even sometimes with some new) codebases there
can be a name conflict with some popular names like 'min' or 'max'.
You have to watch out for those. The bad thing is when somebody
actually switches those without you actually knowing it. There is
definitely less probability of a mistake if you fully qualify those.

V

 

[Marcus Kwok]

Well, not giving into the desire to reduce having to type too many
characters by inserting 'using namespace std' or a using declarations
with standard names, is a good habit. Of course, you're going to
eventually run into this situation:

std::deque<
SomeRatherLongTypeName,
OtherLongNameOfTheAllocator> myRatherLongTypeNameCollection;

and then you want to iterate of it using 'const_iterator'... How
bad is that? Then you resort to

typedef std::deque<
SomeRatherLongTypeName,
OtherLongNameOfTheAllocator> myTypeCollection_t;

and iteration becomes realtively easy then

myTypeCollection_t::const_iterator ...

Doing all that does *hide* the fact that the collection is, in fact,
a standard container. Well... I say, so? Bid deal!

On the other hand, typedef'ing the standard containers can help
maintenance. If you later decide that a different container is better
for your purposes, then (assuming you use the iterators correctly) all
you need to change is the typedef.

 

[Jerry Coffin]

[ ... ]

On the other hand, typedef'ing the standard containers can help
maintenance. If you later decide that a different container is better
for your purposes, then (assuming you use the iterators correctly) all
you need to change is the typedef.

IME, this is rarely true. If you make _extremely_ limited use of the
container, it can be possible, but (at best) for most real code is
extremely limited at best.

Just for example, to make much use of a container, you need to add
elements to the container. If you were using a vector, you almost
certainly do that with push_back. If (for example) you switch to a set,
your linker will quickly inform you that set doesn't have a 'push_back'
member -- you need to use 'insert' intead.

It's entirely reasonable to write specific algorithms to work on a
variety of containers -- but for a complete program, such a switch is
rarely possible and even when it is it's almost certain to accomplish
nothing (e.g. code written for a vector can usually work with a deque,
but gains nothing by doing so).

 

[Victor Bazarov]

[..]
It's entirely reasonable to write specific algorithms to work on a
variety of containers -- but for a complete program, such a switch is
rarely possible and even when it is it's almost certain to accomplish
nothing (e.g. code written for a vector can usually work with a deque,
but gains nothing by doing so).

It is true that choice of the container is usually made upfront, but
I don't agree that switching from a vector to a deque gains nothing.
A deque is faster when it comes to allocation, so if you expect your
code to use indexing (random access iterators) and require a growing
container, then the performance or contiguousness will be the factors
that tip the decision scale toward vector or deque.

V

 

[James Kanze]

[..]
It's entirely reasonable to write specific algorithms to work on a
variety of containers -- but for a complete program, such a switch is
rarely possible and even when it is it's almost certain to accomplish
nothing (e.g. code written for a vector can usually work with a deque,
but gains nothing by doing so).

It is true that choice of the container is usually made upfront, but
I don't agree that switching from a vector to a deque gains nothing.
A deque is faster when it comes to allocation, so if you expect your
code to use indexing (random access iterators) and require a growing
container, then the performance or contiguousness will be the factors
that tip the decision scale toward vector or deque.

Switching between sequences is sometimes possible; switching
between a sequence and an associative container, rarely, I
think. Even switching between sequences can be tricky, since
iterator validity is often a dominant factor in choosing which
container to use to begin with.

 

[Victor Bazarov]

[..]
It's entirely reasonable to write specific algorithms to work on a
variety of containers -- but for a complete program, such a switch
is rarely possible and even when it is it's almost certain to
accomplish nothing (e.g. code written for a vector can usually work
with a deque, but gains nothing by doing so).

It is true that choice of the container is usually made upfront, but
I don't agree that switching from a vector to a deque gains nothing.
A deque is faster when it comes to allocation, so if you expect your
code to use indexing (random access iterators) and require a growing
container, then the performance or contiguousness will be the factors
that tip the decision scale toward vector or deque.

Switching between sequences is sometimes possible; switching
between a sequence and an associative container, rarely, I
think. Even switching between sequences can be tricky, since
iterator validity is often a dominant factor in choosing which
container to use to begin with.

If that's the reason, yes. I sometimes choose 'vector' because its
storage is guaranteed to be contiguous. In that case changing to
'deque' or 'list' is definitely out of the question.

V

 

[Jerry Coffin]

[ ... ]

It is true that choice of the container is usually made upfront, but
I don't agree that switching from a vector to a deque gains nothing.
A deque is faster when it comes to allocation, so if you expect your
code to use indexing (random access iterators) and require a growing
container, then the performance or contiguousness will be the factors
that tip the decision scale toward vector or deque.

"nothing" was probably a bit of an exaggeration -- but only a bit of
one. Worse, deque vs. vector is probably the closest thing there is to a
strict superset -- i.e. one container that's relatively to substitute
for another under quite a few circumstances. Even so, such a change
requires care, and even at best we're basically looking at basically a
micro-optimization.

Most other such switches are considerably more difficult to support.
Each container has some unique features, and it's fairly unusual to use
a container without using at least a few of its unique features.