November 2004 - Boost - lists.preview.boost.org

[name_params] Flag arguments?
by Rene Rivera 21 Nov '04

21 Nov '04

Dave, Daniel, I have a use case which would be nice to support. I have some functions which take some number of flag arguments, akin to: void foo(const char * name, float value, bool flag1 = false, bool flag2 = false) { std::cout << name << " = " << value << "\n"; } And I can add the named arg interface, so I can use it as: foo((value = 5.2f, name = "baz", flag1 = true)); But ideally I'd like the use to look like: foo((value = 5.2f, name = "baz", flag1)); That is, the presence of the keyword is enough to set the argument to true. Possible? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 2

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

21 Nov '04

>Not a bug. Empty macro arguments are currently undefined behavior in C++. There is nothing that I can do about that. C99 added explicit support for them, but they are not (yet) part of C++. I very much appreciate your answer. And ultimately this hasn't become a big deal, since - as you saw - I found a way around the problem all the same. But now let me answer a very good question you asked: > #define ENUM(name, start, entries)\ > BOOST_PP_SEQ_ENUM( \ > BOOST_PP_IIF(ENUMS, \ > (typedef enum{ BOOST_PP_SEQ_HEAD(entries) = start) \ > BOOST_PP_SEQ_TAIL(entries) \ > (LAST_##name } name;) \ > , \ > (static void PP_NILFUNC();) \ > ) \ > ) >Why are you doing the test *inside* of the invocation of SEQ_ENUM? The short answer: I wanted a **single** ENUM macro definition that permitted the printable strings *AND* the enums themselves to be conditionally compileable. I think my intention will make more sense if I show you the entire printable enum. It looks like this: #ifndef ENUMS /*By default, turn enums on*/ #define ENUMS 1 #endif #ifndef ESTRINGS /*By default, turn printable strings on*/ #define ESTRINGS 1 #endif #ifndef EDEBUG #define EDEBUG 0 /*By default, turn ESTRINGS "compliment" condition off */ #endif /*Used internally by the ENUM macro*/ #ifdef ENUM_STR #undef ENUM_STR #endif #define ENUM_STR(r, data, elem) BOOST_PP_STRINGIZE(elem) #define ENUM(name, start, entries) \ BOOST_PP_SEQ_ENUM( \ BOOST_PP_IIF(ENUMS, \ (typedef enum{ BOOST_PP_SEQ_HEAD(entries) = start) \ BOOST_PP_SEQ_TAIL(entries) \ (LAST_##name } name;) \ , \ (static void PP_NILFUNC();) \ ) \ ) \ BOOST_PP_SEQ_ENUM( \ BOOST_PP_IIF(BOOST_PP_BITOR(EDEBUG,ESTRINGS), \ (static const char* name##_Str[]={ BOOST_PP_STRINGIZE(BOOST_PP_SEQ_HEAD(entries)) ) \ BOOST_PP_SEQ_TRANSFORM(ENUM_STR, _, BOOST_PP_SEQ_TAIL(entries) ) \ (};) \ , \ (static void PP_NILFUNC();) \ ) \ ) Now, as I think you pointed out yourself, you can't place the BOOST_PP_SEQ_ENUM inside of a BOOST_PP_EXPR_IIF statement like this: #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;) \ ) \ ) \ So, what I've shown you in the printable enum above was the only solution I could think of to achieve the result: i.e. a **single** ENUM macro definition that permitted the printable strings *AND* the enums themselves to be conditionally compileable. On the other hand, I'm intrigued with what you presented here: #define ENUM(name, start, entries) \ BOOST_PP_IIF( \ ENUMS, \ BOOST_PP_SEQ_ENUM, BOOST_PP_TUPLE_EAT(1) \ )( \ (typedef enum { BOOST_PP_SEQ_HEAD(entries) = start) \ BOOST_PP_SEQ_TAIL(entries) \ (LAST_ ## name } name;) \ ) \ I didn't pay attention to BOOST_PP_TUPLE_EAT when I was (frantically) trying to make a printable enum. Perhaps it is a means by which I can get rid of the "hack" I described earlier? It sure looks like it will work! Oh, by the way, I was so pleased with the printable enum - I was actually thinking of submitting it for inclusion into Boost. Would a submission like that be more nuisance than benefit? Thanks, -Brent

2 1

[Boost-bugs] [ boost-Bugs-1070327 ] vc-7_1-stlport native-wchar_t problem
by SourceForge.net 21 Nov '04

21 Nov '04

Bugs item #1070327, was opened at 2004-11-20 23:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1070327&group_… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: vc-7_1-stlport native-wchar_t problem Initial Comment: There is a problem with "tools/build/v1/vc-7_1- stlport.tools.jam". I tried to build boost 1.32.0 with jam optioned as "- snative-wchar_t=on". But cl option didn't include a '/Zc:wchar_t'. :( Therefore, i modified "tools/build/v1/vc-7_1- stlport.tools.jam" as following (not correct fix, just for workaround) #feature native-wchar_t : off on ; feature native-wchar_t : on off ; Finally it worked! - veblush ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=1070327&group_… ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

boost 1.32 acknowledgements
by Bronek Kozicki 21 Nov '04

21 Nov '04

In the acknowledgements section I see my name twice, while I do not see Aleksey Gurtovoy . I understand that our release manager is very modest person, but listing my name (person who did very little for Boost, if anything) and forgetting name of release manager seems wrong. B.

20 47

Build of boost_1_32_0 hangs on MacOS X build
by Steve Hartwell 21 Nov '04

21 Nov '04

Could other MacOS X developers confirm that the boost build 1.32 candidate fails to build on MacOS 10.3.6 with gcc 3.3? The problem I'm seeing is that while compiling "xml_grammar.cpp", cc1plus slows to a crawl while its virtual memory allocation rises to 1.8GB until my system becomes so unresponsive I have to kill it. Jam then proceeds until the release build of "xml_grammar.cpp", with the same results (cc1plus hanging). Killing that process leads to the same problems in the debug compile of "xml_wgrammar.cpp", as well as the release compile of "xml_wgrammar.cpp". I have observed this problem both with a dual-processor G5 and a single-processor G4. Everything else in the build seems to be proceed OK after I kill the cc1plus processes that hang on "xml_grammar.cpp". The command line I'm using to build is: bjam -sTOOLS=darwin -sBUILD="debug release <runtime-link>static/dynamic" Please let me know if anyone is having better luck with this. Best regards, Steve Hartwell p.s. There is an additional difficulty with the build of boost 'serialization' where some directory names end with ".a" and ".dylib". Although these are legal directory names, this confuses the heck out of the Xcode IDE, and makes it impossible to include the contents of these named directories into an Xcode project. It would be nice if the names of these directories could be changed to end with "_a" and "_dylib" instead, or something similar. p.p.s. boring (but precise) stuff about the cc1plus hang follows: When cc1plus hangs, ps shows the following arguments: /usr/libexec/gcc/darwin/ppc/3.3/cc1plus -quiet -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=0 -D__APPLE_CC__=1666 -D__DYNAMIC__ -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp -D__GNUG__=3 -fPIC -quiet -dumpbase xml_wgrammar.cpp -auxbase-strip bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar o -O3 -Wno-long-double -Wno-inline -Wall -ftemplate-depth-256 -finline-functions -fcoalesce-templates -D__private_extern__=extern -o Since this is all 'ps' is willing to output for this process, here is the parent process, whose arg list seems more complete: c++ -c -ftemplate-depth-256 -DNDEBUG -DNDEBUG -DBOOST_TEST_NO_AUTO_LINK=1 -Wno-long-double -no-cpp-precomp -O3 -finline-functions -Wno-inline -Wall -fcoalesce-templates -Ibin/boost/libs/serialization/build -I/usr/include -I/Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0 -o bin/boost/libs/serialization/build/libboost_wserialization.a/darwin/ release/runtime-link-static/xml_wgrammar.o /Volumes/Nod/Users/hartwell/Documents/Development/Building Blocks/C-C++/BOOST/boost_1_32_0/libs/serialization/build/../src/ xml_wgrammar.cpp

6 8

Library TR draft available
by Beman Dawes 20 Nov '04

20 Nov '04

The latest draft of the C++ Standard Library Technical Report is now available at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1711.pdf There may be editorial (non-substantiative) changes to the final version of the TR document, but this latest draft is believed to be final in terms of technical content. Thus it should be safe for implementors or users to write code based on this latest draft. It will be several years before most compilers come with a full implementation of the TR. But some vendors (Metrowerks, for example) are already shipping a few TR components. That brings up the question of what Boost code does during the transition. To insure Boost code works with various TR implementations, some Boost code will want to use the compiler vendor's version of the TR if the TR component required is available, but otherwise will want to use Boost equivalent code. How do we handle that? The TR doesn't provide in configuration macros, so I guess we will have to roll our own. --Beman

7 17

RE: [boost] GUI validation [was: GUI Library Proposal for a Proposal]
by Arias Brent-P96059 20 Nov '04

20 Nov '04

I have not been paying attention to any of the GUI posts - until now. So I havn't the slightest idea if my comment is relevant. Here it goes: >** events, propagation and handling mechanisms, (event_target, listener, >subscribers...) I've never seen an "events, propagation, handling" mechanism as elegant as Miro Samek's Quantum Framework / Quantum Hierarchical State Machine. If there are any reading this who have not heard of it - you'd do well to buy his book and "settle in". At work we're using it for an embedded software defined radio, and at home I intend on using it for GUI/DirectX development. -Brent

1 0

tarball build doc issue
by Jared McIntyre 19 Nov '04

19 Nov '04

The documentation for bjam setup in more/getting_started.html says to "chdir boost-1.31.0" as a possible place to you may have installed boost. Should this be made 1.32.0? Jared McIntyre

2 1

[jamboost] [fsm] gcc-3.4.x patches
by Juergen Hunold 19 Nov '04

19 Nov '04

Hi ! The attached patch fixes the last problems with gcc-3.4.1 due to missing "template" keywords. Tested against gcc-3.3.4 (SuSE-9.2) Andreas, I tried to sent you my V2 jamfiles to your yahoo.com address, but did not get a reply from you. Is that a throw-away address ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold(a)ive.uni-hannover.de ! www.ive.uni-hannover.de ------------------------ Yahoo! Groups Sponsor --------------------~--> $9.95 domain names from Yahoo!. Register anything. http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/z3wwlB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/jamboost/ <*> To unsubscribe from this group, send an email to: jamboost-unsubscribe(a)yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/

3 5

Macro for using overloaded functions with templated code.
by Daniel James 19 Nov '04

19 Nov '04

I've written a macro (the implementation is attached) for generating a function object for using overloaded functions with generic code such as the STL algorithms and boost::bind. A simple example of it's use: void foo(int); void foo(char*); GENERATE_OVERLOADED(void, foo); int main() { int values[] = { 1, 2, 3, 4 }; std::for_each(values, values+4, foo_overloaded); } GENERATE_OVERLOADED (yes, the naming is pretty bad) creates an object called which contains overloaded calls to operator() which forward to the named functions. Something like: struct foo_overloaded_type { void operator() const { return foo(); } template <class T1> void operator(T1 const& p1) const { return foo(p1); } template <class T1, class T2> void operator(T1 const& p1, T2 const& p2) const { return foo(p1, p2); } // etc. } foo_overloaded; The main advantage is that you don't have to select the desired overload. It can also be useful when different calls will have different argument types such as iterating over a tuple in fusion (I guess you could call it a visitor). Any comments on this? Would anyone else find this useful? Also, has anyone done something similar? I'd be surprised if no one has, I always feel like I'm missing something when I'm doing this kind of thing. The implementation is lacking in several ways - it doesn't work for non-const references, the return type is fixed, needs to deal with member functions, namespace issues and so on. I suppose, it could also be better integrated with bind, lambda or pheonix. Daniel

3 8