Issue 4550: eliminate "using namespace std;"

For those inexperienced with the problems this can cause, see http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice

Summary of these changes:
  * eliminate "using namespace std;"
  * add "std::" to everything in *.hh files (and other included files)
  * add "using std::whatever;" in *.cc files for common types (e.g. string, vector)
  * add "std::" in *.cc files for functions (e.g. swap) and other less common things (e.g. less)

Patch set 1 consists of other issues already in review.

Patch set 2 consists of manual changes in preparation for patch set 3, which is an automated removal of "using namespace std" and addition of "std::" where necessary.

See the review comments for the script used to make the changes in patch set 3.

[Dan Eble, 2015-08-15 13:09:11]

Add using-declarations (manual)

[Dan Eble, 2015-08-15 13:45:16]

Add using-declarations (manual)

[Dan Eble, 2015-08-15 13:53:10]

Remove "using namespace std" (automated)

[Dan Eble, 2015-08-15 14:02:45]

On 2015/08/15 13:53:10, Dan Eble wrote:
> Remove "using namespace std" (automated)

This bash script produced the changes in patch set 3.

# $1 = words to find e.g. '\(foo\|bar\)'
# $2 = file name
function add_std_prefix_to_word () {
    sed -i "/^#/!s/\\(^\\|[^_0-9A-Za-z:\\.]\\)\\($1\\)\\>/\\1std::\\2/g" $2
}

# $1 = types to find
# $2 = file name
function add_std_prefix_to_template () {
    sed -i "/^#/!{
:top
s/\\(^\\|[^_0-9A-Za-z:\\.]\\)\\($1 *<\\)/\\1std::\\2/
ttop
}" $2
}

# remove "using namespace std;" everywhere
for FILE in $(git grep -l "using namespace" flower lily)
do
    case "$FILE" in
	*.cc|*.hh|*.[it]cc|*.ll|*.yy)
	    sed -i "/^ *using namespace std;.*\$/d" "$FILE"
	    ;;
	*)
    esac
done

# add "std::" to these words in included files
TYPES_RE='\(istream\|string\)'
for FILE in $(git grep -l "$TYPES_RE" flower lily)
do
    case "$FILE" in
	*.hh|*.[it]cc)
	    add_std_prefix_to_word "$TYPES_RE" "$FILE"
	    ;;
	*)
    esac
done

# add "std::" to these words in all files
TYPES_RE='\(endl\|ios\|cerr\|cout\)'
for FILE in $(git grep -l "$TYPES_RE" flower lily)
do
    case "$FILE" in
	*.cc|*.hh|*.[it]cc)
	    add_std_prefix_to_word "$TYPES_RE" "$FILE"
	    ;;
	*)
    esac
done

# add "std::" to these templates in included files
TYPES_RE='\(list\|map\|pair\|set\|vector\)'
for FILE in $(git grep -l "$TYPES_RE" flower lily)
do
    case "$FILE" in
	*.hh|*.[it]cc)
	    add_std_prefix_to_template "$TYPES_RE" "$FILE"
	    ;;
	*)
    esac
done

# add "std::" to these templates everywhere
TYPES_RE='\(greater\|less\|numeric_limits\|unary_function\)'
for FILE in $(git grep -l "$TYPES_RE" flower lily)
do
    case "$FILE" in
	*.cc|*.hh|*.[it]cc)
	    add_std_prefix_to_template "$TYPES_RE" "$FILE"
	    ;;
	*)
    esac
done

FUNCS_RE='\(make_pair\|max\|min\|swap\)'
for FILE in $(git grep -l "$FUNCS_RE" flower lily)
do
    case "$FILE" in
	*.cc|*.hh|*.[it]cc)
	    # add "std::" to function name
	    sed -i "/^ *using std::$FUNCS_RE;.*\$/d
/^#/!{
:top
s/\\(^\\|[^_0-9A-Za-z:\\.]\\)\\($FUNCS_RE *([^)]\\)/\\1std::\\2/
ttop
}" $FILE
	    ;;
	*)
    esac
done

[dak, 2015-08-23 16:25:30]

https://codereview.appspot.com/254670043/diff/60001/flower/include/std-vector.hh
File flower/include/std-vector.hh (right):

https://codereview.appspot.com/254670043/diff/60001/flower/include/std-vector...
flower/include/std-vector.hh:70: #if HAVE_STL_DATA_METHOD
As it stands, this patch would appear quite broken to me as it fails to work
when the config variable HAVE_STL_DATA_METHOD is 0: in that case, std-vector.hh
defines its own vector template class that is _not_ accessible via std::vector.

Until this is sorted out, I strongly suggest that we revert this patch.

[dak, 2015-08-23 16:31:46]

dak@gnu.org writes:

>
https://codereview.appspot.com/254670043/diff/60001/flower/include/std-vector.hh
> File flower/include/std-vector.hh (right):
>
>
https://codereview.appspot.com/254670043/diff/60001/flower/include/std-vector...
> flower/include/std-vector.hh:70: #if HAVE_STL_DATA_METHOD
> As it stands, this patch would appear quite broken to me as it fails to
> work when the config variable HAVE_STL_DATA_METHOD is 0: in that case,
> std-vector.hh defines its own vector template class that is _not_
> accessible via std::vector.
>
> Until this is sorted out, I strongly suggest that we revert this patch.
>
> https://codereview.appspot.com/254670043/

Since this patch touches a lot of code, I'd recommend to all with a
Patch-push tag who find that they'd need to fix merge conflicts when
rebasing to current master to just do

git rebase --abort

and rather wait whether we'll indeed revert this patch for now.  It
would be a nuisance if they fixed the merge conflicts and pushed with
the result that the revert of issue4550 takes more work and is harder to
disentangle.

Dan, any input on the HAVE_STL_DATA_METHOD issue?  Reverting here would
also conveniently postpone our problems with what appears to be
incomplete coverage of isinf and other functions.

-- 
David Kastrup

[Dan Eble, 2015-08-23 18:48:00]

On 2015/08/23 16:31:46, dak wrote:
> > As it stands, this patch would appear quite broken to me as it fails to
> > work when the config variable HAVE_STL_DATA_METHOD is 0: in that case,
> > std-vector.hh defines its own vector template class that is _not_
> > accessible via std::vector.

Drat.  Do we need this huge kludge in this day and age?   Any idea which
platform this is necessary for?

> > Until this is sorted out, I strongly suggest that we revert this patch.

I agree.

[dan_faithful.be, 2015-08-23 18:50:27]

On Aug 23, 2015, at 14:48 , nine.fierce.ballads@gmail.com wrote:
> 
>> > Until this is sorted out, I strongly suggest that we revert this
> patch.
> 
> I agree.

And note that this is issue *4550*, not what appears in the subject line.

Who is going to do the reverting?

> https://codereview.appspot.com/254670043/
— 
Dan

[dak, 2015-08-23 20:31:56]

On 2015/08/23 18:48:00, Dan Eble wrote:
> On 2015/08/23 16:31:46, dak wrote:
> > > As it stands, this patch would appear quite broken to me as it fails to
> > > work when the config variable HAVE_STL_DATA_METHOD is 0: in that case,
> > > std-vector.hh defines its own vector template class that is _not_
> > > accessible via std::vector.
> 
> Drat.  Do we need this huge kludge in this day and age?   Any idea which
> platform this is necessary for?

data is only available as of C++11 as far as I can tell, and we don't demand
C++11 yet.  I think that the GNU C++ library is less bothered about keeping
standards separated and tends to introduce stuff early if it does not conflict. 
So I have no idea which GCC versions are actually concerned.

However, I seem to remember that I looked at the uses of data and most uses
seemed to be better replaced by something else.  I don't know when the "is
stored contiguously" guarantee for the vector and string classes was formally
codified, but the presence of cstr should be sufficient for most string uses of
data.

[Dan Eble, 2015-08-24 01:36:32]

On 2015/08/23 20:31:56, dak wrote:
> However, I seem to remember that I looked at the uses of data and most uses
> seemed to be better replaced by something else.  I don't know when the "is

Good idea.  I'll see what I can replace with more standard methods.

[Dan Eble, 2015-08-27 12:16:50]

On 2015/08/24 01:36:32, Dan Eble wrote:
> On 2015/08/23 20:31:56, dak wrote:
> > However, I seem to remember that I looked at the uses of data and most uses
> > seemed to be better replaced by something else.  I don't know when the "is
> 
> Good idea.  I'll see what I can replace with more standard methods.

FYI, I found only one use of std::vector::data() and you are right.  This has
led me into cleaning up some code that uses Grob_array.  I might be able to post
a review of it in a day or two.