- Boost - lists.boost.org

[concept] why is `requires` plural?
by Lorenzo Caminiti 27 May '10

27 May '10

Hello all, This might be a very silly curiosity: Does anyone know why `requires` (plural) is used to specify concept requirements? Most keywords (all?) are not plural so I would have expexted `require` to be used instead of `requires`. Howerver, the C++0x proposals and ConceptC++ use `requires`. Consequently, Boost.ConceptCheck uses BOOST_CONCEPT_REQUIRES(). Do you know why the plural form was selected? Thank you. -- Sent from my mobile device Lorenzo

4 7

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

27 May '10

Hi Richard, >Hi Christophe > >Yes it works with typedef int no_exception_thrown; >I was using typedef int no_exception; which is used in euml examples >than I have look at the code and I figured out that it is actually >no_exception_thrown instead of no_exception. Yes, euml uses another name (which is an instance of an internal type, and not a type definition like no_exception_thrown but I disgress). >So now I can compile with -fno-rtti and -fno-exception thank you very >much for the support !!!!!. Great! >I have a question related to the fix for no-rtti the define >BOOST_NO_RTTI removes function definition : HandledEnum >process_any_event( ::boost::any const& evt); >which is called in flavor_compile_time in case of composite state. > >In case if I'm using favor_runtime_speed which is the default I >believe than I can still use composite states with no-rtti ?. > >Br. >Richie Yes of course. The method process_any_event is simply there for the favor_compile_time policy (to allow compiling submachines on different cores). So without rtti, all you lose is the possibility to trade runtime speed in exchange for a better compile time, which is in your case probably unimportant as you seem to be more interested in performance. Regards, Christophe

1 0

Re: [boost] [MSM] compiling MSM with GCC 4.4.1 and -fno-exception
by Richard Szabo 27 May '10

27 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 > >Hi Richard, > >I tried it out and it works. The default event dispatching occurs >inside a try/catch but you can deactivate it by adding a typedef to >the fsm declaration: >typedef int no_exception_thrown; >(see in MsmSimple.cpp) >Now it should compile properly with -fno-exceptions (and dispatch >events slightly faster). >HTH, >Christophe Hi Christophe Yes it works with typedef int no_exception_thrown; I was using typedef int no_exception; which is used in euml examples than I have look at the code and I figured out that it is actually no_exception_thrown instead of no_exception. So now I can compile with -fno-rtti and -fno-exception thank you very much for the support !!!!!. I have a question related to the fix for no-rtti the define BOOST_NO_RTTI removes function definition : HandledEnum process_any_event( ::boost::any const& evt); which is called in flavor_compile_time in case of composite state. In case if I'm using favor_runtime_speed which is the default I believe than I can still use composite states with no-rtti ?. Br. Richie

1 0

BOOST_NO_EXTERN_TEMPLATE
by Stefan Strasser 27 May '10

27 May '10

Hi, Boost.Config defines the macro BOOST_NO_EXTERN_TEMPLATE, which probably [1] refers to suppressing the instantiation of a template using the "extern" keyword. This is part of the C++0x draft but has long been implemented by several compilers, including MSVC[2] and GCC[3]. BOOST_NO_EXTERN_TEMPLATE is still defined for both compilers, why is that? do those implementations differ from the proposed C++0x behaviour[4], so the macro is defined because it refers to a C++0x feature? Or is this a bug? Is using "extern template" recommended for boost libraries (under construction)? specifically, the library lends itself to seperate precompiled source and started out as such, but making it more configurable turned seperate source code into templates and increased compile time. the default use case (which was the only use case before) could still be compiled seperately if "extern template" is available. [1] the documentation says the macro indicates no support for explicit instantiation. I assume this is a documentation bug, because of its name and it's listed as a C++0x feature: http://www.boost.org/doc/libs/1_43_0/libs/config/doc/html/boost_config/boos… [2] http://msdn.microsoft.com/en-us/library/by56e477.aspx [3] http://gcc.gnu.org/onlinedocs/gcc/Template-Instantiation.html [4] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1987.htm

2 2

[boost-build] restrict target directory to dependent features (repost)
by Sandeep Gupta 26 May '10

26 May '10

Hi, This is a repost from boost-build mailing list. It failed to catch an attention. Would appreciate any help any this problem. Essentially my question is that can I specify a symmetric feature to be non-propagated. To elaborate: Is it possible in bjam to restrict target directory to generators features? I can better state the problem with an example. Lets say I have two generators G1 (maps .foo to .g1), G2 (maps .g1 to .g2), with corresponding feature F1, F2. If I import both generators than then the target directory is bin/debug/F1-f1/F2-f2 even if I am activating G1 generator. Ideally what I would like is the output be restricted by the generators features i.e let say I have g1 xx.g1 : xx.foo : <F1> f1 ; g2 xx.g2 : xx.g1 : <F2>f2 <F1>f1 ; then the target for g1 should be /bin/debug/F1-f1/, and target for g2 should be bin/debug/F1-fi/F2-f2 and it should look for g1 in directory bin/debug/F1-fi/F2-f2. Is there a way to configure bjam to adopt the later policy?. Thanks. Sandeep

1 0

[c++-sig]Python binding for templated constructor
by Sandeep Gupta 26 May '10

26 May '10

Hi, I have a class with a generic constructor as follows : class X { indexes m_idx; template<class strategy> X(){ build_indexes<strategy>() }; My problem is that I am not able to figure out the syntax to export this constructor. Is the above class not well defined ?. Thanks. Sandeep

2 2

Re: [boost] [MSM] compiling MSM with GCC 4.4.1 and -fno-exception
by Christophe Henry 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 Hi Richard, I tried it out and it works. The default event dispatching occurs inside a try/catch but you can deactivate it by adding a typedef to the fsm declaration: typedef int no_exception_thrown; (see in MsmSimple.cpp) Now it should compile properly with -fno-exceptions (and dispatch events slightly faster). HTH, Christophe

1 0

Review Request: Boost.Locale
by Artyom 26 May '10

26 May '10

Hello, I want to request a formal review for Boost.Locale library. Short Description: ------------------ Boost.Locale is powerful localization library that provides powerful localization tool extending existing built-in C++ localization facilities in Unicode aware way. Documentation: -------------- - Reference: http://cppcms.sourceforge.net/boost_locale/html/index.html - Tutorial: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html Sources: -------- - https://sourceforge.net/projects/cppcms/files/boost_locale/boost_locale_for… Tested Compilers: ----------------- - GCC 3.4, 4.1, 4.2, 4.3, 4.4 (including C++0x support of new Unicode characters) - MSVC 2008 - Intel 11.0 - Sun Studio 12 with STLPort Tested Platforms: ----------------- - Linux 2.6 - FreeBSD 8.0 - OpenSolaris - Windows XP/SP2: incuding MSVC, MinGW and Cygwin Updates from previous versions: ------------------------------- - Redesigned Context information support in message catalogs: switched to native gettext msgctxt support. - Cleanup of MSVC warnings. - MSVC8 fixes. - Build Cleanup. Thank You, Artyom Beilis

7 23

missing checks of compilation flags in boost/detail/container_fwd.hpp
by F.S. 26 May '10

26 May '10

Hello everybody, I don't how to send patches to you. This is a very small one, which allows to compile boost libraries with gnu c++ library using the Profile or Parallel mode. Maybe it's useful for you: *************** *** 13,19 **** #include <boost/config.hpp> #include <boost/detail/workaround.hpp> ! #if ((defined(__GLIBCPP__) || defined(__GLIBCXX__)) && ( defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PROFILE) || defined(_GLIBCXX_PARALLEL))) \ || BOOST_WORKAROUND(__BORLANDC__, > 0x551) \ || BOOST_WORKAROUND(__DMC__, BOOST_TESTED_AT(0x842)) \ || (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) --- 13,19 ---- #include <boost/config.hpp> #include <boost/detail/workaround.hpp> ! #if ((defined(__GLIBCPP__) || defined(__GLIBCXX__)) && defined(_GLIBCXX_DEBUG)) \ || BOOST_WORKAROUND(__BORLANDC__, > 0x551) \ || BOOST_WORKAROUND(__DMC__, BOOST_TESTED_AT(0x842)) \ || (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) Regards Florian

2 1

[serialization] Warnings from spirit header in XML archive headers (non_terminal/rule.hpp)
by Number Cruncher 26 May '10

26 May '10

I'm encountering many warning about a deprecated header when writing my own XML input archive class: In file included from /opt/cfs/include/boost/archive/impl/basic_xml_grammar.hpp:59, from /opt/cfs/include/boost/archive/impl/xml_iarchive_impl.ipp:41, /opt/cfs/include/boost/spirit/core/non_terminal/rule.hpp:18:4: warning: #warning is a GCC extension /opt/cfs/include/boost/spirit/core/non_terminal/rule.hpp:18:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic_rule.hpp" This is because the serialization library is using "Spirit.Classic" and should be including different headers: http://www.boost.org/doc/libs/1_43_0/libs/spirit/doc/html/spirit/what_s_new… I've noticed patches related to this on the web, e.g. http://gitorious.org/ryppl/doc/commit/2711cc4a1e8751455f9188ffefa9b34de1379… ... and have repackaged a patch against the current 1.43.0 which fixes these warnings? Please could this be committed for the next release? Regards, Simon

2 2