using namespace std;

using namespace std;

Post by Keith H Du » Wed, 09 Jun 2010 02:44:00



Of course NOT since there is no binary std::equal function.
There is the iterator based 3-arg and 4-arg std::equal and
the value based binary std::equal_to.

Clearly it is not so "obvious what std::equal(a,b,c) means"
at least to you who claim it so. You fail. Try again.

KHD
 
 
 

using namespace std;

Post by Leigh John » Wed, 09 Jun 2010 02:45:09


Ah yes, I did forget, thanks. This just reinforces my point, it is obvious
(when you use your brain :)) what "std::equal(a, b, c)" means but not what
"equal(a, b, c)" means.

/Leigh

 
 
 

using namespace std;

Post by Leigh John » Wed, 09 Jun 2010 02:47:13


I did try again when replying to Oo Tib (before I got your incredibly
predictable response) which was:

"Ah yes, I did forget, thanks. This just reinforces my point, it is obvious
(when you use your brain :)) what "std::equal(a, b, c)" means but not what
"equal(a, b, c)" means."

So try again.

/Leigh
 
 
 

using namespace std;

Post by Kai-Uwe Bu » Wed, 09 Jun 2010 03:10:46


[...]
[...]

"elevate"? Mankind sure is doomed. <g>


Best

Kai-Uwe Bux
 
 
 

using namespace std;

Post by Keith H Du » Wed, 09 Jun 2010 03:13:10


There is a reason and the reason is that you have very little to
zero experience /writing/ generic algorithms. And by that I don't
mean child's play templated code. I mean /generic algorithms/.


Sure mixing is fine where appropriate. Programming is often about
using the right tool from the full spectrum of tools. For generic
programming ADL is often essential and is a motivating reason for
avoiding explicit qualification in many cases.


Yes that was an incorrect assumption. Sometimes one must avoid
explicit qualification in order to avoid disabling ADL. In other
words, sometimes explicit qualification is the /wrong/ choice.

KHD
 
 
 

using namespace std;

Post by Leigh John » Wed, 09 Jun 2010 03:30:13


This is simply false and obvious flame attempt. Please define "algorithm".
If by "algorithm" you mean something in the style of what appears in
<algorithm> then no I have not written many generic "algorithms" in the
*recent past* as <algorithm> mostly suffices. I do however write generic
code such as containers. The point here is that in a typical day how much
of the code you write is generic? ADL can come into play when writing a
generic alogorithm sure but in non-generic business logic code you should
find the need to invoke ADL to be a lot less, if this is not the case for
you then I maintain that your code is an awful mess.

/Leigh
 
 
 

using namespace std;

Post by Leigh John » Wed, 09 Jun 2010 03:40:18


And perusing over my codebase I take part of what I said back, I have
written quite a bit of code which is what (I guess) you consider to be a
"generic algorithm" but guessing what you actually mean by "algorithm" is
hard as you behave mostly like an argumentative troll.

/Leigh
 
 
 

using namespace std;

Post by Stuart Red » Wed, 09 Jun 2010 16:33:29


D**n it! I just knew that if I for once do not post actually compiled
code, I'd mkae some stupid mistake. My _very_ last word about the
whole "using namespace" discussion will thus be:

std::ostream& my_cout = std::cout;

or rather

my_ostream& my_cout = std::cout;

Thanks for the correction,
Stuart
 
 
 

using namespace std;

Post by Jorgen Gra » Sun, 13 Jun 2010 16:45:12


Maybe it was a mistake and maybe it was a good idea at the time ...

But why dwell on that now, seven years later? If you want to, you can
just remove that "using", and fix the code until it compiles again.
Put the missing std:: in the header files as needed, and in each
source file put that "using namespace std". Then you're in a situation
where the problem is local, and can be fixed one file at a time.

And as far as I can see, this is a safe transformation which shouldn't
trigger any run-time bugs.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
 
 

using namespace std;

Post by Ron Franci » Fri, 18 Jun 2010 10:56:53


I think this solution is less readable and is one step further away from deciphering.
Someone comes across the variable 'theItems' and looks at its definition to see what it is and finds
it is of type 'items'!
Then you have to find where 'items' is defined.
If it is on the previous line then it is easy enough, but not as easy as just seeing that it is of
type 'vector'.

I agree that ultimately std::vector is the most readable, but I wouldn't call it laziness to use
'using namespace std' or 'using std::vector'.
For a start it is a minor insult to anyone who chooses to use it, automatically getting them
offside, and I don't believe is valid as an argument as it has no bearing on whether the code it is
effective or not.
One may say that using the lift is lazy compared to using the stairs, but the lift is more
convenient, especially if you are in a hurry.
Ultimately you may get a heart attack by using the lift too much, but then again, maybe it gives you
more time for those ultimate sports.

Regards
Ron Francis
www.RonaldFrancis.com
 
 
 

using namespace std;

Post by Tii » Fri, 18 Jun 2010 13:13:37


Why it is important that it is a vector? You typically need to do
something with each of the items in container or find one of them.
That goes more-or-less similarly with most of the containers. It is
specially made so to ease replacing one container with more fitting
container type later.

It is therefore usually advisable to also write code so that it does
not depend on exact type of container where possible. Typedefing helps
there a lot. "items" is bad example name i think. Lets say there is
Person and its Children. Person should not have other person multiple
times listed among its children so initially most obvious container
may feel to be std::set. Later it may appear that some other container
is better. All these std::set<our::smart_ptr<Person>>::iterator
everywhere damages that goal and set<smart_ptr<Person>>::iterator does
not help any. Why you say it is readable? Using
Person::Children::iterator from start is both more readable and
flexible.
 
 
 

using namespace std;

Post by Ron Franci » Wed, 23 Jun 2010 23:25:14


<quote>
Why it is important that it is a vector? You typically need to do
something with each of the items in container or find one of them.
That goes more-or-less similarly with most of the containers. It is
specially made so to ease replacing one container with more fitting
container type later.

It is therefore usually advisable to also write code so that it does
not depend on exact type of container where possible. Typedefing helps
there a lot. "items" is bad example name i think. Lets say there is
Person and its Children. Person should not have other person multiple
times listed among its children so initially most obvious container
may feel to be std::set. Later it may appear that some other container
is better. All these std::set<our::smart_ptr<Person>>::iterator
everywhere damages that goal and set<smart_ptr<Person>>::iterator does
not help any. Why you say it is readable? Using
Person::Children::iterator from start is both more readable and
flexible.
</quote>

My apologies for my reader not prefixing ">" to the above text.
As I said, it is one more step away from finding out what type the variable is.
I haven't had all that much to do with these containers, so I don't know how similar their
interfaces are, but unless the coding is obvious, you wouldn't even know the variable was a
container.
"Person::Children::iterator" gives you an idea that it is a container, but it may be user defined
and so don't necessarily know its methods.
But, I didn't say there weren't benefits to doing it that way, only that it was more difficult to
read.
Ability to change the code is certainly a valid reason to do it that way and I also agree that the
logic of "Person::Children::iterator" is easier to digest in a different way.

Regards
Ron Francis
www.RonaldFrancis.com