Hello, Mickael. Thursday, February 5, 2009 at 9:04:14 PM you wrote: MW> Ein Held a écrit : MW> This is very funny. In fr.comp.lang.c++, we had a troll about using MW> usage. It appears that a lot of contributor use qualified names in MW> professionnal code, to avoid namespaces collision and improve readness. MW> Because when we use a string, I can need to know where it come from. MW> That's an example. MW> The second point we raised is the bad habit of beginners, who MW> massively use the using namespace directive at global scope, and worst MW> in header's global scope ! From the common point of view I completely agree with your opinion. But now we are talking about fundamental language libraries. I think it looks too strange if, for example, C# source code contains something like: System.String str = "blah-blah-blah"; System.Console.WriteLine(str); //... System.Collections.Generic.List<int> some_list = new System.Collections.Generic.List<int>(); :) Because standard C# file template contains at least three usings (System, System.Collections.Generic and System.Text) Same for Java code. I mean what for other mainstream languages 'using declarations' are a common practice. And if we are talking about beginners, in present time it is hard to explain why programmer have to use full-qualified ids even for standard facilities. Of course 'because it is avoid namespace clash' is quite good explanation. But this explanation looks too strange near other languages. In this case we could get answer like this: 'Are C++ so worst and difficult if even fundamental libraries are not easy-to-use and conflicts each other???' -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru

Hello, Michael. Thursday, February 5, 2009 at 11:09:49 PM you wrote: MF> We're getting off-topic, but I couldn't resist. We are talking about namespaces, so I think it is good idea to look around. :) MF> What happens when I do: MF> using System.Drawing; MF> using Microsoft.XNA.Framework; MF> Point p = new Point(); // Doh! Good example. But... You have to do something very _special_ if you want to get the same result inside only 'System' namespace. Isn't it? I mean what you can use unqualified ids and usings in most cases without any errors from the compilator _when you use only standard facilities_. MF> You see, these problems occur in C# too, and the same answer (from MF> C++) is given as to how to correct the issue. Make a namespace alias, MF> or use full qualification. MF> If you want to use boost, use boost::. If you want to use the STD MF> library, use std::. Perfectly! What you can say about following pieces of code: std::vector vec; std::for_each(vec.begin(), vec.end(), std::bind(&std::shared_ptr<SomeClass>::get, std::placeholders::_1, std::bind(&SomeClass::foo, std::placeholders::_1, 10))); and vector vec; for_each(vec.begin(), vec.end(), bind(&shared_ptr<SomeClass>::get, _1, bind(&SomeClass::foo, _1, 10))); from the readness point of view? Assume what I place std and std::placeholders namespace into new namespace ('slib'): slib::vector vec; slib::for_each(vec.begin(), vec.end(), slib::bind(&slib::shared_ptr<SomeClass>::get, slib::_1, slib::bind(&SomeClass::foo, slib::_1, 10))); Is it quite readable or your eyes are seeing only 'slib' and '::'? Is _it_ improving of 'code readness'? And you are offering C++ beginners to use such coding style. It is good style, but I'm absolutely sure what beginners (even with C# or Java experience) say you something ugly and then return to C# or Java. :) -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru

Sergey Sadovnikov writes:

Perfectly! What you can say about following pieces of code:

std::vector vec; std::for_each(vec.begin(), vec.end(),

std::bind(&std::shared_ptr<SomeClass>::get, std::placeholders::_1, std::bind(&SomeClass::foo, std::placeholders::_1, 10)));

and

vector vec; for_each(vec.begin(), vec.end(), bind(&shared_ptr<SomeClass>::get, _1,

bind(&SomeClass::foo, _1, 10)));

What about scoped using directive (or using declaration)? { // begin code using namespaces using namespace std; using namespace std::placeholders; vector vec; for_each(vec.begin(), vec.end(), bind(&shared_ptr<SomeClass>::get, _1, bind(&SomeClass::foo, _1, 10))); } // end code using namespaces Explicit, readable, and doesn't affect code outside the braces

Sergey Sadovnikov wrote: [ snip]

From the common point of view I completely agree with your opinion. But now we are talking about fundamental language libraries. I think it looks too strange if, for example, C# source code contains something like:

System.String str = "blah-blah-blah"; System.Console.WriteLine(str); //... System.Collections.Generic.Listsome_list = new System.Collections.Generic.List();

:) Because standard C# file template contains at least three usings (System, System.Collections.Generic and System.Text)

Same for Java code. I mean what for other mainstream languages 'using declarations' are a common practice. And if we are talking about beginners, in present time it is hard to explain why programmer have to use full-qualified ids even for standard facilities. Of course 'because it is avoid namespace clash' is quite good explanation. But this explanation looks too strange near other languages. In this case we could get answer like this: 'Are C++ so worst and difficult if even fundamental libraries are not easy-to-use and conflicts each other???'

The thing is that boost is a testbed of libraries aimed for eventual standardization. And when that standardization happens, you have some standard facilities both in std and boost namespaces. Neither C# nor Java has something similar AFAIK, that's why identifier collisions are uncommon in their 'fundamental libraries'. Is this a problem with boost, after all? One can either - not use boost but wait some years for the new standard or a technical report to be published and implemented and then use the libraries in question (avoiding namespace clashes), or - use the boost libraries right away and optionally provide a feedback on them to make the future standard better, but with a clear understanding that writing using-directives for both boost and std namespaces in the same scope may cause problems in the future due to the nature of boost. I guess such an explicit disclaimer would be handy at the top of boost documentation. All this is just my personal point of view, of course. Best Regards, Gevorg