- Boost - lists.boost.org

[patch] Fix for Boost.Test (bad XML format)
by Ferdinand Prantl 26 Nov '04

26 Nov '04

Hello, here we are yet another one fix for Boost.Test. Ending tangs of TestCase and TestSuite were accidentally extended with a dangling attribute value, e.g.: </TestSuite="UnicodeTest"> The fix for supplied_log_formatters.cpp is attached and it's quite clear. Apparently my former fixes did no get into 1.32; they help only HP compiler anyway, and maybe only the version I use. This one is more serious ;-) F. -----Original Message----- From: Ferdinand Prantl Sent: Friday, November 05, 2004 12:35 To: boost(a)lists.boost.org Subject: Compile fix for Boost.Test for aCC on HP-UX Hello, you can find a small fix for boost/test/detail/basic_cstring/basic_cstring.hpp attached and a dirty workaround for a compiler bug in aCC for boost/test/unit_test_suite.hpp. As of the latter; the compiler seems to get confused by equal names in different namespaces and classes; renaming Impl helps or making the previous structure friend helps too (this I chose to minimize the change). Ferda HP-UX B.11.11 U 9000/800 aCC: HP ANSI C++ B3910B A.03.37 <<basic_cstring.hpp.diff>>

1 0

Re: Boost Sandbox layout?
by Rene Rivera 26 Nov '04

26 Nov '04

Any comments on this from the Boost Sandbox admins, or anyone? -------- Original Message -------- Subject: Re: Boost Sandbox layout? Date: Wed, 17 Nov 2004 18:41:58 -0600 David Abrahams wrote: > Rene Rivera <grafik.list(a)redshift-software.com> writes: > >>Was there ever a discussion as to the layout? (A cursory search did >>not reveal anything) > > I like what I _think_ you're suggesting we actually should do, but > would you mind spelling it out for everyone's benefit? I was trying not to prejudice the conversation if there was already reasons for the current layout... But since you ask :-) I think it would more beneficial to have each library in an individual sub directory of the boost-sandbox. Each library would still be required to follow the regular Boost layout within itself. For example I'm putting together the warnings submission and it would be nice to set it up like this: /boost-sandbox/warnings /boost/utility/warnings.hpp /libs/utility /docs/warnings.html /test /Jamfile /nowarn_unused_var_test.cpp Having the isolated subdir would remove the 3 drawbacks I mentioned. But itself has some drawbacks: 1) Some of the setup files would be duplicated. Like the boost.png, Jamfile, Jamrules, and boost-build.jam at the "top" level. But at the same time it means that the library would be truly standalone. 2) An eventual long list of directories right at the top. One advantage is the reduce complexity of management by the library authors. As it would be much easier to do things like remove a library from the sandbox after it's been accepted into Boost, a single recursive cvs remove and commit instead of finding all the files and dirs. It might even be possible to setup some form of script automation to make snapshots of the individual libraries automatically available (without CVS access). -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

5 7

[fsm] Adapted to 1.32
by Andreas Huber 25 Nov '04

25 Nov '04

Dear Boosters The fsm submission has been adapted to the 1.32 release. The zip can be found here: http://boost-sandbox.sf.net/fsm.zip The docs are also available online: http://boost-sandbox.sf.net/libs/fsm Feedback is highly welcome! Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

interest in a type_iterator (cast_iterator) ?
by troy d. straszheim 25 Nov '04

25 Nov '04

I'm wondering if there is any interest in a "type_iterator", built on top of the iterator_adaptor. If so I'll send it out. It is a kind of combination of transform_iterator and filter_iterator, where the transform is a cast, and the filter predicate is whether or not each entry in the container passes the cast. This you would want to do when iterating over heterogenous containers (where you are forced to reconstruct type information by downcasting) or containers of boost::any. I was going to call it downcast_iterator but the boost::any stuff isn't a downcast, so I came up with type_iterator. Maybe cast_iterator is better? Generally it looks like this type_iterator<TypeThatIWant, UnderlyingIterator> Here's an example: struct Base { virtual ~Base() {} }; struct Derived : public Base { virtual ~Derived(){}; virtual void OnlyDerivedHasThis(){} }; vector<Base*> v; // love boost::assign v += new Base, new Derived, new Base, ... etc. type_iterator<Derived,vector<Base*>::iterator> iter = make_type_iterator<Derived>(v.begin(), v.end()); while (iter.base() != iter.end()) { (*iter)->OnlyDerivedHasThis(); ++iter; } In order to cooperate with associative containers, containers of shared_ptr's and so forth, the type_iterator maps the type of the underlying iterator (and the cast used) like this: underlying iterator's type_iterator's cast reference_type reference_type ----------------------------------------------------------------------------- Base*& Derived*& dynamic_cast<> shared_ptr<Base>& shared_ptr<Derived>& dynamic_pointer_cast<> any& Derived*& any_cast<> pair<T,Base*>& pair<T,Derived*>& dynamic_cast<> pair<T,shared_ptr<Base> >& pair<T,shared_ptr<Derived> >& dynamic_pointer_cast<> pair<T,any>& pair<T,Derived*>& any_cast<> For instance: type_iterator< Derived, std::map<string,shared_ptr<Base> > > iter; *iter <= returns type pair<string,shared_ptr<Derived> >& I'm sure there are things that need changing, (for instance, should the "any" map to Derived* or just Derived? Should it incorporate the behavior of indirect_iterator and do an extra dereference? Dunno.) I'm just wondering if there is interest before I generalize too far beyond what my client needs. DISCLAIMER: it's widely believed that the need to iterate like this (or the need to downcast at all) indicates a lousy inheritance hierarchy and that in these cases the desire to downcast should be removed via improving the base classes. I hope I don't provoke any lectures on the evils of downcasting: this iterator is not intended to substitute for good class design... cheers, troy d. straszheim

1 0

Boost Shmem-Shared memory library first archive available
by Ion Gaztañaga 25 Nov '04

25 Nov '04

Hello to all, As promised two weeks ago, I have a first rough version of shared memory library in Yahoo Files. I've renamed and reenginered the classes from my STL in shared memory article and boostified almost all parts. The file is in: http://groups.yahoo.com/group/boost/files/boost.shmem.zip Shared memory mutex interface is taken from Boost Threads and scoped locks are needed to lock the mutexes. Since thread scoped locks can't be used from single threaded processes due to header checks, I've cloned them in Boost Shmem, but I would want to reuse thread locks if this library goes on. The offset smart pointer takes much of its interface from boost smart pointers. Boost config is used to build the different dll versions with auto-link and some boost utilities are used (noncopyable for example). This version uses templatized shared memory front-end so that a new shared memory management allocation can be used without changing existing code. In general, I've tried to all that I think it was necessary to adapt to boost, although surely there are many flaws here. The boost shmem jamfile builds for VC-7_1 in WinXP and gcc 3.4.1 in Mandrake 10.1. I've put several test and example files, although my poor jam knowledge makes that tests can only be build for windows using bjam (i don't know how to pass -l link specific options when building in linux to link with librt.a, sorry). Under proj directory there are some VC .NET IDE files to build the library, examples and tests and also a Makefile to build all under linux). I've also documented almost all files using doxygen style and the reference can be build using bjam --v2. If this library goes on, I plan to build a complete boostbook, since I've been reading all the documentation from boost utils. For now, there is a single page help as a tutorial/internal explanation. I would to know if those people that saw the library idea as interesting need any more features for this first version. Francis Andre needs some more sofisticated options and I would like to work with him for a more elaborated version if this library is accepted for boost. Francis suggested compatibility with boost.serialization and I would need some help with that. For this first and surely far from acceptable version I would like receive any comment you like regarding dessign, interface, etc... Help with bjam for building all correctly will be appreciated. I've put some attention in exception handling but surely there will be some problems due to my lack of experience in this area. If anyone wants to colaborate in any aspect of this library, please let me know, I'm totally open for this. Regards, Ion Gaztañaga

3 2

[signals] Replacing a connected slot
by Jody Hagins 25 Nov '04

25 Nov '04

I have a class that needs to react to a particular signal. However, the manner in which it handles the signal is state dependent. I would, therefore, like to change the connected slot when necessary. In general, this is not a problem. However, changing the connection inside another slot is problematic. For example, assume that Foo::bar() is already connected to signal_, and signal_() is called... void Foo:: bar() { std::cout << "Foo::bar()\n"; current_connection_.disconnect(); current_connection_ = signal_.connect( boost::bind(&Foo::bar1, this)); } void Foo:: bar1() { std::cout << "Foo::bar1()\n"; } What I want to happen is that bar() will be called, then it will be disconnected, and bar1 will then be connected in its place. For example, given this calling sequence... signal_(); signal_(); I expect to see... Foo::bar() Foo::bar1() However, sometimes I may see... Foo::bar() Foo::bar1() Foo::bar1() because bar1() MAY get connected AFTER the place where bar() used to be connected, resulting in it also being called for the same signal invocation. What I think I want is a way to "replace" a connected slot, without disturbing anything else... void Foo:: bar() { std::cout << "Foo::bar()\n"; current_connection_.replace_slot(&Foo::bar1, this); } This is especially important if the slot is originally connected with... signal_.connect( invocation_level, boost::bind(&Foo::bar1, this)); because I see no way to retrieve the ordering information from the connection. In any event, how do you suggest I "replace" a conected slot, while still guaranteeing that the "connection" is invoked exactly once? Thanks!!!

2 3

Re: Boost Shmem-Shared memory library first archiveavailable
by ION_G_M 25 Nov '04

25 Nov '04

Thank you Pavel for your comments, I would like to comment on some things >1. The HTML documentation does't allow to change font in browser. >2. End of document can be marked so it doesn't > look like cut in half during transmission. >3. docs 3.2: Sorry for errors and bad html. It was generated from MS Word so I will try to rewrite it using plan html. I'll change that shortly. >4. Example in 3.2: the "alignement" parameter in > segment.create() isn't found in code. I can't find the error you mention, I've just downloaded the zip file and 3.2 does not have any example. In 4.2 segment.create is missing a ",". >5. Example in 4.2: > segment.named_new<MyType> > ("MyType instance", /*name of the object*/ > 10 /*number of elements*/, > false /*if previously present, return error*/, > 0 /*ctor first argument*/, > 0 /*ctor second argument*/); a.It returns false. Exceptions are used only to indicate memory errors throwing bad_alloc. You are right there is info missing here. I will add more documentation in examples. b.If you find this approach more useful, I have no problem. I really don't like the boolean parameter, but I wanted to have a "find or create" functionality. If you like a find_or_named_new<>() additional function to indicate that approach I find it more clear than with a boolean parameters. c.The syntax you propose is better, no doubt. I don't have experience with it so to implement this I suppose named_new<> should return an proxy object with overloaded operator()() functions. Is that right? If you want to help me I'm open. If boosters prefer throwing exceptions instead or returning false no problem here. A problem I see is that my interface allows creating an array like new[]. Do you consider this necessary? You prefer a different function? Maybe the proxy object should have an operator[] that can be used to specify array allocation? > std::pair< MyType *, std::size_t> res = > segment.find_named_new< MyType > ("MyType instance"); >Why do I need the "size"? Doesn't a type have >always the same size regardless? Size contains the number of elements in case you allocate an array. with segment.named_new<MyType> ("MyType instance", /*name of the object*/ 10 /*number of elements*/, ... you allocate an array of 10 elements. so it will return 10. >6. Could you use namespace shmem_detail or so > instead of "detal" to avoid possible clashes? No problem. I've seen detail namespace in some projects so I thought it was not a problem. detail namespace is inside boost::shmem namespace so it wouldn't be necessary. You find it necessary even if detail namespace is really boost::shmem::detail? >7. exceptions.hpp: >a) file name should be shmem_exceptions.hpp or so No problem >b) does it make sense to have common base > for both exceptions there? My exception handling experience is null, so I based all in thread exception examples, where lock_error inherits from thread_exception. No problem changing this is you find it necessary. >8. offset_ptr.hpp: full_offset_ptr class >a) using char as de-facto bool class has usually > no practical advantage and may be actually slowe. No problem. You are right, with all platforms using 4 byte alignment bool and char use the same space and it can be slower I suppose due to mask operations. >b) The flag could be eliminated completely. > If m_offset == 0 it is NULL pointer and > no data allocated in shmem will starts > on the beginning. This would also eliminate > need for min_offset_ptr. The offset indicates the distance between the pointee and the this pointer of offset_ptr, so m_offset == 0 indicates a pointer pointing to itself and this is quite common in STL containers when empty, since next pointer in the end node points to end node, resulting in a m_offset = 0. Obviously this is different from a null pointer. If I change the meaning of m_offset to offset from the beginning of the segment I need the base address stored somewhere (and the base address is different in each process), so that I can convert from offset_ptr<A> to A* using get() or the constructor. Using my approach I can convert between A* and offset_ptr<A> without any additional data. Obviously, your approach is more performance friendly since m_offset does not need to be changed with each assignment and constructor. If boost people find the additional member as a waste comparing to A* <-> offset_ptr<A> conversions I would change it but I find my approach quite useful, since I don't want to deal with base addresses stored somewhere for each process when building a offset_ptr. >c) swap() could be added and other operators. Ok. I will add it. Which other operator you miss? >9. Maybe the protection of mutext from shared ptr > lib could be worked around I don't understand your point. Could you give me an example please? >10. The example in 4.3 uses very dirty C-like > approach with casts. Cannot it be rewritten > in C++ way with overloaded new? If you refer to (list_node*)segment.allocate(...) line, segment in this case is a low-level void* returning function. If you prefer an allocate<Type> approach, I don't have any problem, but remember that this segment object is of type shmem_alloc which allocs raw memory, something like when writing your own void* operator new(size_t size) for a class. If you have I workaround in mind, please let me know. >11. Some source files use Unix line ends, > some DOS line ends. Just bit strange. It's because I've tested and changed things in both windows and linux. I'll try to convert all to a common line feed. >12. The simple algorithm to find fitting memory > block may not be adequate for high-performance > apps (who are most likely to use shared > memory). You are right. The default algorithm is space-friendly, which I thought it was more important than performance for fixed size segments. You can write your own algorithm and use it since shmem_alloc is a typedef of basic_shmem_alloc<default_algo>. If you prefer another algo like segregated lists, I can try to write it, so that the user can choose the allocation algorithm. I've written the pooled allocator due to default algorithm slowness. >13. Can be be possible to identify named objects > with something else than C string? Say > wchar_t* or numeral or other templated type? Well, I've chosen a c string as an universal name, but other types could be used. Do you think that the key type should be templatized? I think that an integer key can speed up a lot searches but I have to think about which classes should be templatized. When storing other type of strings (for example std::string, I would need to build an allocator for strings in shared memory but also a std::string since it's probable that current STL won't work with Shemem STL allocator). The key meaning would be different since right now, I copy the string to shared memory but with configurable key type things are more complicated. >14. What I would like to see: >a) avoiding shmem specific containers/mutexes/etc > as much as possible. I think you can't avoid mutexes if you want to guarantee atomic memory allocation, since I have no skills to write a lock-free memory allocator. Regarding to containers, it was no my intention to write them, but I needed some of them to store name-buffer mappings and a node container to test the pooled allocator in several systems. For now, I have only succeed using shmem STL allocators in a modified Dinkum STL. STLport and libstc++ use suppose allocator::pointer to be a raw pointer, so I can't use STL containers. I've chosen internal containers to be public because I find them very useful, but if this is not accepted they can be used only for internal uses and removed from documentation. Regarding mutexes and etc... can you be more explicit? I propose mutexes to be general. If boost want to implement process-shared mutexes in other way, say in another library, I would use them, but for the moment, this is all that I have. >b) ability to "equalize" shared memory features I would need some help in this because my operating system knowledge is very limited. Mimic-ing UNIX way in windows can be very difficult, I think, unless you use a mapped file. I would need some serious help here. >c) support for inheritance in shmem using object > factories, e.g. like one in Classloader > http://s11n.net/papers/classloading_cpp.html I'll check it. Thanks for the url. >d) support for "transactions": I would like to My knowledge in transaction world is null so I can't help you with that. I suppose that a shared memory condition variable should be very interesting to notify events to other processes, but I'm afraid this is a work for more skilled programmers than me (people from boost::threads, perhaps?). As far as I know in windows is difficult to implement a shared memory condition variable, pthreads-win32 does no support it and I don't know how cygwin solves this. Thank you again for all your comments. I would like to make some changes you've suggested, so I will wait your response regarding open issues and comments from other boosters before doing any change. Regards, Ion

3 4

[iostreams(jonathan)] - using with 1.32
by Jeff Flinn 24 Nov '04

24 Nov '04

Jonathan, Do you have a version that works with the 1.32 release? If not any suggestions on modifications for use with 1.32? The two main items I see are mpl/apply_if.h and utility/select_by_size.hpp. I've change the includes for ...mpl/apply_if.h to mpl/eval_if.h and occurences of apply_if to mpl::eval_if. Is that sufficient? I've copied boost_1_31_0/utility/select_by_size.hpp to boost_1_32_0/utility/select_by_size.hpp . Is this sufficient? I've got some other compile errors but I'm not sure if they are just downstream errors caused by these issues. Thanks, Jeff

3 7

RE: [boost] preprocessor fix
by Arias Brent-P96059 24 Nov '04

24 Nov '04

I can't allow the boost mailing to pour into my work account over the holidays, so I'm unsubscribing. However, I'd like to continue our conversation - I guess offline if thats ok. I'll want to ask about updates to Besser's printable enum for starters. My e-mail is panoply(a)att.net By the way, what other portions of Boost have you contributed to besides preprocessor programming? Remember, I will have already unsubscribed before you can respond to this letter - so if you respond, please respond to the e-mail I provided. Thanks, -Brent -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org]On Behalf Of Paul Mensonides Sent: Tuesday, November 23, 2004 6:53 PM To: boost(a)lists.boost.org Subject: RE: [boost] preprocessor fix > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Arias Brent-P96059 > > Have you seen > http://www.cuj.com/documents/s=8470/cujboost0306besser/? > > > Yes, I have seen that before. I did not use it for several > reasons: (1) I think the source for Besser's ENUM was not > easily available, (2) my employer gets nervous when code > "looks" too C++ oriented and gets nervous when macros become > too "involved" - which means "lengthy" (3) Besser's ENUMX > macro requires that you specify the number of parameters > (e.g. ENUM3 or ENUM23). I believe that he got rid of that (really annoying) issue. At first, that code was written more like the pp-lib itself is written--repetition of macros. That almost defeats the purpose of using the pp-lib at all. The pp-lib's strength is that it provides basic interfaces that enable you to build more complex interfaces or solutions. That basic interface provides, among other things, an abstraction layer over manual repetition of macros--so clients don't have to do it. Later on, I think that the code changed to using sequences. > Reason #3 was a real hurdle for me - because I'm trying to > provide this macro to other developers who might "rebel" if > using the macro requires from them non-intuitive new concepts > or exercises. That is, if they didn't have to count the > number of parameters in the enumeration before - they may > well reject the ENUM macro if it starts to require them to > count the entries. I definitely understand that. > So, I set out to make an ENUM macro that (1) didn't need its > entries counted by the developer and (2) had a short > definition (which makes it less daunting for "managment" buy-in). I understand that as well. :( > You said: > > >there are still basic notions of computation, etc., such as control > >flow--which is nothing but a conditional "invocation" > >of its accompanying code. Those kinds of things still apply at the > >preprocessor level. What you really needed was a way to > conditionally > >enumerate some sequence elements, not enumerate a > conditional sequence. > > My implementation was "backwards" because I was unable to > make the code compile otherwise. That is, depending on the > value of ENUMS, the following code did not compile: Sorry, I'm getting way too used to variadics. If SEQ_ENUM generates more than one comma-separated element, then the comma will interfere with the internals of EXPR_IIF. E.g. #define CAT(a, b) PRIMITIVE_CAT(a, b) #define PRIMITIVE_CAT(a, b) a ## b #define EXPR_IIF(bit, expr) PRIMITIVE_CAT(EXPR_IIF_, bit)(expr) #define EXPR_IIF_0(expr) #define EXPR_IIF_1(expr) expr #define COMMA() , EXPR_IIF(0, a COMMA() b) EXPR_IIF(1, a COMMA() b) Both of these invocations will (i.e. "should") fail. For 'expr', EXPR_IIF gets the argument "a COMMA() b". That is fine because it is a single argument. However, macro arguments (by default) are expanded _before_ they replace the formal parameter instances in the replacement list. The argument "a COMMA() b" expands to "a , b". With that, the expansion procedes as follows: EXPR_IIF(0, a COMMA() b) 0 -> 0 a COMMA() b -> a , b -> PRIMITIVE_CAT(EXPR_IIF_, 0)(a , b) -> EXPR_IIF_0(a , b) // error: too many arguments The same thing occurs if 'bit' is 1, and that is what is occuring with EXPR_IIF and SEQ_ENUM. BTW, an argument that expands to include open commas (i.e. it becomes more than one argument when passed again) is called (by me) an "intermediate". Dealing with intermediates is one of the major reasons why the pp-lib source is as hacked up as it is because many preprocessors don't do the expansion order correctly. Using intermediates requires that a single argument become some known number of arguments at a fairly particular time. BTW2, for anyone that may be interested, placemarkers (which is, in essence, C99 uses to deal with empty arguments) can be used to prevent argument expansion pretty much indefinitely. E.g. #define A(x) B(x) #define B(x) C(x) #define C(x) D(x) #define D(x) x A(x) Here 'x' gets scanned for macro expansion once on entry to A, once on entry to B, once on entry to C, once on entry to D, and once again during the rescan of D's replacement list. It gets scanned for macro expansion a total of five times. However, #define A(p, x) B(, p ## x) #define B(p, x) C(, p ## x) #define C(p, x) D(, p ## x) #define D(p, x) p ## x A(, x) Here 'x' gets scanned once--during the rescan of D's replacement list. (You can't get rid of that one.) The point of this is optimization. Scanning preprocessing tokens for expansion can become expensive (especially when the scan is a no-op--which the preprocessor cannot assume). For example, the following code... #define A(x) B(B(B(B(B(B(x)))))) #define B(x) C(C(C(C(C(C(x)))))) #define C(x) D(D(D(D(D(D(x)))))) #define D(x) x ...has more computational power than the pp-lib. The 'x' argument gets scanned 260 times. If there was nine macros (instead of four), the scan count is in the millions. With thirteen, the scan count is in the billions. It is a sum of powers plus one scan on entry to A. If 'n' is the number of macros, and 'b' is the parametric base (i.e. the number or "M(M(M(M(M(M(..." in the replacement lists), then the scan count is 1 + the summation from k=0 to n-1 of b^k -- which can be rewritten as 1+(1-b^n)/(1 - b). [If anyone actually wants to see this in action, try this on a compliant preprocessor (such as gcc)... // file.c #define CAT(a, b) PRIMITIVE_CAT(a, b) #define PRIMITIVE_CAT(a, b) a ## b #define SPLIT(i, im) PRIMITIVE_CAT(SPLIT_, i)(im) #define SPLIT_0(a, b) a #define SPLIT_1(a, b) b #define IS_NULLARY(x) \ SPLIT(0, CAT(IS_NULLARY_R_, IS_NULLARY_C x)) \ /**/ #define IS_NULLARY_C() 1 #define IS_NULLARY_R_1 1, ~ #define IS_NULLARY_R_IS_NULLARY_C 0, ~ #define EMPTY() #define EAT(x) #define IIF(bit) PRIMITIVE_CAT(IIF_, bit) #define IIF_0(t, f) f #define IIF_1(t, f) t #define A(x) B(B(B(B(B(B(x)))))) #define B(x) C(C(C(C(C(C(x)))))) #define C(x) D(D(D(D(D(D(x)))))) #define D(x) E(E(E(E(E(E(x)))))) #define E(x) x #define KILL(x) x #define IS_ALIVE() IS_NULLARY(KILL(())) #define TEXT(t) \ IIF(IS_ALIVE())(TEXT_A, EAT)(t) \ /**/ #define TEXT_A(t) t TEXT_B EMPTY()()(t) #define TEXT_B() TEXT KILL( A( TEXT( Boost ) ) ) gcc --pedantic -x c++ -std=c++98 -E -P file.c ...this generates 'Boost' more than 1500 times. A word of warning: don't actually do this in real code, especially with something that generates lots and lots of scans because even though 't' (called, by me, an "active argument") eventually stops expanding (referred to, by me, as "reaching a terminal state") the preprocessor still performs the scans (etc.)--even though the scans might be no-ops. Scanning, for example, the single preprocessing token + billions of times (and the invocations required to generate those scans) is no small operation--in fact, it takes a *really* *really* *really* long time to generate a single + if you don't run out of memory first (which you probably will).] Obviously, scanning itself can become expensive. It is interesting that the most important benefit of placemarkers may well be that it provides a means to prevent argument expansion rather than providing the means to pass empty arguments (which is also very useful). > > #define ENUM(name, start, entries) \ > > BOOST_PP_EXPR_IIF(ENUMS)( \ > > BOOST_PP_SEQ_ENUM( \ > > (typedef enum { BOOST_PP_SEQ_HEAD(entries) = start) \ > > BOOST_PP_SEQ_TAIL(entries) \ > > (LAST_ ## name } name;) \ > > ) \ > > ) \ > You said: > > >You can do it, but EXPR_IIF does not lazily evaluate its > argument (the > >syntax above is what EXPR_IIF would look like if it *did* lazily > >evaluate it argument). > >In other words, when ENUMS is 0, SEQ_ENUM will still be invoked, but > >its results will be discarded. > > I'm not sure what you are suggesting. Depending on the value > of ENUMS, the code snippet I showed above would not compile - > lazy evaluation or not. If it won't compile, then there's > nothing for me to ponder (except to use a different approach > - which happily you taught me with the TUPLE_EAT macro). :) Apologies. I was thinking about EXPR_IIF with variadics. With variadics, you can, ala: #define EXPR_IIF(bit, ...) PRIMITIVE_CAT(EXPR_IIF_, bit)(__VA_ARGS__) #define EXPR_IIF_0(...) #define EXPR_IIF_1(...) __VA_ARGS__ E.g. here the number of arguments doesn't matter. If, on the other hand, EXPR_IIF did lazy evaluation, then you can still do it without variadics: #define EXPR_IIF(bit) PRIMITIVE_CAT(EXPR_IIF_, bit) #define EXPR_IIF_0(expr) #define EXPR_IIF_1(expr) expr syntax: EXPR_IIF(bit)(expr) Here, 'expr' doesn't get expanded at all if 'bit' is 0. The side-effect of lazy evaluation is that the argument is not passed on (internally) to another macro, which means that the situation that occurs in the pp-lib-style EXPR_IIF (the first one above) cannot occur. I could redesign EXPR_IIF (etc.) using the "EXPR_IIF(bit)(expr)" form. That would allow the code to work. I still couldn't guarantee lazy evaluation, of course, because preprocessors are terrible in general. However, if I do so, I open an encapsulation hole in the workarounds for various preprocessors. Granted, there are many of those already--the pp-lib cannot actually "fix" broken preprocessors after all--but client exposure is minimized. Regards, Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re: [boost] Re: Merge of RC_1_32_0 with trunk?
by JOAQUIN LOPEZ MU?Z 24 Nov '04

24 Nov '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Miércoles, Noviembre 24, 2004 6:00 pm Asunto: Re: [boost] Re: Merge of RC_1_32_0 with trunk? > Joaquín Mª López Muñoz writes: > > OK. A note of warning, though: during the last days before the > release,> Aleksey commited some changes to the docs directly in > the branch. These > > changes affect: > > > > 1. The main page (portions of the release notes) > > 2. The MPL docs > > 3. Boost.MultiIndex (some docs pages) > > 4. Other libraries? > > > > I'm sure Aleksey'll take care of 1 and 2, > > I'm going to take care of everything. > Oh, I'm afraid I've already done the job for multi_index :( So, you can safely skip that library. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0