- Boost - lists.boost.org

[mpl] replace_if
by Jonathan Turkanis 21 Nov '04

21 Nov '04

Hi Aleksey, The new MPL document is very nice! I believe the synopsis for replace_if (http://www.boost.org/libs/mpl/doc/refmanual/replace-if.html) is missing the third template parameter. Is that correct? Jonathan

2 3

Can I get the function signature of the result of a bind() ?
by Roland Schwarz 21 Nov '04

21 Nov '04

Sorry if my question seems somehow weird. I already posted a similar one to the users list but with no result. So I try again but also post a small example to make my question clear. The purpose of the example is to autoconnect a couple of member classes to a containing class without the need to explicitely call the constructors of the member classes: #include <boost/signal.hpp> #include <boost/any.hpp> #include <boost/bind.hpp> boost::any pinit; // todo: should be thread local in MT version template<typename Function> struct ctor_signal_push : public boost::signal<Function>{ ctor_signal_push() { pinit = this; } // todo: make it a stack }; template<typename Signature, typename Function> void ctor_connect(Function fn) { boost::any_cast<ctor_signal_push<Signature>* >(pinit)->connect(fn); // can this be done without the Signature parameter? // i.e. can the Signature be deduced from Function? (which might be a functor) } class A; class B { public: B() { ctor_connect<void (A*)>(boost::bind(init, this, _1)); } void init(A* p) { pOuter = p; }; A* pOuter; }; class C { public: C() { ctor_connect<void (A*)>(boost::bind(init, this, _1)); } void init(A* p) { pOuter = p; }; A* pOuter; }; class A { public: A(); ctor_signal_push<void (A*)> init; B aB; C aC; B aB1; B aB2; // ctor_signal_pop; }; A::A() { init(this); // connect all member classes } int main(int argc, char* argv[]) { A aA; return 0; } This does work well so far, but I would like to get rid of the explicit "void (A*)" parameter in ctor_connect<void (A*)>(boost::bind(init, this, _1)); Is this possible? Perhaps I am even trying to do something that I should better avoid because there is a better solution available. Does anyone know? Thank you for any hints, Roland

1 0

Re: [boost] Re: Front page redesign...
by JOAQUIN LOPEZ MU?Z 21 Nov '04

21 Nov '04

Hi Jeff ----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Noviembre 21, 2004 4:29 pm Asunto: Re: [boost] Re: Front page redesign... [...] > I'll have some additional thoughts on content organization if I > can ever get > finished with my OOPSLA workshop writeup. We had some specific > discussionsabout content changes that need to be made... > Dou you have any idea when you'll have this done? I'm very much interested in knowing what the workshop came up with (as most of us here at the list, I guess.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: Re: Re: shared_ptr and serialization
by Dave Gomboc 21 Nov '04

21 Nov '04

> Honestly, I don't need to serialize std::tr1::shared_ptr - why would > any of us ever use it as long as we have boost::shared_ptr which (with > serialization is a superset of std::tr1::shared_ptr.) That's a completely bogus argument. > I understand your objection to boost::serialization depending upon the > implementation details of boost::shared_ptr. I just don't see any way to > address this other than making big changes to either the serialization > libary or shared_ptr. Even then, its not obvious to me that its even > possible. Doesn't Peter's own serialization library succeed in not requiring special access to boost::shared_ptr? If so, it is an existence proof that there's a way to do it, which I think means that big changes may need to be made to Boost.Serialization. It will be a reasonable expectation for a Boost.Serialization user to serialize std::tr1::shared_ptrs in the future. Has Peter described the algorithm he used? Dave

3 2

[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