I'm doing a toy project which uses a lot of boost libraries. In the course of doing this, I'm reminded of something that has bugged me for a long time. That is the placement of lots of stuff inside the namespace boost. Now that boost is the size that it is, this can become are real barrier to making things understandable. Currently I'm looking at range and iterator libraries - but I'm no there are lots of offenders. Certain names like join, zip, map, copy, etc. ... apear in multiple libraries. I would like to use "using namespace boost" but then I'm afraid that using something like copy will be ambigiuos Could we agree that the boost namespace (and directory structure) only be used for library names. Some time ago, I caught hell for including just a couple of functions in boost/namespace and directory. But I see tons of stuff in there now. Robert Ramey
As a user of boost, I find difficult to guess the name of something because for some libraries, stuff is just in boost:: namespace (regex and type traits for example) and for others it is in boost::library:: namespace (for example string algorithms). It would help to have a standard naming convention. Frédéric
At Sun, 16 Jan 2011 00:26:00 +0400, Denis Shevchenko wrote:
Make that "simple legacy libraries." IMO we've gone past the point that we can afford to put anything new directly in boost. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
+1 _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
----- Original Message ----- From: "Robert Ramey" <ramey@rrsd.com> To: <boost@lists.boost.org> Sent: Saturday, January 15, 2011 7:58 PM Subject: [boost] namespace boost?
The recent accepted Boost.Ratio library place all inside namespace boost. If the boost comuniti prefer I place it on boost::ratios namespace i wil adapt the code before releasing it. Vicente
In addition, I think that a single standard of namespaces should be combined with a single standard of .hpp files location in main 'boost' directory. IMHO, simple libraries (such boost::mem_fn or boost::lexical_cast) which consist of a single .hpp file can (or must) be placed in main 'boost' directory, so user can write: #include <boost/mem_fn.hpp> For more complex libraries, all .hpp files must be placed in own directory (like boost::ptr_container), so user writes: #include <boost/ptr_container/ptr_container.hpp>
----- Original Message ----- From: "Denis Shevchenko" <for.dshevchenko@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, January 15, 2011 9:35 PM Subject: Re: [boost] namespace boost?
I find useful to have the file that include all the other files at the boost directory level. As it is the case for Boost.Flyweight #include <boost/flyweight.hpp> Vicente
----- Original Message ----- From: "Denis Shevchenko" <for.dshevchenko@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, January 15, 2011 9:56 PM Subject: Re: [boost] namespace boost?
You are right, and I forget often to replace this file, but usualy it doesn't changes to much. The ideal will be that this file include a all.hpp file included on the library directory. Other have proposed someting like #include<boost/flyweight/all.hpp> Vicente
16.01.2011 01:10, vicente.botet пишет:
The ideal will be that this file include a all.hpp file included on the library directory. Other have proposed someting like
#include<boost/flyweight/all.hpp>
I agree. And, IMHO, all.hpp file must exists for libraries with set of 'independent' files (that can be used independently of the other), something like this: #include <boost/algorithm/string/all.hpp> But for libraries with one 'main concept' file must exists such file. For example, in my Configurator: #include <boost/configurator/configurator.hpp> - Denis
Denis Shevchenko wrote:
+1
That should not preclude configurator/all.hpp, even if all.hpp merely includes configurator.hpp. You can change boost/configurator/all.hpp should the need ever arise while boost/configurator.hpp won't need to change. That makes selective, local changes easier because they would be isolated to the configurator subdirectory. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2011/1/18 Stewart, Robert <Robert.Stewart@sig.com>:
This is true, but I don't want to encourage a proliferation of files with the same name (in different directories). That will just make development harder. I can't help but think that those against boost/library_name.hpp are focusing so hard on purity that they're ignoring convenience. It should be _trivial_ for people to get started with a boost library, and #include <boost/library_name/library_name.hpp> makes a bad first impression, IMO. At it has no practical benefit: there are identical chances of colliding instances of boost/library_name.hpp and of colliding instances of boost/library_name/library_name.hpp, because the information there is redundant. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
For the person just starting with a Boost library, boost/library_name.hpp is the way to go (I wasn't suggesting not having that file). If that includes boost/library_name/all.hpp, then once boost/library_name.hpp exists, it will never change so library_name's developer need never worry about it again. I wasn't commenting on the wisdom of boost/configurator/configurator.hpp, though I agree that the redundancy is unfortunate. However, if there's no other include file in boost/configurator, what name should it have? _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
AMDG On 1/18/2011 9:50 AM, Stewart, Robert wrote:
How about we just say that a library should reserve a single name under boost and how it uses it is up to the library author (i.e. a single header, a directory, or a directory + header are all fine.). If we're just trying to keep the top-level boost from getting cluttered, there's no reason to overspecify the solution. In Christ, Steven Watanabe
Steven Watanabe wrote:
I don't think encouraging that the top-level header do nothing but forward to a header in the library directory is overspecifying. Within this thread there was mention of forgetting to update the top-level header to match changes in the library directory. If it only forwards to a single header in the library directory, then all places to make changes are within the library's directory. Beyond that, they way you've described it captures the idea pretty well. The all.hpp discussion was, really, as a replacement for top-level headers. However, it wouldn't hurt to suggest that the top-level header might include boost/library_name/all.hpp as a guide to new library authors to remove the need to invent something for each new library. (By making it a suggestion, most will follow the convention, but choosing another filename would not be wrong.) _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
vicente.botet wrote:
or #include <boost/flyweight/include.hpp> for the convenience header. actually, I might be ok with each library permitting ONE #include<boost/flyweight.hpp> // convenience header. I though I would prefer the former. My normal practice is not to use these anyway but rather pick out the specific one's I'm interested in. So it's not a huge issue for me. The reason I do this is that I like knowing that I'm including only the minimum required to get the job done. I recognise that tastes differ on this. oh well.
At Sat, 15 Jan 2011 14:30:46 -0800, Steven Watanabe wrote:
Yeah, it's OK by me as well. If there's not going to be a collision with boost/flyweight/xxx.hpp, then boost/flyweight.hpp isn't going to collide either. And if it were to collide, we'd have bigger problems than just a poor choice of header paths :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 01/15/2011 02:11 PM, Robert Ramey wrote:
All of this implies that I prefer people to break things into different headers more intelligently, i.e. if something is used in multiple places it should have a separate header so I don't get extra stuff I don't need by including something I do need. That's one of my pet peeves. Of course I have no objection to the existence of a parent include file that includes everything for people that don't want to think about it and to treat a particular part of a project as a black box. I do that sometimes too. There's not enough time in the world to become an expert on everything, (gad that's so frustrating, isn't it?!). Patrick
Denis Shevchenko wrote:
12345678901234567890123456789012345678901234567890123456789012345
+1
-1 The single header libraries still have documentation and tests which should all fall into library-specific subdirectories of their respective parents. As noted elsewhere, boost/mem_fn.hpp can still exist, but it should simply include boost/<library>/mem_fn.hpp even though the latter may be the only header in boost/<library>. Not only does this follow a consistent pattern, but it also leaves room for later additions should they appear.
+1 Furthermore, the directory and namespace names should be identical. Thus, boost/ptr_container provides code in boost::ptr_container. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
The library name is normally (but not always) singular, e.g. Boost.Tuple, which is IMO more logical than Boost.Tuples. The folder name equals the library name. The library often contains a class named as the library, e.g. tuple, and the namespace therefore or for other reasons is something different, here tuples, so this requirement is difficult to meet. Regards, Barend
Barend Gehrels wrote:
Note that this proposal conflicts with some existing libraries (e.g. tuple, bimap).
Existing libraries must be grandfathered, but that doesn't mean new libraries should be permitted to make things even messier! _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On 18/01/11 15:23, Barend Gehrels wrote:
Forgetting about the legacy and naming of existing libraries, in my opinion libraries and namespaces should be singular. I can't think of any reason why it has to be plural. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
2011/1/18 Mateusz Loskot <mateusz@loskot.net>:
... it is official boost guideline, for the case that your library exports a class that is identical with the library's name: http://www.boost.org/development/requirements.html#Naming_consistency Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On 18/01/11 15:49, Joachim Faulhaber wrote:
Forgot about this one. So, I know only one reason then, this particular one. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Joachim Faulhaber wrote:
from the above "Here is how it works. The library is given a name that describes the contents of the library. Cryptic abbreviations are strongly discouraged. Following the practice of the C++ Standard Library, names are usually singular rather than plural. For example, a library dealing with file systems might chose the name "filesystem", but not "filesystems", "fs" or "nicecode". Hmmmm - I either never saw this or had forgotten about it. How is it we have names like kara, qi, phoenix, fusion, gil, spirit, wave and xpressive ?
Regards, Joachim
At Tue, 18 Jan 2011 15:19:49 -0800, Michael Caisse wrote:
Not only that; he plays a mean samba! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Brilliant! LOL Regards Hartmut --------------- http://boost-spirit.com
On Tue, Jan 18, 2011 at 10:49 AM, Joachim Faulhaber <afojgo@googlemail.com> wrote:
Though again, I'd like to discuss whether we want to keep that policy. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Jan 18, 2011, at 4:29 PM, Robert Kawulak wrote:
While I like the basic discussion about moving away from naming the namespace as the plural form of the class, I have always been for clarity and naming things after wthat they represent. So...why not call the folder 'tuple' (as it is the name of the library), the class 'tuple' and the namespace 'tuple_nmsp'. The names would be perfectly clear, no clashes in regards to singular/plural and in addition, you clearly can identify the namespace and the class...which can be confusing from time to time with the whole tuple/tuples thing otherwise....at least it is for me... ;) Just my (outside) $0.02 worth... Ciao, Andreas
On Wed, Jan 19, 2011 at 7:06 AM, Andreas Masur <boost@andreasmasur.com> wrote:
Am I the only one who thinks adding the type of an identifier to the name is ugly? As in <identifier>_<type> (in this case `tuple_nmsp` or `tuple_lib`)? Imagine if everytime you had to call a real person instead of just their name you had to say "<name>, friend" or "<name>, daughter". That wouldn't be very nice would it? -- Dean Michael Berris about.me/deanberris
2011/1/19 Dean Michael Berris <mikhailberis@gmail.com>:
There once was a ui_time long ago, when pchr_developers were using prefixed LPSTR_names to be able to immediately distinguish between different LPCTSTR_types, even before their compilers ;) Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
I agree with you, those suffices are too much. Just an "s" is enough. I personally can live with plural namespaces if they are necessary. So the guidelines on the website (put into this thread by Joachim) http://www.boost.org/development/requirements.html#Naming_consistency are clear, make sense, and are followed by most previous libraries. I see no reason for change. Regards, Barend
On Wed, Jan 19, 2011 at 4:18 PM, Barend Gehrels <barend@geodan.nl> wrote:
I agree with this. Sorry but I missed the context of the original discussion -- is there a specific problem we're trying to solve by changing the way things are going? Or is it just because "it doesn't look nice"? -- Dean Michael Berris about.me/deanberris
At Wed, 19 Jan 2011 16:32:11 +0800, Dean Michael Berris wrote:
Mostly because things aren't going any one way, so in setting the way forward there's an opportunity to revisit old decisions and-bikesheds-ly y'rs, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 19/01/11 05:51, Dean Michael Berris wrote:
There are libraries with 'lib' in name like libpng, libtiff or zlib, so there could be: libspirit libgeometry libfilesystem ... Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
On Wed, Jan 19, 2011 at 7:56 PM, Mateusz Loskot <mateusz@loskot.net> wrote:
Right, but you don't have them in the namespace. Mostly I think the reason for having 'lib' as a prefix is mostly because of UNIX/Linux and GCC intepreting `-lfoo` to mean link in a library named `libfoo` for shorthand and for convention. I might see the need for that in a filesystem where you have to distinguish names because you don't typically have a namespace (although directories are there, which is another issue). That doesn't make me like the 'lib' name myself. Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D -- Dean Michael Berris about.me/deanberris
On 19/01/11 11:58, Dean Michael Berris wrote:
Right.
That doesn't make me like the 'lib' name myself.
Me neither.
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D
Take this thread as a warning and learn the lesson, otherwise you will have your users wining and complaining on the name in a few years ;-))) Cheers, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote:
cpp-net? :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dean Michael Berris wrote:
I dislike the suggestion of .NET evoked by Boost.Net. It suggests that Boost is into .NET development! _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Op 19-1-2011 18:20, Stewart, Robert schreef:
Yeah, I realized that after hitting the send button. Anyway, both C++ and C# are case-sensitive, so probably no problem ;-) Besides that, I would like to have in .NET such a wonderful, peer-reviewed, Open Source, pretty-licensed, well-known, reliable, community-driven collection, as Boost is (Boost.NET?) Regards, Barend
On 19/01/11 17:04, Dean Michael Berris wrote:
Then let's have it Boost.xNet Cheers, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
2011/1/20 TONGARI <tongari95@gmail.com>:
But it sounds like a domain name or something MS has.
Oh my, you're right about the MS part! It's obvious I don't deal with much MS technologies -- or choose to ignore them as much as I can. :D
Will Boost.Network sounds better?
Yeah, that's what I had in mind in the first place. Not really as creative as I'd like, but should be good enough. It is after all just a name. ;) -- Dean Michael Berris about.me/deanberris
On Thu, Jan 20, 2011 at 12:27 AM, Barend Gehrels <barend@geodan.nl> wrote:
I like that. :) I shall credit you with the name suggestion. :D
We had the same thing, ggl (generic geometry library) became Boost.Geometry because both generic and library were redundant.
Interesting. I wonder how Spirit did it though, was it called Spirit outside of Boost to start with and just retained the name? Also, PP is an acronym, was that "grandfathered in"? MPL, GIL, and MPI are acronyms too. -- Dean Michael Berris about.me/deanberris
On 1/20/2011 12:43 AM, Dean Michael Berris wrote:
I wonder how Spirit did it though, was it called Spirit outside of Boost to start with and just retained the name?
Yes. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 19/01/11 16:27, Barend Gehrels wrote:
Speaking of names and (my) personal preferences, Boost.Image or Boost.Raster would be better than GIL. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
At Wed, 19 Jan 2011 16:56:58 +0000, Mateusz Loskot wrote:
+1! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 19/01/11 18:20, Dave Abrahams wrote:
I don't want to be too poisonous here, wondering what would be a procedure to rename library? A renaming review? Simple poll? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
Mateusz Loskot wrote:
As one of the main complainers regarding cryptic library names, let me say that trying to address after the fact is a really bad idea. Maintaining an already accepted library is a much larger task than it would first appear. The idea that a maintainer is on the hoook for what ever some other group "decides" (none of whose members would actually be doing the work) is not really realistic. The time for dealing with this is during the review. One of the strengths of the review system is that it actually provides a design cutoff. This is necessary to actually get anything accomplished. The lack of the "cutoff" is likely the single frequent of failed projects in all sectors - industry, government, and private domain. Lack of a cutoff is another name for "feature creep" Robert Ramey
Best regards,
On 20/01/11 16:45, Robert Ramey wrote:
You are right.
Understood. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
On Thu, Jan 20, 2011 at 12:19 AM, Dave Abrahams <dave@boostpro.com> wrote:
LOL :D Seriously though I like the Boost.Net suggestion. I just might start calling it that as soon as I'm satisfied with the implementation/documentation to be submitted for review (soon). :) -- Dean Michael Berris about.me/deanberris
On 19/01/11 12:55, Denis Shevchenko wrote:
Of course, it is. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
I think everyone likes the names without postfixes more, but there's the issue with name clashes. I, on the other hand, avoided the clash of the central class name in my library - constrained - by calling the library Constrained Value and the namespace constrained_value. But in some cases it's not easy to make up a meaningful and not ugly name. Best regards, Robert
On Wed, 19 Jan 2011 13:13:22 +0100 Robert Kawulak <robert.kawulak@gmail.com> wrote:
I use the _t suffix for types, when I need a namespace of the same name (and often when I don't too). wchar_t and the int*_t/uint*_t types have made it a fairly accepted practice. I'm ambivalent about it, but it *does* solve the problem. -- Chad Nelson Oak Circle Software, Inc. * * *
At Tue, 18 Jan 2011 22:29:06 +0100, Robert Kawulak wrote:
Meh; such names get needlessly long, IMO. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
18.01.2011 18:50, Stewart, Robert пишет:
Hm... Yes, you are right.
Yes, this is a good requirement, but, IMHO, this requirement should not be *mandatory* for all libraries. But... Perhaps it should be. I think it should be discussed in more detail. But important that as a result of this discussion was adopted by the standard one for all. - Denis
At Sat, 15 Jan 2011 21:32:39 +0100, vicente.botet wrote:
Please! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
At Sat, 15 Jan 2011 16:30:57 -0500, Beman Dawes wrote:
If it has a type called "ratio" in it, "ratios" might be a better choice for the namespace. That, at least, is how tuple did it. I can't find a good rationale for that choice now, but once upon a time it used to be our recommended practice. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Jan 15, 2011, at 4:46 PM, Dave Abrahams wrote:
http://www.boost.org/doc/libs/1_45_0/libs/tuple/doc/design_decisions_rationa... "For those who are really interested in namespaces"
At Sat, 15 Jan 2011 17:12:37 -0500, Kim Barrett wrote:
Interesting. I wonder if those errors they encountered with using are conforming behavior and/or obsolete issues due to compiler fixes. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
AMDG On 1/15/2011 8:24 PM, Dave Abrahams wrote:
I'm sure that the errors are correct. The code in question is |namespace boost { namespace tuple { class tuple; } using tuple::tuple; // error } | Obviously you can't have a namespace and a class in the same scope without errors. This isn't going to be an issue unless a library puts something directly under namespace boost, which we're discouraging anyway. In Christ, Steven Watanabe
On Sun, Jan 16, 2011 at 12:10 AM, Steven Watanabe <watanabesj@gmail.com> wrote:
Then I say, "make it match the library name, with a bias towards singular library names." -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Jan 18, 2011 at 12:26 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
Okay. Should we care about that case? Remember, I'm the one who just made the plea to remember convenience :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
And more... Single standard of namespaces would resolve the problem with placeholders. When I write: _1 what is it? Is it boost::lambda, boost::bind or boost::spirit::qi? IMHO, each placeholder must be placed in own namespace. - Denis
On 1/15/2011 5:13 PM, Denis Shevchenko wrote:
You forgot boost::mpl, which is also has the numeric placeholders. For some ( if not all ) of those libraries the placeholders are in their own namespace. But either the names are lifted into the global namespace for ease of use or the end-user puts it there. Of course ideally the authors should not be putting their placeholders into the global namespace, but let the end-user do that if he wants. The library authors are aware of this issue, but changing now will break much code so that is probably the reason why changes have not been made.
On 15/01/2011 19:58, Robert Ramey wrote:
boost::copy is a range-based version of std::copy. It's not ambiguous because it doesn't have the same arity. Anyway, it's probably not a good idea to do "using namespace boost", just like you shouldn't do "using namespace std"...
+1 - it will come round and bite you eventually (or some poor unsuspecting maintainer). And Boost's many examples should NOT set a bad example by doing "using namespace boost". IMO "using boost::a_library::a_function;" is actually much better, despite being longer, because it makes clear where the function comes from. Authors NB! Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
Paul A. Bristow wrote:
I agree WRT to boost, but not std. It doesn't have to apply to boost either, but that is the current reality.
+1 (Not because of the ambiguities such a using directive might cause but because examples shouldn't leave room for guessing.) _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Mathias Gaunard wrote:
There's nothing wrong with either one, in a .cpp file, provided the namespaces are well managed. That's certainly the case with std, but less so with boost for reasons being discussed in this thread. If using namespace std introduces ambiguities, they can be resolved with scoping on demand. Meanwhile, non-ambiguous names don't need scope resolution. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (27)
-
Andreas Masur -
Barend Gehrels -
Beman Dawes -
Chad Nelson -
Dave Abrahams -
Dean Michael Berris -
Denis Shevchenko -
Edward Diener -
Frédéric Bron -
Hartmut Kaiser -
Joachim Faulhaber -
Joel de Guzman -
Joel Falcou -
John Maddock -
Kim Barrett -
Mateusz Loskot -
Mathias Gaunard -
Michael Caisse -
Mostafa -
Patrick Horgan -
Paul A. Bristow -
Robert Kawulak -
Robert Ramey -
Steven Watanabe -
Stewart, Robert -
TONGARI -
vicente.botet