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
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
? NO!
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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
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
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
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
::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
!
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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
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
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
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
!
Regards,
--
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
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
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
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
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
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
;
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
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
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
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
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
, 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
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
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
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
. 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
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
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
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
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
-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
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
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
) 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
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
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
. 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
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
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
), // 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
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
. 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
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
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
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
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
.
--
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
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
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
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
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
. 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
;
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
.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
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
::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
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
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
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
://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
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
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
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
* 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
.
--
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
::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
. 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
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
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
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
de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
(__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
: 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
- 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
- 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
- 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
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
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
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
- 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
));
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
- 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
;
};
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
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
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
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
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 Guzma
- 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 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
.
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
time.
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- 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
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
1 - 100 of 122 matches
Mail list logo
