[boost] Re: compile-time binary constants
On Sat, 18 Jan 2003 20:16:36 -0700, Greg Colvin
[EMAIL PROTECTED] wrote:
At a meeting years ago I proposed to make string literals more
useful as constant expressions, but we decided against that.
As I recall part of the problem is that linkers are free to map
the same literal string to different addresses in different
compilation units.
Well, it's obvious that implications must be carefully analyzed. What
I was thinking to in the context of this thread was probably something
*less general* than what you proposed: making an expression of the
form
string-literal [ integral-constant-expression ]
or
integral-constant-expression [ string-literal ]
an integral constant expression of type const char. Problems with the
fact that such expression is currently an lvalue are easily solvable
with appropriate rules. The idea was that given, for instance,
template char c
struct binary_digit {
static const int value = (c == '0'? 0 : 1);
};
you would be able to write:
binary_digit 110[1]::value
just like you can now write
binary_digit '1'::value
This is IMHO useful in a number of idioms. Do you disagree?
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
On Sat, 18 Jan 2003 21:55:59 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
Gennaro Prota [EMAIL PROTECTED] writes:
I see. Can we expect an extension for C++0x then?
Not unless someone makes a formal proposal. Are you volunteering?
Yes, I would be glad to write a formal proposal. But, as it has been
repeatedly pointed out on comp.std.c++, this is not enough if you are
not in the committee and that, de facto, there are very little chances
for the proposal to be approved if you are not present to defend it
and respond to questions and, above all, objections.
As I hinted at in a previous post, the limitations about integral
constant expressions are a little odd to me. For instance, why
prohibiting the comma operator?
I don't know; maybe because there's some implication about order of
evaluation? Did you check DE?
I don't have DE. However this is a legacy of C. The C99 rationale
says:
An integer constant expression must involve only numbers
knowable at translation time, and operators with no side
effects.
C++ could have IMHO lifted this restriction, to allow at least the
classical sizeof usages in combination with overload resolution as the
EXPLICIT_CAST example shows.
Do you remember my EXPLICIT_CAST?
Nope.
#define EXPLICIT_CAST(dst_type, expr) \
( static_cast check_helperdst_type, \
sizeof(implicit_castdst_type(expr)) \
:: type(expr) )
The intent was for it to be suitable for constant expressions. Well,
as you may have noticed the check_helper template was there just
because I couldn't do something like:
template typename T
void implicit_cast (typename identityT::type x) {
return x;
}
template typename T
char implicit_cast (...);
#define EXPLICIT_CAST(dst_type, expr) \
( sizeof( implicit_castdst_type(expr) ) \
,\
static_castdst_type(expr) \
)
This seems natural: you use sizeof to check whether implicit
conversion happens, then you discard its result. What's wrong with
it?
For one thing, it doesn't check whether an implicit conversion
occurs.
Uh? It checks whether expr is implicitly convertible to dst_type, in
the sense that if it is then it gives a diagnostic. What do you mean??
For another thing, it would be a compile-error if the
expression *can* be implicitly converted to the destination type,
which makes no sense to me.
Isn't this the intent? The implementation I gave earlier, i.e.
http://lists.boost.org/MailArchives/boost/msg39819.php
does the same thing.
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] HP regression tests
Toon, There are a couple of config issues arising from the HP regression tests (and thanks for running these BTW): The output from config_info is not showing up in the report (which is really the reason for the extra queries below), try deleting boost-path/status/bin/config_info.test/ before you next run the tests. The compiler seems not to support template templates according to the config_test failure. We currently have: #if (__HP_aCC = 33900) #define BOOST_NO_TEMPLATE_TEMPLATES #define BOOST_NO_MEMBER_TEMPLATE_KEYWORD #define BOOST_NO_UNREACHABLE_RETURN_DETECTION #endif which I presume needs updating? What is the latest __HP_aCC version number? The thread code is all failing, probably because the jam toolset is not set up correctly, according to the online docs at: http://docs.hp.com/hpux/onlinedocs/dev/aCC/a_03_26/threads.htm we need to set: -D_RWSTD_MULTI_THREAD -D_REENTRANT when compiling and add -lpthread to the linker, I can't find any reference to the -mt option that is currently in the jam toolset. Thanks, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] date_time oversight?
date_names_put is defined in date_names_put.hpp as
templateclass Config,
class charT = char,
class OutputIterator = std::ostreambuf_iteratorcharT
class date_names_put : public std::locale::facet
file greg_facet.hpp defines:
typedef boost::date_time::date_names_putgreg_facet_config greg_base_facet;
This makes use of the default charT = char.
Later in that file...
template class charT, class traits
inline
std::basic_ostreamcharT, traits
operator(std::basic_ostreamcharT, traits os, const date d)
{
typedef boost::date_time::ostream_date_formatterdate, greg_base_facet, charT
greg_ostream_formatter;
greg_ostream_formatter::date_put(d, os);
return os;
}
This function purports to be valid for any charT. However, because greg_base_facet is
a typedef for date_names_put with a default of char, it looks to me it wouldn't work
for
other char types such as wchar_t.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line config file library)
Edward Diener [EMAIL PROTECTED] writes: Fredrik Blomqvist [EMAIL PROTECTED] wrote in message b0cvd7$4dv$[EMAIL PROTECTED]">news:b0cvd7$4dv$[EMAIL PROTECTED]... -snip- I thought the C++ template solution by Damian Conway was pretty neat, -snip- I thought so too at first, but at a closer look you can see that the code in practice only works for integers.. It solves the problem in the original thread, but shouldn't be mistaken for a generic solution. It seems as if it should work for any type with a copy constructor. Perhaps I missed something. Nonetheless I do favor a compiler change such as allowing the default keyword to be used instead as Mr. Terekhov suggested in that same thread. That would be much cleaner and should be easy for any compiler to handle. This is one case where I would like to see the language updated with such an easy, transparent solution to the problem. Of course if others don't see it as much of a problem, they wouldn't be in favor of the solution since it involves the dreaded C++ language change Oh, it's a problem alright, but I'm still not very convinced of that solution. The problem with interfaces that have lots of positional parameters is that you forget what the different positions mean. To solve that problem, you need either named parameters or a position-independent interface. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] HP regression tests
John Maddock [EMAIL PROTECTED] writes: Toon, There are a couple of config issues arising from the HP regression tests (and thanks for running these BTW): The output from config_info is not showing up in the report (which is really the reason for the extra queries below), try deleting boost-path/status/bin/config_info.test/ before you next run the tests. The compiler seems not to support template templates according to the config_test failure. We currently have: #if (__HP_aCC = 33900) #define BOOST_NO_TEMPLATE_TEMPLATES #define BOOST_NO_MEMBER_TEMPLATE_KEYWORD #define BOOST_NO_UNREACHABLE_RETURN_DETECTION #endif which I presume needs updating? What is the latest __HP_aCC version number? The thread code is all failing, probably because the jam toolset is not set up correctly, according to the online docs at: http://docs.hp.com/hpux/onlinedocs/dev/aCC/a_03_26/threads.htm we need to set: -D_RWSTD_MULTI_THREAD -D_REENTRANT when compiling and add -lpthread to the linker, I can't find any reference to the -mt option that is currently in the jam toolset. There's another reason, probably. HP has what they call incomplete pthread support. I explicitly enabled threading in the HP OS config because I didn't think a partial implementation should prevent us from testing. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time binary constants
Gennaro Prota [EMAIL PROTECTED] writes:
On Sat, 18 Jan 2003 21:55:59 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
Gennaro Prota [EMAIL PROTECTED] writes:
I see. Can we expect an extension for C++0x then?
Not unless someone makes a formal proposal. Are you volunteering?
Yes, I would be glad to write a formal proposal. But, as it has been
repeatedly pointed out on comp.std.c++, this is not enough if you are
not in the committee and that, de facto, there are very little chances
for the proposal to be approved if you are not present to defend it
and respond to questions and, above all, objections.
Anyone can show up for a meeting. Another thing you can do is to
convince someone who will be there to represent the proposal for you.
Do you remember my EXPLICIT_CAST?
Nope.
#define EXPLICIT_CAST(dst_type, expr) \
( static_cast check_helperdst_type, \
sizeof(implicit_castdst_type(expr)) \
:: type(expr) )
The intent was for it to be suitable for constant expressions. Well,
as you may have noticed the check_helper template was there just
because I couldn't do something like:
template typename T
void implicit_cast (typename identityT::type x) {
return x;
}
template typename T
char implicit_cast (...);
#define EXPLICIT_CAST(dst_type, expr) \
( sizeof( implicit_castdst_type(expr) ) \
,\
static_castdst_type(expr) \
)
This seems natural: you use sizeof to check whether implicit
conversion happens, then you discard its result. What's wrong with
it?
For one thing, it doesn't check whether an implicit conversion
occurs.
Uh? It checks whether expr is implicitly convertible to dst_type, in
the sense that if it is then it gives a diagnostic. What do you mean??
For another thing, it would be a compile-error if the
expression *can* be implicitly converted to the destination type,
which makes no sense to me.
Isn't this the intent?
I don't know what the intent is; you never explained that to me. What
this does is to static_cast only when it must be forced (often in the
unsafe direction); it was hard to see how that could be useful.
Maybe just as a way of stating and checking that you know what you're
doing?
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with boost on Cray C++ release 3.6
I still have three problems with Cray C++ v. 3.6, but got some parts to compile. They are: i) a problem with template instantiation - here it seems that the compiler might not be correctly installed on our system and I will talk to the Cray engineers. ii) static assertions do not work iii) in some cases typenames in base classes are not found While I am still working on these three issues, I could solve the problem with cstdint.hpp. and have attached a context diff of the changes. The main issue was that short is 32 bit and int is 64 bit on the Cray: --- cstdint.hpp 27 Dec 2002 16:51:52 - 1.28 +++ cstdint.hpp 19 Jan 2003 15:25:04 - @@ -160,7 +160,11 @@ // 16-bit types ---// -# if USHRT_MAX == 0x +# if USHRT_MAX == 0x + typedef short int_least16_t; + typedef unsigned short uint_least16_t; +#define BOOST_NO_INT16_T +# elif USHRT_MAX == 0x typedef short int16_t; typedef short int_least16_t; typedef short int_fast16_t; @@ -187,6 +191,13 @@ typedef unsigned intuint32_t; typedef unsigned intuint_least32_t; typedef unsigned intuint_fast32_t; +# elif USHRT_MAX == 0x + typedef short int32_t; + typedef short int_least32_t; + typedef short int_fast32_t; + typedef unsigned short uint32_t; + typedef unsigned short uint_least32_t; + typedef unsigned short uint_fast32_t; # else #error defaults not correct; you must hand modify boost/cstdint.hpp # endif ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
On Sun, 19 Jan 2003 09:42:51 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
For another thing, it would be a compile-error if the
expression *can* be implicitly converted to the destination type,
which makes no sense to me.
Isn't this the intent?
I don't know what the intent is; you never explained that to me. What
this does is to static_cast only when it must be forced (often in the
unsafe direction); it was hard to see how that could be useful.
Maybe just as a way of stating and checking that you know what you're
doing?
Well, actually I did it just for the fun of it. The original thread
was about implicit_cast, not explicit, and I added some thoughts. In
any case the comment I've made here about the comma operator applies
to the implicit piece as well:
template typename T
char implicit_cast (typename identityT::type x) {
return x;
}
// incomplete return type now is here
template typename T
void implicit_cast (...);
#define IMPLICIT_CAST(dst_type, expr) \
( sizeof( implicit_castdst_type(expr) ) \
,\
static_castdst_type(expr) \
)
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] intel-linux-tools.jam
On Friday 17 January 2003 11:07, David Abrahams wrote: Toon Knapen [EMAIL PROTECTED] writes: On Friday 17 January 2003 14:59, David Abrahams wrote: No, please restore that feature. The build system offers no guarantees about the order in which specified libraries will be added to NEEDLIBS, and we'd rather work in all circumstances than save whatever miniscule amount of link time it takes to deal with the repetition. Done. Nevertheless I use bjam also for my own project (as you might know) and there I've always removed the duplication because I don't want to allow developers to create circulare dependencies. And the system has worked fine (thanks again jamboosters) It's not just about circular dependencies. If library A depends on library B, when you link them into an executable there's no guarantee that they'll appear in the right order. OK but I never had any trouble with it so far (although NEEDLIBS is only used once in my linkline to prevent people from creating circular dependencies) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression tests for aCC are up
On Friday 17 January 2003 11:28, Rene Rivera wrote: [2003-01-17] Toon Knapen wrote: On Friday 17 January 2003 12:32, John Maddock wrote: So only the gcc tests will be run, I assume that you have some detritus in bin directory from previous HP aCC runs, which is why you are seeing some results listed. Add the necessary toolset(s) to test_tools. Thanks John. Had some other minor trouble but finally it worked. What are the minor troubles? Are they with the run_test.sh script? Are they with the BJam build.sh script? Something else? Basically anything we should point out to people and/or try and fix? I've been struggling a bit with it so next time I'll update the status I'll start from scratch and make sure to notify all involved of the changes I had to make to make it work. Last time there were many minor issues and I lost track of them. Thanks for offering your help. toon ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Policy-based smart pointers revisisted(was: Re:Preliminarysubmission: command line config file library)
Edward Diener [EMAIL PROTECTED] writes: Maybe it should be refactored out into the MPL if it is generic enough to do so and then others can use it more easily in their own policy-like classes ? I really think that MPL is an inappropriate place for it. It would be very useful as a separate library, though. Boost.Python uses the technique for template parameters and for function arguments, so we'd want to support both. If it is not generic enough, maybe the technique can be documented somewhere. I know as a user of policy-like classes the biggest difficulty is having to choose the correct optional parameters when one wants to change any one of them from the default. If your technique can get around this limitation while providing multiple policies, I would love to read about how it works so that if I ever design policy-based template classes I can use it also. It can, provided that you can write a predicate metafunction which distinguishes each type (policy) you're interested in. When two of the optional arguments can have identical interfaces and/or other detectable requirements, my technique breaks down. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time binary constants
Gennaro Prota [EMAIL PROTECTED] writes:
On Sun, 19 Jan 2003 09:42:51 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
For another thing, it would be a compile-error if the
expression *can* be implicitly converted to the destination type,
which makes no sense to me.
Isn't this the intent?
I don't know what the intent is; you never explained that to me. What
this does is to static_cast only when it must be forced (often in the
unsafe direction); it was hard to see how that could be useful.
Maybe just as a way of stating and checking that you know what you're
doing?
Well, actually I did it just for the fun of it. The original thread
was about implicit_cast, not explicit, and I added some thoughts. In
any case the comment I've made here about the comma operator applies
to the implicit piece as well:
template typename T
char implicit_cast (typename identityT::type x) {
return x;
}
// incomplete return type now is here
template typename T
void implicit_cast (...);
#define IMPLICIT_CAST(dst_type, expr) \
( sizeof( implicit_castdst_type(expr) ) \
,\
static_castdst_type(expr) \
)
Why wouldn't you just write implicit_castdst_type(expr) in this
case? Are you trying to save copies?
(You might think I'm not interested in the comma operator issue. I
guess you'd be right. It would be good to do something about it, but
I don't feel strongly. If you do, you will have to champion it).
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line config file library)
David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Edward Diener [EMAIL PROTECTED] writes: Fredrik Blomqvist [EMAIL PROTECTED] wrote in message b0cvd7$4dv$[EMAIL PROTECTED]">news:b0cvd7$4dv$[EMAIL PROTECTED]... -snip- I thought the C++ template solution by Damian Conway was pretty neat, -snip- I thought so too at first, but at a closer look you can see that the code in practice only works for integers.. It solves the problem in the original thread, but shouldn't be mistaken for a generic solution. It seems as if it should work for any type with a copy constructor. Perhaps I missed something. Nonetheless I do favor a compiler change such as allowing the default keyword to be used instead as Mr. Terekhov suggested in that same thread. That would be much cleaner and should be easy for any compiler to handle. This is one case where I would like to see the language updated with such an easy, transparent solution to the problem. Of course if others don't see it as much of a problem, they wouldn't be in favor of the solution since it involves the dreaded C++ language change Oh, it's a problem alright, but I'm still not very convinced of that solution. The problem with interfaces that have lots of positional parameters is that you forget what the different positions mean. To solve that problem, you need either named parameters or a position-independent interface. Since the C++ language already has embraced positional parameters as its normal means of passing information to functions, classes, or templates, it is a little disingenuous to complain about them. Every function call is essentially a matter of knowing what the different positions mean. Since we are stuck with this metaphor, so to speak, we can at least make the best of it in regard to default parameters with a simple solution. I wouldn't mind the idea of named parameters so much other than the adjustment away from what every C++ programmer has previously become accustomed to using. I imagine the compilers would also get more complicated as another area for dealing with C++ identifiers would have to be dealt with. Simply adding default in order to invoke the default value for a particular position is so much easier. My point is: since we already deal with positions in nearly everything, why not add default as has been suggested. If the language evolves to named parameters or some other means of a position-independent interface for passing normal parameters, we can consider these other ideas for passing default values. Keeping the metaphor consistent ( KTMC as opposed to KISS g ) seems to me to be the best idea for now. That's not to say that you or others shouldn't invent better means, if you think it worthwhile, given what the language currently offers. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] intel-linux-tools.jam
Toon Knapen [EMAIL PROTECTED] writes: On Friday 17 January 2003 11:07, David Abrahams wrote: It's not just about circular dependencies. If library A depends on library B, when you link them into an executable there's no guarantee that they'll appear in the right order. OK but I never had any trouble with it so far (although NEEDLIBS is only used once in my linkline to prevent people from creating circular dependencies) It's fine if you're willing to tolerate things occasionally not working in your project in order to prevent some misuse. Boost.Build has different design goals, so we have to use the more-reliable approach. Don't say I didn't warn you... ;-). -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_STATIC_CONSTANT and VC++ enums
On Sat, 18 Jan 2003 19:34:44 +0100, Gennaro Prota
[EMAIL PROTECTED] wrote:
On Sat, 18 Jan 2003 13:06:06 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
Right. But does it print anything in this case?
if (e1 0)
std::cout whoops\n;
Then I'd be worried.
Then you are worried ;-)
Of course the same thing holds for
if (boost::integer_traitsunsigned int::const_max 0) {
std::cout whoops\n;
}
This means that I can leave the code as is and add a note to the
documentation that mentions the problem?
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression tests for aCC are up
At 11:05 AM 1/17/2003, David Abrahams wrote: Toon Knapen [EMAIL PROTECTED] writes: On Friday 17 January 2003 12:32, John Maddock wrote: So only the gcc tests will be run, I assume that you have some detritus in bin directory from previous HP aCC runs, which is why you are seeing some results listed. Add the necessary toolset(s) to test_tools. Thanks John. Had some other minor trouble but finally it worked. I moved http://boost.sourceforge.net/regression-logs/index.html so it would be easier to browse all the logs. I hope nobody minds. Sounds like a good idea, but I don't see it there. Did it go astray? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line config file library)
From: Edward Diener [EMAIL PROTECTED] David Abrahams [EMAIL PROTECTED] wrote in message Oh, it's a problem alright, but I'm still not very convinced of that solution. The problem with interfaces that have lots of positional parameters is that you forget what the different positions mean. To solve that problem, you need either named parameters or a position-independent interface. Since the C++ language already has embraced positional parameters as its normal means of passing information to functions, classes, or templates, it is a little disingenuous to complain about them. Every function call is essentially a matter of knowing what the different positions mean. Since we are stuck with this metaphor, so to speak, we can at least make the best of it in regard to default parameters with a simple solution. This issue is also discussed in DE. When you have ordinary function calls, you also have the names/values used in the call, to help you understand the meaning of the parameters. Consider: Window w=make_window(Title,0,0,100,100,some_flags); with defaults anywhere in the parameter list, you could get: Window w=make_window(,123); It may be non-trivial to figure out what the number corresponds to, unless you remember what the preceding parameters are, or look them up. This was a concern mentioned in DE, and also what Dave says here. If you instead used (named parameters): make_window(flags_is(123)), or use detection by type, as Dave described, it could be easier to see what is going on. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line config file library)
Edward Diener [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote... Edward Diener [EMAIL PROTECTED] writes: Nonetheless I do favor a compiler change such as allowing the default keyword to be used instead as Mr. Terekhov suggested in that same thread. That would be much cleaner and should be easy for any compiler to handle. This is one case where I would like to see the language updated with such an easy, transparent solution to the problem. Of course if others don't see it as much of a problem, they wouldn't be in favor of the solution since it involves the dreaded C++ language change Oh, it's a problem alright, but I'm still not very convinced of that solution. The problem with interfaces that have lots of positional parameters is that you forget what the different positions mean. To solve that problem, you need either named parameters or a position-independent interface. Since the C++ language already has embraced positional parameters as its normal means of passing information to functions, classes, or templates, it is a little disingenuous to complain about them. Do you know the meaning of disingenuous? Did you really mean to accuse me of intellectual dishonesty? Every function call is essentially a matter of knowing what the different positions mean. Since we are stuck with this metaphor, so to speak, we can at least make the best of it in regard to default parameters with a simple solution. I think you're way off base. To begin with, I'm not complaining about positional parameters; I'm saying that they don't work well when there are many. Secondly, we're not neccessarily stuck with this metaphor. Once the possibility of making language extensions arises, we have lots of freedom to choose different approaches. I wouldn't mind the idea of named parameters so much other than the adjustment away from what every C++ programmer has previously become accustomed to using. I imagine the compilers would also get more complicated as another area for dealing with C++ identifiers would have to be dealt with. Simply adding default in order to invoke the default value for a particular position is so much easier. My point is: since we already deal with positions in nearly everything, why not add default as has been suggested. If the language evolves to named parameters or some other means of a position-independent interface for passing normal parameters, we can consider these other ideas for passing default values. Keeping the metaphor consistent ( KTMC as opposed to KISS g ) seems to me to be the best idea for now. That's not to say that you or others shouldn't invent better means, if you think it worthwhile, given what the language currently offers. It doesn't matter what the best idea for now is, unless you take a *very* long view of now, and in that case there's plenty of time to design a better approach. The next standard won't come out for a few years at least, and then we'll be stuck with that for another 10 years or so. It's hard enough to add any core language change that I don't want to invest time in something which solves only half the problem. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time binary constants
From: Gennaro Prota [EMAIL PROTECTED]
On Sat, 18 Jan 2003 20:16:36 -0700, Greg Colvin
[EMAIL PROTECTED] wrote:
At a meeting years ago I proposed to make string literals more
useful as constant expressions, but we decided against that.
As I recall part of the problem is that linkers are free to map
the same literal string to different addresses in different
compilation units.
I'm not sure what you are referring to by using string-literals as
constant expressions. If you are alluding to making the array
referred to by a string-literal usable as a template argument, like in
template const char c[]
struct X {};
X hello x;
then I'd like to make a comment. Currently C++ doesn't allow this.
Briefly, the problem is that a string-literal (which is not an object
per se, but an expression which *refers* to an object implicitly
created by the compiler) refers to an unnamed object and such an
object is not usable as a template argument. However it would be
perfectly possible to give it a compiler-generated name. Now, as you
say, it's not specified whether array objects corresponding to
identical string literals are collapsed together or not and thus you
don't know whether e.g. x and y below have the same type or not
X hello x; // (*)
X hello y;
You could avoid this problem by encoding the text string in the value used
to represent the string literal. That would ensure that all template
instantiations, using the same string literal, regardless of translation
unit, have the same type. However, you would still have the issue, as Greg
says, here, that the literals could have different addresses in different
TUs, so that if you took their address, you'd get different values, despite
being the same literal.
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time binary constants
As interesting as this may be, the discussion of string literals as template parameters is off-topic for this group. Please either connect this discussion back to library design or take it elsewhere. Thanks, Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Policy-based smart pointers revisisted(was:Re:Preliminarysubmission: command line config file library)
Terje Slettebø [EMAIL PROTECTED] wrote in message 092001c2bfeb$e91ee110$cb6c6f50@pc">news:092001c2bfeb$e91ee110$cb6c6f50@pc... This issue is also discussed in DE. When you have ordinary function calls, you also have the names/values used in the call, to help you understand the meaning of the parameters. Consider: Window w=make_window(Title,0,0,100,100,some_flags); with defaults anywhere in the parameter list, you could get: Window w=make_window(,123); It may be non-trivial to figure out what the number corresponds to, unless you remember what the preceding parameters are, or look them up. One thing I like less about DE is that it discusses some problem, a couple of possible solutions to it, and why they are not recommendable. It does not, however, discuss the obvious alternative solutions that avoid the mentioned drawbacks. For example, in this case DE does not go the normal path of discussing how the solutions: Window w=make_window(?,?,?,?,?,123); or: Window w=make_window(default,default,default,default,default,123); would work. Andrei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time binary constants
At 12:11 PM 1/19/2003, David Abrahams wrote: As interesting as this may be, the discussion of string literals as template parameters is off-topic for this group. Please either connect this discussion back to library design or take it elsewhere. Agreed. An interesting question is how to design around the existing language to get the effect of having string literals. Such attempts are often a good way to tell whether and how the language might need to be extended. Of the top of my head, how about a static table of strings, and a parallel enumeration of indexes into the table, so that the indexes are integral constants suitable for use as template parameters. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] A question about static_log2
Can someone who was subscribed when the Integer library was approved
explain me what were the reasons to choose the current implementation
of static_log2 against e.g.
template unsigned long n
struct log2 {
BOOST_STATIC_CONSTANT(unsigned long,
value = 1 + (log2n/2::value));
};
template
struct log21 {
BOOST_STATIC_CONSTANT(unsigned long, value = 0);
};
?
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
On Sun, 19 Jan 2003 12:29:25 -0700, Greg Colvin [EMAIL PROTECTED] wrote: At 12:11 PM 1/19/2003, David Abrahams wrote: As interesting as this may be, the discussion of string literals as template parameters is off-topic for this group. Please either connect this discussion back to library design or take it elsewhere. Agreed. An interesting question is how to design around the existing language to get the effect of having string literals. Such attempts are often a good way to tell whether and how the language might need to be extended. I agree too that the discussion is off-topic, of course. The reason why I often seize the opportunity to point out language limitations here is that many boosters are committee members too, and if limitations are recognized to be important for *real code*, then it is more likely that someone may bring up the issue in the committee itself. In particular, I'm under the impression that static processing of string-literals is an important area of meta-programming, for now ignored. If we had it I guess we would have already discovered important applications (just like it has happened with templates themselves, for which usages have been discovered far beyond the intent of their inventor(s)) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
On Sun, 19 Jan 2003 12:59:16 -0500, David Abrahams [EMAIL PROTECTED] wrote: Why wouldn't you just write implicit_castdst_type(expr) in this case? Are you trying to save copies? It seems that you are deep in other thoughts today ;-) You know the reason why I don't use implicit_castdst_type(expr). (You might think I'm not interested in the comma operator issue. I guess you'd be right. It would be good to do something about it, but I don't feel strongly. If you do, you will have to champion it). Yeah :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [build/test] Testing different configurations, misc questions
I have been upgrading the Jamfiles for the date_time library have a couple questions: 1) I have a need to build tests with different compile options. For example consider the following example where the tests are the same, but the compile options are different. test-suite date_time_gregorian : [ run gregorian/testdate.cpp lib../build/boost_date_time : : : defineDATE_TIME_INLINE ] ; test-suite date_time_gregrian_no_inline : [ run gregorian/testdate.cpp lib../build/boost_date_time ] ; Is there some way to do this? 2) I notice that some Jamfile.v2 files showing up. When is this going live, and is there something library authors need to do to keep these up to date? 3) Is there a way to get verbose output when the test is run? I realize the data is output into a file, but when I am testing changes I like to run the whole test suite output into a single file which I can grep and scan quickly. Thanks, Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [build/test] Testing different configurations, miscquestions
Jeff Garland [EMAIL PROTECTED] writes: I have been upgrading the Jamfiles for the date_time library have a couple questions: 1) I have a need to build tests with different compile options. For example consider the following example where the tests are the same, but the compile options are different. test-suite date_time_gregorian : [ run gregorian/testdate.cpp lib../build/boost_date_time : : : defineDATE_TIME_INLINE ] ; test-suite date_time_gregrian_no_inline : [ run gregorian/testdate.cpp lib../build/boost_date_time ] ; Is there some way to do this? Yeah, just use different names for the two tests. The signature of the run rule is: run ( sources + : args * : input-files * : requirements * : name ? : default-build * ) 2) I notice that some Jamfile.v2 files showing up. When is this going live, When we get the system finished. You can already use it with GCC on Windows and Linux (and, I think Kylix). and is there something library authors need to do to keep these up to date? No, the Boost.Build maintainers are doing that for now. 3) Is there a way to get verbose output when the test is run? I realize the data is output into a file, but when I am testing changes I like to run the whole test suite output into a single file which I can grep and scan quickly. Add --verbose-test to the bjam command-line. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time binary constants
Gennaro Prota [EMAIL PROTECTED] writes: On Sun, 19 Jan 2003 12:59:16 -0500, David Abrahams [EMAIL PROTECTED] wrote: Why wouldn't you just write implicit_castdst_type(expr) in this case? Are you trying to save copies? It seems that you are deep in other thoughts today ;-) You know the reason why I don't use implicit_castdst_type(expr). If I knew I wouldn't have asked. If you've posted about it before, you should know that I don't read every post. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission:command line config file library)
David B. Held on Sat, 18 Jan 2003 05:07:00 -0600 wrote: Edward Diener [EMAIL PROTECTED] wrote in message b0aro4$5gq$[EMAIL PROTECTED]">news:b0aro4$5gq$[EMAIL PROTECTED]... [...] Actually, the policy_ptr code in the sandbox features a policy adaptor that automagically detects specified policies, and fills in defaults, in any order. However, it requires that the user specify policies using MPL Lambda syntax. And that still doesn't avoid the fact that non-default configurations may require specifying several policies. Finally, the policy_ptr code has gotten too big for its own good, and has too many templated c'tors that interfere with each other. Frankly, I don't understand all the issues with it any more. I will probably try to write tests for some more policy combinations, and then solicit help to figure out how to make the conversion c'tors work. They seem to be the last and biggest hurdle. I volunteer. [...] Dave I looked at the documentation in the sandbox: .../libs/policy_ptr/doc/header.html#class-smart_ptr and I'd like to emulate it. Would tell me what tools helped you do this? I noted that on the acknowledgments.html page you have a link with William Kempf 's name; however, when I followed it, I got: .../boost-sandbox/boost-sandbox/people/william_kempf.htm: unknown location Is there's some other url documenting William's method? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
On Sun, 19 Jan 2003 15:48:00 -0500, David Abrahams [EMAIL PROTECTED] wrote: If I knew I wouldn't have asked. If you've posted about it before, you should know that I don't read every post. I thought this was clear and that you were abstracted when asking it now. The reason is just that implicit_castdst_type(expr) is not a constant expression. Nothing more. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [build/test] Testing different configurations, miscquestions
Is there some way to do this? Yeah, just use different names for the two tests. The signature of the run rule is: run ( sources + : args * : input-files * : requirements * : name ? : default-build * ) Ok here is a snippet of my actual Jamfile. For some reason only the first of these gets built and run. Any ideas? test-suite date_time_posixtime : [ run posix_time/testc_local_adjustor.cpp lib../build/boost_date_time : : : defineDATE_TIME_INLINE defineBOOST_DATE_TIME_POSIX_TIME_STD_CONFIG ] # bunch of other tests ; #test the 64bit configuration test-suite date_time_posixtime_64bit : [ run posix_time/testc_local_adjustor.cpp lib../build/boost_date_time : : 64b_local_adjustor : defineDATE_TIME_INLINE ] ; 2) I notice that some Jamfile.v2 files showing up. When is this going live, When we get the system finished. You can already use it with GCC on Windows and Linux (and, I think Kylix). and is there something library authors need to do to keep these up to date? No, the Boost.Build maintainers are doing that for now. 3) Is there a way to get verbose output when the test is run? I realize the data is output into a file, but when I am testing changes I like to run the whole test suite output into a single file which I can grep and scan quickly. Add --verbose-test to the bjam command-line. Nice, thanks! Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost as charity-ware
On Sun, 19 Jan 2003 15:19:15 -0600, Rene Rivera [EMAIL PROTECTED] wrote: [2003-01-19] Gennaro Prota wrote: I would *love* to see boost becoming a charity-ware collection of libraries. Why? What a question! Because that would mean making good deeds. The idea is that we choose a list of associations and bodies, and set up a mechanism, through the boost site or another site, where download is possible only by making a donation to one of the associations. That would be the only condition and the software would be of course free to use, copy and modify. If it's free to use, copy and modify isn't requiring payment contradictory? Shrug. Ok, maybe I should be contented with just encouraging a donation :-/ Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost as charity-ware
Gennaro Prota [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... I would *love* to see boost becoming a charity-ware collection of libraries. The idea is that we choose a list of associations and bodies, and set up a mechanism, through the boost site or another site, where download is possible only by making a donation to one of the associations. That would be the only condition and the software would be of course free to use, copy and modify. Any interest? Yes. How do I apply to be a charity under this program? ; Dave ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost as charity-ware
[2003-01-19] Gennaro Prota wrote: On Sun, 19 Jan 2003 15:19:15 -0600, Rene Rivera [EMAIL PROTECTED] wrote: [2003-01-19] Gennaro Prota wrote: I would *love* to see boost becoming a charity-ware collection of libraries. Why? What a question! Because that would mean making good deeds. You shouldn't need Boost to do good deeds ;-) The idea is that we choose a list of associations and bodies, and set up a mechanism, through the boost site or another site, where download is possible only by making a donation to one of the associations. That would be the only condition and the software would be of course free to use, copy and modify. If it's free to use, copy and modify isn't requiring payment contradictory? Shrug. Ok, maybe I should be contented with just encouraging a donation :-/ The best donation, would be that of time and effort towards Boost itself. For that matter hire Dave, his sig... -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution That should help Boost out tremendously ;-) -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] A question about static_log2
Gennaro Prota:
Can someone who was subscribed when the Integer library was approved
explain me what were the reasons to choose the current implementation
of static_log2 against e.g.
I can't help in that, but
template unsigned long n
struct log2 {
BOOST_STATIC_CONSTANT(unsigned long,
value = 1 + (log2n/2::value));
};
template
struct log21 {
BOOST_STATIC_CONSTANT(unsigned long, value = 0);
};
the above algorithm is inefficient and should not be used. Consider the
following algorithm instead:
#include iostream
#include climits
templateunsigned long x,
int n = sizeof(unsigned long) * CHAR_BIT / 2
struct log2 {
private:
enum {c = (1 n) = x};
public:
enum {value = c*n + log2(x(c*n)),(n/2)::value};
};
template
struct log21,0 {enum {value = 0};};
int main() {
std::cerr log21::value '\n';
std::cerr log22::value '\n';
std::cerr log23::value '\n';
std::cerr log25::value '\n';
std::cerr log26::value '\n';
std::cerr log27::value '\n';
std::cerr log28::value '\n';
std::cerr log2(120)::value '\n';
return 0;
}
Regards,
Vesa Karvonen
_
The new MSN 8 is here: Try it free* for 2 months
http://join.msn.com/?page=dept/dialup
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] running regression tests
At 12:31 PM 1/17/2003, Ronald Garcia wrote: When I run ./process_jam_log bin\bjam.log I get the error: Usage: bjam [bjam-args] | process_jam_log [locate-root] locate-root is the same as the bjam ALL_LOCATE_TARGET parameter, if any. Default is boost-root. no errors detected So instead I ran: ./process_jam_log $BOOST_ROOT bin/bjam.log no errors detected This just might be a nit with the docs (needing to explicitly supply BOOST_ROOT on the command line)? You only need to explicitly specify BOOST_ROOT if you are in a directory different from boost-root/status. I will do some more work on the docs, however. They need to be updated to show how to use the tests with ALL_LOCATE_TARGET, which is a cleaner way to run them. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line config file library)
David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Edward Diener [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote... Edward Diener [EMAIL PROTECTED] writes: Nonetheless I do favor a compiler change such as allowing the default keyword to be used instead as Mr. Terekhov suggested in that same thread. That would be much cleaner and should be easy for any compiler to handle. This is one case where I would like to see the language updated with such an easy, transparent solution to the problem. Of course if others don't see it as much of a problem, they wouldn't be in favor of the solution since it involves the dreaded C++ language change Oh, it's a problem alright, but I'm still not very convinced of that solution. The problem with interfaces that have lots of positional parameters is that you forget what the different positions mean. To solve that problem, you need either named parameters or a position-independent interface. Since the C++ language already has embraced positional parameters as its normal means of passing information to functions, classes, or templates, it is a little disingenuous to complain about them. Do you know the meaning of disingenuous? Did you really mean to accuse me of intellectual dishonesty? Not at all. My dictionary doesn't define disingenuous as intellectual dishonesty but even by its definition it was a very poor choice in the expression above and I shouldn't have used it along with the complain rhetoric. Just got carried away. What I meant to say was that arguing against positional default parameters goes against the grain of the language IMHO. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Policy-based smart pointers revisisted
Terje Slettebø [EMAIL PROTECTED] wrote in message 038e01c2bf0e$cc8f35a0$cb6c6f50@pc">news:038e01c2bf0e$cc8f35a0$cb6c6f50@pc... I'm also all for simplicity, cohesion, decoupling, do the simplest thing that could possibly work (XP/pragmatic programmers), etc., and I'm sure Andrei is, as well. After all, when Loki's typelists have been discussed, he's stated that they are heavily KISSed. Others have argued that the flexibility of MPL makes it worth it. So it's a little ironic situation. :) I did a good job (until now) abstaining myself from doing the **exact** same remark... I'm not sure how an argument and its exact opposite could lead to a congruent viewpoint. Back to pbd smart pointers, looks like nobody needs policy-based smart pointers coz they're so complex and shared_ptr just works for everybody, yet new xyz_ptr classes designed from scratch seem to appear around here quite often :o\. I just can't stop remarking how easy they can all be implemented as policies of Loki::SmartPtr. Andrei the lurker ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Policy-based smart pointers revisisted
Andrei Alexandrescu wrote: Back to pbd smart pointers, looks like nobody needs policy-based smart pointers coz they're so complex and shared_ptr just works for everybody, yet new xyz_ptr classes designed from scratch seem to appear around here quite often :o\. I just can't stop remarking how easy they can all be implemented as policies of Loki::SmartPtr. Coming from the standpoint of someone who uses this stuff rather than writes it g I love Loki, it has some really neat solutions to some very practical problems. It is at the heart of some of our more important frameworks here g Modern C++ design is a cracking book, and the chapter on smart pointers really shows off the potential of policy based design. The loki pointer looks fantastic. Yet I always find myself turning to either scoped_ptr (practically essential with the borland VCL), std::auto_ptr (for returning from factory-type functions) or shared_ptr (for just about everything else) The simplicity is simply too big a lure. Although we could tune and focus our pointers more effectively using policies and Loki, we then have the complexity of many pointer types running through our code, and having to remember the nuances of how each one was defined. Using the basic 3 mentioned above simply cuts out the clutter. We don't even use the full flexibility in shared_ptr, with deleter functions, weak_ptr and the like. Maybe our needs are just that bit simpler than everyone else? As pointer out previously, named template parameters and template typedefs would both make a big difference, but I think the Loki pointer is better today as a driving example of why we need these features than as something I can use in its own right. It is clearly a fantastic beast, which is why it makes such a good motivating example g If I can see the utility and still draw back from its use, we (or rather 'the committee') need to find some way of driving down those barriers. Andrei the lurker Nice to know your still around g -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] date_time oversight?
... details omitted... This function purports to be valid for any charT. However, because greg_base_facet is a typedef for date_names_put with a default of char, it looks to me it wouldn't work for other char types such as wchar_t. Yes, this is, or rather was a bug. Fix checked into CVS. Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time binary constants
At 07:00 AM 1/19/2003, Gennaro Prota wrote: Yes, I would be glad to write a formal proposal. But, as it has been repeatedly pointed out on comp.std.c++, this is not enough if you are not in the committee and that, de facto, there are very little chances for the proposal to be approved if you are not present to defend it and respond to questions and, above all, objections. That isn't entirely correct. It true that it is awfully hard to get a proposal through unless there are people present who understand the proposal in serious detail, but they don't have to be the proposal's authors. For example, John Maddock has made a number of proposals, and all seem likely to be accepted. John could well end up with more accepted proposals for the TR than anyone else, and he is also a co-author of a static assert proposal likely to become part of the core language. Yet John has never attended a meeting AFAIK. (I hope we can convince him to come to the Oxford meeting!) John's proposals meet real needs, are clearly worded, and are carefully researched. He makes sure there are others on the committee who understand the proposals, and can present them to the rest of the committee. He participates in the committee's email reflectors, answering questions as they come up. If you have a reasonable, useful, proposal then don't worry about getting it presented to the committee. Sure, it helps to be there in person, but there are plenty of existence proof's that attendance isn't a requirement. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Live summary of regression tests.
In order to make regression test browsing more pleasant for all of us. I decided to work up a little script to gather up all the test results that get posted to the boost.sourceforge.net site. So browse on over to: http://boost.sourceforge.net/regression-logs ..and take a look. And for those doing regression testing, this a zero maintenance page. Just put up the cs-PLATFORM*.html files in there and they'll automatically show :-) Enjoy. -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Policy-based smart pointers revisisted
At 05:24 PM 1/19/2003, Andrei Alexandrescu wrote: Terje Slettebø [EMAIL PROTECTED] wrote in message 038e01c2bf0e$cc8f35a0$cb6c6f50@pc">news:038e01c2bf0e$cc8f35a0$cb6c6f50@pc... I'm also all for simplicity, cohesion, decoupling, do the simplest thing that could possibly work (XP/pragmatic programmers), etc., and I'm sure Andrei is, as well. After all, when Loki's typelists have been discussed, he's stated that they are heavily KISSed. Others have argued that the flexibility of MPL makes it worth it. So it's a little ironic situation. :) I did a good job (until now) abstaining myself from doing the **exact** same remark... I'm not sure how an argument and its exact opposite could lead to a congruent viewpoint. Back to pbd smart pointers, looks like nobody needs policy-based smart pointers coz they're so complex and shared_ptr just works for everybody, yet new xyz_ptr classes designed from scratch seem to appear around here quite often :o\. I just can't stop remarking how easy they can all be implemented as policies of Loki::SmartPtr. In my opinion, all that stands in the way of boost::smart_ptr is the effort of submitting a proposal and seeing it through review. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Policy-based smart pointers revisisted
Alisdair Meredith [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Yet I always find myself turning to either scoped_ptr (practically essential with the borland VCL), std::auto_ptr (for returning from factory-type functions) or shared_ptr (for just about everything else) The simplicity is simply too big a lure. Although we could tune and focus our pointers more effectively using policies and Loki, we then have the complexity of many pointer types running through our code, and having to remember the nuances of how each one was defined. Using the basic 3 mentioned above simply cuts out the clutter. I agree with you that simplicity is great. In wake of your down-to-earth arguments, I think maybe it would be better to cease thinking that policy-based smart pointers are an appealing solution. Many designs I myself have seen here and there are a turnoff because they fail to draw the proverbial line in the sand and find that nice elegant balance between simplicity and completeness. Andrei ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Live summary of regression tests.
In order to make regression test browsing more pleasant for all of us. I decided to work up a little script to gather up all the test results that get posted to the boost.sourceforge.net site. So browse on over to: http://boost.sourceforge.net/regression-logs ..and take a look. And for those doing regression testing, this a zero maintenance page. Just put up the cs-PLATFORM*.html files in there and they'll automatically show :-) Nice! Any explanation why so many more tests on Win32 and BSD (300+) than on say Linux (~200)? Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Live summary of regression tests.
On Sunday 19 January 2003 09:14 pm, Rene Rivera wrote: In order to make regression test browsing more pleasant for all of us. I decided to work up a little script to gather up all the test results that get posted to the boost.sourceforge.net site. So browse on over to: http://boost.sourceforge.net/regression-logs ..and take a look. Very nice! Do we get dancing monkey graphics if we hit 100% pass? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Live summary of regression tests.
[2003-01-19] Jeff Garland wrote: In order to make regression test browsing more pleasant for all of us. I decided to work up a little script to gather up all the test results that get posted to the boost.sourceforge.net site. So browse on over to: http://boost.sourceforge.net/regression-logs ..and take a look. And for those doing regression testing, this a zero maintenance page. Just put up the cs-PLATFORM*.html files in there and they'll automatically show :-) Nice! Any explanation why so many more tests on Win32 and BSD (300+) than on say Linux (~200)? The Linux tests don't use the new regression programs? -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- 102708583@icq ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-docs] Integrating BoostBook documentation withHTMLdocumentation
At 02:30 PM 1/19/2003, Douglas Gregor wrote: The alphabetized/categorized list of libraries generated from the BoostBook documentation now includes all libraries that have (only) HTML documentation, so it is now possible to replace boost/libs/libraries.htm with the generated doc/html/libraries.html. Here is the HTML: http://www.cs.rpi.edu/~gregod/boost/doc/html/libraries.html I have a script that regenerates the all of the current documentation formats (HTML, PDF, man pages, XSL formatting objects, and DocBook---see the link above) that will be run nightly following updates of the Boost and Boost Sandbox CVS repositories, so the current CVS documentation will be available from the above URL. I'd like to make a CVS link to this URL under the Documentation header on the Boost main page. Objections? I'd like to see a bit more refinement first, and understand how the maintenance works. Let's take the last first. What does a developer do to add a new library? As far as refinement goes: * Why the bloat of breaking libraries.html up into multiple files? For me, at least, this reduces the quality of the browsing experience. * If for some reason it is really desirable to split the one file into two, the second one should have a meaningful name. ch01s02.html gives you no clue as to what next is linking too. * The navigation header and footer need more work, IMO: -- Some color and general site navigation help. If you don't like the usual Boost intermediate level page header (see the current libraries.htm), design another one. But the page needs something to give it a bit of life, identification with Boost, navigation back to home, etc. -- Footer should have a revised date. I like the horizon rule, too. -- Personally, I dislike prev and next links in general, and particularly those that give no indication of what they are linking to. Hovering the cursor to see the link URL helps a bit, but only a little. * Have you tried single spacing the alpha and by category lists? The old single spacing seems a tiny bit easier to scan, although that is obviously very subjective. * The formatting of the HTML isn't very human reader friendly. Would it be possible to do a bit of formatting? Have you check to verify there won't be any CVS churn once this becomes something that is checked into CVS? (Unless, of course, there is a real change on the page.) The content looks good, but I think a bit more work on the presentation is needed. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-docs] Integrating BoostBook documentation withHTMLdocumentation
On Sunday 19 January 2003 08:25 pm, Beman Dawes wrote: I'd like to see a bit more refinement first, and understand how the maintenance works. Let's take the last first. What does a developer do to add a new library? If the library documentation is in the BoostBook format, just make sure the Boost documentation includes the BoostBook source (e.g., by adding an appropriate xi:include element to boost.xml). If the library documentation is in HTML, the developer needs to add a library description to the file boost-sandbox/libs/documentation/examples/boost.xml. A library description looks like this: library name=Compressed Pair dirname=utility html-only=1 url=../../libs/utility/compressed_pair.htm libraryinfo author firstnameJohn/firstname surnameMaddock/surname /author author firstnameHoward/firstname surnameHinnant/surname /author librarypurposeEmpty member optimization/librarypurpose librarycategory name=category:data-structures/ librarycategory name=category:misc/ /libraryinfo /library I think the above is relatively self-explanatory. The library category names are in the same file (boost.xml), and are each defined like this: librarycategorydef name=category:string-text String and text processing /librarycategorydef As far as refinement goes: * Why the bloat of breaking libraries.html up into multiple files? For me, at least, this reduces the quality of the browsing experience. That's mostly an issue with the way I'm using DocBook. Will fix. * The navigation header and footer need more work, IMO: -- Some color and general site navigation help. If you don't like the usual Boost intermediate level page header (see the current libraries.htm), design another one. But the page needs something to give it a bit of life, identification with Boost, navigation back to home, etc. Will do. Sprucing up the headers has been on the task list for a while, but nobody has yet to take on the challenge :) -- Footer should have a revised date. I like the horizon rule, too. A generated date would be easy; a revised date isn't so easy, because it's not trivial to figure out when something used in the list changed. -- Personally, I dislike prev and next links in general, and particularly those that give no indication of what they are linking to. Hovering the cursor to see the link URL helps a bit, but only a little. The footer is much better than the header in this regard, because it actually gives names. * Have you tried single spacing the alpha and by category lists? The old single spacing seems a tiny bit easier to scan, although that is obviously very subjective. Done. I think it does look better. * The formatting of the HTML isn't very human reader friendly. Would it be possible to do a bit of formatting? I'm not sure. XSLT does have an indent property when transforming to another XML document, but AFAIK it's not considered safe to use when spacing is important. And spacing _is_ important, especially within the reference documentation. Have you check to verify there won't be any CVS churn once this becomes something that is checked into CVS? (Unless, of course, there is a real change on the page.) I'm not expecting this page to go into CVS, but to be autogenerated nightly along with the rest of the documentation. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
