Re: [boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
Andrei Alexandrescu [EMAIL PROTECTED] wrote: By the way, could optionalT use variantT, SomeInsipidType as a backend? I suggested that before. Now I think that it is not practical. It can, but it will not be optimal. I see it the other way now. I suggest that a partial specialization of variantT, empty be written that takes advantage of optionalT in its implementation. I think now that the partial specialization of variantT, empty will satisfy the anti-pointer-like crowd. variant seems to have the right interface. Perhaps we were barking up the wrong tree? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
Mat Marcus [EMAIL PROTECTED] wrote:
--On Monday, September 01, 2003 3:37 PM -0300 Fernando Cacciola
[EMAIL PROTECTED] wrote:
Joel de Guzman [EMAIL PROTECTED] wrote in message
One can think of an optionalT as conceptually a specialized but
nevertheless, *IS-A* T, with the added specialization that it can
be in a dead-uninitialized state. Maybe we'll call it a zombie
object, undead object, you name it ;-)
Hmmm. I'm not so sure about this. When I hear the phrase optionalT
IS-A T with an added specialization I am reminded of the phrase a
Square IS-A Rectangle with an added specialization which usually gets
folks into trouble. [Theoretical aside: I still see optionalT as a
sum/union, e.g. T + nil/ T | nil. That is I don't think we really want
A + B B (the sum/union of A and B) to be a subtype of A.]
This is the model that I was trying to *sell* from the very very start when
optional first came out for review. I never really understood why people
didn't see it that way. This is exactly the reason why I suggested looking
at other languages: to be able to get a solid grasp of the concepts behind
such a *thing* so as to be able to answer with utmost certainty the question:
: what is optional?
Some people say it is a container. Not! Some people say it is like a pointer
that can be NULL. Not! And this uncertainty leads us to confusion, and,
ultimately: missguided syntax and semantics.
My attempt to image optionalT as conceptually a specialized but
nevertheless, *IS-A* T, with the added specialization that it can
be in a dead-uninitialized state. Is a feeble attempt to re-sell the idea
of the concept that will be immediately obvious to the OO programmer. I
never really understood why I wasn't able to sell the idea that an
optionalT is *REALLY REALLY REALLY* nothing else but a
union of T and nil.
Here's a question that tries to get to the crux of the pointer-like
interface matter. Should T* and optionalT both be models of a
pointer-like syntactic concept?
Definitely No!
I imagine that those who would answer yes do so because they may want
to write generic code that uniformly handles pointers and possibly
uninitialized variables. Those who answer no to the above question may
prefer to write code that uniformly handles T and optionalT. As you
know, my (current) answer is no. There may be a third group who want
both. The problem is that I find that the pointer-like interface is
distracting, but that may be because I'm unfamiliar with the use-cases
where you might want to handle T*'s and optionalT's uniformly or
even replace raw pointers with optionalT's, since pointers also
bring allocation issues with them. Instead I have been mainly focused
on replacing T's with optionalT's. This is why I gravitate towards
having an optional that models a syntactic concept such as PU that
makes no mention of pointer-like syntax.
I agree 200%. I think the *only* meaningful argument against this
was posed by Brian. That, in C++, you cannot make XT be a
drop-in replacement of T because implicit conversion will not
allow code such as:
struct A { void foo(); }
template class T
void bar(T t) { t.bar(); }
bar(A());
bar(XA()); // HERE
Unless:
class XT : public T {...};
But then again, that's just a technical impediment.
By the way, I would also like to thank you for your work on optional
and your contributions to boost. I also appreciate your open
discussion of the design of optional and optional-like classes. My
posts are just those of a potential user who is interested in finding
the right point in the design space for my needs. If my use cases or
arguments prove useful to others or if optional is influenced to meet
more of my needs, then of course I will be pleased. If not, I'm still
learning about the design space from you and others on this list, so I
benefit either way.
Same here. I would certainly hope to hear more from you. In fact,
I wish to hear more from the type-theory people such as Mat and Vesa
;-)
Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: Direct value accesing via implicit conversion: int i = opt seems wrong because this is the operation that can lead to undefined behaviour. Doesn't have to be undefined behaviour. Yes it does. Accesing a value that isn't there is by all means undefined behaviour. Aren't you throwing an exception or something? This doesn't define the access value operation. It just defines the function that is used to implement it. But defining such a call doesn't help much from the POV of the operation. i.e., you cannot get the value if it isn't there and an exception here is no better at it than a core dump. Wrong! Therefore, the operation is flaged as possibly undefined. Whether to detect and throw, or assert, or do nothing is QoI issue. If optional were to be someday standarized, implementators would decide how to deal with the undefined behaviour here. variant throws throws a bad_get exception when you get a reference to a T which is not the held type. I don't see a problem why you can't do something similar. Pardon me, but you are clearly mistaken! Are you saying that variant's getT(v) leads to undefined behavior? NO! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: optional, tie, and iterator_adaptor
Dave Gomboc [EMAIL PROTECTED] wrote: [Fernando Cacciola] The most fundamental point is that being Haskell a pure functional language there is no possibly undefined behaviour to worry about, so Maybe doesn't need to address this issue as optional does. ... and later ... I account the possibly undefined behavior of accesing an uninitialized optional as a real and important problem. You can get rid of the possibly undefined behaviour by defining it! Throw an exception when there's an attempted coercion from nil/undefined to a normal value. Exactly! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: You did sell the idea that it can be a union, but I held to the idea that it can just as well be considered as *REALLY REALLY REALLY* nothing else but a container that has a T or is empty. I agree there is nothing wrong with the union model, but I don't see why is it better than the other. In fear that this is becoming non-productive and as I've already mentioned that I respect whatever you decide on (I'm satisfied with the optional regardless of its quirks), this will be my final post on the issue. The problem, the way I see it, is that optional mixes at least 3 concepts all at once. First, the concept of variantT, nil, second is the concept of optional as a container and third (I know you disagree, but) pointer- like concept. I understand that the optional started out with the pointer- like concept and moved on to embrace other concepts to satisfy the needs of people who want some features which do not fit quite nicely with the pointer-like concept (e.g. == and != and soon direct assignment?). Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: Point taken. There's no need to argue anymore. I guess significantly more feedback will weight the balance. Thanks for all your comments! It might look the other way around but they were very helpful. Bottom line is, and most importantly, optional gets the job done and it does it really well! :-) FWIW, it's easy to write a wrapper around optional that satisfies our wishes (in fact, I sent a class interface scheme to Dave G. tell me if you are interested). It might also be a nice idea to write a partial-specialization of variantT, empty that takes advantage of the optimizations of optional. Best Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Optional, tie, and iterator_adaptor
David Abrahams [EMAIL PROTECTED] wrote: Joel de Guzman [EMAIL PROTECTED] writes: Now, unlike YACC, Spirit has iteration (kleene, plus, optional) Here's a more or less the complete suite of patterns and the corresponding semantic-action signatures: r ::= a b-F(tupleA, B) r ::= a | b -F(variantA, B) r ::= a* -F(vectorA) r ::= a+ -F(vectorA) r ::= a? -F(optionalA) This is somewhat OT, but I want to suggest you consider something else. I did this in a parser generator system I wrote, and it worked out really well. If the rule is x - a b | c d c Then the way you refer to the semantic value associated with the a symbol is by writing, simply, 'a'. The way you refer to the semantic value of the first c symbol is by writing c[0], and you refer to the 2nd one as c[1]. I'm sure you get the idea. Then the user almost never needs to worry about positional associations between grammar symbols and their semantic values. It's actually fairly rare that the same symbol appears twice on the rhs of a rule (especially when rules are reduced to eliminate |) and keeping track of whether it's the first or nth instance of 'X' is much easier than keeping track of precisely where the Xs fall in the sequence of symbols. My system was written in Python, but you might be able to adapt the general idea to C++. Hmmm, nice! How does it handle iteration like x - a* and the optional x - a? -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Optional, tie, and iterator_adaptor
Brian McNamara [EMAIL PROTECTED] wrote: I should mention in passing that, while in general I think implicit conversions are bad news and should be avoided whenever reasonable, I do think the conversion to bool is an exceptional case, simply because it is already so deeply ingrained in C++ (and C) language/culture. (Fortunately bool has a very narrow interface, so it doesn't get us into too much trouble. Implicit conversions to user-defined types may create arbitrary interface conflicts/conceptual ambiguities, and this is where the real trouble begins.) Perhaps, but we were also taught that operator overloading may create arbitrary interface conflicts/conceptual ambiguities, and this is where the real trouble begins ;-) That may be true in some (many?) contexts, but it is not definitely universally true. As I mentioned in another post, I never had, nor seen, any complaints about reference_wrapperT, which incidentally, has an implicit conversion to T. ref(var) has been in extensive use by a lot of libraries for many years now. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Optional, tie, and iterator_adaptor
Brian McNamara [EMAIL PROTECTED] wrote: On Sun, Aug 31, 2003 at 10:41:15AM -0700, Mat Marcus wrote: also interesting, although I think that readability suffers. I'd give up bool conversion and operator! to avoid the need for ~ if that would reasonably solve the muddling issues. But perhaps there would be too many other problems -- I haven't explored this deeply yet. Right; to clarify, I don't think the boolean conversion operator is interfering with the implicit conversion to T. Rather I think each is an instance of implicit conversion, and implicit conversions just don't work well with templates in general, in my experience. It does interfere with the implicit conversion to T. Consider this: optionalbool o; if (o) foo(o); If you choose implicit conversion to T (which is debatable), the implicit conversion to (safe)bool will have to go: optionalbool o; if (o != none) foo(o); But I see now that you are against implicit conversions, in general. Fair enough. FWIW, I never had, nor seen, any complaints about reference_wrapperT, which incidentally, has an implicit conversion to T. In fact, I find the implicit conversion very useful. Anyway... at the very least, I wish this is possible: optionalbool o; if (o) foo(o.get()); But no, here too, we should write: optionalbool o; if (o) foo(*o.get()); Which goes against existing practice in boost. See reference_wrapper::get, tuple::get, variant::get, etc. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] generic uses of optionalT
Brian McNamara [EMAIL PROTECTED] wrote: On Sun, Aug 31, 2003 at 09:12:59PM -0600, Dave Gomboc wrote: The point is that optionalT is not a T, and most notably, a template function will never perform the coercion. Replace the lines like B b = get2(args); in your example with real calls to, e.g. do_something( get2(args) ) and do_something() is likely to fail if it's a template function (expecting a T and not an optionalT). Okay, you've demonstrated that it may not be possible to drop-in optionalT for T with zero code changes when T is not a scalar type. (Usually, my Ts are! ;-) Nonetheless, it is at least still possible to write generic code that accepts either T or the wrapped T, which is definitely an improvement over writing a whack of special-casing code. Darn! Can't we just overload operator.() operator-dot ? ahemahemcoughcoughcough ;-) I want my proxies! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: generic uses of optionalT
Eric! You DA Man!
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
Eric Friedman [EMAIL PROTECTED] wrote:
Dave Gomboc wrote:
[snip]
I don't like get() because I cannot write x.get() when x is a POD. This
would mean I have to support nilableT and T with different code,
which is exactly what I'm trying to avoid.
Why not overload boost::get again for optional? This would certainly improve
consistency with variant. For instance:
optionalT opt;
...
T r = boost::getT(opt); // throws bad_get if opt empty
T* p = boost::getT(opt); // p is null if opt empty
In the same line, we could make optional visitable:
class my_visitor : public boost::static_visitor {
void operator()(boost::empty) const
{
...
}
void operator()(const T operand) const
{
...
}
};
boost::apply_visitor( my_visitor(), opt );
Support for visitation would also allow seamless integration with the
typeswitch construct I'm working on:
switch_(opt)
= case_boost::empty( ... )
= case_T( ... )
;
I don't have experience with boost::optional, so I don't know how any of the
above would require changes to its interface or concepts.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: First of all, let's not confuse syntax with semantics. optional HAS strict value semantics. No it does not. The accessors have pointer behavior! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: vector::begin returns an object with operators * and -, yet these objects are not pointers, and once that is learned, people do not think they are pointers. Huh? pointer semantics (behavior) does not mean that they have to be pointers. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: Joel de Guzman [EMAIL PROTECTED] wrote in message There's a lot of experience with it in other languages. Why not leverage that? Haskell::Maybe for instance. Do you know of anything else besides Haskell? No. I don't, and I took the time to investigate Maybe looking at Haskell programs using it. As Brian pointed out, it is not so easy to port Maybe to C++ because its usage is extensively supported by Haskell features that are not present in C++. The most fundamental point is that being Haskell a pure functional language there is no possibly undefined behaviour to worry about, so Maybe doesn't need to address this issue as optional does. Agreed. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: Joel de Guzman [EMAIL PROTECTED] wrote in message Direct initialization: opt = 1 seems right since this operation is never undefined. This would mirror variant's interface. Ok. Direct value accesing via implicit conversion: int i = opt seems wrong because this is the operation that can lead to undefined behaviour. Doesn't have to be undefined behaviour. Aren't you throwing an exception or something? variant throws throws a bad_get exception when you get a reference to a T which is not the held type. I don't see a problem why you can't do something similar. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
Fernando Cacciola [EMAIL PROTECTED] wrote: Even if I agree with you that an optionalT should not be a T, an optionalT is definitely not a pointer to T. Definitely! If HTML had blinking banners I think I'd use one to state this :-) Nor should it model a pointer. That was my point and the point of others who dislike *opt. Yet iterators are not pointers either but they do use operators * and - Iterators are not pointers, but they model the pointer. Right. In fact, looking at it more closely, I *could* almost agree with you that an optionalT is not a T. There is in fact a getter function (get). In fact all three (tuple, optional and variant) have a get function. That's fine, yet, here again, the optional does not jive well because it returns access *by pointer* whereas both tuple and variant return access by reference. This get() issue we agree should be fixed. Agreed. If there's a way to get at the values through a generic get function that unifies the access of optional with variant such that I can think of optional as an optimized specialization of variantT, none, I would be very happy. With such an interface, I can simply ignore the pointer-like interface, if you wish to keep it ;-) Thanks you very much! And BTW, kudos for such a well engineered library! Spirit has been using it since v1.7 and I am very happy with it. The comments I gave so far are merely my opinion. You are of course free to have your own preferences :-) Keep up the good work! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Optional, tie, and iterator_adaptor
Gregory Colvin [EMAIL PROTECTED] wrote: On Monday, Sep 1, 2003, at 11:31 America/Denver, Joel de Guzman wrote: Fernando Cacciola [EMAIL PROTECTED] wrote: vector::begin returns an object with operators * and -, yet these objects are not pointers, and once that is learned, people do not think they are pointers. Huh? pointer semantics (behavior) does not mean that they have to be pointers. But would the following hold if p and q are optionlint? *q = 1; p = q; *p = 2; assert(*q == 2); No, because the model is half-baked, which is exactly the reason for my dislike. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Optional, tie, and iterator_adaptor
Daniel Frey [EMAIL PROTECTED] wrote: Joel de Guzman wrote: Although I don't see this as problematic: optionalint x; if (x) foo(x); Or perhaps: optionalint x; if (!!x) foo(x); We already have an implicit conversion to safe_bool and an operator ! anyway. Keep it. There's nothing wrong with it: operator unspecified-bool-type() const; bool operator!() const; IMHO, there is something terribly wrong here because now optionalT has two interfaces. The interface of optional itself and the interface of T. If you think that optionalT can be used like T (having the value-interface), you are immediately fooled by if(x) as it doesn't check T's value. A pointer-interface is much cleaner as it gives the user a hint that he is using a wrapper and in practice, I always prefer to be a little more explicit on these things (even at the cost of an occasional * here and there) than to have silent bugs. If you really want it to be explicit, the first version, which I prefer (and you snipped ;-) is so much better: optionalint x; if (x != none) foo(x); Who's fooling who? You said 2 interfaces, the current optionalT is actually the one with the 2 interfaces. In some ways, it has a value interface (construction, reset , ==, !=) and pointer interface on some (*, -, get). What I am trying very hard to say is to stick to only *ONE* interface and one concept. Syntactically, there's nothing inherently wrong with: if (x) foo(x); We see it all the time with ints: int x; if (x) foo(x); Yet, I have to admit that after thinking about it some more, I realized an ambiguity when T is bool. Example: optionalbool x; if (x) foo(x); That is why I really prefer the more explicit syntax: optionalint x; if (x != none) foo(x); A small price to pay, considering the advantages. 1) Unification of the optional and variant where optionalT -- variantT, none_t. 2) Only one underlying semantics (value-semantics) as opposed to (sometimes value, sometimes pointer semantics) and 3) Plays well with generic code (I'll give another use-case in addition to Mat's). -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Spirit question...CORRECTION to my grammer!
Chris,
Spirit has its own mailing list:
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Please post further questions there. Thanks.
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
Chris Cooney [EMAIL PROTECTED] wrote:
Hello,
I've been fiddling around with boost::spirit in an
attempt to write a small and esoteric scripting language.
Here's some code snipits of what I'm trying to do.
example script (a one liner in this case):
DO_SOMETHING(param1,param2)
the grammer:
struct my_grammer : public grammarmy_grammer
{
my_grammer(vectorstring v_): v(v_) {}
template typename ScannerT
struct definition
{
definition(wb_grammer const self)
{
//char token defs
COMMA = ch_p(',');
LPAREN = ch_p('(');
RPAREN = ch_p(')');
USCORE = ch_p('_');
param_alnum = lexeme_d[alpha_p *(alnum_p)];
do_something = str_p(DO_SOMETHING) LPAREN
/*param1*/param_alnum[append(self.v)] !COMMA
/*param2*/param_alnum[append(self.v)] RPAREN;
do_something_else = str_p(DO_SOMETHING_ELSE) LPAREN
/*param1*/param_mode[append(self.v)] !COMMA
/*param2*/param_type[append(self.v)] RPAREN;
functions = do_something | do_something_else;
}
ruleScannerT
COMMA,LPAREN,RPAREN,USCORE,param_alnum,do_something,do_something_else,functi
ons;
ruleScannerT const
start() const { return functions; }
};
vectorstring v;
};
int main()
{
vectorstring v;
my_grammer script_grammer(v);
string str;
while (getline(cin, str))
{
parse_info info = parse(str.c_str(), script_grammer, space_p);
if (info.full)
{
//determine which rule (script function) was called
//and do something with the parameters stored in the vector
}
else
{
//error out.
}
}
}
problem:
My problem is how to determine which rule was the one
that resulted in a successful parsing of the
line (DO_SOMETHING(param1,param2));
NOTE: I'm unfortunately stuck with the MSVC 7.0 compiler so
I can't use the Tree functionalities of spirit because of their
implementations use of partial template specialization.
any ideas?
Thank you very much,
Chris.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [boost.optional boost.variant] Why can't weallowreferences?
David Abrahams [EMAIL PROTECTED] wrote: Joel de Guzman [EMAIL PROTECTED] writes: optionalT::reset ( T const ) ; Does it matter what happens when T is an auto_ptr? Hmmm, an optional auto_ptr. What an interesting mix. Well, I'm not sure. Fernando? -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [boost.optional boost.variant] Why can't weallowreferences?
David Abrahams [EMAIL PROTECTED] wrote: Jaakko Jarvi [EMAIL PROTECTED] writes: I've noticed that call_traits doesn't support function references. I'm not sure whether it makes sense to store function references in optionals, though, but in any case. Something like this fails: typedef void (afuncref)(int); typedef call_traitsafunc::reference t; The problem is that the call_traits templates have other typedefs in the same class, e.g. const_reference, which gets instantiated as well, and it adds the const qualifier to a function type. Just another reason not to write degenerate traits BLOB metafunctions. call_traits, if it's useful for anything (which I sometimes wonder about because I have a hard time figuring out what it does), should be rewritten as separate individual metafunctions. FWIW, I find it a useful utility. However, I agree that it should be broken down into individual pieces. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: Spirit question...CORRECTION to my grammer!
Chris Cooney [EMAIL PROTECTED] wrote: Sorry everyone. Hey, no need for apologies :o) -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [boost.optional boost.variant] Why can't weallowreferences?
Fernando Cacciola [EMAIL PROTECTED] wrote: I'm way overprotective, I guess (maybe it's because I'll be father for the first time in a couple of months :-) Congratulations! The only remaining issue is the optional interface: Currenty, there is the following: optionalT::optional ( T const ) ; optionalT::reset ( T const ) ; But If 'T' is allowed to be a reference, then these should have to be changed to: optionalT::optional ( T ) ; optionalT::reset ( T ) ; I think reset should be: optionalT::reset ( T const ) ; Following reference assign semantics, an optional reference once bound cannot re-bind to another reference. So, we can be able to: int i; optionalint opt(i); opt.reset(3); // same as i = 3 Which is similar to: int i; int r = i; r = 3; // same as i = 3 I think this is a big difference of semantics to T*. We can only bind an optional reference at construction time. This is an advantage to a plain T* because we are assured that no rebinding will take place. Thus, I have to disagree that we would never explicitly use optionalT. I think there's merit in its usage too. the question is, what should be the 'conceptual' signature of these functions? (how should they be documented). The same goes for operator*(). For non-reference types, it is: T operator*(); but for reference types, is has to be: T operator*(); Anyway, this issues are the same for tuples, so whatever it was done there it can be done with optional. How about: typedef typename call_traitsT::param_type ctor_param; typedef typename call_traitsT::param_type assign_param; typedef typename call_traitsT::reference return_type; optionalT::optional(ctor_param arg); optionalT::reset(assign_param arg); return_type operator*(); I think that's pretty good documentation in and by itself. It might also be a good idea to make the return type part of the public API. Sometimes, we want to have temporaries, e.g. to circumvent the function forwarding problem. Example: optionalT::return_type v = *opt; a_func_accepting_a_reference(v); Many thanks! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [boost.optional boost.variant] Why can't weallowreferences?
Hi again, Take 2: typedef typename call_traitsT::param_type ctor_param; typedef typename call_traitstypename remove_referenceT::type::param_type assign_param; typedef typename call_traitsT::reference return_type; optional(typename call_traitsT::param_type arg); void reset(assign_param arg); return_type operator*(); I think reset should be: optionalT::reset ( T const ) ; Following reference assign semantics, an optional reference once bound cannot re-bind to another reference. So, we can be able to: int i; optionalint opt(i); opt.reset(3); // same as i = 3 Which is similar to: int i; int r = i; r = 3; // same as i = 3 I think this is a big difference of semantics to T*. We can only bind an optional reference at construction time. This is an advantage to a plain T* because we are assured that no rebinding will take place. Thus, I have to disagree that we would never explicitly use optionalT. I think there's merit in its usage too. the question is, what should be the 'conceptual' signature of these functions? (how should they be documented). The same goes for operator*(). For non-reference types, it is: T operator*(); but for reference types, is has to be: T operator*(); Anyway, this issues are the same for tuples, so whatever it was done there it can be done with optional. How about: typedef typename call_traitsT::param_type ctor_param; typedef typename call_traitsT::param_type assign_param; typedef typename call_traitsT::reference return_type; optionalT::optional(ctor_param arg); optionalT::reset(assign_param arg); return_type operator*(); I think that's pretty good documentation in and by itself. It might also be a good idea to make the return type part of the public API. Sometimes, we want to have temporaries, e.g. to circumvent the function forwarding problem. Example: optionalT::return_type v = *opt; a_func_accepting_a_reference(v); Many thanks! -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [boost.optional boost.variant] Why can't weallowreferences?
Joel de Guzman [EMAIL PROTECTED] wrote: Hi again, Take 2: typedef typename call_traitsT::param_type ctor_param; typedef typename call_traitstypename remove_referenceT::type::param_type assign_param; typedef typename call_traitsT::reference return_type; optional(typename call_traitsT::param_type arg); void reset(assign_param arg); return_type operator*(); Whoops! That should be: optional(ctor_param arg); void reset(assign_param arg); return_type operator*(); Anyway, it's the same. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Spirit question...
David B. Held [EMAIL PROTECTED] wrote: Chris Cooney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] That was my problem - thank you. The moral being: Using anychar_p all by itself is usually a Bad Thing(TM) More accurately: Using *anychar_p or +anychar_p all by itself is usually a Bad Thing(TM) That's because it's like the langoliers--it eats everything up. You usually want to say what it shouldn't eat up by subtracting the terminating character from the parser. I think this is a Spirit FAQ. It is now ;-) -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [boost.optional boost.variant] Why can't we allowreferences?
pardon me if this gets re-posted Hi, Is there a reason why we can't allow: optionalint opt; Also, is there a reason why we can't allow: variantint, double var; IIUC, internally, it's just a matter of storing a boost.reference_wrapper if T is a reference. In as much as tupleint is allowed, I see no reason why optional and variant can't allow references. Am I missing something? TIA, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI/GDI template library
E. Gladyshev [EMAIL PROTECTED] wrote: The notus project has been setup on sf. http://sourceforge.net/projects/notus It has several public forums including the Design forum. No mailing list? IMO, I would highly suggest a mailing list instead of a web based forum. Easier to post-to, maintain, archive, etc. -- Joel de Guzman joel [at] boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
Beman Dawes [EMAIL PROTECTED] wrote: At 10:54 AM 8/5/2003, Brock Peabody wrote: I don't know much about other GUI systems but win32 and MFC. I think we can try to define the low-level layer using win32 and/or MFC as the starting point. If we cover these two, it'll be a good start and prove of concept. Actually for a proof of concept we could get by with just one. Given the major differences between underlying GUI API's, your really need to be developing in parallel for both Windows and Linux right from the start. And don't forget the Mac ;-) -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
Gregory Colvin [EMAIL PROTECTED] wrote: Perhaps Perseus, who slew the Medusa, the snake-haired monster of so frightful an aspect that no living thing could behold her without being turned into stone. Perseus avoid being turned to stone by clever use of indirection -- he avoided looking directly at Medusa, instead looking only at her reflection in the mirror of his polished shield. http://www.online-mythology.com/perseus_medusa/ Man! You Da Man! :-) -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] GUI/GDI template library
E. Gladyshev [EMAIL PROTECTED] wrote: --- Brock Peabody [EMAIL PROTECTED] wrote: It stands for 'standard'. Maybe that's a little pretentious for us at this early stage :) gtl would probably be better. I suspect that if we get to a review some people may request something more verbose. Since GTL is already taken, how about GTF (GUI Template Framework)? Can't we be more imaginative than that? Aren't we all already saturated with acronyms and acronyms and yet more acronyms? There is no policy anyway that forces us to use acronyms in boost. When Spirit was being reviewed, I was a bit afraid that someone would come out and suggest that it be named as BPL. Akkk! Fortunately, no one did. And after all, BPL already stands for boost python library. In the world of computers, it is already a sea of acronyms. IMO, acronyms are ugly! This is my opinion of course. I am entitled to my own opinion right? :-) bicycle-shed-ingly-yrs, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: GUI sublanguage ?
Brock Peabody [EMAIL PROTECTED] wrote: Have you invented universal algorithm for window size/position ? It works surprisingly well. I know I described it in detail in an earlier post, I can sum it up again if you like. It works well especially if you need complete resizability. Please do. I've lost track of the thread and I want to catch up. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preparing 1.30.1 Release
David Abrahams [EMAIL PROTECTED] wrote: I have put a diff of the changes between Version_1_30_0 and RC_1_30_0 at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be the changes that go into the Boost 1.30.1 release. Will the authors/maintainers of the following libraries please post a brief summary of the fixes that were applied? smart_ptr lexical_cast function lambda MPL type_traits workaround (that's me) Python (me again) error_handling.html (again, me) Hi Dave, I'd like to add Spirit 1.6.1 (a bug fix release) to Boost 1.30.1. There are no new features in 1.6.1, just bug fixes. Here are the list of bug fixes. a.. Fixed. Using MSVC++6 (SP5), calling the assign action with a string value on parsers using the file_iterator will not work. b.. Fixed: using assign semantic action in a grammar with a multi_pass iterator adaptor applied to an std::istream_iterator resulted in a failure to compile under msvc 7.0. c.. Fixed: There is a bug in the range_runCharT::set (rangeCharT const r) function in the boost\spirit\utility\impl\chset\range_run.ipp. d.. Fixed: handling of trailing whitespace bug (ast_parse/pt_parse related) e.. Fixed: comment_p and end of data bug f.. Fixed: Most trailing space bug: g.. Fixed: chset::operator~(range) bug operator(chset, range) bug operator(range, chset) bug h.. Fixed: impl::detach_clear bug i.. Fixed: mismatch closure return type bug j.. Fixed: access_node_d[] and access_match_d[] iterator bugs k.. Fixed a bug regarding threadsafety of Phoenix/Spirit closures. l.. Added missing include files to miniboost I am about to commit Spirit 1.6.1 to the RC_1_30_0 but wanted to ask anyway. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Preparing 1.30.1 Release
David Abrahams [EMAIL PROTECTED] wrote: Joel de Guzman [EMAIL PROTECTED] writes: I'd like to add Spirit 1.6.1 (a bug fix release) to Boost 1.30.1. There are no new features in 1.6.1, just bug fixes. Here are the list of bug fixes. [snip] I am about to commit Spirit 1.6.1 to the RC_1_30_0 but wanted to ask anyway. Thanks for asking. Normally, I'd say absolutely not. We announced we were starting this release a while back and said that there would be only minimal changes required to fix bugs which could reasonably be applied in a week. That week is long past. However, since, like Boost.Python, Spirit doesn't appear in the regression tests (we've got to fix that) and no libraries depend on it (right?), you can't hurt the regression results by upgrading Spirit to 1.6.1. You may proceed if you can do it in an hour or less. Commencing. I should be finished in a couple of minutes. Actually, the bug fixes we're done and 1.6.1 was released before the announcement. The release has been thoroughly tested. I'm confident the commit will not hurt anything. Thanks for the consideration. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preparing 1.30.1 Release
Martin Wille [EMAIL PROTECTED] wrote: Joel de Guzman wrote: l.. Added missing include files to miniboost For the records: that one doesn't apply to Boost 1.30.1. Yes that's correct. Sorry. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Spirit rules
Kai-Mikael Jää-Aro [EMAIL PROTECTED] wrote: Joel de Guzman wrote: Kai-Mikael Jää-Aro [EMAIL PROTECTED] wrote: I obviously have not understood how spirit rules are supposed to work. The simple program below fails to compile (spewing out 42 lines of error messages). If I replace the application of 'Id' with int_p directly it works OK. What am I supposed to do to get the intended effect? [snip] See the FAQ The Scanner Business. It's always a good idea to scan the FAQ first. I have read, but not understood. I change the rule to rulephrase_scanner_t, but I am still not allowed to perform the assignment. I suspect that I am supposed to supply further arguments to the rule in order to specify its return type so that the assignment gets properly interpreted, so I have carefully gone through the manual pages for The Rule, Semantic Actions and Predefined Actions, with quick dips into other sections, but I have not found examples of how to do it. Hi again, Would this solve your problem? int ID; rulephrase_scanner_t Id = int_p[assign(ID)]; parse(argv[1], Id space_p); BTW, did I mention that Spirit has its mailing list? [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spirit-general HTH, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Spirit rules
Kai-Mikael Jää-Aro [EMAIL PROTECTED] wrote:
I obviously have not understood how spirit rules are supposed to work. The
simple program below fails to compile (spewing out 42 lines of error
messages). If I replace the application of 'Id' with int_p directly it works
OK.
What am I supposed to do to get the intended effect?
#include iostream
#include boost/spirit.hpp
using namespace std;
using namespace boost::spirit;
int main(int *argc, char *argv[])
{
int ID;
rule Id = int_p;
if (parse(argv[1],
Id [assign(ID)],
space_p).full)
{
cout Value = ID endl;
}
else
{
cout Failed\n;
}
}
Hi,
See the FAQ The Scanner Business. It's always a good idea
to scan the FAQ first.
BTW, Spirit has its own mailing list:
Spirit-general mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Cheers,
--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: N1477 Single Pass Iterators and *r++
David Abrahams [EMAIL PROTECTED] wrote: Joel de Guzman [EMAIL PROTECTED] writes: Beman Dawes [EMAIL PROTECTED] wrote: In the main CVS? iterator-categories.html is still dated several days ago. Or am I looking in the wrong place? I guess so. Why would I be editing a document in the multi_array lib? I was talking about boost-root/libs/iterator/doc/iterator-categories.html, committed July 7 by Joel. That is the document I was expecting to see updated. Oh, I never saw that. Joel, it's inconvenient to have the .html file with a different name from the .rst file. Is there any reason we can't change that so they're both named new-iter-concepts.xxx? I didn't put those. Those files were taken from the sandbox as-is. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_nan
Gabriel Dos Reis [EMAIL PROTECTED] wrote: Joel de Guzman [EMAIL PROTECTED] writes: Fernando Cacciola [EMAIL PROTECTED] wrote: Gabriel Dos Reis [EMAIL PROTECTED] wrote in Yes. It is an incorrect (unfortunately popular) implementation. Right. We should say that more often. It is incorrect however popular. Most compilers provide a non standard extension for this purpose. For instance, Borland uses _isnan. In general, these extensions are found on float. The best approach, IMO, is to have a boost::is_nan() with compiler specific implementations. Hi, We have an is_nan(float) implementation (for quiet NaNs of course) that does just that. Right now, it supports most compilers on Win32 but it should be straight-forward to support others. Right now, it is tested on: g++2.95.3 (MinGW) g++3.1 (MinGW) Borland 5.5.1 Comeau 4.24 (Win32) Microsoft Visual C++ 6 Microsoft Visual C++ 7 Microsoft Visual C++ 7.1 Metrowerks CodeWarrior 7.2 The default implementation assumes IEEE754 floating point. It takes advantage of the fact that IEEE754 has a well defined binary layout for quiet NaNs. I'm not sure what you mean by that. IEEE-754 defines an *abstract* binary model, not a concrete one. And the exact mapping to concrete implementation is NOT defined. That is not what I call a well defined binary layout. Yes of course. What's important is that it defines the bits of what constitutes a NaN, b[0] .. b[N] and we can create a mapping from bits 0..N of the abstract binary model to the actual (concrete) binary layout of a platform/processor. For example on HP boxes, the concrete binary layout of qNaNs and sNaNs is flipped (in the leading bits) from those of SPARCs. Yes, both have IEEE-754 conforming representations. There are many other variants. (I learnt those when I tried to get compiler support for numeric_limits in GCC). Those who are interested might want to have a look at gcc/real.[hc]. Nice. Thanks for the tip. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Spirit v1.7.0 and v1.6.1 Released
Hello, Spirit v1.7.0 and v1.6.1 have been released. Get it here: Spirit v1.7.0: http://tinyurl.com/gssn Spirit v1.6.1: http://tinyurl.com/gsss Take note that by convention, odd minor version releases (e.g. 1.7.0) are developmental while even minor version releases (e.g. 1.6.1) are stable. What's new: http://spirit.sourceforge.net/distrib/change_log.html Have fun!!! Cheers, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
David Abrahams [EMAIL PROTECTED] wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: IMO we should just stop using 'void_' for internal purposes and give it up to users :). I am still unsure about 'void_' being better than 'nil' or 'null' Users already have a type, 'void', which means void. There's no correspondence between void_ and void the way there is between bool_ and bool. IMO, there is. For example, the new TR1 tuples implementation (it's feature complete and in the sandbox now BTW) uses void_ as it would a void tuple element. nil_t or something would do, but we'll need to convert this to void_ simply because MPL expects void_. Admittedly, the void_ is not part of its public API and the use should not care about it, *but* you have to consider that the tuple lib *IS* a client of MPL. As such, it needs the mpl_void_ as a *public* API. Another good example is Phoenix/LL. We are using void_ much as a void argument to something. Here now, there is a direct mapping to our C++ void. Again, the void_ is not part of Phoenix's public API but then again, it *is* a client of MPL. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: N1477 Single Pass Iterators and *r++
Beman Dawes [EMAIL PROTECTED] wrote: In the main CVS? iterator-categories.html is still dated several days ago. Or am I looking in the wrong place? I guess so. Why would I be editing a document in the multi_array lib? I was talking about boost-root/libs/iterator/doc/iterator-categories.html, committed July 7 by Joel. That is the document I was expecting to see updated. Wouldn't it be better to bring the Boost CVS libs/iterator/doc stuff up-to-date? Particularly since there is no index.html in libs/iterator pointing to other locations. This is really what I intend to do. However, I'm having some difficulties with my net connection right now. If anyone would be so kind to link in the docs, I would appreciate it very much. Regards, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New iterator adaptors and bjam builds
David Abrahams [EMAIL PROTECTED] wrote: Jens Maurer [EMAIL PROTECTED] writes: May I suggest that you remove (for example) (ALL_LOCATE_TARGET)/status/bin/transform_iterator_example.test No wonder! That's not the utility suite; that's the iterator_adaptors suite. Mostly an easy fix. There are already replacement tests in libs/iterator/test. Yep, I'll remove these artifacts. Pardon the confusion. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: New iterator adaptors and bjam builds
Beman Dawes [EMAIL PROTECTED] wrote: At 01:27 PM 7/11/2003, David Abrahams wrote: Jens Maurer [EMAIL PROTECTED] writes: There seem to be a number of files in boost-root/libs/utility that are holdovers from the prior version of iterator adaptors. I'll fix this situation. Is the plan to remove all iterator related files from boost-root/libs/utility and replace them with files in boost-root/libs/iterator (or its sub-directories)? Yes. That's the plan, AFAIK. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_nan
Fernando Cacciola [EMAIL PROTECTED] wrote: Fernando Cacciola [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks to Gabriel we may have an is_nan() right now. Oops! It was Joel de Guzman who offered his is_nan() implementation. Sorry Joel :-) No problem. I thought Gaby also offered an implementation ahead of me. So you guys are interested then? It would really be nice to have a common boost implementation. I'll put it in the sandbox tomorrow. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Visitor-based framework to describe classes with exampleofobjectdump in XML format
Alexander Nasonov [EMAIL PROTECTED] wrote:
From user point of view it's easy. Every class is described using intuitive
class-decl-like style:
void describe_Driver(descriptorDriver class_)
{
class_(Driver).derived_fromPerson()
[
member(Driver::licence_id, licence_id), // note comma operator
member(Driver::licence_issue_date, licence_issue_date)
];
}
Cool syntax! Hmmm Reminds me of Boost.Python, luabind and ahem... Phoenix ;-)
--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_nan
Fernando Cacciola [EMAIL PROTECTED] wrote: Gabriel Dos Reis [EMAIL PROTECTED] wrote in Yes. It is an incorrect (unfortunately popular) implementation. Right. We should say that more often. It is incorrect however popular. Most compilers provide a non standard extension for this purpose. For instance, Borland uses _isnan. In general, these extensions are found on float. The best approach, IMO, is to have a boost::is_nan() with compiler specific implementations. Hi, We have an is_nan(float) implementation (for quiet NaNs of course) that does just that. Right now, it supports most compilers on Win32 but it should be straight-forward to support others. Right now, it is tested on: g++2.95.3 (MinGW) g++3.1 (MinGW) Borland 5.5.1 Comeau 4.24 (Win32) Microsoft Visual C++ 6 Microsoft Visual C++ 7 Microsoft Visual C++ 7.1 Metrowerks CodeWarrior 7.2 The default implementation assumes IEEE754 floating point. It takes advantage of the fact that IEEE754 has a well defined binary layout for quiet NaNs. Platform specific implementations forward the call to the correct platform header when available. The code does not rely on the availability of numeric_limits. I hope this can be used as the basis of a standardized boost::is_nan utility. Thoughts? -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: New Iterator Adapters - filter_iterator
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I was under the impression that Dave is gonna move it to the main trunk real soon, so keeping it on your local disk for a few more days might be the easiest solution. Dave? I'm on vacation until the 6th at least. Joel volunteered to make that move, though I'm not sure what his schedule looks like. If he's bitten off more than he can chew I may jump in to help out. Joel? I'm cool. Let's do it. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Draft of new Boost Software License
Andreas Huber [EMAIL PROTECTED] wrote: || What about html files? Are they considered to be under || the the Software umbrella? Html or any other form of || electronic documentation can be seen as software but you || could just as well argue that it's only data (which || AFAICT would not fall under the license then). Software can be purely data, right? The documentation IMO, should be part of the Software. || BTW, I (German mother-tongue) agree with Rene that the || long sentences are a bit difficult to grasp. However, I || don't care that much as long as it's legally || bullet-proof. I agree. Kudos to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen! Cheers, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] A problem concerning msvc++ and boost::spirit::phoenix
Yep. Anyway, VC7.1 (VS 2003) is a joy to use with Spirit.
We've tried our best to make Spirit work with VC6. See:
http://spirit.sourceforge.net/wiki/index.php?page=Compiler+Table
Most of the modules, except the ones that use Phoenix,
works with VC6 and 7. Notice though how VC7.1 scores!
--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
Michael Walter wrote:
Visual C++ 6.0 doesn't support partial template specialization.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of DudeSan
Sent: Thursday, June 19, 2003 3:27 PM
To: [EMAIL PROTECTED]
Subject: [boost] A problem concerning msvc++ and
boost::spirit::phoenix
While I was playing around with spirit yesterday, I stumbled on
something nasty. I'm not sure if this is the right place to report
this
but I'll post it here anyway :)
I found a calculator example
(http://www.oreillynet.com/network/2003/05/06/examples/calculatorexample
.html) which includes boost/spirit/phoenix/tuples.hpp (not directly
but via boost/spirit/phoenix/binders.hpp).
Here I found the first occurrence; it seems that the Visual C++ 6.0
compiler doesn't see the difference between
template typename T
struct access {
typedef const T ctype;
typedef T type;
};
and
template typename T
struct accessT {
typedef T ctype;
typedef T type;
};
It reports template class has already been defined as a non-template
class, so it seems that 'template typename T struct access' isn't
being recognized as a template class.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Spirit example typo
Michael Walter wrote: In http://www.boost.org/libs/spirit/doc/number_list.cpp.html, using namespace spirit should read using namespace boost::spirit; I think. Apologies if this is the wrong list for such an unimportant report ;) Hey, Thanks! -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [C++-sig] Re: Interest in luabind
David Abrahams wrote: [ snip [] syntax ] * We like the syntax :) It is nice for C++ programmers, but Python programmers at least are very much more comfortable without the brackets. FWIW, I like the syntax ;-) But then of course I'm biased :o) Regards, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: optional: size optimization
Fernando Cacciola wrote:
padding 100%, but which will be quite easy to use is this:
templateclass T, class tag_t
struct aligned_storage
{
void const* address() const ;
void* address();
// If tag_t fits in the padding, it is allocated there,
// else it is allocated separately (but in here)
tag_t const tag() const ;
tag_t tag();
}
Funny, that was my first prototype :o)...
Yes, that's very good, if it's possible to implement
I was concerned about, emmm..., alignment issues.
I reckon tag_t type should be enforced to be an integral
of some size.
--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: const T const and C++98
Reece Dunn wrote: construct when passing values. This was because I had been looking at the spirit library and read T const ref; as T const ref; To be clear, Spirit's convention is T const ref. Cheers, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] PP lambda?
Paul Mensonides wrote: Joel de Guzman wrote: And that takes all the fun out of it. pp-metaprogramming and indeed template metaprogramming, given the current language, is all about _manipulation_ of the language. If you take that away, it is still very useful, but not as creative, therefore, not as fun. ;) It would be nice to experiment on new features such as scopes and true iteration. I think it is also a good idea to *push* the CPP specifications with the future in mind. A scoping mechanism is already in being considered (FYI, precisely because it *limits* the preprocessor). Scope, IMO, should be the first priority. For one, I would certainly wish to see the BOOST_PP prefix a thing of the past. I always get a mild headache trying to grok Boost.PP expressions. ... Here's a possible syntax (quoted from CLC++M). I'm sure many of you are already aware of this, nevertheless... Francis Glassborow wrote: In message [EMAIL PROTECTED], James Kanze [EMAIL PROTECTED] writes And although it might sound a bit heretical -- the lack of a preprocessor, or any other means, of making logging and tracing as simple as possible. Not heretical these days. We spent time earlier this week in the evolution group of WG21 J16 considering ways to take control of the pre-processor to make it work well in C++. Our current thinking is to add something like: # // no preprocessor macros can permeate this barrier // unless explicitly asked for #import XYZ // allow that macro through #define ABC 123 #define FALSE 0 ... #export FALSE # // only explicitly exported macros escape IOWs create a mechanism to control the scope of pre-processor macros. Hmmm how about namespaces (or modules) ? :o)... # BOOST_PP // boost PP namespace // blah blah blah # # MY_MODULE // my module namespace #using BOOST_PP // using boost PP namespace // blah blah blah # Regards, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [lambda]/[spirit-phoenix] Lazyevaluation+expressiontemplates
Fernando Cacciola wrote: Hi, First question: I see that there is a phoenix subdirectory under both boost/spirit and lib/spirit; does this mean that pheonix is distributed with boost 1.30.0? or only part of it? There will be an LL/Phx merger. I hope it will be soon. That depends a lot on which is the least compiler to support. Right now, I have the core up and running on VC7 but ICEs on VC6. Either I leave VC6 behind (now that 7.1 is imminent), or I spend more time hunting by trial and error. The new LL/Phx merger is MPL based. BTW, Borland works as it does in Phoenix as do a lot more compilers: http://spirit.sourceforge.net/wiki/index.php?page=Compiler+Table So the question is *to-vc6-or-not-to-vc6*, please send in your votes. Second question: I'm trying to do something which I think could be done with some of the functional programming libraries and tools available here at boost, perhaps in combination with other tools from elsewhere. [snip] Ah..Lazy-evaluation... This was asked in the past. Phoenix named placeholders: Phoenix+boost::function :-)... This link might be of interest to you: http://article.gmane.org/gmane.comp.parsers.spirit.general/3393/match=placeholder+cpp This feature will hopefully, if Jaakko agrees, be part of the new merger. I'm heavily investigating *true* lazy evaluation, not to be confused with partial evaluation that's currently done in LL and Phoenix. To avoid confusion, I should change everything lazy in the Phx docs to probably be deferred. These are subtly different concepts. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] spirit::rule::set_id()
Hi Jon, Ok. I'll ask the tree-people (Dan and Hartmut :-) This is their domain... BTW... Please post follow ups to Spirit-general mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spirit-general Thanks! -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net Jon Wray wrote: Sorry, I'm refering tree_node::value.id().to_long(). The token_node_d directive in the code below creates these nodes, and stores the associated rule id in them. The rule id being stored changed when I upgraded to the latest version of Spirit. Please reread my message below with this context in mind. Thanks, Jon -Original Message- From: Joel de Guzman [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 3:58 AM To: Boost mailing list Subject: Re: [boost] spirit::rule::set_id() Jon Wray wrote: Thanks! I noticed that this change leads to different behavior when assigning rules. Consider this code: typename rule_ScannerT, IDENTIFIER::type Identifier; typename rule_ScannerT, FUNCTION::type Function; typename rule_ScannerT, PREDICATE::type Predicate; typename rule_ScannerT, VARIABLE::type Variable; Identifier = lexeme_d[token_node_d[(alpha_p | '_' | '$') *(alnum_p '_' | '$')]]; Function = Identifier; Predicate = Identifier; Variable = Identifier; value.id().to_long() used to return FUNCTION, PREDICATE, or VARIABLE, but it now returns IDENTIFIER. [snip] Huh? AFAICT, Function.id() == FUNCTION, Predicate.id() == PREDICATE and Variable.id() == VARIABLE. I tested this... rulescanner, parser_context, parser_tag1 r1; rulescanner, parser_context, parser_tag2 r2; r1 = r2; assert(r1.id() == 1); assert(r2.id() == 2); What am I missing? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
Douglas Paul Gregor wrote: BoostBook is nearing the point where building documentation is as easy as building libraries. The Boost.Build v2 modules for BoostBook (and associated tools) are quite functional and work well for me, but I want to verify the they will work well for someone else. I would like a volunteer to try out the BoostBook tools to see if they can easily build documentation, and report your successes, failures, and general level of frustration to the Boost documentation list or to me personally so I can improve the situation for future users and developers. You'll need a few tools, a very recent checkout of Boost CVS, and possibly a little patience, but everything is explained (I hope) in the Getting Started guide here: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ Any takers? Please? Spirit desperately needs a reference manual. Yes, I'm very interested. I am also very interested to build Spirit based tools to make the task easier. I'm just afraid of the time that I need to commit. Perhaps I can proceed step-wise? Suggestions? -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BoostBook] Guinea pig request
Douglas Paul Gregor wrote: FWIW, the basic Jamfile.v2 for using Doxygen would be: project boost/spirit/doc ; import boostbook : boostbook ; import doxygen : doxygen ; doxygen spirit.doxygen : ../../../boost/spirit/ : recursiveon pattern*.hpp ; boostbook spirit : spirit.doxygen ; With a patched Doxygen (see the Getting Started docs) and this Jamfile.v2 in libs/spirit/doc, I can generate skeletal documentation for Spirit. Cool. I'll try this. Thanks! It seems you have lots of guinea pigs now :-) -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] spirit::rule::set_id()
Jon Wray wrote: Thanks! I noticed that this change leads to different behavior when assigning rules. Consider this code: typename rule_ScannerT, IDENTIFIER::type Identifier; typename rule_ScannerT, FUNCTION::type Function; typename rule_ScannerT, PREDICATE::type Predicate; typename rule_ScannerT, VARIABLE::type Variable; Identifier = lexeme_d[token_node_d[(alpha_p | '_' | '$') *(alnum_p '_' | '$')]]; Function = Identifier; Predicate = Identifier; Variable = Identifier; value.id().to_long() used to return FUNCTION, PREDICATE, or VARIABLE, but it now returns IDENTIFIER. [snip] Huh? AFAICT, Function.id() == FUNCTION, Predicate.id() == PREDICATE and Variable.id() == VARIABLE. I tested this... rulescanner, parser_context, parser_tag1 r1; rulescanner, parser_context, parser_tag2 r2; r1 = r2; assert(r1.id() == 1); assert(r2.id() == 2); What am I missing? -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] spirit documentation bug
Dave Gomboc wrote: Section Portability 8. Intel 7.0VisualAge C++ 5.02 should be split into two lines. Thanks for the various doc-bug reports. Duly noted. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] spirit::rule::set_id()
Jon Wray wrote:
What happened to spirit::rule::set_id()? It was in Spirit 1.5.1, but it's
missing from 1.6.0. The doc still refers to it (see the very bottom of
http://www.boost.org/libs/spirit/doc/rule.html).
Giovanni Bajo wrote:
I might be dumb, but I read in the documentation that each rule
should have a member called set_id() to modify the parser ID. Now,
looking into the code that method does not exist. Not only that, but
there is not even a member holding the parser_id, it's just computed
on the fly through a policy, which means that it is impossible to
modify at runtime.
No, you are not dumb. This is a documentation oversight.
The only way I found was:
ruleT, parser_context, parser_tagAST::ID_INTERFACE
interf;
This is correct. Pardon the oversight. The change was done so as to
have a consistent interface for rules, subrules and grammars. Following
the precept that the user should not pay for features she does not need,
the member variable was taken out in favor of a static constant. The
additional member variable is not needed in many cases.
which is quite bloated, especially since I have to do this for many
many rules. So, where is the missing set_id() member?
In the meantime, this is the way to do it. You can write a simple
metaprogram to ease the typing (pun?). Example:
template typename ScannerT, in ID
struct rule_
{
ruleScannerT, parser_context, parser_tagID type;
};
Then:
rule_T, AST::ID_INTERFACE::type interf;
Sometime in the future, the interface to rules will be made easier
such that the optional template arguments can be passed in
arbitrary sequence.
Hope this helps. Again pardon the oversight.
--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] OK to tag for 1.30.0 release?
Beman Dawes wrote: At 04:36 PM 3/19/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 12:52 PM 3/19/2003, Beman Dawes wrote: Please speak up now if you have any uncommitted RC_1_30_0 changes orother problems. Otherwise we will tag for release at 3 PM US Eastern Time (20:00 UTC). Currently holding waiting for resolution of Boost.Python link problem. Also, CVS is running so slowly this afternoon that it is agony to do anything that traverses the whole tree. Actually getting a release ready requires doing that a number of times. Thus I hold the actual release work until later tonight or tomorrow morning. In the meantime, please don't commit any more changes (except the final Python fix) to RC_1_30_0. I'd like to make a small doc patch if you don't mind. It can't destabilize any tests. Non-code patches are OK. Spirit version 1.5.2 will also have to be bumped to 1.6.0 (the final release version). By convention, odd numbered minor versions are developmental. The final release will have the version change. The patches do not affect the code. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] OK to tag for 1.30.0 release?
Beman Dawes wrote: At 05:40 PM 3/19/2003, Joel de Guzman wrote: Spirit version 1.5.2 will also have to be bumped to 1.6.0 (the final release version). By convention, odd numbered minor versions are developmental. The final release will have the version change. The patches do not affect the code. Unless there is some problem I'm not aware of, you should go ahead and do that now. Done. The code should not be affected at all but I'll do some regression tests just to be sure. Thanks! -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] OK to tag for 1.30.0 release?
Joel de Guzman wrote: Beman Dawes wrote: At 05:40 PM 3/19/2003, Joel de Guzman wrote: Spirit version 1.5.2 will also have to be bumped to 1.6.0 (the final release version). By convention, odd numbered minor versions are developmental. The final release will have the version change. The patches do not affect the code. Unless there is some problem I'm not aware of, you should go ahead and do that now. Done. The code should not be affected at all but I'll do some regression tests just to be sure. Regression tests done. Spirit v1.6.0 is ready for release. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Beta boost+spirit - VC7.1 buffer overrun error
vc wrote: Hi all, I am using the VS .NET 2003 (VC7.1) on Windows 2000 and I'm porting a Linux application on Windows. I got the BETA sources (http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip) and I give it a try, but the compiler stops with the Buffer overrun detected! error (see Vccrash.jpg attached). For being easier to duplicate, attached is also a sample (see spirit-problem.cc) that has this behavior. I have to mention that on 2003.02.18 I took the spirit sources from the cvs, and this sample compiles fine with those sources. That is why I assume that this is a new added problem into the spirit sources. As a summary, when using: - version 1.29 of boost and cvs sources of spirit from 2003.02.18 = the sample compiles ok - boost 1.30 beta (boost and spirit) = the sample is not compiling ok Can you tell me please if this is indeed a spirit problem or not? What compiler errors are you getting? If it's the attached Buffer overrun detected! error, then that's clearly a VC7.1 compiler bug. Anyway, since this is clearly a Spirit support related question, please post your reply to Spirit-general mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spirit-general Let's continue our discussion there. See 'ya, -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] When will be the next boost released?
vc wrote: No, as the guys from spirit told me that the 1.5.1 version was released before VS. NET 2003 so their code is not designed for this new compiler. And indeed 2 weeks ago I took the spirit sources from the cvs and I didn't get that error anymore. No that's not correct. VC7.1 is known to compile Spirit with no workarounds as early as January last year (v1.3.x and Spirit-X). Anyway, the msvc_ps_helper.hpp is an inadvertent wart and is now removed. Still, I think you must report the ICE. Such things should not happen. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [Spirit-general] Re: Spirit problem with CW8 on MacOS X (was Re:[boost] XML Samples...)
Paul Snively wrote: Secondly, ast_xml.cpp takes a long time to compile--and no wonder; CW Pro 8.3 generates ~14 megabytes for it! I assume that's debug mode? release mode should be so much smaller. I've had good results with CW7.2 on Windows and I believe the CW compiler is very good. For example, g++ simple.xml generates 23M in debug mode and 320K in release. CW7.2 creates 1.4M in debug and 166K in release. I believe CW can do more if it can be made to inline more! How much can CW8 inline? For reference, see: http://spirit.sourceforge.net/wiki/index.php?page=Compiler+Inlining+Table Hope this helps! Oh yes! Thanks a lot. It seems there's a lot of work ahead to patch all the #include console.h. A lot of the sample apps need argv or argc. I'd certainly appreciate it if you can send in a patch file. Many thanks! -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Spirit problem with CW8 on MacOS X (was Re: [boost] XML Samples...)
Michael Burbidge wrote: I've been trying to use the XML samples in libs/example/application/xml. They build fine, but get a runtime assert when given even the simplest xml file. Are these samples kept up to date? Here's the assert that I get: Assertion (r.is_valid()) failed in range_run.ipp, function set, line 132 This is on Mac OS X using CodeWarrior 8. I assume this is a Spirit related question. Before anything else, please post Spirit support related questions to: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spirit-general Also, it would be best to write a more descriptive title. Otherwise, your post might probably be easy to miss. Ok, nuff said... The XML stuff has been tested and works with no problems on Windows and Linux. I come from the Mac but unfortunately I do not have access to a Mac and CW8 right now. Fortunately Paul Snively volunteered to check Spirit on CW8 on the Mac. You can also help out by giving us a more detailed account. For instance, what is the current state of the range (r) when the assertion fired? Please post subsequent messages to Spirit's mailing lits. Let's continue this thread there. Thank you. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: resource manager naming
Terje Slettebø wrote: You don't need to know the template parameters to know that it is a *pair*. That's the big difference. The template parameter is an abstract concept. Detached from the parameters, it is still a pair. The same does not hold for managedT. What is managed? It is not even a noun without the qualifiers. Good point, it's not a noun. resource_manager, manager or resource are nouns, so they may be better. managedwidget // does this *manage* the actual rendering into the window? Gotcha! No it doesn't! To adjust it so it becomes a noun: managerwidget Manager of widget. It's kind of implied that what is managed is the resource itself, even though resource doesn't say anywhere. This is similar to that you think it's implied that resourcewidget means it manages the resource, even though manage doesn't say anywhere. By the way, I used widget in the meaning of anything, as it's used some places (like foo and bar). Look at it this way. Which noun best describes the following: 1) You acquire it 2) You release it 3) You transfer its ownership A) manager B) resource C) managed resource_manager starts to look attractive, again. ;) Perhaps. But there's a *better* and *shorter* alternative that very well fits the description. We can say: linear_list_of_items_managerint, YUCK! Instead, we say listint. The management *is* implicit! Also, in general, I would say that any name suffixed by _manager are best used for classes that manage *many* things simultaneously, NOT JUST ONE. Take a window_manager for example. It is something that manages the operations of many windows. In the Macintosh, for example, the resource manager manages all* the resources in an application. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: resource manager naming
David Abrahams wrote: Dave Gomboc [EMAIL PROTECTED] writes: So then reverse resource_manager and get managed_resource, or just managed. Why not just resource? Management is implied anyway; that's the reason for the existence of the class. *laugh* I was thinking exactly the opposite. To me, the resource itself is clear from the template parameter -- it's the management that needs to be indicated. +1 for managed. I'm with Dave G. on this one. resourcelock doesn't tell me anything; I already know that every lock is a resource. Yes, but not all resources are locks. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: resource manager naming
Brian Gray wrote: On Thursday, February 27, 2003, at 09:15 AM, David Abrahams wrote: Sam Partington [EMAIL PROTECTED] writes: Could it not just be called shared. After all it is merely a more general term of shared_ptr. And the type of the resource kind of makes it implicit. std::auto_ptr is a non-shared resource manager. So then reverse resource_manager and get managed_resource, or just managed. Why not just resource? Management is implied anyway; that's the reason for the existence of the class. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: resource manager naming
Dave Gomboc wrote: So then reverse resource_manager and get managed_resource, or just managed. Why not just resource? Management is implied anyway; that's the reason for the existence of the class. *laugh* I was thinking exactly the opposite. To me, the resource itself is clear from the template parameter -- it's the management that needs to be indicated. +1 for managed. What template parameter? That's not a part of the name. Template parameters, just like function arguments are never a part of the name. You do not need to read the header file to get the essence. The name itself should indicate the function of the class without looking elsewhere. managed? What is managed? ... answer: take a look at the template parameter and you'll see what I mean. I'm sorry, that doesn't make sense. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: resource manager naming
Terje Slettebø wrote: From: Joel de Guzman [EMAIL PROTECTED] Dave Gomboc wrote: So then reverse resource_manager and get managed_resource, or just managed. Why not just resource? Management is implied anyway; that's the reason for the existence of the class. *laugh* I was thinking exactly the opposite. To me, the resource itself is clear from the template parameter -- it's the management that needs to be indicated. +1 for managed. What template parameter? That's not a part of the name. Template parameters, just like function arguments are never a part of the name. You do not need to read the header file to get the essence. The name itself should indicate the function of the class without looking elsewhere. managed? What is managed? ... answer: take a look at the template parameter and you'll see what I mean. I'm sorry, that doesn't make sense. managedlock managedwidget,shared // Smart pointer resourcelock resourcewidget,shared // Smart pointer When the template is in use (unless it uses a default template argument), the template argument will be part of the signature, and therefore show what is managed. Therefore, I think managed makes sense, too. IIUC, your argument can be used for e.g. std::pair, too. std::pair of what? Answer: That depends on the template arguments. No, a pair is always a pair regardless of what the composed types are: pairT1, T2 // a pair comprised of T1 and T2 You don't need to know the template parameters to know that it is a *pair*. That's the big difference. The template parameter is an abstract concept. Detached from the parameters, it is still a pair. The same does not hold for managedT. What is managed? It is not even a noun without the qualifiers. managedwidget // does this *manage* the actual rendering into the window? Gotcha! No it doesn't! OTOH: resourcewidget // ah yes, widget is a resource. we want to manage the resource -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Formal review or Variant Library (Ed B.)
Ed Brey wrote: [Use of a member function instead of a free function.] It's easy to make this case if you assume dependent variants are an edge case. Let's assume that dependent variants are not an edge case. Would you say that the advantages of tight binding for non-template cases and prettier syntax for dependent variants are each strong enough to justify a dual interface, i.e. free and member? Interestingly, of the two, I'd say that member is most natural and free is pragmatic, working around the compiler's lack of omnicience. I'll also be needing variant a lot from inside template code. I dislike the template keyword that gets in the way. IMO, the way to go is the C++ cast style syntax: extractT(v). There should only be one way to do this. Not two. And FWIW, there's a precedent. Although currently, boost::tuples has two ways to access its elements getN(t) and t.getN(), the TR (and the one that will be a part of the standard) for tuples does not have the member get anymore. IMO, this is a strong case *for* the free cast style and *against* the member function style. The variant and optional should strive to follow tuple's lead. In fact, come to think of it, why not just: getT(v) ??? -- Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Formal review or Variant Library (Ed B.)
David Abrahams wrote: BTW, I just realized that a conversion from variantT to optionalT could be used to do extraction as well. Maybe it would be better to ditch extract altogether and just use optional? I think this makes sense. The disadvantage is the overhead of optional just to do extraction. I understand from the other posts that implementing optional in terms of variant as is an overkill? If so, at least effort must be put into making both libraries reuse as much common parts as possible. I'm sure there are lots of commonality, right? -- Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] When to branch-for-release 1.30.0?
Beman Dawes wrote: In terms of new libraries and most major revisions, Boost developers committed their files early, so we are in great shape. Thanks to the developers of Filesystem, Optional, Interval, MPL, Spirit, Smart pointers, Date-Time. (If your library didn't get mentioned, its because no one updated boost-root/index.htm Latest News, where I got the above list of libraries.) Bjorn Karlsson, our Maintenance Wizard, has been working with developers to clear maintenance issues major and minor. However, various regression test failures, hangs, and loops have come up in the last few days, and I'd like to clear at least some of these before branch-for-release. So I'm proposing we spend Saturday and Sunday trying to clear regression test problems, and then branch-for-release Monday around noon Eastern US time, (5PM UTC). Sounds good. Looking forward. -- Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: some more questions on MPL and Borland
Aleksey Gurtovoy wrote: Joel de Guzman wrote: Yaiks! I hope it gets fixed soon. Spirit has been committed to the boost CVS now and I just switched to MPL so Spirit relies on MPL now. If you look at the errors more closely, you'll see that it's not MPL, but 'is_convertible' that is broken, for Borland 5.5.1; yes, hopefully things will be restored soon (John?). Yes, I noticed that. I have reverted to an older version of the file right now while waiting for it to be fixed. Thanks! -- Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] integral_c on g++2.95.3
Hi, I'm not sure if you are aware of this but g++ 2.95.3 cannot handle the casts: g++ 2.95.3 [no STLport] C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: `static_cast_expr' not supported by dump_expr C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: `static_cast_expr' not supported by dump_expr C:/dev/boost/boost/mpl/integral_c.hpp:68: sorry, not implemented: `static_cast_expr' not supported by dump_expr C:/dev/boost/boost/mpl/integral_c.hpp:68: sorry, not implemented: `static_cast_expr' not supported by dump_expr and I must revert to: #elif defined(__GNUC__) (__GNUC__ 3) // g++ 2.95.3 cannot take the casts, typedef integral_cT, (value + 1) next; typedef integral_cT, (value - 1) prior; #else typedef integral_cT, static_castT(value + 1) next; typedef integral_cT, static_castT(value - 1) prior; #endif Regards, Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] some more questions on MPL and Borland
Hi,
Borland cannot handle this code:
#include boost/type_traits.hpp
#include boost/mpl/if.hpp
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template typename T
struct C : if_is_emptyT, A, B::type {};
struct D { int i; };
struct E {};
struct F : CD {};
struct G : CE {};
Is there a known workaround? Can this be fixed?
I keep on bumping into this problem and its variants.
Or is there a better MPL idiom?
TIA,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
errors follow
Borland 5.5.1 [no STLport]
C:\dev\mpl_if.cpp:
Error E2396 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: Template argument
must be a
constant expression
Error E2299 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: Cannot generate
template
specialization from 'type_traits::ice_andb1,b2,b3,b4,b5,b6,b7'
Error E2293 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: ) expected
Error E2230 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: In-line data member
initialization requires an integral constant expression
Error E2230 C:\dev\boost\boost/mpl/bool_c.hpp 27: In-line data member initialization
requires an
integral constant expression
Error E2029 C:\dev\boost\boost/type_traits/is_convertible.hpp 195: 'bool_cvalue'
must be a
previously defined class or struct
Error E2451 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Undefined symbol 'value'
Error E2401 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Invalid template argument
list
Error E2299 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Cannot generate template
specialization
from 'type_traits::ice_orb1,b2,b3,b4,b5,b6,b7'
Error E2293 C:\dev\boost\boost/type_traits/is_empty.hpp 109: ) expected
Error E2230 C:\dev\boost\boost/type_traits/is_empty.hpp 109: In-line data member
initialization
requires an integral constant expression
Error E2029 C:\dev\boost\boost/type_traits/is_empty.hpp 193: 'bool_cvalue' must be
a previously
defined class or struct
Error E2029 C:\dev\boost\boost/mpl/aux_/value_wknd.hpp 30: 'is_emptyD' must be a
previously
defined class or struct
Error E2407 C:\dev\boost\boost/mpl/if.hpp 62: Dependent type qualifier
'aux::value_wkndis_emptyD
' has no member symbol named 'value'
Error E2407 C:\dev\boost\boost/mpl/if.hpp 62: Dependent type qualifier
'aux::value_wkndis_emptyD
' has no member symbol named 'value'
Error E2407 C:\dev\boost\boost/mpl/if.hpp 65: Dependent type qualifier
'aux::value_wkndis_emptyD
' has no member symbol named 'value'
Error E2407 C:\dev\boost\boost/mpl/if.hpp 65: Dependent type qualifier
'aux::value_wkndis_emptyD
' has no member symbol named 'value'
Error E2402 C:\dev\mpl_if.cpp 11: Illegal base class type: formal type 'typename
if_is_emptyT,A,B::type' resolves to 'typename if_c,A,B::type'
Error E2029 C:\dev\mpl_if.cpp 16: 'CD' must be a previously defined class or struct
Error E2396 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: Template argument
must be a
constant expression
Error E2299 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: Cannot generate
template
specialization from 'type_traits::ice_andb1,b2,b3,b4,b5,b6,b7'
Error E2293 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: ) expected
Error E2230 C:\dev\boost\boost/type_traits/is_convertible.hpp 190: In-line data member
initialization requires an integral constant expression
Error E2029 C:\dev\boost\boost/type_traits/is_convertible.hpp 195: 'bool_cvalue'
must be a
previously defined class or struct
Error E2451 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Undefined symbol 'value'
Error E2228 C:\dev\boost\boost/type_traits/is_empty.hpp 109: Too many error or warning
messages
*** 26 errors in Compile ***
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] integral_c on g++2.95.3
- Original Message - From: Gabriel Dos Reis [EMAIL PROTECTED] Dave Abrahams [EMAIL PROTECTED] writes: | On Tuesday, February 04, 2003 4:05 AM [GMT+1=CET], | Gabriel Dos Reis [EMAIL PROTECTED] wrote: | | Joel de Guzman [EMAIL PROTECTED] writes: | | Hi, | | I'm not sure if you are aware of this but g++ 2.95.3 cannot | handle the casts: | | g++ 2.95.3 [no STLport] | C:/dev/boost/boost/mpl/integral_c.hpp:67: sorry, not implemented: | `static_cast_expr' not supported by dump_expr | | This means that the part of GCC-2.95.x compiler responsible for | pretty-printing static_cast_expr was not taught to do its homework. | | In that case it would seem likely that it could be fixed by reverting to | C-style cast, no? Yes, I believe so. Yup, this works: #elif defined(__GNUC__) (__GNUC__ 3) // g++ 2.95.3 cannot take static_cast the casts, typedef integral_cT, T(value + 1) next; typedef integral_cT, T(value - 1) prior; Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: some more questions on MPL and Borland
- Original Message -
From: Vladimir Prus [EMAIL PROTECTED]
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include boost/type_traits.hpp
#include boost/mpl/if.hpp
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template typename T
struct C : if_is_emptyT, A, B::type {};
struct D { int i; };
struct E {};
struct F : CD {};
struct G : CE {};
Just tried. Works pretty fine. My CVS tree might be a week old, or so.
Also, maybe 'if_c::boost::is_emptyT::value, A, B' will work. Did
the same with 'is_same' recently.
I just updated from CVS before posting this to be sure.
Borland 5.5.1,
bcc32 -O1 -w-inl -w-aus -q -P
Regards,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: some more questions on MPL and Borland
- Original Message -
From: Vladimir Prus [EMAIL PROTECTED]
Joel de Guzman wrote:
Hi,
Borland cannot handle this code:
#include boost/type_traits.hpp
#include boost/mpl/if.hpp
using namespace boost;
using namespace boost::mpl;
struct A {};
struct B {};
template typename T
struct C : if_is_emptyT, A, B::type {};
struct D { int i; };
struct E {};
struct F : CD {};
struct G : CE {};
Just tried. Works pretty fine. My CVS tree might be a week old, or so.
Also, maybe 'if_c::boost::is_emptyT::value, A, B' will work. Did
the same with 'is_same' recently.
template typename T
struct C : if_c ::boost::is_emptyT::value, A, B::type {};
Nope, does not work.
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Bad Quoting and Outlook Express
Dave Abrahams wrote: Hey all you Outlook Express users - if you're tired of sending mangled emails, like this: Dominik Jain wrote in message news:aip4cd$15eofi$[EMAIL PROTECTED]... This is a simple sample text, and as you will see, Outlook Express is going to wrap this line. I've always hated that! And one night I said to myself, It can't go on like this. And so I wrote OE-QuoteFix... check out this free utility: http://home.in.tum.de/~jain/software/oe-quotefix/ I'm pretty sure I'm going to be switching back to Outlook Express from emacs/GNUs because of this (and the many joys of OE). I'm using it right now, and it just works! improving-quality-of-life-for-all-boosters-ly y'rs, Dave P.S. I'm tempted to suggest that we should link to this on our website and/or in our welcome email. FINALLY! I am using it now. What a joy :-) Yes, please make the link visible somewhere. It will do a lot of good. Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: some more questions on MPL and Borland
Vladimir Prus wrote: I just updated from CVS before posting this to be sure. Borland 5.5.1, bcc32 -O1 -w-inl -w-aus -q -P Yes, this fails for me too, *after update*. I meant to say that ~ week's old CVS was ok. Guess you'll have to do binary search in time to find out who and when broke this. Yaiks! I hope it gets fixed soon. Spirit has been committed to the boost CVS now and I just switched to MPL so Spirit relies on MPL now. Thanks, Volodya! Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] any_cast issues
- Original Message -
From: Vladimir Prus [EMAIL PROTECTED]
Greg Dehaas wrote:
Hi All,
boost::any test = Test Me;
[...]
And the error message is:
c:\dev\boost\boost\any.hpp(105) : error C2536: 'boost::any::holderchar
[8]::held' : cannot specify explicit initializer for arrays
c:\dev\boost\boost\any.hpp(122) : see declaration of 'held'
c:\dev\boost\boost\any.hpp(103) : while compiling class-template
member function '__thiscall boost::any::holderchar
[8]::boost::any::holderchar [8](const char ()[8])'
Hmm... the same problem can be seen if you try
std::make_pair(1, 2);
the template parameters are deduces as char[1] and char[1], and there's no
much you can do with that type, not even copy it. That's the way template
argument deduction works, IIRC. I suggest that you change ctors of any and
any::holder to take value instead of reference, and tell what you got. Of
course, you should be able to say
boost::any test = static_castconst char*(Test me);
Yes, but a library can make it work. For instance, make_tuple(hello, , world)
works as expected. QOI matter?
// Arrays can't be stored as plain types; convert them to references.
templateclass T, int n
struct make_tuple_traits T[n] {
typedef const T (type)[n];
};
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
- Original Message -
From: Aleksey Gurtovoy [EMAIL PROTECTED]
Joel de Guzman wrote:
Here's the Phoenix version:
struct my_function_
{
template typename Arg1T, typename Arg2T
struct result { typedef void type; };
template typename U
void operator()(std::string const text, U)
{
// ...
}
};
functionmy_function_ my_function; // here!
Then:
mpl::for_each my_types (my_function(text, _1));
This is way too cool! Now we only need to provide such free-standing forms
of all STL algorithms/member functions, and we will be living in a different
world:
std::vectorstd::string v;
push_back(v, text); // plain call
for_each(input, push_back(v, _1)); // currying
for_each(v, for_each(_1, print_char)); // more currying
// etc.!
Breathtaking, IMO.
That was my intent. Well, as Peter noted, there's a problem
with ambiguity. Obviously, there's the namespace solution.
Once the functionftor feature will be incorporated into
LL, the curried form can be written easily as ll::for_each.
This feature has been with Phoenix since its inception. That's
why I requested people to look deeper than the cute if_[] syntax
when Phoenix was first introduced. The library is really so much
more than that.
The next step (hopefully soon) is to have the ability to wrap
classes easily so as to provide member functions in curried form,
so we can write:
for_each(c.begin(), c.end(), obj.print(_1));
Then, well can really live in a curried world.
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
This is way too cool! Now we only need to provide such free-standing forms
of all STL algorithms/member functions, and we will be living in a different
world:
std::vectorstd::string v;
push_back(v, text); // plain call
for_each(input, push_back(v, _1)); // currying
for_each(v, for_each(_1, print_char)); // more currying
// etc.!
Breathtaking, IMO.
That was my intent.
I'd like you to take my breath, too, but I'm not as quick as Aleksey.
I tried to compile your code but I couldn't come up with a plausible
definition for function Could you fill in some details?
A good start is libs/phoenix/test/functors_tests.cpp
and libs/phoenix/example/fundamental/sample3.cpp
There are jamfiles in there FWIW.
Here's sample3.cpp:
#include vector
#include algorithm
#include iostream
#include boost/phoenix/functions.hpp
#include boost/phoenix/primitives.hpp
using namespace std;
using namespace phoenix;
struct is_odd_ {
template typename ArgT
struct result { typedef bool type; };
template typename ArgT
bool operator()(ArgT arg1) const
{ return arg1 % 2 == 1; }
};
functionis_odd_ is_odd;
int
main()
{
int init[] = { 2, 10, 4, 5, 1, 6, 8, 3, 9, 7 };
vectorint c(init, init + 10);
typedef vectorint::iterator iterator;
// Find the first odd number in container c
iterator it = find_if(c.begin(), c.end(), is_odd(arg1));
if (it != c.end())
cout *it;// if found, print the result
return 0;
}
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
- Original Message -
From: Joel de Guzman [EMAIL PROTECTED]
A good start is libs/phoenix/test/functors_tests.cpp
and libs/phoenix/example/fundamental/sample3.cpp
There are jamfiles in there FWIW.
BTW, here's the lambda-lambda solution posed by Joel Young:
#include iostream
#include boost/phoenix/operators.hpp
#include boost/phoenix/primitives.hpp
#include boost/phoenix/composite.hpp
#include boost/phoenix/functions.hpp
//
using namespace std;
using namespace phoenix;
//
struct square_ {
template typename X
struct result { typedef X type; };
template typename X
X operator()(X x)
{
return x * x;
}
};
functionsquare_ square;
//
template typename F
struct ffx {
template typename X
struct result { typedef X type; };
ffx(F f_) : f(f_) {}
template typename X
X operator()(X x)
{
return f(f(x));
}
F f;
};
template typename F
functionffxF
doub(functionF f)
{
return functionffxF (f.op);
}
//
int
main()
{
cout doub(square)(5.0)() endl;
cout doub(doub(square))(5.0)() endl;
cout doub(doub(doub(square)))(5.0)() endl;
return 0;
}
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
- Original Message -
From: Aleksey Gurtovoy [EMAIL PROTECTED]
My current understanding (which, admittedly, is not backed up by a
real-world experience) is that if you care about higher-orderness of your
generic algorithms, a preferred implementation construct for those
algorithms is not a function template, but a static _function object_ (a
technique used in FC++):
struct my_function_
{
template typename U
void operator()(std::string const text, U)
{
// ...
}
} my_function; // here!
For ordinary uses, the above will act just like a plain function template
(minus ADL/explicit template arguments specification):
my_function(text, int());
and it will also allow one to do something like this:
std::string text(text);
mpl::for_each my_types (boost::bindvoid(my_function, text, _1));
This technique is adopted by Phoenix. With this, you can even do
(as suggested by Joel Young):
- \ \
double - /\ f . /\ x. f(f x)
- / \ / \
struct square_ {
template typename X
struct result { typedef X type; };
template typename X
X operator()(X x)
{
return x * x;
}
};
functionsquare_ square;
template typename F
struct ffx {
template typename X
struct result { typedef X type; };
ffx(F f_) : f(f_) {}
template typename X
X operator()(X x)
{
return f(f(x));
}
F f;
};
template typename F
functionffxF
doub(functionF f)
{
return functionffxF (f.op);
}
int
main()
{
cout doub(square)(5.0)() endl;
cout doub(doub(square))(5.0)() endl;
cout doub(doub(doub(square)))(5.0)() endl;
return 0;
}
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
PS Jaakko and I are working on the LL/Phoenix merger.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MPL::void_t
Hi,
Question why is mpl::void_t an incomplete type? Sometimes I need
to instantiate it. For example to signal a zero arity functor call:
typename actor_resultBaseT, tuple ::type
operator()() const
{
return this-eval(void_t());
}
template typename T0
typename actor_resultBaseT, tupleT0 ::type
operator()(T0 a0) const
{
return this-eval(a0);
}
Of course I can do it differently, but it wouldn't be as clean and
generic as above. Thoughts?
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Spirit and slow compile (from gmane.comp.lib.boost.devel)
- Original Message -
From: [EMAIL PROTECTED]
Hi,
I was talking to you on the boost newsgroup about spirit being slow to compile
Here is a standalone section of code, it'll compile but you can't do anything with it
The compile takes about 15 mins on my machine
(We are using spirit for a second file but that is smaller and only takes a minute
or two)
The Spec of my machine is P3 833, 512M RAM
I'm using NT4 SP6a and VC6 SP4
I split it into a lib and it works fine so the problem is less crucial than it was!
[]
I have a feeling that the Grammar is just big so it's slow and there may not be
any getting around that but let me know if you see anything we are doing wrong
[]
Indeed! I counted 25 grammars. Wow I'm amazed, some grammars are
quite elaborate, even :-)
After taking a peek at the grammars, I see one minor and one
major code tweaks that should improve both the actual code size
and compile time speed.
minor: use chlit or strlit rather than ruleScannerT whenever possible.
(e.g. m_CommaToken)
major: I see lots of code duplication. It would be best to factor out common
grammar definitions into base definition classes. Example:
templateclass ScannerT
struct basic_definition
{
templateclass GrammarT
basic_definition(GrammarT const self)
{
// common definitions
}
};
Then subclass your grammar definition from this.
struct my_grammar : public spirit::grammargrammar
{
templateclass ScannerT
struct definition : basic_definitionScannerT
{
typedef basic_definitionScannerT base_t;
definition(my_grammar const self)
: base_t(self)
{
}
};
};
It would help a lot to factor out the common grammars this way. You
can even use multiple inheritance where necessary.
I hope this helps. I took the liberty to re-post this to the list in the hope
that this simple tip might be useful to others.
BTW, in the near future, productions such as:
r = a | b | c | d | e...
where the alternatives have unambiguous prefixes, example:
a = LINEDESC: ...
b = PAINTDESC: ...
can be optimized through Spirit style syntactic predicates.
Ahh, finaly BTW, you do not need to wrap str_p(...) inside
a lexeme because strlits are implicit lexemes.
Regards,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [Spirit-general] Re: [boost] Re: spirit and compile speed
- Original Message - From: Vincent Finn [EMAIL PROTECTED] I had a look at the mailing list but it comes up as read-only for me for some reason? I am logged in to Source Forge but haven't used it much as for the news group I subscribed to it (it appears in the list of available news groups) but when I try to access it I'm told it doesn't exist on the server ?? Hmmm... I'm not sure why. I have added 2 parsers to my code base and the compile time (VC6) has gone from 10 mins to 30mins :-( Yes, this is the next battle. How big are your grammars? How many productions? Are you using subrules? Better yet, can I see your code? I can send a stripped down code (it'll take a while to put it together so it'll be next week some time) 3 question on that 1) Would you prefer a direct mail with it or an atachment to the NG? 2) Do you need tgz or is zip fine? 3) Is a VC project file fine to show the compile setting I am using? Sure. No problem. A VC project file is Ok and zip is just fine. This is another developers code but I made the call to use Spirit so I have to do the optimising ! so please bear with me if it takes a while for me to split it off :( I'd appreciate that a lot. This will help me fine tune Spirit and will be very useful in targetting the points where optimization is needed. At the very least, yes, you can separate the parsers from the project. How about writing some wrappers that *hides* the grammars in *.cpp files? You can for example have an opaque API in a header such as: bool parse(char const* source); That seems obvious now that you say it I was thinking in terms of spliting spirit off which causes problems but , as you say, all I need is to build a lib with my parser in so that spirit is hidden. Thanks for the quick response, Vin Most welcome! Regards, Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Hello MPL world!
- Original Message - From: David Abrahams [EMAIL PROTECTED] David B. Held [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Yitzhak Sapir [EMAIL PROTECTED] writes: I think storing the text Hello world! in a vector [...] And then using functors to print it such as: [...] While this is a cute idea, my first impression would be: Uh...is this really something I could use in my own code? On the other hand, I seem to use compile-time if more than anything else, even in user code. I suspect that most people will use mpl::if_ and type traits more than anything else, so I think Dave's original example with is_pointer would connect with the most programmers. I think I agree with you here. And I disagree. I think the hello world example presented is a good start to whet the appetite of a would be MPL user. Why? 1) It shows, in simple terms, how compile time structures can be useful at runtime. 2) An STL programmer will immediately be at home because of the use of the vector and the for_each. On the other hand, I suspect that library authors are more likely to use the type containers and algorithms, so an example illustrating those might be more appropriate for them. So I guess it depends on the intended audience. I dunno, I use compile-time if_ in my libraries more than anything else. Same here. P.S. Outputting Hello, world in a way that generates significantly more code than the run-time version is probably not a good way to endear users to metaprogramming. ; Again, I disagree. The C++ hello world generates more code (bringing in the iostreams in whole) than its C counterpart yet no one complained. Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Sprit into the boost distribution
- Original Message - From: Peter Simons [EMAIL PROTECTED] Joel de Guzman writes: What would be particularly nice is if the sync is entirely scripted, so anyone with Boost CVS write access can run it. [...] perhaps all that is needed is to have a working directory which is first updated from the Spirit CVS, and then committed to the Boost CVS. Can we do this Dan? No, it does not work that way. You cannot check-out a tree from one repository and then commit it into another. CVS cannot do it. The only way you can synchronize the repositories via CVS directly is by importing a checked-out copy from the Spirit repository into the Boost repository. This _can_ be scripted, though. I am using a similar approach to synchronize my local CVS server with Boost's. The problem is, though, that this whole operation gets somewhat complicated when people start committing to both the Spirit and the Boost version of the repository, because then you'll have to manually merge the changes into one branch. And that's not always very easy to do. Another problem is that cvs import does not track deleted files; this has to be emulated by the script as well. Hmmm... Can you suggest a practical solution? Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Sprit into the boost distribution
- Original Message - From: Beman Dawes [EMAIL PROTECTED] once Spirit is checked in its CVS. What might be a nice strategy is to continue with the current Spirit-CVS as a sandbox where ideas and prototypes are developed while more stable snapshots are sent of to Boost's CVS. Thoughts? I worry a little about this arrangement. I don't want to slow down Spirit development, but it seems likely that fixes will sometimes want to be committed to the Boost CVS by Boost developers (say, when a backwards-incompatible change in another library breaks some part of Spirit). Maybe we should just give all of your core developers CVS access to Boost...? While I understand Dave's concern above, I also think we should be flexible. If we followed the strategy Joel outlines above, it is always possible for a Boost developer to commit a fix directly to the stable Spirit version in the Boost CVS. I would be willing try Joel's strategy. More than that, really, I think it might be quite useful for a very active library with lots of developers. What I would like from Joel and the other Spirit CVS participants is assurance that a procedure is worked out so that we can be sure the two CVS's are brought into sync at appropriate times. I'll make sure that this will happen. It would be nice if we can do this automatically as you outlined below. If not, I'll have to make it a point to sync periodically. What would be particularly nice is if the sync is entirely scripted, so anyone with Boost CVS write access can run it. (Presumably read-only access to the Spirit CVS is all that is required on that end.) If the entire Spirit CVS (or entire sub-trees) is to be mirrored in the Boost CVS, perhaps all that is needed is to have a working directory which is first updated from the Spirit CVS, and then committed to the Boost CVS. Is that all there is to a sync operation? Can we do this Dan? Many thanks and regards, Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: The Wonder of Tuples
- Original Message - From: Roland Richter [EMAIL PROTECTED] There has been some out-of-list discussion about this, and some work is being done. There's a PP based tuple implementation (mostly written by Joel) in Spirit's CVS that conforms to the Tuple speicification in the TR. Where is it? Do you refer to the files under spirit/spirit/boost/preprocessor/tuple, or is there something else? Try spirit /spirit/boost/phoenix/tuples in PHOENIX_X branch Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] The Wonder of Tuples
- Original Message - From: Jaakko Jarvi [EMAIL PROTECTED] Aleksey Gurtovoy wrote: David A. Greene wrote: The fundamental problem is that it's inconvenient to iterate through a tuple. 'tuple_ext' (tuple extensions) make it easier - http://groups.yahoo.com/group/Boost-Users/message/704. Has any discussion taken place about incorporating something like this into Boost? Seems like a useful bit of code. There has been some out-of-list discussion about this, and some work is being done. There's a PP based tuple implementation (mostly written by Joel) in Spirit's CVS that conforms to the Tuple speicification in the TR. (Note that the current Boost.Tuples is not one-to-one what was accepted into the TR. Most notably, the cons-list interface was not standardized.) The PP based tuples are not complete yet, and what the iteration interface will be is still undecided. Yup, I've been itching to reply to the thread but opted to wait for Jaakko. There's already a TR conformant tuple implementation in Spirit's CVS in the PHOENIX_X branch. It is PP and MPL based. Compiles on all relevant compilers. There is only one implementation, unlike boost tuples which has a different implementation for MSVC which can easily get out of sync (it is out of sync now in fact. e.g. the MSVC branch does not convert a make_tuple(ref(x)) to tupleX. And interestingly, some code that does not compile on some compilers now compile with this implementation. All of Jaakko's regression tests (except the cons related stuff) plus some more new ones compile and run. With the help of Jaakko, Aleksey et. al, I wish to implement a set of tuple algorithms similar to STLs. The tricky part is that it should work at compile time, run-time and half-run-compile time. Cheers, Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] reference_wrapper as functor
- Original Message - From: Peter Dimov [EMAIL PROTECTED] From: Joel de Guzman [EMAIL PROTECTED] [...] The condition is expected to be a functor that returns a boolean condition. I was hoping that I can use the ref(b) as a functor such that I can write: bool b; if_p(ref(b)) [ parse_this ] Not a good idea. In lambda terms the above is var(b), not ref(b). We've been using ref(x) to mean just like x, i.e. ref(b)() means b(). One day we might even get that core change that would enable reference_wrapperT::operator T to be considered in a ref(f)() expression; for now, we fake it in bind, function, etc. I beg to disagree. I do not see that as reasonable. The use of var(b) will bring in tons of scaffolding. This is the main reason why I want to request for the operator(). I've struggled hard to keep the core of Spirit small enough to do micro parsing. I do not wish to force the user to use lambda or phoenix, bind nor function just to do such a trivial operation that can be accomplished by a one-liner in ref(x). Historically, Spirit had a ref(x) that does that identity thingy. It has been made obsolete in favor of boost::ref. I might have to bring it back to life if my request cannot be granted. I see no other way to accomplish ref(x)() for micro-parsing tasks. Regards, Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] reference_wrapper as functor
Hi, Is there a chance that we can add an operator() to the reference wrapper? In particular, I would like to be able to use it as a nullary functor. This would obviously be very useful and should not disrupt the current code. In particular, consider Spirit's conditional parsers (as once asked by Beman). if_p(c) [ parse_this ] The condition is expected to be a functor that returns a boolean condition. I was hoping that I can use the ref(b) as a functor such that I can write: bool b; if_p(ref(b)) [ parse_this ] Of course I can metaprogram the condition to dispatch appropriately when the condition is a reference_wrapper but it wouldn't be as simple and elegant. Thoughts? TIA. Joel de Guzman [EMAIL PROTECTED] http://www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
