boost and std collisons in c++0x
Hello I would like to know more about boost's general attitude towards c++0x and the collisions of boost with std. As of now, we move both, ::boost- and ::std-namesspace in the global namespace via using xxx. This is exactly what we want - boost and the stl are both such fundamental libraries that using an explicit namespace specifier everytime we want to use content of these namespaces is not accaptable. This would just blow the code and make it unreadable. Once we move up to c++0x, we will not be able to keep this way of coding up. ::std::tr1 is merged into ::std and so the former tr1 classes will collide with the boost ones if explicit namespace identifiers are missing. I would like to stress the fact that code, perfectly fine to the boost documentation, will fail to compiler most likely. #include <iostream> //This one might include <array> using namespace std; #include <boost/array.hpp> using namespace boost; array<int,1> blub; //fail Is there anything planned to prevent this happen? Thank you
Ein Held a écrit :
As of now, we move both, ::boost- and ::std-namesspace in the global namespace via using xxx. This is exactly what we want - boost and the stl are both such fundamental libraries that using an explicit namespace specifier everytime we want to use content of these namespaces is not accaptable. This would just blow the code and make it unreadable.
This is very funny. In fr.comp.lang.c++, we had a troll about using usage. It appears that a lot of contributor use qualified names in professionnal code, to avoid namespaces collision and improve readness. Because when we use a string, I can need to know where it come from. That's an example. The second point we raised is the bad habit of beginners, who massively use the using namespace directive at global scope, and worst in header's global scope ! Daniel Lidström provided a good way to assure a consistent use of tools that comes from differents libraries. He imports objects and functions he need in a project specific namespace. This is a very soft approach, because you can support evolution and migrations more easily, at the cost of basics macros.
#include <iostream> //This one might include <array> using namespace std;
Bad, very bad. Be aware that namespace encapsulation have no interest if you cancel it. -- Mickaël Wolff aka Lupus Michaelis Racine <http://lupusmic.org> Blog <http://blog.lupusmic.org>
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
On Thu, Feb 5, 2009 at 2:55 PM, Sergey Sadovnikov <flex_ferrum@artberg.ru> wrote:
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)
We're getting off-topic, but I couldn't resist. What happens when I do: using System.Drawing; using Microsoft.XNA.Framework; Point p = new Point(); // Doh! You see, these problems occur in C# too, and the same answer (from C++) is given as to how to correct the issue. Make a namespace alias, or use full qualification. If you want to use boost, use boost::. If you want to use the STD library, use std::. --Michael Fawcett
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<std::shared_ptr<SomeClass>> 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<shared_ptr<SomeClass>> 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<slib::shared_ptr<SomeClass>> 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
On Thu, Feb 5, 2009 at 4:02 PM, Sergey Sadovnikov <flex_ferrum@artberg.ru> wrote:
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_.
True, but same with C++. If you are only using std namespace, you have no problems. It's only when you bring multiple namespaces into the same scope. e.g. System + XNA, or std + boost. <snip code>
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. :)
While I'm used to seeing the former, I agree it's more readable without the namespace qualifications. --Michael Fawcett
Sergey Sadovnikov <flex_ferrum <at> artberg.ru> writes:
Perfectly! What you can say about following pieces of code:
std::vector<std::shared_ptr<SomeClass>> 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<shared_ptr<SomeClass>> 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<shared_ptr<SomeClass>> 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
Hello, dariomt. Friday, February 6, 2009 at 1:02:30 AM Michael Fawcett wrote:
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> True, but same with C++. If you are only using std namespace, you MF> have no problems. It's only when you bring multiple namespaces into MF> the same scope. e.g. System + XNA, or std + boost. But I see some significant difference. Both std and boost are standard libraries for most C++ programmers. One 'de-jure' and another 'de-facto'. In the near future both STL and boost will contain similar set of most-useful entities. Unlike System and XNA. Friday, February 6, 2009 at 11:46:12 AM dariomt wrote: d> Sergey Sadovnikov <flex_ferrum <at> artberg.ru> writes: d> What about scoped using directive (or using declaration)? d> { // begin code using namespaces d> using namespace std; d> using namespace std::placeholders; d> vector<shared_ptr<SomeClass>> vec; d> for_each(vec.begin(), vec.end(), d> bind(&shared_ptr<SomeClass>::get, _1, d> bind(&SomeClass::foo, _1, 10))); d> } // end code using namespaces d> Explicit, readable, and doesn't affect code outside the braces Just add 'using namespace boost' in this scope for some manner, and you could return to the previous problem: { // begin code using namespaces using namespace std; using namespace std::placeholders; using namespace boost; std::vector<string> path_parts; split(vec, "/1/2/3/4", is_any_of("\\/") ); // string splitter from string algo for_each(path_parts.begin(), path_parts.end(), bind(&SomeClass::RegisterPathPart, _1)); // do something with string parts } // end code using namespaces -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru
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
participants (6)
-
dariomt -
Ein Held -
Gevorg Voskanyan -
Michael Fawcett -
Mickael Wolff -
Sergey Sadovnikov