- Boost - lists.boost.org

[MSM] compiling MSM with GCC 4.4.1 and -fno-exception
by Richard Szabo 26 May '10

26 May '10

Hi Christophe Thanks for the fix of no-rtti I will try out shortly. I have discovered a similar issue with exceptions. GCC 4.4.1 reports errors when it parses MSM that exceptions are disabled but there is code using that. Thanks Richie

1 0

[thread] r62122 fix for #3178 introduces duplicate symbol
by Lars Viklund 26 May '10

26 May '10

Hi list. In trunk, revision 62122 (which fixes a negative sleeping time bug #3178) added a detail helper function pin_to_zero at boost/thread/win32/thread_data.hpp:148, which isn't marked inline. This leads to multiple symbol definitions for anything that tries to link to Boost.Thread. The fix is trivial, just add an inline. -- Lars Viklund | zao(a)acc.umu.se

2 1

CGI / FastCGI library update
by Darren Garvey 26 May '10

26 May '10

Hi, I have packaged a version of a CGI / FastCGI library* up to sourceforge and would very much appreciate feedback and critique from interested parties. Feedback from this list has been invaluable in the past. You can download the library from: http://sf.net/projects/cgi/files The documentation still needs work, which I am doing as I can find the time. It can be found online at: http://cgi.sf.net/docs and a brief feature list can be found from: http://cgi.sf.net The library interface has reached a relatively stable point after a savage bunch of changes recently and I'm quite pleased with how it is shaping up. A brief list of features of the library are: * Out of the box support for FastCGI and CGI, tested with Apache 2.2 and mod_fcgid on Windows XP, 7 and linux. * Type-safe access to different request data (eg. get / post / environment / cookies) * Access to request data in STL-like constructs, with some CGI-specific helper functions. * Optional support for user-defined, strongly-typed sessions. * A lightweight utility wrapper for using HTML / XML / etc. templates - dubbed "stencils". * A traits-based design that allows library users to alter the implementation of parts of the library at compile time. For reference, the code is also in the Boost sandbox at: https://svn.boost.org/svn/boost/sandbox/SOC/2007/cgi/trunk Cheers, Darren * the one started way back in the GSoC of 2007...

7 21

[log] Forward Declarations
by Christoph Heindl 26 May '10

26 May '10

Andrey, are you thinking about providing a header containing forward declarations of boost.log datatypes? If not, I'd like to request that feature. Best regards, Christoph

3 6

[fusion] type in doc
by vicente.botet 25 May '10

25 May '10

Hi, I guess there is a typo in fusion/extension/sequence_facade.html " The sequence_facade template provides an intrusive mechanism for producing a conforming Fusion iterator. " Instead of iterator should be sequence, isn't it? _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

Re: [boost] [MSM] compiling MSM with GCC 4.4.1 and -fno-rtti
by Christophe Henry 25 May '10

25 May '10

>> Interestingly, this also happens with gcc by simply including >> <boost/function.hpp>. > > I think I fixed this some time ago? Which Boost and which g++? Sorry, you're right, I was trying with 1.40. With 1.42, it works. >> I see there is a BOOST_NO_RTTI switch, does someone see a problem if I >> use it as a way to disable the features making use of any or function? > > BOOST_NO_RTTI is the right switch for any, for function (before the fix) > you'd have needed BOOST_NO_TYPEID. There is a difference on, for example, > MSVC. The switch is actually pretty cool and made my life way easier :) Richard, I just committed the fix in the trunk (https://svn.boost.org/svn/boost/trunk/boost/msm/back/state_machine.hpp) it should work now. Thanks, Christophe

1 0

Re: [boost] [MSM] compiling MSM with GCC 4.4.1 and -fno-rtti
by Christophe Henry 25 May '10

25 May '10

> Hi All > > I try to compile boost msm in an embedded target with gcc 4.4.1 for > performance reasons I want to disable RTTI. > I'm having problems because backend is using boost::any which is uses RTTI. > Is it possible to remove this dependency ?. > or introduce some compile switch like in shared pointers .... > BOOST_NO_STD_TYPEINFO > > Thanks in advance. > Richie Hi all, Interestingly, this also happens with gcc by simply including <boost/function.hpp>. I see there is a BOOST_NO_RTTI switch, does someone see a problem if I use it as a way to disable the features making use of any or function? Christophe

2 1

[serialization] Binary iarchive invalid signature
by Gevorg Voskanyan 25 May '10

25 May '10

Hi, Binary iarchive is supposed to throw invalid_signature archive_exception when the archive content doesn't start with the expected signature. However in some cases a different behavior is observed when trying to load from an invalid archive. For example, if the supposed signature size being read ends up a huge number (can easily happen trying to load from an arbitrary file not created with Boost.Serialization), the program spends a few seconds on line 111 of basic_binary_iprimitive.ipp (s.resize(l);) allocating a big chunk of memory to read the signature into, then tries to read that many bytes from the stream, which, assuming the file is not that large, reads less bytes than requested so it all ends up throwing archive_exception(stream_error) at basic_binary_iprimitive.hpp:164. Another example is when the 'signature size' being read happens to be a larger number still, then s.resize(l); throws std::bad_alloc when in fact the user would want to get archive_exception(invalid_signature) instead. I've attached a patch for archive/impl/basic_binary_iarchive.ipp against Boost 1.43 version that fixes the problem for me. Comments? Thanks, Gevorg P.S. Boost 1.43, Win XP SP2, MSVC 8

2 2

[parameter] arg_list.hpp depends on maybe.hpp
by Andrey Semashev 25 May '10

25 May '10

I've been inspecting my code for a possible compilation speedup. The code uses Boost.Parameter and thus my attention shifted to it as well. I noticed that the parameter/aux_/arg_list.hpp header depends on parameter/aux_/maybe.hpp, which appears to be quite heavy due to its usage of Boost.Optional and other headers. From the code it looks like this "maybe" is only related to python binding, and the only thing arg_list.hpp needs from it is the maybe_base class, which is trivial. Is it possible to extract this class to a separate header and remove the dependency on maybe.hpp from arg_list.hpp or am I missing something? The change looks quite harmless. If I'm not missing anything, am I allowed to apply the change?

4 7

[config] Major upgrade to Boost.Config symbol visibility macros
by Beman Dawes 25 May '10

25 May '10

The upgrade to Boost.Config symbol visibility macros that has been under discussion has been committed to trunk. This lays the groundwork for resolving #2144, #2309, #3697. See https://svn.boost.org/trac/boost/changeset/62140 Thanks Jürgen Hunold for his patches and much other work on symbol visibility issues. The changeset also applied the changes to Boost.System to act as a testbed to ensure the changes are correct. That's a concern because any breakage in Boost.Config could break a lot of other stuff. We also want to get the Boost.Config changes right the first time as they kick off rebuilds of everything that uses the config system. The changes have been tested locally on Windows, Linux, and the Mac, and Boost.Filesystem has been retested on those systems as a reality check that unmodified user code continues to work. As trunk regression tests cycle and our confidence builds, we will start to suggest and/or apply changes to other libraries to make use of the new facilities. --Beman

7 9