- Boost - lists.boost.org

VC8 type traits documentation
by Carl Daniel 13 Jul '05

13 Jul '05

Peter Dimov asked, and I don't recall seeing an answer posted (back on May 5): "Where is the instrinsic support documented, BTW?" Here: http://msdn2.microsoft.com/library/ms177194(en-us,vs.80).aspx -cd

3 3

Interest in a binary_int template for binary literals?
by Scott Schurr 13 Jul '05

13 Jul '05

Greetings, Prompted by some discussion on comp.sdt.c++.moderated, I have a small template that allows the user to declare an integer literal in binary. Usage looks like: #include "binary_int.hpp" unsigned int binary = binary_int<1001,0011,1011,0000>::b; The template is written to support up to 64 bits, although my compiler only allows me test up to 32 bits. I intend to use it for programming hardware registers in the language of the hardware folk at my company. The template is only about 150 lines and doesn't really deserve a library, but it could potentially be tucked into another library if it is deemed useful. Thanks. Scott Schurr

6 6

BOOST_NO_RESULT_OF
by David Abrahams 13 Jul '05

13 Jul '05

I want this macro for the parameters library. Currently, result_of uses #if !defined(BOOST_NO_SFINAE) && !defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION) And otherwise, gives an #error That makes it hard to use portably, because the criteria under which result_of will be supported are not encapsulated, and I couldn't even define it in that file usefully (I'd still get an #error when it isn't supported). Shouldn't there be a generalized way to handle this sort of situation? -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 5

Re: [boost] Bug in boost::thread
by Gili 13 Jul '05

13 Jul '05

> I don't understand. What about the quite explicit message in > http://www.boost.org/doc/html/threads/implementation_notes.html#threads.impl > ementation_notes.win32 ? > > /David Well, I never read that. I highly recommend you copy that note over to the documentation for the Thread constructor. The limitations should be attached to the method in question, not in some arbitrary chapter later on (no one reads manuals cover to cover). Just my 2 cents. Gili

1 0

Mysterious Cygwin GCC 3.4.4 link problems
by David Abrahams 13 Jul '05

13 Jul '05

Does anyone have a clue about this? Other toolsets, including gcc-2.95.3, gcc-3.3.3, and gcc-4.0.0 all work fine. "/usr/local/gcc-3.4.4/bin/g++.exe" -Wall -ftemplate-depth-100 -O0 -fno-inline -g -DBOOST_ALL_NO_LIB=1 -I"..\..\.." -c -o "..\..\..\bin.v2\libs\parameter\test\sfinae.test\gcc-3.4.4\debug\sfinae.o" "sfinae.cpp" "/usr/local/gcc-3.4.4/bin/g++.exe" -o "..\..\..\bin.v2\libs\parameter\test\sfinae.test\gcc-3.4.4\debug\sfinae.exe" "..\..\..\bin.v2\libs\parameter\test\sfinae.test\gcc-3.4.4\debug\sfinae.o" -g /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_terminate' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_terminate' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_unexpected' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_terminate' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_terminate' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_terminate.o):: undefined reference to `___w32_sharedptr_unexpected' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_throw.o):: undefined reference to `___w32_sharedptr_unexpected' /usr/lib/gcc/i686-pc-cygwin/3.4.4/libstdc++.a(eh_throw.o):: undefined reference to `___w32_sharedptr_terminate' collect2: ld returned 1 exit status -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2

Bug in boost::thread
by Gili 13 Jul '05

13 Jul '05

If one creates a new boost::thread within DLLMain or a function it invokes, CreateThread (invoked by Boost) creates a new thread but does not start it. Boost's code then waits on the native thread to start before returning from the constructor but because this never occurs it blocks forever. You should either document this limitation (i.e. one may not create a boost::thread within DLLMain or a function invoked by it) or change the implementation to handle this limitation. Thank you, Gili -- http://www.desktopbeautifier.com/

4 3

Problem with Boost 1.32.0 and the Borland free compiler
by Sean Childs 13 Jul '05

13 Jul '05

I get this message when using boost/regex (it may or may not occur with other boost libraries, I havn't checked): Warning W8097 H:\Libraries\boost_1_32_0\boost/config/auto_link.hpp 240: Not all options can be restored at this time "Fatal F1004 test.cpp 15: Internal compiler error at 0x40638d with base 0x400000 in function main(int,char * *)". On line 240 (or thereabouts) of boost/config/auto_link.hpp (Boost version 1.32.0). This: "#pragma defineonoption BOOST_BORLAND_DEBUG -v" causes an ICE with Borland's free compiler if the option -v is not already being used. I don't know if this is common or not, though I did find one other message stating the same problem: http://lists.boost.org/boost/2005/04/25188.php.

2 3

[Boost.build v2 (1.32.0)] Writing an extension for LEIF (XSD to C++ Class Generator)...
by Sylvain, Gregory M 13 Jul '05

13 Jul '05

Hello all, We are currently using boost_1_32_0 and I'm trying to write a toolset file to enable us to use Roguewave's LEIF xsd2cpp C++ class generator from within bjam. (The xsd2cpp command is just a C++ class generator that generates C++ class from a respective W3C XSD Schema). I'm not having much luck, I've been through the boost build manual, samples, etc. and I'm still having problems. In the end, I would like to be able to write a library rule such as : lib libclientxml : schemas.xsd ; And have boost run RW's xsd2cpp tool run on the file schemas.xsd and all of the resulting cpp files that are generated would be compiled and archived in libclientxml. I have a toolset file in my boost-build/tools directory as follows: ---- begin file boost-build/tools/xsd2cpp.jam ---- import type ; type.register XSD : xsd ; import generators ; class cpp-generator : generator { rule __init__ ( * : * ) { generator.__init__ $(1) : $(2) : $(3) : $(4) : $(5) : $(6) : $(7) : $(8) : $(9) ; } # after the actions is executed, get a list of the generated targets that # results from this action rule generated-targets ( sources * : property-set : project name ?) { local leafs ; local temp = [ virtual-targets.traverse $(sources[1]) : : include-sources ] ; for local f in $(temp) { leafs += $(f) ; } return [ generator.generated-targets $(sources) $(leafs) : $(property-set) : $(project) $(name) ] ; } } generators.register [ new cpp-generator xsd2cpp.xsd2cpp : XSD : CPP ] ; actions xsd2cpp { # run RW's xsd2cpp command over the source and produce a lot of C++ code. xsd2cpp -STL "$(>)" } ---- end file boost-build/tools/xsd2cpp.jam ---- If anyone has a clue how to do this, please let me know. Or if I've going about this the wrong way, I would like to here that as well. Thanks for any assistance with this, greg

2 1

Re: [boost] Bug in boost::thread
by Jost, Andrew 13 Jul '05

13 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Jonathan Turkanis > Sent: Wednesday, July 13, 2005 12:38 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Bug in boost::thread > > David Bergman wrote: > > I don't understand. What about the quite explicit message in > > > http://www.boost.org/doc/html/threads/implementation_notes.html#thread > > s.impl > > ementation_notes.win32 ? > > I'm not sure that "Implementation Notes" is a good subject > heading for a descriptions of implementation limitations. > "Implementation Notes" sounds like it will contain a > discussion of how the library interface is implemented, > rather than how the library fails to implement the interface. I agree. > I'd prefer "Limitations of the Current Implementation." > > Jonathan > Or, "Known Problems" > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Posting Etiquette -- Replying to Regression Results Posts
by Jeff Garland 13 Jul '05

13 Jul '05

All - When replying to a 'regression results post', please change the subject line if you are narrowing the focus of the discussion to a single or couple libraries. It's really annoying to have to look thru post after post to see if your library is involved in the discussion. See my recent post for an example. This will only take a few seconds, but will save many others time in filtering thru all the posts. Thanks, Jeff

1 0