[boost] namespace boost?
Robert Ramey
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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Frédéric Bron
> 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
Mostafa
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
Denis Shevchenko
> 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.
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
vicente.botet
From: "Robert Ramey" <ra...@rrsd.com>
To: <bo...@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
Denis Shevchenko
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>
vicente.botet
From: "Denis Shevchenko" <for.dsh...@gmail.com>
To: <bo...@lists.boost.org>
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
Denis Shevchenko
> 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>
'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
placed in own directory, I replacing only it.
- Denis
vicente.botet
From: "Denis Shevchenko" <for.dsh...@gmail.com>
To: <bo...@lists.boost.org>
Sent: Saturday, January 15, 2011 9:56 PM
Subject: Re: [boost] namespace boost?
> 16.01.2011 00:49, vicente.botet пишет:
>> 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
> 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
Dave Abrahams
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
Dave Abrahams
vicente.botet wrote:
>
> ----- Original Message -----
> From: "Robert Ramey" <ra...@rrsd.com>
> To: <bo...@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
_______________________________________________
Denis Shevchenko
> 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>
>
'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
Beman Dawes
> ----- Original Message -----
> From: "Robert Ramey" <ra...@rrsd.com>
> To: <bo...@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
Beman Dawes
> 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
directly into boost, that's fine, but only after a full airing on the list.
--Beman
Dave Abrahams
Beman Dawes wrote:
>
> On Sat, Jan 15, 2011 at 3:32 PM, vicente.botet <vicent...@wanadoo.fr>wrote:
>
> > ----- Original Message -----
> > From: "Robert Ramey" <ra...@rrsd.com>
> > To: <bo...@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
_______________________________________________
Denis Shevchenko
> IMO we've gone past the point that we can afford to put anything new directly in boost.
- Denis
Robert Ramey
> ----- Original Message -----
> From: "Denis Shevchenko" <for.dsh...@gmail.com>
> To: <bo...@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 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.
Kim Barrett
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_rationale.html
"For those who are really interested in namespaces"
Denis Shevchenko
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
Denis Shevchenko
> The reason I do this is that I like knowing that I'm including only
> the minimum required to get the job done.
>
- Denis
Steven Watanabe
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
Patrick Horgan
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
Edward Diener
> 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.
Dave Abrahams
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_rationale.html
> "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
_______________________________________________
Dave Abrahams
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
_______________________________________________
Steven Watanabe
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_rationale.html
>> "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
John Maddock
>> 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.
Mathias Gaunard
> 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"...
Paul A. Bristow
> From: boost-...@lists.boost.org [mailto:boost-...@lists.boost.org]
> On Behalf Of Mathias Gaunard
> Sent: Sunday, January 16, 2011 11:18 AM
> To: bo...@lists.boost.org
> Subject: Re: [boost] namespace boost?
>
>
> > 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
pbri...@hetp.u-net.com
Stewart, Robert
>
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....@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.
Stewart, Robert
> 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....@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.
Stewart, Robert
> 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....@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.
Stewart, Robert
>
> 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....@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.
Stewart, Robert
> 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....@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.
Barend Gehrels
> 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
Stewart, Robert
> 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....@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.
Barend Gehrels
>>> 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
_______________________________________________
Mateusz Loskot
>>>> 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
Denis Shevchenko
>> 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.
>
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
Joachim Faulhaber
> 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
Denis Shevchenko
>
>> 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.
- Denis
Mateusz Loskot
> 2011/1/18 Mateusz Loskot<mat...@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
Denis Shevchenko
>
> ... in my opinion libraries and namespaces should be singular.
> I can't think of any reason why it has to be plural.
>
- Denis
Robert Ramey
> 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
Joachim Faulhaber
> Joachim Faulhaber wrote:
>> 2011/1/18 Mateusz Loskot <mat...@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 ?
>
software and will enhance your karma so they can heal your (con)fusion
and make you wave like a phoenix from the ashes.
Dave Abrahams
<afo...@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
Dave Abrahams
> 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_rationale.html
>>> "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
Steven Watanabe
On 1/18/2011 9:17 AM, Dave Abrahams wrote:
> On Sun, Jan 16, 2011 at 12:10 AM, Steven Watanabe<watan...@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_rationale.html
>>>> "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
Dave Abrahams
>> 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
> AMDG
>
> On 1/18/2011 9:17 AM, Dave Abrahams wrote:
>>
>> On Sun, Jan 16, 2011 at 12:10 AM, Steven Watanabe<watan...@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_rationale.html
>>>>> "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
Stewart, Robert
> 2011/1/18 Stewart, Robert <Robert....@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....@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.
Steven Watanabe
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
Stewart, Robert
>
> 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....@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.
Robert Kawulak
> > 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.
Robert Kawulak
> 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
Andreas Masur
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
Michael Caisse
>
> 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
Michael Caisse
>
> 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
_______________________________________________
Hartmut Kaiser
> 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
Dave Abrahams
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
_______________________________________________
Dave Abrahams
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
_______________________________________________
Dean Michael Berris
>
> 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
Joachim Faulhaber
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
Barend Gehrels
>>>
>>> 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?
>
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
Dean Michael Berris
>>
>> 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
Mateusz Loskot
> 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
Dean Michael Berris
> 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
Mateusz Loskot
> On Wed, Jan 19, 2011 at 7:56 PM, Mateusz Loskot<mat...@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
Robert Kawulak
> 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
Denis Shevchenko
>
> There are libraries with 'lib' in name like
> libpng, libtiff or zlib, so there could be:
>
> libspirit
> libgeometry
> libfilesystem
>
'lib' prefix (or suffix) is needless.
- Denis
Mateusz Loskot
> 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
Chad Nelson
Robert Kawulak <robert....@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.
*
*
*
Dave Abrahams
Dean Michael Berris wrote:
>
> On Wed, Jan 19, 2011 at 4:18 PM, Barend Gehrels <bar...@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
_______________________________________________
Dave Abrahams
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
_______________________________________________
Barend Gehrels
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
Denis Shevchenko
> 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? :-)
- Denis
Denis Shevchenko
> For a library not (yet) in boost, cpp-netlib is appropriate.
>
> As soon as it is in boost, Boost.Net?
>
- Denis
Dean Michael Berris
> 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
Dean Michael Berris
>
> 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
Joel Falcou
> 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.
Mateusz Loskot
>
>
> 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
TONGARI
> 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?
Dean Michael Berris
> 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
Mateusz Loskot
> On Thu, Jan 20, 2011 at 12:46 AM, Joel Falcou<joel....@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
Stewart, Robert
> On Thu, Jan 20, 2011 at 12:46 AM, Joel Falcou
> <joel....@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....@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.
Denis Shevchenko
> 2011/1/20 Denis Shevchenko<for.dsh...@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.
>
- Denis
Barend Gehrels
> Dean Michael Berris wrote:
>> On Thu, Jan 20, 2011 at 12:46 AM, Joel Falcou
>> <joel....@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
Dean Michael Berris
>
> 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
Barend Gehrels
>> As soon as it is in boost, Boost.Net?
> I like that. :) I shall credit you with the name suggestion. :D
>
Barend
Dean Michael Berris
> 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
Dave Abrahams
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
_______________________________________________
Brent Spillner
>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
When I first saw the name 'cpp-netlib' I assumed it was a numerical library. ;-)
Joel de Guzman
> 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
Andreas Masur
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
TONGARI
> 2011/1/20 TONGARI <tong...@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 :-)
Mateusz Loskot
> 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
Robert Ramey
> 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,
Mateusz Loskot
> 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