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
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.
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
On Sat, 15 Jan 2011 12:08:16 -0800, Frédéric Bron <frederic.bron@m4x.org> wrote:
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.
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
+1 Clients can always restructure/alias namespaces to suit their needs. +1 On the standard naming convention. Mostafa
16.01.2011 00:08, Frédéric Bron пишет:
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. I completely agree. I think that only a simple libraries should be located in a namespace boost (for example, boost::mem_fn or boost::lexical_cast). All other libraries should be located in own namespace boost::own::.
- Denis
At Sun, 16 Jan 2011 00:26:00 +0400, Denis Shevchenko wrote:
16.01.2011 00:08, Frédéric Bron пишет:
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.
I completely agree. I think that only a simple libraries should be located in a namespace boost (for example, boost::mem_fn or boost::lexical_cast). All other libraries should be located in own namespace boost::own::.
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
At Sun, 16 Jan 2011 00:26:00 +0400, Denis Shevchenko wrote:
16.01.2011 00:08, Frédéric Bron пишет:
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.
I completely agree. I think that only a simple libraries should be located in a namespace boost (for example, boost::mem_fn or boost::lexical_cast). All other libraries should be located in own namespace boost::own::.
Make that "simple legacy libraries." IMO we've gone past the point that we can afford to put anything new directly in boost.
I lean that way too. If something comes up that we all agreed should go
On Sat, Jan 15, 2011 at 4:22 PM, Dave Abrahams <dave@boostpro.com> wrote: directly into boost, that's fine, but only after a full airing on the list. --Beman
Dave Abrahams wrote:
Denis Shevchenko wrote:
I completely agree. I think that only a simple libraries should be located in a namespace boost (for example, boost::mem_fn or boost::lexical_cast). All other libraries should be located in own namespace boost::own::.
Make that "simple legacy libraries." IMO we've gone past the point that we can afford to put anything new directly in boost.
+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?
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.
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?
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>
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
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> Hmm... But what if I want to update one header-only library? If I have 'common' file that include all the other files at the boost directory level, I must replace this file AND own directory. But if all files
16.01.2011 00:49, vicente.botet пишет: placed in own directory, I replacing only it. - Denis
----- 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?
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> Hmm... But what if I want to update one header-only library? If I have 'common' file that include all the other files at the boost directory level, I must replace this file AND own directory. But if all files
16.01.2011 00:49, vicente.botet пишет: placed in own directory, I replacing only it.
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:
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>
+1
But for libraries with one 'main concept' file must exists such file. For example, in my Configurator:
#include <boost/configurator/configurator.hpp>
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.
18.01.2011 18:58, Stewart, Robert пишет:
But for libraries with one 'main concept' file must exists such file. For example, in my Configurator:
#include<boost/configurator/configurator.hpp> 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.
Yes, I agree. Confess, never thought about it... - Denis
2011/1/18 Stewart, Robert <Robert.Stewart@sig.com>:
But for libraries with one 'main concept' file must exists such file. For example, in my Configurator:
#include <boost/configurator/configurator.hpp>
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.
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:
2011/1/18 Stewart, Robert <Robert.Stewart@sig.com>:
But for libraries with one 'main concept' file must exists such file. For example, in my Configurator:
#include <boost/configurator/configurator.hpp>
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.
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.
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:
Dave Abrahams wrote:
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.
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?
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:
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.
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:
----- 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?
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> Hmm... But what if I want to update one header-only library? If I have 'common' file that include all the other files at the boost
16.01.2011 00:49, vicente.botet ?????: directory level, I must replace this file AND own directory. But if all files placed in own directory, I replacing only it.
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>
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.
Vicente
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG On 1/15/2011 2:11 PM, Robert Ramey wrote:
vicente.botet wrote:
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> 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 favor this approach because it's already common practice. I don't consider any of the arguments against it that I've seen sufficient to justify going to something new. In Christ, Steven Watanabe
At Sat, 15 Jan 2011 14:30:46 -0800, Steven Watanabe wrote:
AMDG
On 1/15/2011 2:11 PM, Robert Ramey wrote:
vicente.botet wrote:
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> 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 favor this approach because it's already common practice. I don't consider any of the arguments against it that I've seen sufficient to justify going to something new.
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:
vicente.botet wrote:
----- 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?
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> Hmm... But what if I want to update one header-only library? If I have 'common' file that include all the other files at the boost
16.01.2011 00:49, vicente.botet ?????: directory level, I must replace this file AND own directory. But if all files placed in own directory, I replacing only it. 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> 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. Your compiler loves you for this, less work to do. I do the same, because it is less work for the compiler, because I worry about side effects from things I don't need, because I don't know without close examination if any extra memory will be used by including something I don't need, and because by including the minimum I need I can convince myself that I have a deeper understanding.
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
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>
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>
Nod, agreed: having a simple "include everything" header at the top level can be very useful. We can still put everything in a sub-namespace (and IMO this should be the norm for new libraries). John.
Denis Shevchenko wrote:
12345678901234567890123456789012345678901234567890123456789012345
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.
+1
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>
-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.
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>
+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.
Furthermore, the directory and namespace names should be identical. Thus, boost/ptr_container provides code in boost::ptr_container. Note that this proposal conflicts with some existing libraries (e.g. tuple, bimap).
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:
Rob Stewart wrote:
Furthermore, the directory and namespace names should be identical. Thus, boost/ptr_container provides code in boost::ptr_container.
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.
Furthermore, the directory and namespace names should be identical. Thus, boost/ptr_container provides code in boost::ptr_container. 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!
I understand and agree, but I also gave a reason why this requirement is sometimes difficult to meet. Regards, Barend
On 18/01/11 15:23, Barend Gehrels wrote:
Furthermore, the directory and namespace names should be identical. Thus, boost/ptr_container provides code in boost::ptr_container. 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!
I understand and agree, but I also gave a reason why this requirement is sometimes difficult to meet.
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>:
On 18/01/11 15:23, Barend Gehrels wrote:
Furthermore, the directory and namespace names should be identical. Thus, boost/ptr_container provides code in boost::ptr_container.
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!
I understand and agree, but I also gave a reason why this requirement is sometimes difficult to meet.
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.
... 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:
2011/1/18 Mateusz Loskot<mateusz@loskot.net>:
On 18/01/11 15:23, Barend Gehrels wrote:
Furthermore, the directory and namespace names should be identical. Thus, boost/ptr_container provides code in boost::ptr_container.
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!
I understand and agree, but I also gave a reason why this requirement is sometimes difficult to meet.
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.
... 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
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:
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
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
2011/1/18 Robert Ramey <ramey@rrsd.com>:
Joachim Faulhaber wrote:
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
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 ?
because xpressive names have a better spirit, bring qi to your software and will enhance your karma so they can heal your (con)fusion and make you wave like a phoenix from the ashes.
From: Joachim Faulhaber
How is it we have names like kara, qi, phoenix, fusion, gil, spirit, wave and xpressive ?
because xpressive names have a better spirit, bring qi to your software and will enhance your karma so they can heal your (con)fusion and make you wave like a phoenix from the ashes.
Wow, that's gilorious.
On 01/18/2011 09:08 AM, Joachim Faulhaber wrote:
because xpressive names have a better spirit, bring qi to your software and will enhance your karma so they can heal your (con)fusion and make you wave like a phoenix from the ashes. _______________________________________________
very clever Joachim. -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
At Tue, 18 Jan 2011 15:19:49 -0800, Michael Caisse wrote:
On 01/18/2011 09:08 AM, Joachim Faulhaber wrote:
because xpressive names have a better spirit, bring qi to your software and will enhance your karma so they can heal your (con)fusion and make you wave like a phoenix from the ashes. _______________________________________________
very clever Joachim.
Not only that; he plays a mean samba! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 01/18/2011 09:08 AM, Joachim Faulhaber wrote:
because xpressive names have a better spirit, bring qi to your software and will enhance your karma so they can heal your (con)fusion and make you wave like a phoenix from the ashes. _______________________________________________
very clever Joachim. -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
because xpressive names have a better spirit, bring qi to your software and will enhance your karma so they can heal your (con)fusion and make you wave like a phoenix from the ashes.
Brilliant! LOL Regards Hartmut --------------- http://boost-spirit.com
On Tue, Jan 18, 2011 at 10:49 AM, Joachim Faulhaber <afojgo@googlemail.com> 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.
... 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
Though again, I'd like to discuss whether we want to keep that policy. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
From: Barend Gehrels 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.
Even I am not convinced to the idea myself, but here it is: in cases like Boost.Tuple call the folder 'tuple_lib' and the namespace 'boost::tuple_lib'. This fixes the problem with ambiguous names and looks not worse than 'tuples'. Best regards, Robert
On Jan 18, 2011, at 4:29 PM, Robert Kawulak wrote:
From: Barend Gehrels 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.
Even I am not convinced to the idea myself, but here it is: in cases like Boost.Tuple call the folder 'tuple_lib' and the namespace 'boost::tuple_lib'. This fixes the problem with ambiguous names and looks not worse than 'tuples'.
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:
On Jan 18, 2011, at 4:29 PM, Robert Kawulak wrote:
From: Barend Gehrels 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.
Even I am not convinced to the idea myself, but here it is: in cases like Boost.Tuple call the folder 'tuple_lib' and the namespace 'boost::tuple_lib'. This fixes the problem with ambiguous names and looks not worse than 'tuples'.
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... ;)
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>:
On Wed, Jan 19, 2011 at 7:06 AM, Andreas Masur <boost@andreasmasur.com> wrote:
On Jan 18, 2011, at 4:29 PM, Robert Kawulak wrote:
From: Barend Gehrels 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.
Even I am not convinced to the idea myself, but here it is: in cases like Boost.Tuple call the folder 'tuple_lib' and the namespace 'boost::tuple_lib'. This fixes the problem with ambiguous names and looks not worse than 'tuples'.
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... ;)
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?
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
Even I am not convinced to the idea myself, but here it is: in cases like Boost.Tuple call the folder 'tuple_lib' and the namespace 'boost::tuple_lib'. This fixes the problem with ambiguous names and looks not worse than 'tuples'.
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... ;)
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?
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:
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?
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.
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:
On Wed, Jan 19, 2011 at 4:18 PM, Barend Gehrels <barend@geodan.nl> wrote:
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?
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.
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"?
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:
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`)?
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:
On 19/01/11 05:51, Dean Michael Berris 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`)?
There are libraries with 'lib' in name like libpng, libtiff or zlib, so there could be:
libspirit libgeometry libfilesystem ...
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:
On Wed, Jan 19, 2011 at 7:56 PM, Mateusz Loskot<mateusz@loskot.net> wrote:
On 19/01/11 05:51, Dean Michael Berris 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`)?
There are libraries with 'lib' in name like libpng, libtiff or zlib, so there could be:
libspirit libgeometry libfilesystem ...
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).
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:
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D
cpp-net? :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 19-1-2011 17:19, Dave Abrahams wrote:
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote:
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D cpp-net? :-)
For a library not (yet) in boost, cpp-netlib is appropriate. As soon as it is in boost, Boost.Net? We had the same thing, ggl (generic geometry library) became Boost.Geometry because both generic and library were redundant. Barend
On Thu, Jan 20, 2011 at 12:46 AM, Joel Falcou <joel.falcou@lri.fr> wrote:
On 19/01/11 17:31, Denis Shevchenko wrote:
19.01.2011 20:27, Barend Gehrels пишет:
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
+1.
Boost.Network ??
I think Boost.Network works, but Boost.Net is maybe sexier. :D -- Dean Michael Berris about.me/deanberris
Dean Michael Berris wrote:
On Thu, Jan 20, 2011 at 12:46 AM, Joel Falcou <joel.falcou@lri.fr> wrote:
On 19/01/11 17:31, Denis Shevchenko wrote:
19.01.2011 20:27, Barend Gehrels пишет:
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
+1.
Boost.Network ??
I think Boost.Network works, but Boost.Net is maybe sexier. :D
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:
Dean Michael Berris wrote:
On Thu, Jan 20, 2011 at 12:46 AM, Joel Falcou <joel.falcou@lri.fr> wrote:
On 19/01/11 17:31, Denis Shevchenko wrote:
19.01.2011 20:27, Barend Gehrels пишет:
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
+1. Boost.Network ?? I think Boost.Network works, but Boost.Net is maybe sexier. :D I dislike the suggestion of .NET evoked by Boost.Net. It suggests that Boost is into .NET development!
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
2011/1/20 Stewart, Robert <Robert.Stewart@sig.com>:
Dean Michael Berris wrote:
I think Boost.Network works, but Boost.Net is maybe sexier. :D
I dislike the suggestion of .NET evoked by Boost.Net. It suggests that Boost is into .NET development!
You're right, I just completely forgot there's a Microsoft.NET going on outside of my UNIX/Linux view of the world. :) -- Dean Michael Berris about.me/deanberris
On 19/01/11 17:04, Dean Michael Berris wrote:
On Thu, Jan 20, 2011 at 12:46 AM, Joel Falcou<joel.falcou@lri.fr> wrote:
On 19/01/11 17:31, Denis Shevchenko wrote:
19.01.2011 20:27, Barend Gehrels пишет:
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
+1.
Boost.Network ??
I think Boost.Network works, but Boost.Net is maybe sexier. :D
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 Denis Shevchenko <for.dshevchenko@gmail.com>
19.01.2011 20:27, Barend Gehrels пишет:
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
+1.
But it sounds like a domain name or something MS has. Will Boost.Network sounds better?
19.01.2011 20:54, TONGARI пишет:
2011/1/20 Denis Shevchenko<for.dshevchenko@gmail.com>
19.01.2011 20:27, Barend Gehrels пишет:
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
+1. But it sounds like a domain name or something MS has.
:-) Yes, Boost.Network is better, I think... - Denis
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
2011/1/20 Dean Michael Berris <mikhailberis@gmail.com>
2011/1/20 TONGARI <tongari95@gmail.com>:
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. ;)
To be creative, how about: Boost.NetX or Boost.Netful ? not really serious ideas though :-)
On Thu, Jan 20, 2011 at 12:27 AM, Barend Gehrels <barend@geodan.nl> wrote:
On 19-1-2011 17:19, Dave Abrahams wrote:
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote:
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D
cpp-net? :-)
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
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:
On 19-1-2011 17:19, Dave Abrahams wrote:
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote:
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D cpp-net? :-)
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
We had the same thing, ggl (generic geometry library) became Boost.Geometry because both generic and library were redundant.
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:
On 19/01/11 16:27, Barend Gehrels wrote:
On 19-1-2011 17:19, Dave Abrahams wrote:
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote:
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D cpp-net? :-)
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
We had the same thing, ggl (generic geometry library) became Boost.Geometry because both generic and library were redundant.
Speaking of names and (my) personal preferences, Boost.Image or Boost.Raster would be better than GIL.
+1! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On 19/01/11 18:20, Dave Abrahams wrote:
At Wed, 19 Jan 2011 16:56:58 +0000, Mateusz Loskot wrote:
On 19/01/11 16:27, Barend Gehrels wrote:
On 19-1-2011 17:19, Dave Abrahams wrote:
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote:
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D cpp-net? :-)
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
We had the same thing, ggl (generic geometry library) became Boost.Geometry because both generic and library were redundant.
Speaking of names and (my) personal preferences, Boost.Image or Boost.Raster would be better than GIL.
+1!
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:
On 19/01/11 18:20, Dave Abrahams wrote:
At Wed, 19 Jan 2011 16:56:58 +0000, Mateusz Loskot wrote:
On 19/01/11 16:27, Barend Gehrels wrote:
On 19-1-2011 17:19, Dave Abrahams wrote:
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote:
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D cpp-net? :-)
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
We had the same thing, ggl (generic geometry library) became Boost.Geometry because both generic and library were redundant.
Speaking of names and (my) personal preferences, Boost.Image or Boost.Raster would be better than GIL.
+1!
I don't want to be too poisonous here, wondering what would be a procedure to rename library? A renaming review? Simple poll?
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:
Mateusz Loskot wrote:
On 19/01/11 18:20, Dave Abrahams wrote:
At Wed, 19 Jan 2011 16:56:58 +0000, Mateusz Loskot wrote:
On 19/01/11 16:27, Barend Gehrels wrote:
On 19-1-2011 17:19, Dave Abrahams wrote:
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote: > Although cpp-netlib > is there, I'm just not that creative to come up with an > alternate name for it. :D cpp-net? :-)
For a library not (yet) in boost, cpp-netlib is appropriate.
As soon as it is in boost, Boost.Net?
We had the same thing, ggl (generic geometry library) became Boost.Geometry because both generic and library were redundant.
Speaking of names and (my) personal preferences, Boost.Image or Boost.Raster would be better than GIL.
+1!
I don't want to be too poisonous here, wondering what would be a procedure to rename library? A renaming review? Simple poll?
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.
You are right.
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"
Understood. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org
19.01.2011 20:19, Dave Abrahams пишет:
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote:
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D cpp-net? :-) net? :-) We are talking about C++, so 'cpp-' is needless...
- Denis
On Thu, Jan 20, 2011 at 12:19 AM, Dave Abrahams <dave@boostpro.com> wrote:
At Wed, 19 Jan 2011 19:58:09 +0800, Dean Michael Berris wrote:
Although cpp-netlib is there, I'm just not that creative to come up with an alternate name for it. :D
cpp-net? :-)
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
19.01.2011 15:56, Mateusz Loskot пишет:
There are libraries with 'lib' in name like libpng, libtiff or zlib, so there could be:
libspirit libgeometry libfilesystem
I think it is redundant. We are talking about Boost C++ *libraries*, so 'lib' prefix (or suffix) is needless. - Denis
On 19/01/11 12:55, Denis Shevchenko wrote:
19.01.2011 15:56, Mateusz Loskot пишет:
There are libraries with 'lib' in name like libpng, libtiff or zlib, so there could be:
libspirit libgeometry libfilesystem
I think it is redundant. We are talking about Boost C++ *libraries*, so 'lib' prefix (or suffix) is needless.
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
From: Dean Michael 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`)?
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:
From: Dean Michael 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`)?
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.
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. * * *
On Jan 19, 2011, at 12:51 AM, Dean Michael Berris wrote:
[...] 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?
You probably wouldn't....unless the name of your wife and daughter is the same.... ;) Ciao, Andreas
At Tue, 18 Jan 2011 22:29:06 +0100, Robert Kawulak wrote:
From: Barend Gehrels 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.
Even I am not convinced to the idea myself, but here it is: in cases like Boost.Tuple call the folder 'tuple_lib' and the namespace 'boost::tuple_lib'. This fixes the problem with ambiguous names and looks not worse than 'tuples'.
Meh; such names get needlessly long, IMO. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
18.01.2011 18:50, Stewart, Robert пишет:
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> -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.
Hm... Yes, you are right.
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> +1
Furthermore, the directory and namespace names should be identical. Thus, boost/ptr_container provides code in boost::ptr_container.
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:
----- 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?
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.
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.
Please! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sat, Jan 15, 2011 at 3:32 PM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
----- 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?
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.
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.
+1, although I think the name should be boost::ratio rather than boost::ratios
--Beman
At Sat, 15 Jan 2011 16:30:57 -0500, Beman Dawes wrote:
On Sat, Jan 15, 2011 at 3:32 PM, vicente.botet <vicente.botet@wanadoo.fr>wrote:
----- 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?
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.
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.
+1, although I think the name should be boost::ratio rather than boost::ratios
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:
+1, although I think the name should be boost::ratio rather than boost::ratios
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.
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:
On Jan 15, 2011, at 4:46 PM, Dave Abrahams wrote:
+1, although I think the name should be boost::ratio rather than boost::ratios
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.
http://www.boost.org/doc/libs/1_45_0/libs/tuple/doc/design_decisions_rationa... "For those who are really interested in namespaces"
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:
At Sat, 15 Jan 2011 17:12:37 -0500, Kim Barrett wrote:
http://www.boost.org/doc/libs/1_45_0/libs/tuple/doc/design_decisions_rationa... "For those who are really interested in namespaces" Interesting. I wonder if those errors they encountered with using are conforming behavior and/or obsolete issues due to compiler fixes.
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:
AMDG
On 1/15/2011 8:24 PM, Dave Abrahams wrote:
At Sat, 15 Jan 2011 17:12:37 -0500, Kim Barrett wrote:
http://www.boost.org/doc/libs/1_45_0/libs/tuple/doc/design_decisions_rationa... "For those who are really interested in namespaces"
Interesting. I wonder if those errors they encountered with using are conforming behavior and/or obsolete issues due to compiler fixes.
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.
Then I say, "make it match the library name, with a bias towards singular library names." -- Dave Abrahams BoostPro Computing http://www.boostpro.com
AMDG On 1/18/2011 9:17 AM, Dave Abrahams wrote:
On Sun, Jan 16, 2011 at 12:10 AM, Steven Watanabe<watanabesj@gmail.com> wrote:
On 1/15/2011 8:24 PM, Dave Abrahams wrote:
At Sat, 15 Jan 2011 17:12:37 -0500, Kim Barrett wrote:
http://www.boost.org/doc/libs/1_45_0/libs/tuple/doc/design_decisions_rationa... "For those who are really interested in namespaces"
Then I say, "make it match the library name, with a bias towards singular library names."
There's one other way that a user could get a problem. using namespace boost; using namespace boost::tuple; tuple<int> t; In Christ, Steven Watanabe
On Tue, Jan 18, 2011 at 12:26 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
On 1/18/2011 9:17 AM, Dave Abrahams wrote:
On Sun, Jan 16, 2011 at 12:10 AM, Steven Watanabe<watanabesj@gmail.com> wrote:
On 1/15/2011 8:24 PM, Dave Abrahams wrote:
At Sat, 15 Jan 2011 17:12:37 -0500, Kim Barrett wrote:
http://www.boost.org/doc/libs/1_45_0/libs/tuple/doc/design_decisions_rationa... "For those who are really interested in namespaces"
Then I say, "make it match the library name, with a bias towards singular library names."
There's one other way that a user could get a problem.
using namespace boost; using namespace boost::tuple;
tuple<int> t;
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:
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.
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:
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
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"...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Mathias Gaunard Sent: Sunday, January 16, 2011 11:18 AM To: boost@lists.boost.org Subject: Re: [boost] namespace boost?
On 15/01/2011 19:58, Robert Ramey wrote:
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
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:
Mathias Gaunard wrote:
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).
I agree WRT to boost, but not std. It doesn't have to apply to boost either, but that is the current reality.
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.
+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:
Anyway, it's probably not a good idea to do "using namespace boost", just like you shouldn't do "using namespace std"...
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