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]

ph**********@yahoo.com wrote:

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,
OtherLongNameOfTheAllocatormyRatherLongTypeNameCol lection;

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

typedef std::deque<
SomeRatherLongTypeName,
OtherLongNameOfTheAllocatormyTypeCollection_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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Marcus Kwok]

Victor Bazarov <v.********@comacast.netwrote:

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,
OtherLongNameOfTheAllocatormyRatherLongTypeNameCol lection;

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

typedef std::deque<
SomeRatherLongTypeName,
OtherLongNameOfTheAllocatormyTypeCollection_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.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Jerry Coffin]

In article <f8**********@news-int.gatech.edu>, ri******@gehennom.invalid
says...

[ ... ]

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).

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Victor Bazarov]

Jerry Coffin wrote:

[..]
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[James Kanze]

On Jul 26, 12:11 am, "Victor Bazarov" <[e-mail]:

Jerry Coffin wrote:

[..]
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.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Victor Bazarov]

James Kanze wrote:

On Jul 26, 12:11 am, "Victor Bazarov" <[e-mail]:

>Jerry Coffin wrote:

>>[..]
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask