[boost] BOOST_CHECK_EQUAL_COLLECTIONS proposal
I've just tried to use the above test tool, and see the following:
svertka.driver.cpp(127): error in test_svertka: test {result.begin(),
result.end()} == {result2, ...} failed [-431600044 != -78651042]
I think this message misses one thing: the position where mismatch occured. If
differing values are printed, it's natural to print position, too. Gennadiy,
how do you think?
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BOOST_CHECK_EQUAL_COLLECTIONS proposal
svertka.driver.cpp(127): error in test_svertka: test {result.begin(),
result.end()} == {result2, ...} failed [-431600044 != -78651042]
I think this message misses one thing: the position where mismatch
occured. If
differing values are printed, it's natural to print position, too.
Gennadiy,
how do you think?
I could probably add at position N after failed, though it would make an
comparisons implementation much more intricate.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: visitation algorithm
Eric Friedman [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Gennadiy Rozental wrote:
While I do agree O(1) is better than O(N), I would like to point out
that
it is usable only when the pseudo-variadic template interface is used
(i.e.,
variantT1, T2, ..., TN as opposed to variantTypes).
Why? And to be absolutely clear: what do you mean by it?
By it I mean the use of a switch, as you propose.
If variant is given types as a MPL-sequence (e.g., variant mpl::listT1,
T2, ..., TN instead of variantT1, T2, ..., TN), then technique you
propose will not work. Please prove me incorrect, but I don't think you
can.
(Note, however, that loop-unrolling is still possible, though ultimately
it
doesn't change the O(N) complexity of visitation.)
I don't think there is a differrence. In both cases we either rely on actual
number of types that need to be computed (IOW is not sutable for PP) or on
upper limit of types amount (that is PP constant in both cases).
Here how the second case could be implemented:
templatetypename Typelist, typename Storage,typename Visitor
void switch_visitor_selector( Storage storage, int witch, Visitor visitor )
{
switch( witch ) {
case 1:
visitor( Typelist[1](storage) );
break;
case 2:
visitor( Typelist[2](storage) );
break;
...
case MAX_WITCH:
visitor( Typelist[MAX_WITCH](storage) );
break;
}
}
I do not know how smart are modern optimizers. But in general my
understnding was that if-else form should use O(N) comparisons, while
switch
form should be compiled into jump with some computed offset.
I'd be interested to know more about these assumptions before I spend a
great deal of time writing code based upon them.
Does anybody familiar with modern compiler design could confirm/deny above
statement. I will try to dig something myself.
Gennadiy
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: BOOST_CHECK_EQUAL_COLLECTIONS proposal
Gennadiy Rozental wrote:
svertka.driver.cpp(127): error in test_svertka: test
{result.begin(), result.end()} == {result2, ...} failed [-431600044 !=
-78651042]
I think this message misses one thing: the position where mismatch
occured. If
differing values are printed, it's natural to print position, too.
Gennadiy,
how do you think?
I could probably add at position N after failed, though it would make
an comparisons implementation much more intricate.
On the first look, seems like eqaul_and_continue_impl should take extra
parameter --- number of element, with default value of 0. Am I missing
something?
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Variant Library: variant size and strong guaranty
Eric Friedman [EMAIL PROTECTED] writes: While this is certainly quite implementable, I feel a bit uneasy about hinging variant's exception-safety guarantees on such a small point as whether 'void' content is allowed. I imagine it would not only make variant more confusing to use but also may not satisfactorily solve the problem of delegating the space-vs-safety decision to the user. I'm interested in feedback on this issue. Here's the way I see the issue: 1. Being able to maintain a sensible invariant for variant (ugh, English can rot sometimes) is important. b. One or none (i.e. maybe-empty) is a reasonable-sounding invariant. Given that one has to ask what kind of contents are in the variant in order to do anything with them**, it's hard for me to imagine a case where one or none would be any worse than exactly one. c. However, if someone can show code or program logic that is complicated by one or none, I'm perfectly willing to accept that exactly one is a more-reasonable invariant for some or most applications. Iff it's most, including void as one of the variant types to achieve one or none functionality sounds quite elegant. 2. Having a strong-guarantee assignment is NOT important, and in particular should never be bought at the cost of (space or time) efficiency. You can see my writings on why copy/swap is a poor choice for canonical assignment for rationale. In this case, the strong guarantee falls out of the implementation technique required to achieve exactly one, and is not a goal in and of itself. In that case, I see no problem at all that you only get the basic guarantee in the one or none case. -Dave ** or get an exception trying to retrieve them, of course -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Boost.Python and BCC
Chris Trengove [EMAIL PROTECTED] writes:
David Abrahams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Please see if you can come up with a simpler non-specific approach
which might break cwpro7. That's what I'd like to have in the
codebase.
I think I have come across an approach which works with BCC, but I'm afraid
it can hardly be called non-specific. Not being able to use template
syntax with member function pointers is quite a handicap.
What do you mean by that? Are you describing some Borland bug?
We end up with something like
python::detail::member_function_castTarget::stage1(f).stage2(f)
where stage1() is a set of overloaded member functions which merely extract
the class (S) from the member function pointer; eg.
template class S,class R
static cast_helperS,T stage1(R (S::*) ())
{
return cast_helperS,T();
}
Then cast_helperS,T derives from
mpl::if_cis_base_and_derivedS,T::value,...,...
to choose between the two types of cast, which is performed by the stage2()
member function. However, for the base/derived case, we need an additional
full set of overloaded member functions to perform the cast. So the net
effect of this particular compiler bug is that we need to double the work of
Boost.Preprocessor in generating all these overloads!
Ouch. So you are describing a compiler bug :(.
To add insult to injury, we also have to re-write the test file as well,
using typedefs everywhere. For example, change
assert_mf_castint (Y::*)() const, Y(X::f);
to
typedef int (Y::*mpf1)() const;
assert_mf_castmpf1, Y(X::f);
Is this what you meant by not being able to use template syntax with
member function pointers?
I'm not sure if you'd like to have this in the codebase!
I'm willing to jump through one or two hoops to get Borland support.
In this case, the extra PP generation should be a special case for
Borland, and all member_function_cast invocations should be wrapped
up in a macro like BOOST_PYTHON_MEMBER_FUNCTION_CAST(target, f) which
hides the horribility from users.
How does that sound?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_HAS_THREADS in Win32
Jiang Hong said: I'm new to boost. But should '#define BOOST_HAS_THREADS' be added to boost_1_30_0/config/platform/win32.hpp? Or is there a better way? This is defined by the config headers if the compiler you're using has indicated that multi-threading has been requested during compilation. This is generally done by compiling/linking against the multi-threaded RTL. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] indentation algorithm for stream objects
Larry Evans wrote: I disagree. The following (almost) line by line translation of your example to marg_ostream: As I said, I don't know the details of the implementation, so that was a speculation based on how I presumed it was implemented. That's why I like your way; however, in the back of my mind, there's a feeling I started out that way (this was done years ago) and for some reason, after running some tests, found it better to do it this other way. I think the problem was I didn't always know when the beginning-of-line occured; hence, I needed the marg_ostream to keep track of this. I can't remember specifics yet. The problem lies in what to do when reading in data from an external source like a file. In that instance, you have to manually scan the file for '\n' characters and indent then. This is a problem with my design, one solution to which would be to provide a special method for string output that performs the indenting on '\n' characters and the default operator for strings and characters does not do this. I have made several improvements to the original code, including: [1] added a security check for indentor::endIndent() to prevent m_indent.level dropping below 0 [2] added the ability for indentor::indent() to output a newline character [3] indent() is now implemented using width() and fill() functions from OutputFileType, restoring their values afterwards - thanks to Larry Evans for the suggestion [4] added char/wchar_t support by inheriting the character type from OutputFileType -rhd- mailto:[EMAIL PROTECTED] _ Worried what your kids see online? Protect them better with MSN 8 http://join.msn.com/?page=features/parentalpgmarket=en-gbXAPID=186DI=1059 indentor.zip Description: Zip compressed data ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Adding a generic list manipulator
Paul A. Bristow wrote:
Thanks for repackaging the code inside zip, and for mor examples, and
making it work 'strictly' MXVC 7.0 Level 4 NO language extensions
No problem.
But handling at least 2D and 3D C arrays is still acommon requirement.
The problem with 2 or more dimensions is that you cannot specify the
beginning and end point for dimensions beyond the first, making it
impossible to use my formatlist manipulator (in its current implementation)
for displaying things like matrices.
I have a few ideas about how to add support for nD constructs, but do not
have anything resembling a design for them as yet. I will provide more
information once I have something more definate.
Some people are turned on by wide characters.
Then they are going to like the improvements I have made to the manipulator
- it now supports the following, via the formatlistex manipulator:
* ascii characters (char)
* wide characters (wchar_t)
* ascii strings (char * and const char *)
* wide strings (wchar_t * and const wchar_t *)
I have also provided some new examples to demonstrate these in action.
NOTE: There is a bug when using either std::wcout or std::wofstream when you
try to do something like:
std::wcout L\x2200 foo \x2203 bar\n;
This should output
$forall$ foo $there-exists$ bar
but it does not want to work on the MSVC7 compiler and default library. It
*should* work, but unfortunatly does not :-(.
Also: does anyone know why a wide character stream will not accept char and
const char * arguments to the operator, and vise-versa for an ASCII
character stream?
Doubt that you should worry at present - boost\io\ may be suitable?
I have changed the library to the boost::io namespace anyway. I will not
concern myself anymore with the namespace name until a later date, if/when
the library is ready for integration into boost.
Your new examples show how easy it is to use.
Thanks.
I have also revised the code structure to seperate the declerations from the
implementation and also to seperate the different classes. Does anyone have
any comments on this version and the old one? Which do you prefer?
I personally favor the new one, but all comments/criticism are welcome.
One final thing: the test code shows the preliminary notion of seperating
the format information from the formatlist_t class, allowing you to apply a
format across several outputs without having to explicitly adding the
formatting options to the manipulator.
Here is what I have in mind, although it is not currently implemented:
Creating the formatter object and configure it:
boost::io::formatter char fmt;
fmt.format( '(', ')' );
Output binding mechanism #1:
std::cout boost::io::formatlist( i, i + 4 )
.format( fmt );
Output binding mechanism #2:
std::cout boost::io::formatlist( v, fmt ) '\n';
NOTE: In mechanism 2, the format type is inherited from the formatter.
I am looking at supporting both mechanisms for greatest flexability.
-rhd-
mailto:[EMAIL PROTECTED]
_
Use MSN Messenger to send music and pics to your friends
http://www.msn.co.uk/messenger
formatlist.zip
Description: Zip compressed data
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Using variant library with Boost 1.30.0
Eric Friedman wrote: Allen Bierbaum wrote: I have been very impressed with the Variant library and started using it with Boost 1.29. Good to hear. I'd be interested in your experience using the library in a real-world (?) application. I was able to get variant working with 1.30 by pulling some of the code out of the sandbox. I have started using it in my application and have run into one major limitation: variant size (in number of allowed types) I need to use a variant of about 15-20 allowed types. By default variant only works with 10 types. I know that by defining: BOOST_MPL_LIMIT_LIST_SIZE=20 and BOOST_MPL_NO_PREPROCESSED_HEADERS I can get the limit up to 20 or 30 or whatever I want. Unfortunately this also ups the limits on *all* lists that may be in the code and makes compile times take much longer since I can't use the preprocessed headers. Anyway, looking back through the list I found a reference here: http://lists.boost.org/MailArchives/boost/msg38637.php that says the recommended way to do this type of thing when users want longer list types is to use the numbered list types. I know this doesn't directly relate to variant, but I was thinking it would be very nice to have something similar for variant. So for example I could say: boost::variant27... to get a variant that allows 27 types. I would also be happy with something like: boost::variant27, type1, type2,..., type27 but I could see where some people would not like this form since it requires the size to be explicitly set. Maybe something like this would work better. boost::variantS27, type1, ..., type27 This provides an explicit type that is used when you want the first parameter to be the size, but still allows the normal boost::variant type to automatically detect the size. What do you think, are either of these two options feasible (or is there already support for it that I missed)? -Allen I now need to start to using Boost 1.30.0 though and I don't think the variant library distributed for the review will work with the 1.30.0 release. Does anyone have any suggestions how I can use the variant library with Boost 1.30.0? Anyone have an updated distribution of the Variant library? I plan to ready the code for release with 1.31. Until then, you can try using the code in the sandbox, which I have recently updated to work with 1.30. Note, however, that the code in the sandbox will change -- sometimes significantly -- and integrates variant with other libraries I am developing, such as Boost.Visitor and Boost.Move. If this is a problem for you, you may want to update the variant submission code yourself. Most of the required changes are to accomodate class and header name-changes in MPL between 1.29 and 1.30 -- nothing terribly significant. Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- -- Allen Bierbaum [EMAIL PROTECTED] -- -- VR Juggler Team www.vrjuggler.org -- -- Virtual Reality Applications Centerwww.vrac.iastate.edu -- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [lambda]/[spirit-phoenix] Lazy evaluation+expressiontemplates
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? 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. Consider this: // Just two 2D vectors. Vector2D v(1,1), u(2,2); // A vector given by a vector expression. Vector2D s = v + u ; What I want is to have 's' not having a real value but storing the _expression_ (v+u) instead, so that if I subsequently do something like: Vector2D t(3,3); double dot = s * t ; // operator * is dot product is the dot product operation who evaluates 's' to produce the result. Similarly, I should be able to construct even more complex expressions with other vector operations, such as multiplication by a scalar, which are evaluated only at certain specific points. I've been palying with PETE (the Portable Expression Template Engine) but all I can do is something like: some complex expression type s = v + u ; but as soon as 's' is assigned to a Vector2D it is fully evaluated. Thus, I need to combine PETE with some sort of lazy evaluation tool. Can something like this be done with (boost) Lambda, Bind or Phoenix? FYI, what I'm trying to do is to combine what is known as floating-point filtering (explained below) with expression templates+lazy evaluation to allow the construction of geometric objects via algebraic expressions. Ideally, a user would be able to write the following: // // Objects created via ordinary construction // (reduced form in FC terms) // point a(0,0), b(10,10); line D(a,b); // a diagonal line point c(2,0), d(2,10); line L1(c,d); // a vertical line at x=2 point e(2+epsilon,0), f(2+epsilon,10); line L2(e,f); // a vertical line at x=2+espilon // // Objects created via expressions // /* Here, the coordinates for points i0,i1 are given by unevaluated expressions. */ point i0 = intersect(L1,D); point i1 = intersect(L2,D); // // Application of lazy evaluation + floating-point filtering // /* Here, the member function int line::ordering(p0,p1) returns the relative ordering of the input points along the line w.r.t to the line orientation: (i.e., if p0 is before p1, returns +1) */ int order = L1.ordering(i0,i1); /* The thing is that if points i0,i1 are given actual coordinates during the intersection computation, the ordering predicate will deal with unaccurrate data already and won't be able to give a correct result no matter how fancy aritmetic it uses. OTOH, if i0,i1 can be internally represented by the expressions used for the intersection computation, the ordering predicate can use the technique known as floating-point filtering: evaluate the expression first with standard double precision, and if it detects loose of significand data, do it again with an unlimited precision number type. This technique has been used for years but with entirely runtime algebraic number types which mantain the expression tree dynamically via software, which has really slow performance. TIA, Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Variant Library: top level const types
Gennadiy Rozental wrote: So what I want is typedef boost::variantint const,std::string const GlobalParameter; GlobalParameter input_socket( 12345 ); // localhost::12345 GlobalParameter output_socket( MultiplexorSocket ); [snip] What if variant is the member of the class template, and we want to support const type arguments? Why not implement const support if it does not cost us too much and you agree that there exist possible usage cases? I argue that top-level const type arguments are meaningless in the context of variant. Given the example you provide: typedef boost::variantint const, std::string const GlobalParameter; GlobalParameter input_socket(12345); input_socket = 54321; // no way to prevent this!! If there is no way to prevent the code above, then I see the allowance of top-level const types as misleading, at best. Please help me understand your view if you continue to disagree. But I feel more relaxed on this point now. Though I believe if variant will end up without const type support it should be clearly documented that there is a way to implement variant constants in many cases. We can put it in the docs, but it seems straightforward that a const variant would, in fact, not allow modification. What reason would lead someone to believe otherwise? Thanks, Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: variant size and strong guaranty
Gennadiy Rozental wrote: overview.) This technique is necessary to provide a general guarantee of strong exception-safety, which in turn is necessary to maintain a never empty invariant for variant. What is this invariant? And why is it that important. The invariant is quite straightforward: any object of type variantT1, T2, ..., TN contains exactly one object of type T1, T2, ..., or TN. From this it seems that in above passage (This technique is necessary ...) you switched an order of importance: In fact you need double storage to implement never empty invariant (in other case you would need during copy/assignment to first destroy current object), that is necessary to implement strong guaranty. Isn't it? Yes, sorry, I presented the logic in a reversed fashion. The double-storage technique is necessary to maintain a never empty invariant. The double-storage technique provides strong exception-safety incidentally. I am well aware, of course, of the trade-offs made by the use of this technique. Thus the decision is not set in stone, and I'd be willing to consider arguments against it. I will make two final notes, however. 1) In addition to its role in enabling recursive variants, boost::incompleteT provides a convenient way to increase space efficiency (though at the expense of speed efficiency due to heap allocation). Note though that this is only because incomplete wraps a T*, which is small. It does *not* disable the double-storage technique. 2) For every type supporting non-throwing move operations, I have implemented variant to use single-storage. As a (trivial) proof of this, boost::has_nothrow_copy types *do* currently avoid the double-storage overhead.) Of course, until Boost.Move becomes a reality this is nearly all but meaningless for the vast majority of types. Several notes: 1. Intrinsic types have nothrow move constructor, so should follow second case road. Isn't it? Unless there is a bug in the code, this should already be the case, as intrinsic types are covered by has_trivial_copy. 2. Could type that implements swap() method somehow follow the second case road also? For example, could you somehow deduce T* from buffer and swap it with local copy of the argument? Yes, I can look into such optimizations. But as I noted in previous messages, if I can prevent double-storage only for incompleteT (a point on which I'm not certain is even true), it's probably not worthwhile. After all, sizeof(incompleteT) == sizeof(T*), so double-storage means 2*sizeof(T*). 3. Could you use placement copy into local to assign storage and then memcopy it to variant storage? It wouldn't work with all types but may work in many cases isn't it? Here we would have different tradeoff. Such memcpy-able types are already covered by has_trivial_copy, which ultimately enables has_trivial_move. Thus for these types double-storage is already disabled (provided the appropriate traits are specialized). 4. Whatever way these matters will be decided I think it should be carefully documented so the user have a perfect understanding of possible choices. Agreed: the docs should state what requirements exist on types for the various optimizations. [snip] Separate issue is the type of which field. Having it as int is an This is implementation issue that affect the library design (it affects an abstraction overhead). So it's as important as issues above. So long as variant::which() returns an int, I don't see how it is anything other than a design issue: in terms of space efficiency, the difference between sizeof(char) and sizeof(int) is constant. I do not want to argue on terms. My point is that this implementation detail make variantint,short size at least 6 instead of 3. 100% difference. So let's just fix it before release. I don't think it's as bad you say: I don't think variantint, short will be a common use-case. Nonetheless, I'll make the change. - Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: visitation algorithm
Gennadiy Rozental wrote:
Eric Friedman [EMAIL PROTECTED] wrote:
[snip]
If variant is given types as a MPL-sequence (e.g., variant
mpl::listT1,
T2, ..., TN instead of variantT1, T2, ..., TN), then technique you
propose will not work. Please prove me incorrect, but I don't think you
can.
(Note, however, that loop-unrolling is still possible, though ultimately
it doesn't change the O(N) complexity of visitation.)
I don't think there is a differrence. In both cases we either rely on
actual
number of types that need to be computed (IOW is not sutable for PP) or on
upper limit of types amount (that is PP constant in both cases).
Here how the second case could be implemented:
templatetypename Typelist, typename Storage,typename Visitor
void switch_visitor_selector( Storage storage, int witch, Visitor
visitor )
{
switch( witch ) {
case 1:
visitor( Typelist[1](storage) );
break;
case 2:
visitor( Typelist[2](storage) );
break;
...
case MAX_WITCH:
visitor( Typelist[MAX_WITCH](storage) );
break;
}
}
Your pseudo-code is misleading. There is no MAX_WHICH available to the
preprocessor when MPL-sequences are given because there is no theoretical
upper limit on the size of a type-sequence.
If your example is to demonstrate the feasibility of a special case
optimization, well then I have already agreed with you.
Thanks,
Eric
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Using variant library with Boost 1.30.0
Allen Bierbaum wrote: Eric Friedman wrote: Allen Bierbaum wrote: I have been very impressed with the Variant library and started using it with Boost 1.29. Good to hear. I'd be interested in your experience using the library in a real-world (?) application. I was able to get variant working with 1.30 by pulling some of the code out of the sandbox. Good to hear. I have started using it in my application and have run into one major limitation: variant size (in number of allowed types) I need to use a variant of about 15-20 allowed types. By default variant only works with 10 types. [snip: longer lists] What do you think, are either of these two options feasible (or is there already support for it that I missed)? The support is present, but it was not publicized during the review (since mpl::is_sequence from 1.30 is required, and 1.30 had not been released): variant mpl::list27T1, T2, ..., T27 // ...or mpl::vector27, etc. Note, however, that such support, while present, is experimental, and it has not been tested much. The feature will definitely appear when variant is released though. - Eric ___ 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
[boost] Re: Re: Re: Boost.Python and BCC
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is this what you meant by not being able to use template syntax with member function pointers? Yes, this is the infamous BCC emoticon bug. The parser accepts a number of characters (in addition to ) as valid in terminating a template. An example, borrowed from Chris Uzdavinis, is that BCC will happily accept the following! vector vector vector int }:) x; Because member function pointers include an ), they are always treated as terminating any template, and so they don't compile. To my mind, this is a rather amazing bug to have been lying around so long, since you wouldn't think it would be too difficult to fix this elementary parsing error. I'm willing to jump through one or two hoops to get Borland support. In this case, the extra PP generation should be a special case for Borland, and all member_function_cast invocations should be wrapped up in a macro like BOOST_PYTHON_MEMBER_FUNCTION_CAST(target, f) which hides the horribility from users. How does that sound? That sounds OK, and I will work in that direction, but I should point out that I have yet to get any decent examples to compile. Hopefully, now that I have a solution to this problem, I will be that much closer, but one never knows. The other thing which is always in the back of my mind is the potential for the future release of Borland C++Builder 7 (whenever that is) to make a lot of these hacks unnecessary (both for Boost.Python and for other Boost libraries). Borland have announced that they are completely re-architecting their compiler for this release. Chris Trengove ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Variant Library: top level const types
I argue that top-level const type arguments are meaningless in the context of variant. Given the example you provide: typedef boost::variantint const, std::string const GlobalParameter; GlobalParameter input_socket(12345); input_socket = 54321; // no way to prevent this!! How come!? It should be very easy to prohibit all mutating operations for variant once it has top level const bound types (with static asserts) We can put it in the docs, but it seems straightforward that a const variant would, in fact, not allow modification. What reason would lead someone to believe otherwise? No. I meant that: Would we decide to keep the current semantic (without top level const) we need to say explecetly what to do to define variant type for constant object. Gennadiy ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: visitation algorithm
case MAX_WITCH: visitor( Typelist[MAX_WITCH](storage) ); break; } } Your pseudo-code is misleading. There is no MAX_WHICH available to the preprocessor when MPL-sequences are given because there is no theoretical upper limit on the size of a type-sequence. 1. There is theoretical limits for the size of MPL sequences. See MPL docs (BOOST_MPL_LIMIT_LIST_SIZE for list) 2. You could limit variant support only for lists that does not exceed your own limit BOOST_VARIANT_LIMIT_TYPES. 3. You could choose/define any other arbitrary limit (it should probably exceed limits mentioned in items 1 and 2) All you need once you chose the limit is to add default clause to above switch statement with static assert in it. So I believe my code is perfectly implementable. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Variant Library: variant size and strong guaranty
2. Could type that implements swap() method somehow follow the second case road also? For example, could you somehow deduce T* from buffer and swap it with local copy of the argument? Yes, I can look into such optimizations. But as I noted in previous messages, if I can prevent double-storage only for incompleteT (a point on which I'm not certain is even true), it's probably not worthwhile. After all, sizeof(incompleteT) == sizeof(T*), so double-storage means 2*sizeof(T*). So the tradeoff here is extra 4 bytes for the object size plus double indirection for all access operations. Here the question arise then why not use virtual function based solution then? I bet it will be incomparably more simple to understand and probably easier to use. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
