[boost] Problems with boost on Cray C++ release 3.6
Dear Boosters,
All of our codes are now built on top of boost. Since we might use Cray
vector computers more in the future (finally they provides a
standard-conforming C++ standard library in release 3.6) we started
porting our codes to the Cray. I did not run the full test suite, but
just tried to compile my codes for now, which depend on some of the
Boost libraries. I encountered two problems that I want to discuss here:
1.) it seems that Cray C++ with the "-h conform" option, which enforces
strict standard conformance does not compile this code in
boost/filesystem/operations.hpp
class directory_iterator
: public boost::iterator< std::input_iterator_tag,
path, std::ptrdiff_t, const path *, const path & >
{
public:
reference operator*() const { return m_deref(); }
...
};
but complains that reference is not defined. My questions is whether
this is a bug in the Cray C++ compiler, or whether the above code (and
inheritance of the reference type from the base class) is actually not
standard conforming. Can the standard experts help me with that?
Anyways, this code can be made to compile by changing compiler options
to be less standard-conforming.
2.) The main problem, and one which breaks most boost libraries is that
there is no header, nor stdint.h. Neither is required by the
standard, so this is no bug on the Cray side. However, the boost
workaround in boost/cstdint.hpp also fails:
# if USHRT_MAX == 0x
typedef short int16_t;
...
# else
#error defaults not correct; you must hand modify boost/cstdint.hpp
# endif
because on the Cray vector systems a short is 32 bit, and there is no
intrinsic 16-bit integer type. What shall we do?
My suggestions is that we might need a BOOST_NO_INT16_T macro in
addition to the BOOST_NO_INT64_T macro we have now, and to just define
that macro in the code, instead of aborting with an error:
# if USHRT_MAX == 0x
typedef short int16_t;
...
# else
#define BOOST_NO_INT16_T
# endif
What do you think?
Best regards,
Matthias
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Policy-based smart pointers revisited
>From: "Edward Diener" <[EMAIL PROTECTED]> > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Terje Slettebø <[EMAIL PROTECTED]> writes: > > > However, I also understand the concern regarding understanding the > policies > > available, their responsibilities and interaction. Therefore, convenience > > templates like the above could make it easier to use them, while still > > allowing new convenience templates/template typedefs to be made, or new > > policy implementations added. > > > > Having such convenience templates is a bit like having a small > configuration > > DSL on top of the policy-based smart pointer, to use the terminology in > C&E. > > -Sure, and I expected we'd do that. Not to beat this horse to death, > -but I think even that doesn't insulate users from the parameters > -completely. They'll see it in the documentation, and wonder what's > -going on under the covers with all that complexity, and it will be a > -distraction. > > I don't think that is the distraction. I don't think it would be a problem as a distraction, either, any more than the fact that std::string is a typedef for std::basic_string, Allocator = allocator > prevents people from using std::string/std::wstring as they are, without knowing or caring about the extra default template parameters. Kevlin Henney has even suggested _not_ hiding the parameterisation with a typedef, and instead use a string template directly, such as string and string (for immutable strings, may be safely reference counted), or string, now that we are more used to templates. That specifies clearly the character type used, just like we specify the element type in the standard containers (http://www.cuj.com/experts/1905/henney.htm). As an aside, it might even be possible to extend the language, so that class template parameters may be deduced from an initialiser. In that case, std::string str="Test"; (or std::string<> str="Test";) might create a std::string (after implicit conversion from const char *), and std::string wstr=L"Test" might create a std::string. In other words, leaving the deduction to the compiler, as with function templates. If no initialiser is given, you have to specify the parameter explicitly (or it might default). Granted, std::basic_string may not be such a great example of PBD, as the "policies" are hardly changed. For example Matt Austern has pointed out that in order to do case-insensitive string comparison, it may be better to create a comparison functor, which may be passed to algorithms, rather than changing the character traits. And allocators... well, as Scott Meyers says it in "Effective STL", "Allocators are weird.", :) and the implementation would be free to ignore parts of them. > I wonder if there have been any murmurs in the C++ standard committee about > the system for setting default parameters somehow being changed to solve > this problem, so that a user can override a default without having to > override all preceding ones. I know I have heard suggestions about named > default parameters but that doesn't seem to solve the problem in my mind. > Something clearer and cleaner is needed but I don't know what it is. You may not need named parameters, as most of the time, "canned" versions might be fine. And if you'd like named parameters, you might use something like the named template parameters in the Sandbox. If you want something different from the defaults, you have to specify it, somehow. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line & config file library)
"Edward Diener" <[EMAIL PROTECTED]> wrote in message b0aro4$5gq$[EMAIL PROTECTED]">news:b0aro4$5gq$[EMAIL PROTECTED]... > [...] > I wonder if there have been any murmurs in the C++ standard > committee about the system for setting default parameters somehow > being changed to solve this problem, so that a user can override a > default without having to override all preceding ones. I know I have > heard suggestions about named default parameters but that doesn't > seem to solve the problem in my mind. Something clearer and cleaner > is needed but I don't know what it is. 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. As far as policy specification goes, perhaps a new idiom of building policies into a unit, and passing them as one parameter might address both the interface complexity issue and the default policy issue. I think it needs to be considered further. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line & config file library)
"David B. Held" <[EMAIL PROTECTED]> wrote in message b0bcbp$bd9$[EMAIL PROTECTED]">news:b0bcbp$bd9$[EMAIL PROTECTED]... > "Edward Diener" <[EMAIL PROTECTED]> wrote in message > b0aro4$5gq$[EMAIL PROTECTED]">news:b0aro4$5gq$[EMAIL PROTECTED]... > > [...] > > I wonder if there have been any murmurs in the C++ standard > > committee about the system for setting default parameters somehow > > being changed to solve this problem, so that a user can override a > > default without having to override all preceding ones. I know I have > > heard suggestions about named default parameters but that doesn't > > seem to solve the problem in my mind. Something clearer and cleaner > > is needed but I don't know what it is. > > As far as policy specification goes, perhaps a new idiom of building > policies into a unit, and passing them as one parameter might address > both the interface complexity issue and the default policy issue. I think > it needs to be considered further. Given the weakness in C++ handling of default parameters, passing policies as a single parameter where the user only need to specify the variation from the default that he wants would be the best practical solution. The main issue, of all policy-based template classes IMHO, is to make it as easy and transparent to use without the user having to know, or care, about policy variations which he may never want to change. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with boost on Cray C++ release 3.6
> 1.) it seems that Cray C++ with the "-h conform" option, which enforces
> strict standard conformance does not compile this code in
> boost/filesystem/operations.hpp
>
> class directory_iterator
>: public boost::iterator< std::input_iterator_tag,
>path, std::ptrdiff_t, const path *, const path & >
> {
> public:
>reference operator*() const { return m_deref(); }
> ...
>};
>
> but complains that reference is not defined. My questions is whether
> this is a bug in the Cray C++ compiler, or whether the above code (and
> inheritance of the reference type from the base class) is actually not
> standard conforming. Can the standard experts help me with that?
>
> Anyways, this code can be made to compile by changing compiler options
> to be less standard-conforming.
I think it is a bug: member lookup rules (10.2) requires that base classes
are searched as well as the current class (this is not quite true for
template classes, but the class is not a template in this case).
One workaround might be to add:
typedef boost::iterator< std::input_iterator_tag, path, std::ptrdiff_t,
const path *, const path & > base_type;
typedef base_type::reference reference;
>
> 2.) The main problem, and one which breaks most boost libraries is that
> there is no header, nor stdint.h. Neither is required by the
> standard, so this is no bug on the Cray side. However, the boost
> workaround in boost/cstdint.hpp also fails:
>
> # if USHRT_MAX == 0x
> typedef short int16_t;
> ...
> # else
> #error defaults not correct; you must hand modify boost/cstdint.hpp
> # endif
>
> because on the Cray vector systems a short is 32 bit, and there is no
> intrinsic 16-bit integer type. What shall we do?
>
> My suggestions is that we might need a BOOST_NO_INT16_T macro in
> addition to the BOOST_NO_INT64_T macro we have now, and to just define
> that macro in the code, instead of aborting with an error:
>
> # if USHRT_MAX == 0x
> typedef short int16_t;
> ...
> # else
> #define BOOST_NO_INT16_T
> # endif
>
> What do you think?
Probably we need to add a customised stdint.hpp for that compiler, or else
modify the checks to something like:
#ifdef __WHATEVER_CRAY_DEFINES__
typedef short int_least16_t;
typedef unsigned short uint_least16_t;
# elif USHRT_MAX == 0x
typedef short int16_t;
typedef short int_least16_t;
typedef short int_fast16_t;
typedef unsigned short uint16_t;
typedef unsigned short uint_least16_t;
typedef unsigned short uint_fast16_t;
# else
#error defaults not correct; you must hand modify boost/cstdint.hpp
# endif
If you can test and supply patches they would be much appreciated, come to
that, I don't suppose you would like to volunteer to regularly run the
regression tests on that platform would you (no problem if you can't
though)? Testing on Cray would be useful if only because the architecture
is so different from the usual 32-bit platforms we test on.
Thanks for the feedback,
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems with boost on Cray C++ release 3.6
On Saturday, January 18, 2003, at 12:55 PM, John Maddock wrote:
1.) it seems that Cray C++ with the "-h conform" option, which
enforces
strict standard conformance does not compile this code in
boost/filesystem/operations.hpp
class directory_iterator
: public boost::iterator< std::input_iterator_tag,
path, std::ptrdiff_t, const path *, const path & >
{
public:
reference operator*() const { return m_deref(); }
...
};
but complains that reference is not defined. My questions is whether
this is a bug in the Cray C++ compiler, or whether the above code (and
inheritance of the reference type from the base class) is actually not
standard conforming. Can the standard experts help me with that?
Anyways, this code can be made to compile by changing compiler options
to be less standard-conforming.
I think it is a bug: member lookup rules (10.2) requires that base
classes
are searched as well as the current class (this is not quite true for
template classes, but the class is not a template in this case).
Thanks for pointing out the appropriate section of the standard. I
agree with you will report it to Cray as a bug. The funny thing is that
the compiler complains only if I turn on the option "-h conform",
making it strictly standard-conforming.
One workaround might be to add:
typedef boost::iterator< std::input_iterator_tag, path, std::ptrdiff_t,
const path *, const path & > base_type;
typedef base_type::reference reference;
Yes, but shall we do that in all instances where this type of code is
found in boost? I think it is better for now to just use the right
combination of compiler options, to make the compiler swallow this. Of
course if a similar problem is found with other compilers, we can do it
this way.
2.) The main problem, and one which breaks most boost libraries is
that
there is no header, nor stdint.h. Neither is required by the
standard, so this is no bug on the Cray side. However, the boost
workaround in boost/cstdint.hpp also fails:
# if USHRT_MAX == 0x
typedef short int16_t;
...
# else
#error defaults not correct; you must hand modify
boost/cstdint.hpp
# endif
because on the Cray vector systems a short is 32 bit, and there is no
intrinsic 16-bit integer type. What shall we do?
Probably we need to add a customised stdint.hpp for that compiler, or
else
modify the checks to something like:
#ifdef __WHATEVER_CRAY_DEFINES__
typedef short int_least16_t;
typedef unsigned short uint_least16_t;
# elif USHRT_MAX == 0x
typedef short int16_t;
typedef short int_least16_t;
typedef short int_fast16_t;
typedef unsigned short uint16_t;
typedef unsigned short uint_least16_t;
typedef unsigned short uint_fast16_t;
# else
#error defaults not correct; you must hand modify boost/cstdint.hpp
# endif
I will try to implement this. Probably we cannot do it Cray-dependent
since Cray has too many systems (from Alpha-CPUs in the T3E to their
new X1 vector-CPUs). A better idea might be:
#ifdef USHRT_MAX == 0x
typedef short int_least16_t;
typedef unsigned short uint_least16_t;
# elif USHRT_MAX == 0x
typedef short int16_t;
typedef short int_least16_t;
typedef short int_fast16_t;
typedef unsigned short uint16_t;
typedef unsigned short uint_least16_t;
typedef unsigned short uint_fast16_t;
# else
#error defaults not correct; you must hand modify boost/cstdint.hpp
# endif
If you can test and supply patches they would be much appreciated,
I'll do that over the weekend and try to see if some parts of boost
will then compile
come to
that, I don't suppose you would like to volunteer to regularly run the
regression tests on that platform would you (no problem if you can't
though)? Testing on Cray would be useful if only because the
architecture
is so different from the usual 32-bit platforms we test on.
I'll try to do it at least once to see which parts of boost we can use,
and see how much CPU time this gobbles up. If it is not too much, I
will talk to our sysadmins if they would allow me to do it about once a
month. I don't think that testing more often would be possible, since
already compiling only the filesystem library takes about 15 minutes.
best regards,
Matthias
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Comments on date/time library
> Hmmm while I can see your point, I still think a default constructor should > be provided. And as I, along with all of the users in the messages you cited > seemed to have expected that default constructed dates would be set to > 'not_a_date_time', I'd suggest that this would be the most sensible default > value. I don't see any point in *not* providing a default value. Keeping the interface to a minimum, preventing accidental/surprising values, avoiding the controversy of discussing what an appropriate value for the default constructor is. Well, 2 out of 3 anyway :-) But seriously I'm willing to add it, but I don't think I've heard a compelling use case yet... Jeff ___ 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" <[EMAIL PROTECTED]> writes: > 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. > > As far as policy specification goes, perhaps a new idiom of building > policies into a unit, and passing them as one parameter might address > both the interface complexity issue and the default policy issue. I think > it needs to be considered further. I'm sure I've suggested this before, but I think it was ignored: In Boost.Python I'm using a system for interfaces such as this one where optional template parameters can be passed in any order. I'm using the properties of the type to detect their meaning. It works great. Using boost/mpl/has_xxx.hpp (and, for compilers which don't support it, is_base_and_derived) should be enough to build a nice policy-based 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] Re: Policy-based smart pointers revisisted (was: Re:Preliminarysubmission: command line & config file library)
"Edward Diener" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > > -Sure, and I expected we'd do that. Not to beat this horse to death, > -but I think even that doesn't insulate users from the parameters > -completely. They'll see it in the documentation, and wonder what's > -going on under the covers with all that complexity, and it will be a > -distraction. > > I don't think that is the distraction. Here I've been trying to warn against dismissing the effects of complexity, and there you go doing it! Oh, well. > The biggest problem with policy-based template classes is the same > as the problem with functions which have many default parameters: > it's difficult to set just one somewhere in the middle because one > must know the reasonable defaults for everything preceding it. Not neccessarily. See my other 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
[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]... > > In Boost.Python I'm using a system for interfaces such as this one > where optional template parameters can be passed in any order. I'm > using the properties of the type to detect their meaning. It works > great. Using boost/mpl/has_xxx.hpp (and, for compilers which don't > support it, is_base_and_derived) should be enough to build a nice > policy-based interface. Is the technique of allowing optional template parameters to be passed in any order a part of MPL ? I haven't looked at MPL at all since I didn't see it in Boost 1.29 but maybe it is there and I missed it. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Policy-based smart pointers revisisted
From: "Terje Slettebø" <[EMAIL PROTECTED]>
> >From: "David Abrahams" <[EMAIL PROTECTED]>
> >
> > Please don't take this to mean I'm against a
> > policy-based smart pointer; quite the opposite. I've
> > said all along it would be great to have one in boost.
> > I've even wished I had an appropriate occasionally.
Yep.
> > I just don't want to trivialize what I perceive to be
> > valid concerns, either. Understanding the costs of
> > complexity should be as important to the designer of
> > policy-based classes as to everyone else, if not more
> > so.
>
> I understand the concern. For one thing, we don't have template typedefs,
> yet, although me may get a similar effect (if not the same type) with
e.g.:
>
> template
> struct shared_ptr : smart_ptr {};
Not quite.
It is not simply declaration complexity that Dave's talking about - it can
be avoided by making smart_ptr be shared_ptr by using default
parameters. It is semantic complexity. shared_ptr is fairly deep by itself
(and getting the specification and the tests to a state that can be
considered adequate wasn't easy.)
If you make shared_ptr a point in smart_ptr<>'s design space, this
automatically means that smart_ptr is _at least as complex_ as shared_ptr to
teach, specify, test.
Whether smart_ptr should be made to encompass all of the shared_ptr's
functionality (verbatim) is another matter. A policy-based smart pointer has
different design goals, and it might be better to cover (an useful subset
of) the functionality of shared_ptr without copying its interface as is,
using the strengths of the medium, so to speak.
Now to return the suggestion above.
What are the primary strengths of a policy based smart pointer?
1. It allows users to create their own custom smart pointers.
2. It allows users to globally switch to another smart pointer type by
changing a typedef:
typedef counted_policy default_ownership;
// project uses smart_ptr throughout
3. It allows users to write generic functions that can take any smart
pointer.
(1) and (3) aren't affected by convenience wrappers, and (2) is made more
difficult if the shared_ptr<> pictured above is used in the project.
For completeness, there is also
4. Depending on the PBSP design, it might allow users to mix and match smart
pointers of different types.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Policy-based smart pointers revisited
From: "David Abrahams" <[EMAIL PROTECTED]> > > I think Peter also values the fact that boost::shared_ptr has few > dependencies on other boost code, a problem I don't see such an easy > way out of. That's definitely important since so much other Boost code depends on it. But let's assume for the sake of argument that this is not an issue. And let's assume that I need to implement the Boost smart pointers from scratch. I need to decide whether to use a policy-based smart pointer framework, or to resort to the old school low tech method. What should I decide, and what factors need to be considered? Should I go the framework way if it makes my task more difficult? And, considering that there is no policy-based smart pointer framework in Boost, should I design and implement one? Will this be a win in the long run? (*) Or perhaps I should take an existing framework, fill in the missing pieces, resolve any issues, and prepare a formal proposal? My answer has been, and still is, "no". It is a simple cost/benefit analysis, no ideology or psychology involved. -- (*) For me, not for the humanity in general. That's what pragmatic programming is about, solving the problem with the minimum amount of effort. ___ 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 in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> >> In Boost.Python I'm using a system for interfaces such as this one >> where optional template parameters can be passed in any order. I'm >> using the properties of the type to detect their meaning. It works >> great. Using boost/mpl/has_xxx.hpp (and, for compilers which don't >> support it, is_base_and_derived) should be enough to build a nice >> policy-based interface. > > Is the technique of allowing optional template parameters to be passed in > any order a part of MPL ? I haven't looked at MPL at all since I didn't see > it in Boost 1.29 but maybe it is there and I missed it. No; it's implemented in Boost.Python using MPL components, though. -- 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 Tue, 14 Jan 2003 17:11:39 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> writes:
>> As I think you all know, if you have something like
>>
>> enum e { e1 = 1u << 31 };
>>
>> then it simply "promotes" e1 to int instead of unsigned int. For
>> instance this
>>
>> enum e { e1 = 2147483648u };
>>
>> #include
>>
>> int main() {
>> std::cout << e1 << '\n';
>> }
>>
>> outputs -2147483648. Applied to my code, where I have e.g.
>
>Are you sure the promotion doesn't happen when e1 is passed to the
>streaming operator?
I'm afraid I don't understand your question. Maybe you are asking
whether the compiler is just favoring conversion over promotion? I
don't think so. I think the problem is that they just consider int as
the underlying type, always. The overall effect however is
more-or-less the same than if they always converted to int. As a
further example, this executes the if-branch:
if ( (e1 + 0) < 0)
std::cout << "Bad promotion...\n";
Thoughts?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Policy-based smart pointers revisisted (was: Re:Preliminarysubmission: command line & config file library)
Edward Diener wrote: [...] > the system for setting default parameters somehow being changed to solve > this problem, so that a user can override a default without having to > override all > default parameters but that doesn't seem to solve the problem in my mind. > Something clearer and cleaner is needed but I don't know what it is. You might want to take a look at this: http://groups.google.com/groups?threadm=199608081434.IAA07848%40ncar.ucar.EDU (Subject: comp.std.c++: Default arguments) The "bottom line" was: ...why not provide an additional meaning for the "default" keyword... Well, the question/problem/suggestion didn't raise much attention, however. regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Policy-based smart pointers revisisted
>From: "Peter Dimov" <[EMAIL PROTECTED]>
> From: "Terje Slettebø" <[EMAIL PROTECTED]>
> >
> > I understand the concern. For one thing, we don't have template
typedefs,
> > yet, although me may get a similar effect (if not the same type) with
> e.g.:
> >
> > template
> > struct shared_ptr : smart_ptr {};
>
> What are the primary strengths of a policy based smart pointer?
>
> 1. It allows users to create their own custom smart pointers.
> 2. It allows users to globally switch to another smart pointer type by
> changing a typedef:
> 3. It allows users to write generic functions that can take any smart
> pointer.
>
> (1) and (3) aren't affected by convenience wrappers, and (2) is made more
> difficult if the shared_ptr<> pictured above is used in the project.
I think there's also another concern, which may or may not apply here:
Avoiding code duplication. If it's possible to sensibly divide the aspects
of a smart pointer into policies, then instead of writing a new smart
pointer to deal with the change (e.g. from reference counted, to COM-type
reference counted), you just change that particular aspect or policy.
I understand your point about scope. If a component tries to be
all-encompassing, you might loose cohesion in the process. After all, you
could have a component, "Program", and various policies determining what the
program did. :) "Program" wouldn't likely be a very cohesive unit, though.
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 guess it comes down to which of a policy-based system, or a set of
independent smart pointers, as a total, has the best cost/benefit ratio. It
may also depend on how much variation is likely. This is a typical library
issue, anyway. I understand that the Boost smart pointers are quite
versatile, so they may cover much of the functionality needed, anyway.
> For completeness, there is also
>
> 4. Depending on the PBSP design, it might allow users to mix and match
smart
> pointers of different types.
One could also allow this with separate pointers, and as I understand,
that's already the case with the Boost ones (e.g. shared_ptr and weak_ptr
cooperating).
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] type traits question
Ronald Garcia wrote:
> Here's the version blurb:
>
> Edison Design Group C/C++ Front End, version 2.43.1 (Jan 16
> 2001 11:20:19)
> Copyright 1988-1999 Edison Design Group, Inc.
>
> KAI C++ 4.0d (KCC) -- Jan 16 2001 -- (C) Copyright 1994-2000 Kuck &
> Associates,
> Inc.
Thanks!
>
> AFAIK It supports partial template specialization.
> I don't even know the syntax for template template parameters :).
> If you give me an example of it, I can give it a try.
Actually the EDG version is enough - it doesn't.
>
> Let me know if there is any more information I can give you.
Could you test if the following compiles successfully with the latest CVS
sources?
#include "boost/mpl/aux_/has_xxx.hpp"
#include "boost/static_assert.hpp"
template< typename T >
struct remove_const
{
typedef T type;
struct rebind;
};
template< typename T >
struct remove_const::rebind
{
typedef T arg0;
};
BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(has_rebind, rebind, false)
typedef remove_const r;
BOOST_STATIC_ASSERT(has_rebind::value);
TIA,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
On Fri, 17 Jan 2003 08:24:13 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Aleksey and I were just discussing this one. As soon as he's done
>implementing the "for_" algorithm it could look like this:
>
>template // N must be an *octal* constant
>struct binary
>: for_ >, // "forward" state, condition, step
>plus >, _2> // "backward" step
> >
>{};
>
>Now binary<01101>::type::value = 13
Not that I think the application to "binary literals" is particularly
important, but an elegant implementation would be possible if string
literals and [] operator were allowed in constant expressions; this
way one could easily "extract" characters from a string literal and
use them as non-type template arguments of type char. Unfortunately
the committee seems on the road of prohibiting this and other similar
(and potentially more useful) uses of string literals in constant
expressions:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#366
BTW, I've already felt limited by the fact that I cannot use comma
operators in constant expressions, just imagine about this one... :-/
Genny.
___
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 in message > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> > >> In Boost.Python I'm using a system for interfaces such as this one > >> where optional template parameters can be passed in any order. I'm > >> using the properties of the type to detect their meaning. It works > >> great. Using boost/mpl/has_xxx.hpp (and, for compilers which don't > >> support it, is_base_and_derived) should be enough to build a nice > >> policy-based interface. > > > > Is the technique of allowing optional template parameters to be passed in > > any order a part of MPL ? I haven't looked at MPL at all since I didn't see > > it in Boost 1.29 but maybe it is there and I missed it. > > No; it's implemented in Boost.Python using MPL components, though. 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 ? 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. I am a big believer of 3rd party library ease of use while the inner code can be as complex as necessary, a technique which Boost libraries generally follow well. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Policy-based smart pointers revisisted
At 07:33 AM 1/18/2003, Peter Dimov wrote:
>From: "Terje Slettebø" <[EMAIL PROTECTED]>
>> >From: "David Abrahams" <[EMAIL PROTECTED]>
>> >
>> > Please don't take this to mean I'm against a
>> > policy-based smart pointer; quite the opposite. I've
>> > said all along it would be great to have one in boost.
>> > I've even wished I had an appropriate occasionally.
>
>Yep.
>
>> > I just don't want to trivialize what I perceive to be
>> > valid concerns, either. Understanding the costs of
>> > complexity should be as important to the designer of
>> > policy-based classes as to everyone else, if not more
>> > so.
>>
>> I understand the concern. For one thing, we don't have template typedefs,
>> yet, although me may get a similar effect (if not the same type) with
>e.g.:
>>
>> template
>> struct shared_ptr : smart_ptr {};
>
>Not quite.
>
>It is not simply declaration complexity that Dave's talking about - it can
>be avoided by making smart_ptr be shared_ptr by using default
>parameters. It is semantic complexity. shared_ptr is fairly deep by itself
>(and getting the specification and the tests to a state that can be
>considered adequate wasn't easy.)
One aspect of the semantic complexity that bothers me
is that the various flavors of smart pointer may not
be interchangeable. shared_ptr is partly parameterized
on implementation, but the interface and semantics
remain the same. For a policy-based smart pointer
to be usable I think you need a clear set of concepts
that clients can use as requirements, and a clear
delineation of which combinations of policies support
which concepts.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: BOOST_STATIC_CONSTANT and VC++ enums
Gennaro Prota <[EMAIL PROTECTED]> writes:
> On Tue, 14 Jan 2003 17:11:39 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
>>Gennaro Prota <[EMAIL PROTECTED]> writes:
>>> As I think you all know, if you have something like
>>>
>>> enum e { e1 = 1u << 31 };
>>>
>>> then it simply "promotes" e1 to int instead of unsigned int. For
>>> instance this
>>>
>>> enum e { e1 = 2147483648u };
>>>
>>> #include
>>>
>>> int main() {
>>> std::cout << e1 << '\n';
>>> }
>>>
>>> outputs -2147483648. Applied to my code, where I have e.g.
>>
>>Are you sure the promotion doesn't happen when e1 is passed to the
>>streaming operator?
>
> I'm afraid I don't understand your question. Maybe you are asking
> whether the compiler is just favoring conversion over promotion? I
> don't think so. I think the problem is that they just consider int as
> the underlying type, always. The overall effect however is
> more-or-less the same than if they always converted to int. As a
> further example, this executes the if-branch:
>
>if ( (e1 + 0) < 0)
>std::cout << "Bad promotion...\n";
Right. But does it print anything in this case?
if (e1 < 0)
std::cout << "whoops\n";
Then I'd be worried.
--
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] Policy-based smart pointers revisisted
Greg Colvin <[EMAIL PROTECTED]> writes: > One aspect of the semantic complexity that bothers me > is that the various flavors of smart pointer may not > be interchangeable. shared_ptr is partly parameterized > on implementation, but the interface and semantics > remain the same. For a policy-based smart pointer > to be usable I think you need a clear set of concepts > that clients can use as requirements, and a clear > delineation of which combinations of policies support > which concepts. That is definitely a requirement before I can buy into this "advantage" described in Peter's post: 2. It allows users to globally switch to another smart pointer type by changing a typedef: typedef counted_policy default_ownership; -- 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: > Not that I think the application to "binary literals" is particularly > important, but an elegant implementation would be possible if string > literals and [] operator were allowed in constant expressions; this > way one could easily "extract" characters from a string literal and > use them as non-type template arguments of type char. Unfortunately > the committee seems on the road of prohibiting this and other similar > (and potentially more useful) uses of string literals in constant > expressions: > >http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#366 Huh? They're already prohibited. That item is just concerned with eliminating a contradiction in the standard text in accordance with the original intent. On the contrary, the committee has been occasionally discussing how to allow them, since many of us see the value. -- 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: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line & config file library)
"Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Edward Diener wrote: > [...] > > the system for setting default parameters somehow being changed to solve > > this problem, so that a user can override a default without having to > > override all > > default parameters but that doesn't seem to solve the problem in my mind. > > Something clearer and cleaner is needed but I don't know what it is. > > You might want to take a look at this: > > http://groups.google.com/groups?threadm=199608081434.IAA07848%40ncar.ucar.ED U > (Subject: comp.std.c++: Default arguments) > > The "bottom line" was: > >...why not provide an additional meaning for the "default" keyword... > > Well, the question/problem/suggestion didn't raise much attention, however. I am glad to see that others were aware of this limitation in C++ as long as 6 years ago. I thought the C++ template solution by Damian Conway was pretty neat, but a keyword, maybe "default" as you suggested, might be better since it eliminates a dependency on an external classes and lets the compiler figure out what it is completely capable of doing easily. I definitely like the simple solution of a keyword over named arguments or anything dependent on names. It is easy for the compiler to figure out default values in function calls or template instantiations so using a "default" keyword should work pretty transparently. But this discussion has little to do with Boost per se anymore and should really be in comp.std.c++ instead. Nonetheless thanks for pointing me to that long ago discussion. ___ 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]... > [...] > In Boost.Python I'm using a system for interfaces such as this one > where optional template parameters can be passed in any order. > I'm using the properties of the type to detect their meaning. It > works great. Using boost/mpl/has_xxx.hpp (and, for compilers > which don't support it, is_base_and_derived) should be enough to > build a nice policy-based interface. By "works great", do you mean it works great for you as a library implementor, or it works great for users, and they feel it is a good way to specify policies? Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
On Sat, 18 Jan 2003 13:13:45 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >Gennaro Prota <[EMAIL PROTECTED]> writes: >> Unfortunately >> the committee seems on the road of prohibiting this and other similar >> (and potentially more useful) uses of string literals in constant >> expressions: >> >>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#366 > >Huh? They're already prohibited. I meant that they (you ;-)) want to prohibit any use of string literals in constant expressions. Where is it stated that this is already prohibited? Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problems with boost on Cray C++ release 3.6
I'll try to do it at least once to see which parts of boost we can use, and see how much CPU time this gobbles up. If it is not too much, I will talk to our sysadmins if they would allow me to do it about once a month. I don't think that testing more often would be possible, since already compiling only the filesystem library takes about 15 minutes. ? How come? on my lowly PC it take less then a minute... (compiling just the filesystem) /Daniel Yerushalmy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_STATIC_CONSTANT and VC++ enums
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 ;-) Genny. ___ 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)
"David B. Held" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> [...] >> In Boost.Python I'm using a system for interfaces such as this one >> where optional template parameters can be passed in any order. >> I'm using the properties of the type to detect their meaning. It >> works great. Using boost/mpl/has_xxx.hpp (and, for compilers >> which don't support it, is_base_and_derived) should be enough to >> build a nice policy-based interface. > > By "works great", do you mean it works great for you as a library > implementor, or it works great for users, and they feel it is a good > way to specify policies? Yes. Actually I don't think most of my users think they're specifying policies when they do this -- you could even argue that my design isn't policy-based, but that's really beside the point because the crucial feature is that there are many parameters with useful defaults. It just works and nobody thinks about it. I've never had a support request or question related to this part of the 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] Policy-based smart pointers revisisted
>From: "Greg Colvin" <[EMAIL PROTECTED]> > At 07:33 AM 1/18/2003, Peter Dimov wrote: > > > >It is not simply declaration complexity that Dave's talking about - it can > >be avoided by making smart_ptr be shared_ptr by using default > >parameters. It is semantic complexity. shared_ptr is fairly deep by itself > >(and getting the specification and the tests to a state that can be > >considered adequate wasn't easy.) > > One aspect of the semantic complexity that bothers me > is that the various flavors of smart pointer may not > be interchangeable. shared_ptr is partly parameterized > on implementation, but the interface and semantics > remain the same. For a policy-based smart pointer > to be usable I think you need a clear set of concepts > that clients can use as requirements, and a clear > delineation of which combinations of policies support > which concepts. Good idea. This is what I hinted to with providing convenience typedefs/classes, which guaranteed correct, and documented, semantics. C&E distinguishes between the Configuration DSL and the ICCL (Implementation Component Configuration Language). The former is geared towards the user, and embodies application domain knowledge, while the latter is geared towards the implementation, with knowledge about that. Then you have a generator to bridge the two. Policy-based design is typically mostly ICCL, with it being a kind of special case of GenVoca, as Mat Marcus has mentioned. There's typically little or no functionality such as that provided by a Configuration DSL. If one had more functionality like that, it could make it easier to use, and you shouldn't have to be an expert on the implementation of the smart pointer, to be able to choose correct policies, and avoid any invalid combinations or pitfalls. This reminds me that I'll read up on the discussion regarding policies, in the Boost archive. Regards, Terje ___ 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 13:13:45 -0500, David Abrahams > <[EMAIL PROTECTED]> wrote: > >>Gennaro Prota <[EMAIL PROTECTED]> writes: >>> Unfortunately >>> the committee seems on the road of prohibiting this and other similar >>> (and potentially more useful) uses of string literals in constant >>> expressions: >>> >>>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#366 >> >>Huh? They're already prohibited. > > I meant that they (you ;-)) want to prohibit any use of string > literals in constant expressions. Nobody "wants to". It's not well-defined in the standard what it means to treat a string literal as an integral constant expression. Nobody ever intended them to be integral constant expressions. In standardization, you don't resolve problems like this by exploiting loopholes, and especially during this stage of standardization, which is dedicated to closing them. If you want to enable a new capability, you deal with it separately and intentionally. -- 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] running regression tests
On Fri, 17 Jan 2003, David Abrahams wrote: > Ronald Garcia <[EMAIL PROTECTED]> writes: > > > Is there a way to get this to work without previously running the entire > > boost test suite? I just want to test one library. > > For testing one library, forget about report generation. > > Just go to status/ and > [...] Thanks. Thanks to the joys of unix filtering technology, I can get this output to at least give me the basic information that I would like. Now I am wondering, with the current set of tools, is it possible to generate the reports that Beman has been generating for windows for just one library? I have found them to be very very helpful with working on multi_array, especially being able to track down compiler messages via hypertext. If this can't be done by library right now, is there any sense of the amount of work needed to get there? Thanks, ron ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] type traits question
On Sat, 18 Jan 2003, Aleksey Gurtovoy wrote: > Could you test if the following compiles successfully with the latest CVS > sources? > [...] The code you posted compiles under KCC both with and without the --strict command-line parameter. Hope this helps, and thank you. Cheers, ron ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problems with boost on Cray C++ release 3.6
On Saturday, January 18, 2003, at 07:36 PM, Daniel Yerushalmi wrote: I'll try to do it at least once to see which parts of boost we can use, and see how much CPU time this gobbles up. If it is not too much, I will talk to our sysadmins if they would allow me to do it about once a month. I don't think that testing more often would be possible, since already compiling only the filesystem library takes about 15 minutes. ? How come? on my lowly PC it take less then a minute... (compiling just the filesystem) /Daniel Yerushalmy A Cray is optimized for peak-floating point performance even for out-of-cache codes and optimized for that and not for compile time. There are several reasons why it is slow: i) in order to optimize the runtime performance the machine does not use virtual memory for a process, which makes dynamic allocation very slow. If I need more memory than was allocated initially, the whole process is swapped out and has to wait for a later time slice when more memory can be allocated. This is common when compiling template-heavy code. ii) the fast vector units do not help anything for compiling the code. iii) the optimizer is very aggressive, checking every piece of code for vectorization and parallelization possibilities, which makes it even slower. I don't think your PC compiler does that. And finally, it actually only takes about 10 minutes to compile :) Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
On Sat, 18 Jan 2003 14:14:37 -0500, David Abrahams
<[EMAIL PROTECTED]> wrote:
>Gennaro Prota <[EMAIL PROTECTED]> writes:
>
>> On Sat, 18 Jan 2003 13:13:45 -0500, David Abrahams
>> <[EMAIL PROTECTED]> wrote:
>>
>>>Gennaro Prota <[EMAIL PROTECTED]> writes:
Unfortunately
the committee seems on the road of prohibiting this and other similar
(and potentially more useful) uses of string literals in constant
expressions:
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#366
>>>
>>>Huh? They're already prohibited.
>>
>> I meant that they (you ;-)) want to prohibit any use of string
>> literals in constant expressions.
>
>Nobody "wants to".
Ah ok. Everybody has always been wanting to ;-)
>It's not well-defined in the standard what it means to treat a string
>literal as an integral constant expression. Nobody ever intended them
>to be integral constant expressions.
Here we go.
>In standardization, you don't
>resolve problems like this by exploiting loopholes, and especially
>during this stage of standardization, which is dedicated to closing
>them. If you want to enable a new capability, you deal with it
>separately and intentionally.
I see. Can we expect an "extension" for C++0x then?
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? Do you remember my EXPLICIT_CAST?
#define EXPLICIT_CAST(dst_type, expr) \
( static_cast< check_helper(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
void implicit_cast (typename identity::type x) {
return x;
}
template
char implicit_cast (...);
#define EXPLICIT_CAST(dst_type, expr) \
( sizeof( implicit_cast(expr) ) \
,\
static_cast(expr) \
)
This seems natural: you use sizeof to check whether implicit
conversion happens, then you discard its result. What's wrong with it?
Why prohibiting such a usage in a constant expression?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problems with boost on Cray C++ release 3.6
Matthias Troyer <[EMAIL PROTECTED]> writes: > On Saturday, January 18, 2003, at 07:36 PM, Daniel Yerushalmi wrote: > >> >> I'll try to do it at least once to see which parts of boost we can use, >> and see how much CPU time this gobbles up. If it is not too much, I >> will talk to our sysadmins if they would allow me to do it about once a >> month. I don't think that testing more often would be possible, since >> already compiling only the filesystem library takes about 15 minutes. >> >> ? >> How come? on my lowly PC it take less then a >> minute... (compiling just the >> filesystem) >> >> /Daniel Yerushalmy > > A Cray is optimized for peak-floating point performance > even for out-of-cache codes and optimized for that and > not for compile time. There are several reasons why it > is slow: > > i) in order to optimize the runtime performance the > machine does not use virtual memory for a process, > which makes dynamic allocation very slow. If I need > more memory than was allocated initially, the whole > process is swapped out and has to wait for a later time > slice when more memory can be allocated. This is common > when compiling template-heavy code. > > ii) the fast vector units do not help anything for compiling the code. Just one question: why the heck don't they make a cross-compiler which runs on a machine better-suited to compilation? > iii) the optimizer is very aggressive, checking every piece of code > for vectorization and parallelization possibilities, which makes it > even slower. I don't think your PC compiler does that. There's no reason it couldn't, though. > And finally, it actually only takes about 10 minutes to compile :) Utterly painless! ;-) -- 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] GCC problem on Win32 random_test
Beman Dawes <[EMAIL PROTECTED]> writes: > On the Win32 random_test regression test, gcc is chewing up 1.2 gigs > of virtual memory, then dying. See below. > > I'd appreciate it if one of the gcc experts who reads this list > would report the problem to the gcc folks in the appropriate form. I'd say you're more qualified than anyone, given that you know exactly which compiler and system version it's happening on. > Also, random_test is failing other compilers, too. It would be nice > if someone could clear whatever ails it. I tried to do a little. It needs attention from its maintainer, though. -- 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] type traits question
Ronald Garcia wrote: > The code you posted compiles under KCC both with and without > the --strict command-line parameter. Good, check out the latest CVS sources, then - the issue should be fixed now. > Hope this helps, and thank you. You are welcome! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problems with boost on Cray C++ release 3.6
On Saturday, January 18, 2003, at 10:33 PM, David Abrahams wrote: ii) the fast vector units do not help anything for compiling the code. Just one question: why the heck don't they make a cross-compiler which runs on a machine better-suited to compilation? They have that, but it costs extra money to get an additional front-end machine. We just did not spend that money :( iii) the optimizer is very aggressive, checking every piece of code for vectorization and parallelization possibilities, which makes it even slower. I don't think your PC compiler does that. There's no reason it couldn't, though. Correct, and the new X1 seems to require a front-end machine from what I have heard. Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line & config file library)
-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. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: compile-time binary constants
Gennaro Prota <[EMAIL PROTECTED]> writes:
Huh? They're already prohibited.
>>>
>>> I meant that they (you ;-)) want to prohibit any use of string
>>> literals in constant expressions.
>>
>>Nobody "wants to".
>
> Ah ok. Everybody has always been wanting to ;-)
Desires and intentions are sometimes different.
>>It's not well-defined in the standard what it means to treat a string
>>literal as an integral constant expression. Nobody ever intended them
>>to be integral constant expressions.
>
> Here we go.
What is that supposed to mean?
>>In standardization, you don't
>>resolve problems like this by exploiting loopholes, and especially
>>during this stage of standardization, which is dedicated to closing
>>them. If you want to enable a new capability, you deal with it
>>separately and intentionally.
>
> I see. Can we expect an "extension" for C++0x then?
Not unless someone makes a formal proposal. Are you volunteering?
> 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 D&E?
> Do you remember my EXPLICIT_CAST?
Nope.
> #define EXPLICIT_CAST(dst_type, expr) \
> ( static_cast< check_helper sizeof(implicit_cast(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
> void implicit_cast (typename identity::type x) {
> return x;
> }
>
>
> template
> char implicit_cast (...);
>
> #define EXPLICIT_CAST(dst_type, expr) \
> ( sizeof( implicit_cast(expr) ) \
> ,\
> static_cast(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. 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. But I assume that's not what you're
concerned with here ;-)
> Why prohibiting such a usage in a constant expression?
Yer askin' the wrong guy.
--
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
At 11:30 AM 1/18/2003, Gennaro Prota wrote: >On Sat, 18 Jan 2003 13:13:45 -0500, David Abrahams ><[EMAIL PROTECTED]> wrote: > >>Gennaro Prota <[EMAIL PROTECTED]> writes: >>> Unfortunately >>> the committee seems on the road of prohibiting this and other similar >>> (and potentially more useful) uses of string literals in constant >>> expressions: >>> >>>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#366 >> >>Huh? They're already prohibited. > >I meant that they (you ;-)) want to prohibit any use of string >literals in constant expressions. Where is it stated that this is >already prohibited? Other places in the standard make it clear that strings literals are not *integral* constant expressions. The issue you linked to just proposes make this even more clear. 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. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Policy-based smart pointers revisisted (was:Re:Preliminarysubmission: command line & config file library)
"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" . ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
