[boost] 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]...
Terje Slettebø <[EMAIL PROTECTED]> writes:
>>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.
>>
>> 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 {};
>
> etc.
>
> 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.
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. This is a weakness in C++ itself, in
the default parameters system. Previous to template classes it hasn't been
much of an issue since there has been little need to design functions with
many default parameters. However with template classes and the "policy" idea
this weakness really crops up. Policy-based template classes would work fine
if one could choose to set a particular policy within a choice of policies
of a given type without having to worry about any other policy types. But
with the method of specifying default parameters, whether for functions or
types in a template class parameter list, the idea of policy-based template
classes is much less effective simply because it becomes much harder to use
for the end-user. There is something to be said for ease-of-use for template
classes as for anything else.
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.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Policy-based smart pointers revisisted (was: Re:Preliminary submission: command line & config file library)
Terje Slettebø <[EMAIL PROTECTED]> writes:
>>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.
>>
>> 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 {};
>
> etc.
>
> 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.
One way out might be not to tell them that shared_ptr is built on the
policy-based one.
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.
--
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] Policy-based smart pointers revisisted (was: Re: Preliminarysubmission: command line & config file library)
>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.
>
> 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 {};
etc.
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.
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Preliminary submission: command line & config fil elibrary
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > [...] > > We received some resistance from some developers > > claiming it was too complex. But in my view, if you > > don't want to look inside, the typedefs are simple > > enough, just use them. > > We don't have typedef templates; you must mean > something else > [...] I suspect that what he means is, for a given T, create a typedef of the smart pointer specialized on T. Dave ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] type traits question
On Fri, 17 Jan 2003, Aleksey Gurtovoy wrote: > Ronald Garcia wrote: > > Howdy. I am trying to use KCC in strict mode to compile some > > code that depends on type traits. > > Which version? Does it support partial template specialization/template > template parameters? > 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. 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. Let me know if there is any more information I can give you. Note that KCC only gives problems when I run it in --strict mode. Otherwise it seems to run okay. Cheers, ron ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Preliminary submission: command line & configfil e library
[EMAIL PROTECTED] (David Bradley) writes: > David Abrahams wrote: > >>It's truly amazing how many problems are solved by the existing >>boost::shared_ptr<> design, and it's a big advantage to have a >>single-source smart pointer which "just works" in so many ways. >>There's so much to learn about what it's capable of that many people >>legitimately believe more parameterization would harm >>understandability. >> >> > A number of years ago we used a policy based smart > pointer class. Worked really well. Allowed us to easily > choose between intrusive and passive ref counts, as > well as incorporate thread safe vs non-thread safe > versions and easily use the type of smart pointer we > needed for the task at hand all with the same interface > and familiarity. Not to mention that once we got the > basic implementation right, adding new policies was a > breeze. I don't doubt it a bit. A parameterizable smart pointer is surely useful. > We received some resistance from some developers > claiming it was too complex. But in my view, if you > don't want to look inside, the typedefs are simple > enough, just use them. We don't have typedef templates; you must mean something else -- but I agree that it's easy to hide parameterization in a smart pointer interface. All the same, I think your experience with "some developers" proves that this hiding isn't 100% effective. For whatever reason, it incurred mental overhead for these people. > It's just like the rest of the STL that is quite > complex, but people use it. I really don't think so. The STL is designed around parameterization. None of the components have a similar flavor to boost::shared_ptr, which provides a remarkably rich set of capabilities with practically no parameterization. > If one fear this, then why would they not fear > std::string and std::wstring. Both those represent > more complex templates. They each could have been > implemented as a class, "simplifying" the > implementation. Granted it's not a great analogy, but > I don't think a policy based smart pointer is that > much different. It's not a great analogy because though the std strings provide a complicated interface (even ignoring the parameters), they're conceptually trivial. The boost shared_ptr provides a simple interface and is conceptually rich. The fear with smart pointers is that a plethora of parameters will interfere with understanding the concepts of shared_ptr which I guess is supposed to represent the "perfect balance" for common cases. 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. 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. -- 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: Re: Preliminary submission: command line & config fil e library
> > my_program ( 0, 1) ( 1, 3) (( 0, 1), 15 ), (( 0,1), (7.8) ) > This is input of 2 points circle and line. > > > This isn't a simple parsing task anymore. > > Regards Hartmut Depends. Imagine we have defined input operators for Shape classes istream& operator>>( istream&, Point& ); // accept format (x,y); in other case throw an exception istream& operator>>( istream&, Circle& ); // accept format ((x,y), r); in other case throw an exception istream& operator>>( istream&, Line& ); // accept format ((x1,y1), (x2,y2)) in other case throw an exception They could even exist by itself without CLA processing needs. Each one of them is easily implemented (with tokenizer for example). Now In combination with chain_lookup_policy we could have a cla::parser that accept above syntax with arbitrary order of elements. The idea is originated by the article "Industrial strength Pluggable Factories" that could be found online. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line & configfil e library
Gennadiy Rozental wrote: > > Why reinvent the wheel and not reuse existing code, which > is much more > > flexible (and _you_ are the one, who stresses flexibility) > and better > > fits into the task to solve. > > Even with my limited knowledge of Spirit, still I do not > believe I duplicate Spirit functionality in any way. What I > define are the skeletons for different parsing logics. One > could choose what parser (interpreter in my > terms) to use to do a real job. my_program ( 0, 1) ( 1, 3) (( 0, 1), 15 ), (( 0,1), (7.8) ) This is input of 2 points circle and line. This isn't a simple parsing task anymore. Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Preliminary submission: command line & configfil e library
David Abrahams wrote: It's truly amazing how many problems are solved by the existing boost::shared_ptr<> design, and it's a big advantage to have a single-source smart pointer which "just works" in so many ways. There's so much to learn about what it's capable of that many people legitimately believe more parameterization would harm understandability. A number of years ago we used a policy based smart pointer class. Worked really well. Allowed us to easily choose between intrusive and passive ref counts, as well as incorporate thread safe vs non-thread safe versions and easily use the type of smart pointer we needed for the task at hand all with the same interface and familiarity. Not to mention that once we got the basic implementation right, adding new policies was a breeze. We received some resistance from some developers claiming it was too complex. But in my view, if you don't want to look inside, the typedefs are simple enough, just use them. It's just like the rest of the STL that is quite complex, but people use it. If one fear this, then why would they not fear std::string and std::wstring. Both those represent more complex templates. They each could have been implemented as a class, "simplifying" the implementation. Granted it's not a great analogy, but I don't think a policy based smart pointer is that much different. David Bradley [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] type traits question
Ronald Garcia wrote:
> Howdy. I am trying to use KCC in strict mode to compile some
> code that depends on type traits.
Which version? Does it support partial template specialization/template
template parameters?
> I am getting a large quantity of errors along these lines:
>
> "/u/garcia/src/boost/boost/type_traits/is_volatile.hpp", line
> 33: error:
> identifier "is_volatile_rebind" is undefined
>
> BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_volatile,T,::boost::detail::cv
> _traits_imp::is_volatile)
> ^
>
> "/u/garcia/src/boost/boost/type_traits/remove_const.hpp",
> line 56: error:
> identifier "remove_const_rebind" is undefined
> BOOST_TT_AUX_TYPE_TRAIT_DEF1(remove_const,T,typename
> detail::remove_const_impl::type)
> ^
[...]
>
> Any idea what might be causing this?
Yep. The marked line below makes the 'remove_const' definition ill-formed,
and that's what the BOOST_TT_AUX_TYPE_TRAIT_DEF1 macro expands to on
non-conforming compilers:
template< typename T > struct remove_const
{
typedef T type;
friend class remove_const_rebind;
typedef remove_const_rebind rebind; // here
};
Your KCC is the first compiler that is classified by the config system as
non-conforming (not supporting PTS/TTP), but yet complaining about the above
line :). There are several ways how I can fix the above, but before
attempting the fix I need to know answers to the foregoing questions.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line & confi g fil e library
> ... through something like lexical property map: [skip] This is basically how key_lookup_policy::operator[]( std::string key_name ) is implemented. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line & config fil e library
> Why reinvent the wheel and not reuse existing code, which is much more > flexible (and _you_ are the one, who stresses flexibility) and better > fits into the task to solve. Even with my limited knowledge of Spirit, still I do not believe I duplicate Spirit functionality in any way. What I define are the skeletons for different parsing logics. One could choose what parser (interpreter in my terms) to use to do a real job. > I like the way Valodiya solves this: a > clear, streamlined but extensible library with a simple but powerful > interface. I would appreciate your comments on both submissions. Doesn't my solution is "clear, streamlined with a simple but powerful interface. > If I need cla parsing (quite simple or more elabourated - as > in your geometry sample), I can write my own parsers and make them fit > into the picture seemless without any headache. So you could with my framework. > I do not > expect from the > cla framework to do the parsing for me, I do. Why should I repeat string->type interpretation in every program that use cla framework. Another reason is that IMO it's more C++ like solution to work with typed parameters and arguments. Would I work in perl I prefer strings. Also typed parameters allowed me to perform additional validation on whether value could be interpreted as target type. > it should return strings > associated with keys (which are strings too) from different locations > (cla, cfg file, registry etc.). That's all. I do provide an ability to return string results of course if you prefer that. > > Just my 2c worth. > Regards Hartmut > Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line & config fil e library
[EMAIL PROTECTED] wrote:
> I do not expect from the cla framework to do the parsing for me, it
> should return strings associated with keys (which are strings too)
> from different locations (cla, cfg file, registry etc.).
... through something like lexical property map:
template<
typename KeyType
, typename T
, typename Compare = std::less
>
class lexical_property_map
: private std::map< KeyType,T,Compare >
{
typedef lexical_property_mapself_t;
typedef std::map< KeyType,T,Compare > base_t;
public:
typedef typename base_t::key_type key_type;
using base_t::begin;
using base_t::end;
using base_t::empty;
using base_t::size;
using base_t::clear;
using base_t::find;
bool has_key(key_type const& a_key) const
{
return this->find(a_key) != this->end();
}
template< typename U >
self_t& put(key_type const& a_key, U const& a_value)
{
(*this)[a_key] = boost::lexical_cast(a_value);
return *this;
}
template< typename U >
U get(key_type const& a_key, U const& a_default = U()) const
{
return this->has_key(a_key)
? boost::lexical_cast( this->find(a_key)->second )
: a_default
;
}
T get(key_type const& a_key, T const& a_default = T()) const
{
return get(a_key, a_default);
}
};
int main()
{
lexical_property_map options;
options.put("delay", 50);
std::cout << options.get("delay");
}
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] type traits question
Howdy. I am trying to use KCC in strict mode to compile some code that depends on type traits. I am getting a large quantity of errors along these lines: "/u/garcia/src/boost/boost/type_traits/is_volatile.hpp", line 33: error: identifier "is_volatile_rebind" is undefined BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_volatile,T,::boost::detail::cv_traits_imp::is_volatile) ^ "/u/garcia/src/boost/boost/type_traits/remove_const.hpp", line 56: error: identifier "remove_const_rebind" is undefined BOOST_TT_AUX_TYPE_TRAIT_DEF1(remove_const,T,typename detail::remove_const_impl::type) ^ ... ... ... Any idea what might be causing this? I don't have this problem if I don't use --strict mode. I tried poking around but MPL and type traits are a bit rich for my blood. Cheers, ron ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line & configfil e library
Gennadiy Rozental wrote: > > > > It is not necessary. You program will be given *string* > > > > "(0,1) (1,3)" and > > > > can parse it using more powerfull means. I guess Spirit > is quite > > > > appropriate. > > > > > > I provide a way to parse it with very simple means. > > > > Spirit actually _is_ simple :-) > > > > Regards Hartmut > > I don't argue that. (Unfortunately) I am not familiar with > Spirit enough to judge. What I sad is that I *also* provide a > means to implement such parsing logic pretty easy. What would > be more convinient, easier, more appropriate in every > concreate case depends on several factors. One of them is > whether or not you familiar with Spirit. Why reinvent the wheel and not reuse existing code, which is much more flexible (and _you_ are the one, who stresses flexibility) and better fits into the task to solve. I like the way Valodiya solves this: a clear, streamlined but extensible library with a simple but powerful interface. If I need cla parsing (quite simple or more elabourated - as in your geometry sample), I can write my own parsers and make them fit into the picture seemless without any headache. I do not expect from the cla framework to do the parsing for me, it should return strings associated with keys (which are strings too) from different locations (cla, cfg file, registry etc.). That's all. Just my 2c worth. Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: proposal: safe arithmetic class
"Thorsten Ottosen" <[EMAIL PROTECTED]> writes: > As far as possible, a "safe numeric" is a type that never lead the > user into implementation defined behavior. For most of my programs I > wouldn't worry about if it meant a slower type; program correctness > should be the only concern. Something like http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-sandbox/boost/bigint.hpp fits that description. -- 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: proposal: safe arithmetic class
<[EMAIL PROTECTED]> wrote in message 3D8559AE95B4D611B02C0002557C6C8B3C45CF@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C45CF@STH-EXCH... [snip] > > 1) Controlled numeric type promotion and conversion > This would be needed for safe(r) expressions; the rules for integral > promotions, floating point promotions, integral conversions, floating > integral conversions, and the usual arithmetic conversions, would be encoded > explicitly in types or implicitly in expressions. Unary and binary > expressions are handled to produce the correct resulting type; conversions > that would lead to loss of precision or range are invalidated, either at > compile time or runtime. It is probably a nontrivial task to find consensus > on what to allow; for example, should the special rules for unsigned > arithmetic be prohibited or not? [No expression templates required here > either, but could potentially simplify and add functionality to the > implementation.] > > Example: > > Int i=std::numeric_limits::max(); > Short s=7; > UShort us=i+s; // i+s results in a type equivalent to unsigned int, and us > is assigned "the least unsigned integer > // congruent to the source integer (modulo 2n where n is the number of bits > used to represent the unsigned type)" > // , i.e. it "wraps around". Should this be legal for this safe type? My personal view would be that it should throw an exception. > 2) Complex expression conversion and promotion control > > If the aforementioned mechanisms for controlling conversions and promotions > exist, there is still the matter of more "complex" arithmetic, involving > intermediate steps. This is where the expression templates need to enter the > arena, because we can no longer simply evaluate the binary operations; we > must consider the expression as a whole. If we don't, seemingly equivalent > expressions will be treated differently (just as is the case with > built-ins): > > int x=100; > int y=100; > int z=100; > > int r=x*y/z; // Probably a negative number, implementation-defined. > safe_numeric throws an exception if all variables are safe_numeric. > r=x/z*y; // 100. safe_numeric doesn't throw an exception. As far as possible, a "safe numeric" is a type that never lead the user into implementation defined behavior. For most of my programs I wouldn't worry about if it meant a slower type; program correctness should be the only concern. > I don't think all of the above was the intent of your proposal though? no it wasn't. Of course, I also wanted a discussion because it is often not as trivial as I tend to think. >(And > also, there might be value in a partial solution for detecting > errors/problems/strange results at runtime) The three problems stated above > seem to have great potential for solutions through class libraries (and > unlimited precision types, where art thou?), and my point has been (and is) > that 0) is already covered by numeric_cast, and might not need another > solution; the others remain open. I think it might be hard to say if we need three levels of granularity. Anyway, the important thing is that there could be a need for more control of implicit conversions/undefined behavior. As I understand, there have been a proposal to include a recent C-standard header which defines int8_t, int32_t types (which are guarenteed to have the proclaimed size) into C++ too. Maybe these types could be defined with additional "safety" guarantees in C++ so we could avoid adding too many new names (it might be a bad idea if C programs compiled with a C++ compiler must have the same semantics). regards Thorsten ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Preliminary submission: command line & config file li brary
> Since this discussion has been mostly between two folks, I > thought I'd add my take on command line and configuration file > handling. Finnaly. I started to think that it's only me and Volodya who have an interest in a subject. > The purpose of command line parsing is to decode the arguments > list into pieces of information, abstracting the syntax of the > command line away from the program. Thus, the library should be > able to understand any of various encoding schemes. Agree here. That's why lookup_policy is introduced - to support different logic in parameter identification. > The question then becomes how the library should provide the > values from the command line. There are a number of fundamental > types that could be exposed by the library: bool, long, double, > and string. The question is whether the library should support > any others. I selected those types because Boolean and string > parameters are obviously important, and long and double would > handle pretty much all numeric arguments one would put in a > command line. > > You could use std::istream-based input mechanisms to allow types > to parse an input string, thus making the argument to variable > conversion extensible. Beyond that, I don't think anything is > needed. Yes. Once parameter is identified the second task is to parse out value from input. I separated this logic into interpreter class. Default one use lexical_cast(istream) based solution. But if for whatever reason you prefer scanf you will be able to use one. > As for configuration files, there are myriad formats available > and I don't think parsing them has anything to do with command > lines. Agree here. > I can see a special redirection mechanism in which you > tell the command line library that all or some of the arguments > that would otherwise be on the command line will appear in a > file, but the format of such a file should be confined to a > series of lines that conform to what could otherwise have been on > the command line. This is only one of the possible solutions to the task of providing unified program parameters interface. > Some configuration files include CPP-like preprocessing symbols > and directives. Some are section based (like Windows INI files). > Some are just free form lines of text. Some use special symbols > to delimit required columns of data. I don't think there's a > good way to standardize this. > > Sure, you could provide a means to read a file line by line and > pass each line to a parser of some sort. However, given all of > the ways to parse the text one might find in such a file, I don't > see how that could be done so it is sufficiently flexible and yet > actually provides value. IOW, the parsing would be little more > than read a line, give it to the parser, read another line, give > it to the parser, etc. That certainly doesn't justify a special > library. Look on what my config_file iterator is doing. Don't you think it's reusable and worth separating into library? Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Preliminary submission: command line & config fil elibrary
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I think that's a gross mischaracterization. The only new design I've > seen discussed in the past year is something (non-portable IIUC) that > most people can't get their heads around and don't seem to need. It's > an interesting design idea which blends the advantages of intrusive > and non-intrusive smart pointers, but I think is still largely > unproven. Sigh. I know it sounds corny, but... people who sent supportive answers to my post through private email - please understand that that's not helpful at all. Post them here. Back to lurk mode. Thanks for answering Dave. Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preliminary submission: command line & config file li brary
Since this discussion has been mostly between two folks, I thought I'd add my take on command line and configuration file handling. The purpose of command line parsing is to decode the arguments list into pieces of information, abstracting the syntax of the command line away from the program. Thus, the library should be able to understand any of various encoding schemes. The question then becomes how the library should provide the values from the command line. There are a number of fundamental types that could be exposed by the library: bool, long, double, and string. The question is whether the library should support any others. I selected those types because Boolean and string parameters are obviously important, and long and double would handle pretty much all numeric arguments one would put in a command line. You could use std::istream-based input mechanisms to allow types to parse an input string, thus making the argument to variable conversion extensible. Beyond that, I don't think anything is needed. As for configuration files, there are myriad formats available and I don't think parsing them has anything to do with command lines. I can see a special redirection mechanism in which you tell the command line library that all or some of the arguments that would otherwise be on the command line will appear in a file, but the format of such a file should be confined to a series of lines that conform to what could otherwise have been on the command line. Some configuration files include CPP-like preprocessing symbols and directives. Some are section based (like Windows INI files). Some are just free form lines of text. Some use special symbols to delimit required columns of data. I don't think there's a good way to standardize this. Sure, you could provide a means to read a file line by line and pass each line to a parser of some sort. However, given all of the ways to parse the text one might find in such a file, I don't see how that could be done so it is sufficiently flexible and yet actually provides value. IOW, the parsing would be little more than read a line, give it to the parser, read another line, give it to the parser, etc. That certainly doesn't justify a special library. Perhaps I've missed some valuable service that should be included in the proposed library, but I can't see that it should do more than what I've outlined herein. If you do, please enlighten me! -- Rob Stewart [EMAIL PROTECTED] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: any_cast improvement
Alexander Nasonov wrote: Unai Uribarri Rodríguez wrote: Alexander Nasonov wrote: Unai Uribarri Rodríguez wrote: any_cast, as is implemented in boost 1.29, has one weakness; it doesn't allow to compile this piece of code: any x=int(5); ++any_cast(x) Boost.dynamic_any has extract functinos which work this way. But this patch adds that functionality without breaking the interface. For broken compilers it could break all because remove_reference might not work for them. If you see the compiler status page, you can see that the any test and the remove_reference works with the all compilers except Visual C++ 6 & 7 and SGI MIPSpro CC 7.3.1.2m. The any_test fails also with Sun Workshop 6U2. Therefore, this patch doesn't affect the portability of any. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line & config fil e library
> Gennadiy Rozental wrote: > > > > It is not necessary. You program will be given *string* > > > "(0,1) (1,3)" and > > > can parse it using more powerfull means. I guess Spirit is > > > quite appropriate. > > > > I provide a way to parse it with very simple means. > > Spirit actually _is_ simple :-) > > Regards Hartmut I don't argue that. (Unfortunately) I am not familiar with Spirit enough to judge. What I sad is that I *also* provide a means to implement such parsing logic pretty easy. What would be more convinient, easier, more appropriate in every concreate case depends on several factors. One of them is whether or not you familiar with Spirit. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] running regression tests
Ronald Garcia <[EMAIL PROTECTED]> writes: > In any case, when I run: > > ./compiler_status $BOOST_ROOT doh.html > Using > /nfs/magrathea/home/user1/garcia/src/boost/status/bin/constructors.test to > determine compilers > > *** Error: std::runtime_error: boost::filesystem::directory_iterator > constructor: > "/nfs/magrathea/home/user1/garcia/src/boost/libs/filesystem/test/bin": No > such file or directory > > > 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 bjam Or if the library has only one test: bjam where the test name is probably the basename of the test's .cpp file. Add the --verbose-test option if you want to see the output of successful tests. -- 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: Re: Preliminary submission: command line & configfil e library
Gennadiy Rozental wrote: > > It is not necessary. You program will be given *string* > > "(0,1) (1,3)" and > > can parse it using more powerfull means. I guess Spirit is > > quite appropriate. > > I provide a way to parse it with very simple means. Spirit actually _is_ simple :-) Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] running regression tests
Howdy, I'm trying to get the regression system up by following the directions in the docs (boost/more/regression.html#Execution) and running locally and I'm having some problems with the report generation. I'm under the impression that bjam is running my tests as expected, but I'm having trouble with the external tools for generating the reports. I set BOOST_ROOT to point to my boost root ($HOME/boost), and I set TOOLS to gcc. 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)? In any case, when I run: ./compiler_status $BOOST_ROOT doh.html Using /nfs/magrathea/home/user1/garcia/src/boost/status/bin/constructors.test to determine compilers *** Error: std::runtime_error: boost::filesystem::directory_iterator constructor: "/nfs/magrathea/home/user1/garcia/src/boost/libs/filesystem/test/bin": No such file or directory Is there a way to get this to work without previously running the entire boost test suite? I just want to test one library. thanks, ron ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line & config fil e library
> It is not necessary. You program will be given *string* > "(0,1) (1,3)" and > can parse it using more powerfull means. I guess Spirit is > quite appropriate. I provide a way to parse it with very simple means. > > Unfortunately I will be really > > busy till the middle of February. So may not be able to > work on this further meanwhile. > > It's a pity, because I've only one more or less serious > interface change left > in my library, and would prefer to ask for review after that. > Do you have any > idea when your library will have documentation, examples and tests? Not before the date I mention. If you feel that your design could stand in review go ahead. I will submit my once it's done. Hopefully really soon, cause Boost.Test changes will rely on it. > And... how config file parser is concerned with XML? You have option > "input_message", which value happens to be in XML. The config file > parser, which should work on syntactic level, would faithfully return > that XML string. On semantic level, the "validator" function > would parse > the XML. I fail to see how supporting XML depends on config > file parser. Well, Yes. It was bad example. But it does not mean that I could not write wrapper around xerses that uses config_file_iterator line output as an input. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Preliminary submission: command line & configfil e library
"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes: >> I'd like to draw an analogy with shared_ptr. You can provide smart pointer >> with 5 policy parameters, that user can redefine. Still, I would use >> boost::shared_ptr, just because I don't want 10 incompatible smart > pointers in >> my program due to small advantage each one has in special situation. > > Ok, I can't hold it :o). It's funny how policy_based smart pointers have > been vigurously disapproved by some boost participants for various reasons, > yet anytime I log in here there's discussion about a yet another > smart_pointer du jour, designed from scratch, and most of the time > incompatible with all others. I think that's a gross mischaracterization. The only new design I've seen discussed in the past year is something (non-portable IIUC) that most people can't get their heads around and don't seem to need. It's an interesting design idea which blends the advantages of intrusive and non-intrusive smart pointers, but I think is still largely unproven. It's truly amazing how many problems are solved by the existing boost::shared_ptr<> design, and it's a big advantage to have a single-source smart pointer which "just works" in so many ways. There's so much to learn about what it's capable of that many people legitimately believe more parameterization would harm understandability. I don't think anyone disapproves of the idea of a customizable smart pointer design. It would be great to have for special-purpose jobs. If boost::shared_ptr could be implemented in terms of it, so much the better. If you think it would address some real needs that aren't covered by existing boost libraries, you should bring a design up for formal review. If people think they need it, I'm sure it would be accepted. Personally, I'm not sure about the best way to get to a customizable smart pointer. For example, it would be very interesting to see what it looks like to apply the new iterator adaptors design in the boost sandbox to smart pointers. If using one library for all smart pointers is good, using one library for all dereferenceable types is surely better (or maybe not, but I'd like to see how it pans out) ;-). -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
RE: [boost] Re: Preliminary submission: command line & config fil e library
> As my example above shows, you can use simple syntax for two
> arguments and
> explicit/named for all others. Take a look at Boost.Graph: it
> uses named
> arguments, but mostly for numerous details such as
> "color_map". You don't have
> to write
>
> transitive_closure(graph_param(g));
Unfortunately I am not familiar with Boost.Graph, but I believe that in
specific case of CLA I would prefer one style for all parameter's modifiers.
I do not see how description is more important that optional/required for
example. Looking on your example I already confused:
> desc3.add_options()
> ("output,o", "file", "where to send output")
> ("magic", "value", "magic value for the program")
> .default_value("43")
What is "file", "value"? Why do I need to supply default value as a string
and not 43 itself?
What is ,o? Do I need to remember everything that you will reply?
> options_description desc;
> desc.add_options()
> ("roll_trace_file?", "arg?", "roll trace file)
> ;
What id "arg" then? Keyword? Would you remember difference between first
question mark and second?
> >>And what those operator<< will do?
> > Feed option definitions to the cla::parser.
>
> Eeh.. that's only possible if program_options,
> config::parser, and cla::parser
> have the same interface for declaring options. If you add
> custom modifier to
> cla::parser, you have to add it to program_options, and the
> to config::parser
> and then to registry::parser, if you have it.
Not at all. program_option may support only common superset on all
configuration components features. It does not need to know about all
supported features of all components. In my understanding program_options is
only helper facility for one very useful case.
>
> - Volodya
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Preliminary submission: command line & config file li brary
> > You did not get me. I did not talk about options description at all. As I > > keep repeating it another level of abstraction on top of config file, cla, > > registry, db whatever. The only purpose of option description is to store > > unified description of all named options for the program. it does not have > > any parsing functionality inside. Instead when you need to get named program > > parameters from some source you feed it with option_descriptions and get the > > results from it (option_description may also provide unified way to access > > named parameter, that in fact will be a forward to component-specific access > > method). option_description design IMO is separate issue and should be > > discussed separately. Here we talking about config_file component design. > > I'm afraid you did not get me as well. You're saying that parsing level should > not be coupled with validation level. Yes, there's validation level in > config_file class. Yet, it's *rudimentary* validation. I can remove it without > much effect on other parts of library. But IMO, that would make the class less > complete. I argue that there's no coupling that worth worrying about. Again I did not talk about validation. Would I want to add the validation it be third level on top of two I meant. level 1. config_file_iterator - see below what it is doing. One more comment: config_file_iterator produce text lines. Any parser that accept (or could accommodate ) this kind of input could be used as second level parser. level 2. parameters parsing - see below what it is doing level 3. parameters description/validation - holds program parameters and their value/presence validation functors > > My config_file iterator is responsible for > > 1. comments lines > > 2. continuation lines > > 3. ifdef, define, undef, endif ... > > 4. include > > 5. skipping empty lines > > My parameters handling facility is responsible for parsing, storing and > > accessing parameters defined in format (configurable) above. It does not > > know anything about supported parameter by the program it just read what is > > in config file. Later you could access parameters by name and get the value > > if parameter with the supplied name exists. > How parsing "test::debug"'s value or "true" differs from parsing > "--debug=true" from command line? How accessing "test::debug" by name > differs from accessing value of "debug" option from command > line. *I* think > that's almost the same. Consequently, I'd rather not have two > different > classes and two different code handle the same task. Each component is much more feature reach by itself: cla provide support for non-named parameters parameter handling provide support for parameter names with namespaces If there is something common in simplest cases, reuse could be achieved with use of some shared parsers. For example parameter handling could use KeyPolicy classes for parameter identification. But I am not sure it worth persuading cause may be inconvenient. Gennadiy ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression tests for aCC are up
[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? -- 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: Preliminary submission: command line & config file library
Hi all, I have not followed this discussion closely, but I did want to add on one point: On Thu, 16 Jan 2003, Vladimir Prus wrote: > > > > BTW what if I want ? as a part of my parameter name? > > Do you need this really? > > > For example: > > > > my_program /roll trace file? = "yes" > > > > CLA is basic facility that is used by many people with different habits. You > > could not afford to incur too many restrictions. > > I think that *existing* habits shold be supported. However, the library should > encourage some "standard" command line style. Contrived command line style is > only an inconvenience to user. As an example: what does "-r" option to CVS > does? (It has 2 unrelated meanings, and about 4 syntax variations) Some programs might support a command line like this: my_program ? To print out help information (ie same as my_program --help). Therefore, allowing ? as a command line argument is an important use case. I am not sure whether or not Vladimir's proposal would support a question mark by itself. Regards, -Tom Wenisch Computer Architecture Lab Carnegie Mellon University ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Preliminary submission: command line & config fil e library
> I'd like to draw an analogy with shared_ptr. You can provide smart pointer > with 5 policy parameters, that user can redefine. Still, I would use > boost::shared_ptr, just because I don't want 10 incompatible smart pointers in > my program due to small advantage each one has in special situation. Ok, I can't hold it :o). It's funny how policy_based smart pointers have been vigurously disapproved by some boost participants for various reasons, yet anytime I log in here there's discussion about a yet another smart_pointer du jour, designed from scratch, and most of the time incompatible with all others. It's not about small advantages it's about. Andrei ___ 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 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. -- 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] regression tests for aCC are up
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. Someone should probably remove hpux-times.html and hpux.log.gz, from 23-Apr-2002 -- 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] regression tests for aCC are up
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. -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] regression tests for aCC are up
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. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Preliminary submission: command line & configfil e library
Gennadiy Rozental wrote: my_program ( 0, 1) ( 1, 3) (( 0, 1), 15 ), (( 0,1), (7.8) ) > This is input of 2 points circle and line. Here chain_lookup_policy could be useful. What if I want C++ expression specified on the command line? Sure, I don't want make C++ parser operate on command line. Rather, I'd write my_program "f(1, 2) + 10" I don't need "chain_lookup_policy" where a couple of quote characters will do. IT doesn't matter weather or not you are using quotes. To parse out Point, Point, Circle, Line out of input above you need chain of responsibilities logic. It is not necessary. You program will be given *string* "(0,1) (1,3)" and can parse it using more powerfull means. I guess Spirit is quite appropriate. I really can't comment further without seeing the code. Ok. I put in vault area some snapshot. I take some not testes functionality out of there. But you should get the feeling. Looking at it now. It might take some time to form an opinion. Unfortunately I will be really busy till the middle of February. So may not be able to work on this further meanwhile. It's a pity, because I've only one more or less serious interface change left in my library, and would prefer to ask for review after that. Do you have any idea when your library will have documentation, examples and tests? No. Does yours? Getting really picky, does yours allows to validate XML against DTD? In fact yes. My test configuration file look like this: input_message \ \ <> \ <> "expected_output after transformation 1" "cxvbxbxb" "expected_output after transformation 2" "df sdf sdf" Now my test program read test configuration file and feed value of "input_message" parameter to the xerces parser. And... how config file parser is concerned with XML? You have option "input_message", which value happens to be in XML. The config file parser, which should work on syntactic level, would faithfully return that XML string. On semantic level, the "validator" function would parse the XML. I fail to see how supporting XML depends on config file parser. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Comments on date/time library
> > Default Construction > > > > It would be useful if default constructors for gregorian::date and > > posix_time::ptime were provided. The default constructors could maybe work > > as follows: > > > > gregorian::date() ==> gregorian::date(not_a_date_time) > > posix_time::ptime() ==> posix_time::ptime(gregorian::date(not_a_date_time), > > time_duration(0, 0, 0)) > > There has been some recent discussion on this very issue, so > here are a couple boost-user archive links: > > This one shows you how you can create your own default > constructor: > > http://groups.yahoo.com/group/Boost-Users/message/2701 > > > At least one user wanted this at first, but after using the library > for awhile decided it wasn't really necessary. See: > > http://groups.yahoo.com/group/Boost-Users/message/2705 > > > I didn't put these in because I never felt comfortable > about choosing the default values. > 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. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Equivalence Relation class
On Fri, 17 Jan 2003 12:28:50 +0100, Miroslav Silovic wrote: > Jeffrey Yasskin wrote: > >> I have a small class that uses the union/find algorithm to implement a >> dynamic equivalence relation. With some work, it could probably also >> be used to iterate through the equivalent partition. >> >> Would this be a good thing to add to boost? >> > Isn't this functionality equivalent to the dynamic connected components > in the Boost graph library? > > Miro Oops. Yes. Never mind. Jeffrey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] intel-linux-tools.jam
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) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Comments on date/time library
> Default Construction > > It would be useful if default constructors for gregorian::date and > posix_time::ptime were provided. The default constructors could maybe work > as follows: > > gregorian::date() ==> gregorian::date(not_a_date_time) > posix_time::ptime() ==> posix_time::ptime(gregorian::date(not_a_date_time), > time_duration(0, 0, 0)) There has been some recent discussion on this very issue, so here are a couple boost-user archive links: This one shows you how you can create your own default constructor: http://groups.yahoo.com/group/Boost-Users/message/2701 At least one user wanted this at first, but after using the library for awhile decided it wasn't really necessary. See: http://groups.yahoo.com/group/Boost-Users/message/2705 I didn't put these in because I never felt comfortable about choosing the default values. > DATE_TIME_INLINE > > It seems wrong that when using the default build of the date/time library, I > have to #define DATE_TIME_INLINE in all compilation units that use the > date/time library. Wouldn't it be better to reverse this logic and define > DATE_TIME_NO_INLINE only when a non-default build is required? > > Also, shouldn't this symbol be called BOOST_DATE_TIME_INLINE (or > BOOST_DATE_TIME_NO_INLINE :) > > Building > > When building the current CVS state with Borland C++ Builder 5, I am still > getting all tests and examples built when I only want the library built. Yes, these issues will be fixed. Of course with sourceforge down we can't really do much of anything :-( Hopefully it will be back soon... Jeff ___ 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 13:55, David Abrahams wrote: >> Toon Knapen <[EMAIL PROTECTED]> writes: >> > In intel-linux tools, the link-line first contains -l$(FINDLIBS) and next >> > $(NEEDLIBS). Whould'nt it make more sense to revert the order. NEEDLIBS >> > typically contains other libs in the same project (==boost) whereas >> > FINDLIBS typically contains external and/or system libs. NEEDLIBS is thus >> > very likely to depend on FINDLIBS and thus needs to be in front of >> > FINDLIBS. >> > >> > (I remember to have made the same remark about the link-line in >> > gcc-tools.jam but still wanted first an 'OK' of everyone involved) >> >> I think you're right; it's OK with me if you change it. > > Done. I've also retained only one of the two NEEDLIBS (all libs appeared twice > in the link-line). Is that OK ? This would only be necessary in case there > would be circulare dependencies and I'm sure a well designed project like > boost does not suffer from circular dependencies ;) 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. -- 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: Preliminary submission: command line & config fil e library
> > my_program ( 0, 1) ( 1, 3) (( 0, 1), 15 ), (( 0,1), (7.8) ) > > > This is input of 2 points circle and line. Here chain_lookup_policy could > > be useful. > > What if I want C++ expression specified on the command line? Sure, I don't > want make C++ parser operate on command line. Rather, I'd write > > my_program "f(1, 2) + 10" > > I don't need "chain_lookup_policy" where a couple of quote characters will do. IT doesn't matter weather or not you are using quotes. To parse out Point, Point, Circle, Line out of input above you need chain of responsibilities logic. > I really can't comment further without seeing the code. Ok. I put in vault area some snapshot. I take some not testes functionality out of there. But you should get the feeling. Unfortunately I will be really busy till the middle of February. So may not be able to work on this further meanwhile. It's located here: http://groups.yahoo.com/group/boost/files/cla_framework.zip > No. Does yours? Getting really picky, does yours allows to validate XML > against DTD? In fact yes. My test configuration file look like this: input_message \ \ <> \ <> "expected_output after transformation 1" "cxvbxbxb" "expected_output after transformation 2" "df sdf sdf" Now my test program read test configuration file and feed value of "input_message" parameter to the xerces parser. > - Volodya Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compile-time binary constants
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Fredrik Blomqvist" <[EMAIL PROTECTED]> writes:
>
> > Hi there,
> >
> > I thought I'd forward this little link:
> >
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-CPPCompileTimeBinCons
> > t&forum=totd&id=-1
> > (several improved versions of the initial code appear in the thread)
> >
> > This has most likely been done before but IMO a boostified version using
MPL
> > and PP could
> > actually be a useful convenience utility.
>
>
> 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
> >
> {};
>
cool!
The octal "feature" was also discussed in the link above and a good idea was
to use the PP to _always_ insert a leading zero, eliminating a potentially
very annoying bug..
Secondly, another idea that was presented by Jarkko L. was simply to create
a "mega-enum" something like this:
enum {
b0, b1,
};
enum {
b00, b01, b10, b11,
};
enum {
b000, b001, b010,
}
etcetera...
as I said, quite a few variantions came up in the previous thread, many
along this second version.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: proposal: safe arithmetic class
> From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]] > Sorry for not understanding why "exceptionally creative use > of expression > templates" is necessary :-) Could you > elaborate a little on it? I'll try. :-) We are now talking about (if I understand you and Dave correctly) three related problems and solutions, which poses somewhat different challenges: 0) Partially controlled conversions at compile time and runtime This is the case that is covered by your outline, as well as numeric_cast (at least the hopefully-soon-to-be-reviewed numeric_cast that is part of Fernando Cacciola's Numeric Conversion Library). The cast, or the type, is responsible for preserving ranges when converting between types. For integral constant expressions, invalid conversions are detected at compile time, others are caught at runtime. It's partial control, because expressions such as Int i(100*10) obviously aren't detected. [No expression templates required.] Example: int i1=-42; Int i2=-42; unsigned char c1=boost::numeric_cast(i); UChar c2=i2; 1) Controlled numeric type promotion and conversion This would be needed for safe(r) expressions; the rules for integral promotions, floating point promotions, integral conversions, floating integral conversions, and the usual arithmetic conversions, would be encoded explicitly in types or implicitly in expressions. Unary and binary expressions are handled to produce the correct resulting type; conversions that would lead to loss of precision or range are invalidated, either at compile time or runtime. It is probably a nontrivial task to find consensus on what to allow; for example, should the special rules for unsigned arithmetic be prohibited or not? [No expression templates required here either, but could potentially simplify and add functionality to the implementation.] Example: Int i=std::numeric_limits::max(); Short s=7; UShort us=i+s; // i+s results in a type equivalent to unsigned int, and us is assigned "the least unsigned integer // congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type)" // , i.e. it "wraps around". Should this be legal for this safe type? 2) Complex expression conversion and promotion control If the aforementioned mechanisms for controlling conversions and promotions exist, there is still the matter of more "complex" arithmetic, involving intermediate steps. This is where the expression templates need to enter the arena, because we can no longer simply evaluate the binary operations; we must consider the expression as a whole. If we don't, seemingly equivalent expressions will be treated differently (just as is the case with built-ins): int x=100; int y=100; int z=100; int r=x*y/z; // Probably a negative number, implementation-defined. safe_numeric throws an exception if all variables are safe_numeric. r=x/z*y; // 100. safe_numeric doesn't throw an exception. Of course, the example is too contrived; but when passed as arguments, different variable values (potentially) lead to completely different results (ehrm, they probably should in most cases, but I'm referring to those that should yield the same result...). When adding integral constants to the expressions, such as x*y/3+z%10, expression templates would be used for evaluation and optimization. They'd also be used for evaluating and organizing expressions involving more than one operator. So, it is for this purpose that "exceptionally creative use of expression templates" is needed (of course, my view of exceptionally creative doesn't necessarily correlate with that of others :-)). I don't think all of the above was the intent of your proposal though? (And also, there might be value in a partial solution for detecting errors/problems/strange results at runtime) The three problems stated above seem to have great potential for solutions through class libraries (and unlimited precision types, where art thou?), and my point has been (and is) that 0) is already covered by numeric_cast, and might not need another solution; the others remain open. Bjorn ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] compile-time binary constants
"Fredrik Blomqvist" <[EMAIL PROTECTED]> writes:
> Hi there,
>
> I thought I'd forward this little link:
> http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-CPPCompileTimeBinCons
> t&forum=totd&id=-1
> (several improved versions of the initial code appear in the thread)
>
> This has most likely been done before but IMO a boostified version using MPL
> and PP could
> actually be a useful convenience utility.
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
> (since I also remember the discussions of a roman-number utility for example
> :)
Left as an exercise for the reader ;-)
--
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] compile-time binary constants
Fredrik Blomqvist wrote: > > Hi there, > > I thought I'd forward this little link: > http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-CPPCompileTimeBinCons > t&forum=totd&id=-1 > (several improved versions of the initial code appear in the thread) Nice idea. If you add an operator long() to the class, you can even get rid of the ::value > This has most likely been done before but IMO a boostified version using MPL > and PP could > actually be a useful convenience utility. > (since I also remember the discussions of a roman-number utility for example > :) Well, I cannot say whether or not we really need it, but who cares? ;) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] intel-linux-tools.jam
On Friday 17 January 2003 13:55, David Abrahams wrote: > Toon Knapen <[EMAIL PROTECTED]> writes: > > In intel-linux tools, the link-line first contains -l$(FINDLIBS) and next > > $(NEEDLIBS). Whould'nt it make more sense to revert the order. NEEDLIBS > > typically contains other libs in the same project (==boost) whereas > > FINDLIBS typically contains external and/or system libs. NEEDLIBS is thus > > very likely to depend on FINDLIBS and thus needs to be in front of > > FINDLIBS. > > > > (I remember to have made the same remark about the link-line in > > gcc-tools.jam but still wanted first an 'OK' of everyone involved) > > I think you're right; it's OK with me if you change it. Done. I've also retained only one of the two NEEDLIBS (all libs appeared twice in the link-line). Is that OK ? This would only be necessary in case there would be circulare dependencies and I'm sure a well designed project like boost does not suffer from circular dependencies ;) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Comments on date/time library
Hi, I have just begun to use the boost date/time library and would like to make some comments: Default Construction It would be useful if default constructors for gregorian::date and posix_time::ptime were provided. The default constructors could maybe work as follows: gregorian::date() ==> gregorian::date(not_a_date_time) posix_time::ptime() ==> posix_time::ptime(gregorian::date(not_a_date_time), time_duration(0, 0, 0)) DATE_TIME_INLINE It seems wrong that when using the default build of the date/time library, I have to #define DATE_TIME_INLINE in all compilation units that use the date/time library. Wouldn't it be better to reverse this logic and define DATE_TIME_NO_INLINE only when a non-default build is required? Also, shouldn't this symbol be called BOOST_DATE_TIME_INLINE (or BOOST_DATE_TIME_NO_INLINE :) Building When building the current CVS state with Borland C++ Builder 5, I am still getting all tests and examples built when I only want the library built. Cheers S. __ Inflex - installed on mailserver for domain @status-scientific.com Queries to: [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] intel-linux-tools.jam
Toon Knapen <[EMAIL PROTECTED]> writes: > In intel-linux tools, the link-line first contains -l$(FINDLIBS) and next > $(NEEDLIBS). Whould'nt it make more sense to revert the order. NEEDLIBS > typically contains other libs in the same project (==boost) whereas FINDLIBS > typically contains external and/or system libs. NEEDLIBS is thus very likely > to depend on FINDLIBS and thus needs to be in front of FINDLIBS. > > (I remember to have made the same remark about the link-line in gcc-tools.jam > but still wanted first an 'OK' of everyone involved) I think you're right; it's OK with me if you change 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: any_cast improvement
Unai Uribarri Rodríguez wrote: > Alexander Nasonov wrote: >> Unai Uribarri Rodríguez wrote: >> >>>any_cast, as is implemented in boost 1.29, has one weakness; it doesn't >>>allow to compile this piece of code: >>> >>> any x=int(5); >>> ++any_cast(x) >> >> Boost.dynamic_any has extract functinos which work this way. > > But this patch adds that functionality without breaking the interface. For broken compilers it could break all because remove_reference might not work for them. -- Alexander Nasonov Remove -mycop from my e-mail address for timely response ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] compile-time binary constants
Hi there, I thought I'd forward this little link: http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-CPPCompileTimeBinCons t&forum=totd&id=-1 (several improved versions of the initial code appear in the thread) This has most likely been done before but IMO a boostified version using MPL and PP could actually be a useful convenience utility. (since I also remember the discussions of a roman-number utility for example :) /Fredrik ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cvs web access down?
Sourceforge web and pserver based access to cvs is offline. On Fri, Jan 17, 2003 at 11:41:23AM -, John Maddock wrote: > Is anyone able to connect to > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost ? > > I've been getting: > > Server Error > The following error occurred: > Could not connect because of networking problems. Contact your system > administrator. (CANT_CONNECT) > > for the last few days now. > > John Maddock > http://ourworld.compuserve.com/homepages/john_maddock/index.htm > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cvs web access down?
On Fri, Jan 17, 2003 at 11:41:23AM -, John Maddock wrote: > Is anyone able to connect to > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost ? Sourceforge viewcvs/anoncvs is offline and looks like it will be for some unspecified period regards john -- "We're standing there pounding a dead parrot on the counter, and the management response is to frantically swap in new counters to see if that fixes the problem." - Peter Gutmann ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression test on HP-UX
>It's the run_tests.sh with minor modifs. >I also attached the output. Toon, Your test script has: # # "test_tools" are the Boost.Build toolsets to use for building and running the # regression tests. Specify a space separated list, of the Boost.Build toolsets. # Each will be built and tested in sequence. # test_tools=gcc 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. regards, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fw: compile problems on solaris 2.8
> I don't know. The current CVS uses the Borland configuration for > __BORLANDC__, __IBMC__, __IBMCPP__, __SUNPRO_CC. I assume that __SUNPRO_CC > is the operative symbol here, but I don't know if it's the same compiler or > not. If not, than whatever compiler it is needs to be added to the config > file. Yes, it's __SUNPRO_CC, with boost-1.29.0. Thanks for the help. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] cvs web access down?
Is anyone able to connect to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost ? I've been getting: Server Error The following error occurred: Could not connect because of networking problems. Contact your system administrator. (CANT_CONNECT) for the last few days now. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Equivalence Relation class
Jeffrey Yasskin wrote: I have a small class that uses the union/find algorithm to implement a dynamic equivalence relation. With some work, it could probably also be used to iterate through the equivalent partition. Would this be a good thing to add to boost? Isn't this functionality equivalent to the dynamic connected components in the Boost graph library? Miro ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] intel-linux-tools.jam
In intel-linux tools, the link-line first contains -l$(FINDLIBS) and next $(NEEDLIBS). Whould'nt it make more sense to revert the order. NEEDLIBS typically contains other libs in the same project (==boost) whereas FINDLIBS typically contains external and/or system libs. NEEDLIBS is thus very likely to depend on FINDLIBS and thus needs to be in front of FINDLIBS. (I remember to have made the same remark about the link-line in gcc-tools.jam but still wanted first an 'OK' of everyone involved) toon ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: some thoughts about serialisation
In-Reply-To: <[EMAIL PROTECTED]> On Tue, 14 Jan 2003 15:05:55 -0700 Greg Colvin ([EMAIL PROTECTED]) wrote: > >> > How do you see archive versioning being done? For example, > >> > suppose field TOTAL is a double in version 1 and a > >> > fixed-point user-defined type in version 2. > > One answer is "don't do that." Add a new field which can > be initialized from the old one, and stop using the old one. Adding a new field, with a different name, is what I suggested in the email you're commenting to. Removing the old field isn't an option if it is needed, either for loading old archives, or for interfacing to old Python code (or whatever it is the reflection stuff is used for). -- Dave Harris ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regression test on HP-UX
On Sunday 12 January 2003 13:32, John Maddock wrote: > > Rene, how can I get the aCC compile to work (it's reporting "Missing" the > > whole time as you can see) > > Likely options: > > 1) the HP results aren't being filtered through process_jam_log. > 2) you ran out of disk space and the targets weren't built. > 3) some other bjam invocation problem. > > Can you post the actual script you used to run the tests? It's the run_tests.sh with minor modifs. I also attached the output. run_tests.sh Description: application/shellscript hpux_run_tests.out.gz Description: GNU Zip compressed data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
