- Boost - lists.boost.org

[config] Does it work with compilers in C mode ?
by Edward Diener 25 Mar '11

25 Mar '11

Is there any guarantee that the configuration files will work with a C compiler or a C++ compiler in C mode ? Is there anything in the configuration files which is C++ specific ? I am working on bringing my variadic macro data library into Boost PP, and I wanted to use the BOOST_NO_VARIADIC_MACROS in config, but Paul Mensonides was concerned that Boost PP should work with a C compiler and that config could have something that is C++ specific, and therefore be unusable for Boost PP. I would rather not reduplicate the logic of BOOST_NO_VARIADIC_MACROS in Boost PP, even though I was the one to add it to config, because it puts the same code in two different places.

3 6

[documentation] doxygen tags and ALIASES.
by Vicente BOTET 25 Mar '11

25 Mar '11

Hi, I have see that Boost.Local uses some aliases to tag some part of the doxygen documentation. ALIASES=" Params=\"Parameters: \" Param{2}=\"\\1\\2 \" EndParams=\"\" Returns=\"Returns:\" Note=\"Note:\" Warning=\"Warning:\" See=\"See:\" RefSect{1}=\"\\xmlonly \\1\\endxmlonly\" RefSect2{2}=\"\\xmlonly \\2\\endxmlonly\" RefClass{1}=\"\\xmlonly\\1\\endxmlonly\" RefMacro{1}=\"\\xmlonly\\1\\endxmlonly\" " For example /** * @brief This macro is used to specify the local function name. * * This macro must follow the local function body code block { ... } as * shown in the @RefMacro{BOOST_LOCAL_FUNCTION_PARAMS} documentation. * * @Params * @Param{name, * The name of the local function. This name cannot be the name of an operator * operator... and it cannot be the same name of another local function * declared within the same enclosing scope (i.e.\, it is not possible to * overload local function declarations) -- see the * @RefSect2{Advanced_Topics\, Advanced Topics} section. * } * @EndParams * * @See @RefMacro{BOOST_LOCAL_FUNCTION_PARAMS}, @RefSect{Tutorial} section, * @RefSect2{Advanced_Topics, Advanced Topics} section. */ Other use html valises directly. //! Effects: //! \code //! for (; first != last; ++result, ++first) //! new (static_cast(&*result)) //! typename iterator_traits::value_type(boost::move(*first)); //! \endcode //! //! Returns: result Is somewhere a guideline on how to tag the doxygen documentation for Boost libraries? Is there a list of ALIASES? If not, is there some interest in defining one? Thanks, Vicente

6 13

Re: [boost] [type_traits] MSVC rejects typename -- why?
by Lorenzo Caminiti 25 Mar '11

25 Mar '11

On Thu, Mar 24, 2011 at 3:58 PM, Vicente BOTET <vicente.botet(a)wanadoo.fr> wrote: > > Hi, > > > It seems the compiler is not seen it is inside an outer macro. > In this case it seems that we need another macro e.g.BOOST_NESTED_TYPENAME. You could try to follow the protocol of adding a new macro andpropose apatch to John. > > An other alternative: I suspect that the nested structure is code that you generate with your macros in Boost.Local orBoost.Contract. I propose you to define a nested template > > template > void f(T& x) { > template > struct s { > T g() { > typename boost::remove_reference::type i = 0; > return i; > } > }; > x = s().g(); > } Yes, for my application I can use class templates instead of function templates (this is actually not code generated by macros but just a Boost.Local example for the docs that shows how to use BOOST_LOCAL_TYPEOF). I'll leave it up to Boost.Config maintainers to decide if the introduction of BOOST_NESTED_TYPENAME is needed or not. Thanks a lot! -- Lorenzo

1 0

Re: [boost] [inspect] exceptions (FW: [Boost-users] no exceptions)
by Brian Wood 24 Mar '11

24 Mar '11

Dave Abrahams: >At Wed, 23 Mar 2011 14:29:20 -0700, >Emil Dotchevski wrote: >> It is not independent matter because that is exactly what >> BOOST_THROW_EXCEPTION guarantees, except when the library contains >> try..catch or rethrows using throw without arguments, which are rare >> cases. I agree that going the extra mile to workaround those >> additional cases is usually unreasonable. > > I suppose that might be true, depending on your definition of "work > properly." There's no such thing as "working properly without > exceptions" if the library was coded for use with exceptions and you > really need a recoverable response to, say, resource exhaustion. > > That said, "libraries should generally use BOOST_THROW_EXCEPTION" is a > good rule for Boost, and I wouldn't mind having something like it in > the inspect tests, provided that libraries with a legitimate reason > not to use it can be registered as exceptions to the rule. I think you are both more knowledgeable about exceptions and this Boost library than I am, but here's my thinking. In the last 2 or 3 months I added a try/catch and throw without arguments to a file in my library -- http://webEbenezer.net/misc/ReceiveCompressedBuffer.hh . That's the only one so it is rare for me but there are a lot of libraries that are bigger than my library. So I'm not sure it is rare in other libraries. It seems to me that as a library grow this restriction is just waiting for you to run into it. I guess it's a trade-off though if I understand correctly. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

2 1

[GSoC] SIMD proposal
by Mathieu - 24 Mar '11

24 Mar '11

Hello everyone, I'm a french student preparing a Master in Computer Science. I'm highly interested in participating in the 2011 GSoC with Boost. I'm particulary keen on working on the boost.simd subject. I think having SIMD abstraction in boost could be really beneficial (the first example which comes to mind is boost.math). However I have some questions about the subject in order to do my proposal, some of them have already been discussed with Joel Falcou and Mathias Gaunard on IRC, but here it is : One of the main concern I have is that nt2 relies heavily on cmake to detect various things like SSE instruction set support etc. From what I know (I ported nt2 to OpenBSD a while ago), depending on the architecture different methods are used, in order to be portable, like reading from sysctl in OSX or lauching a little executable which collect various informations using cpuid. So the question is : is bjam able to do everything we need to do, or will we need to do the detection in any other way? I use, and I kind of know bjam but I'm not an expert either, I believe Vladimir Prus will be able to help here. Another thing that is a bit blur for me at the moment, is what is the scope of boost.simd? I mean, from what I see the simd part is quite deep-rooted in nt2, has dependencies on several modules of it, so will boost.simd be a subset of nt2 simd module or will we need to rewrite part of it to avoid dragging huge dependencies (and well, end up doing boost.nt2). Mathieu Masson. Regards.

6 14

[type_traits] MSVC rejects typename -- why?
by Lorenzo Caminiti 24 Mar '11

24 Mar '11

Hello all, The following code compiles on GCC (v3.4.3) but it does not on MSVC (cl.exe v14): #include <boost/type_traits.hpp> template<typename T> void f(T& x) { struct s { T g() { // GCC needs this typename but MSVC does not -- why?? typename boost::remove_reference<T&>::type i = 0; return i; } }; x = s().g(); } int main() { int x; f(x); return 0; } MSVC does not accept the `typename` inside `s::g` because it says it's not within a template (but I think it is within a template...). GCC instead requires that `typename`. Which compiler is right? (What does the standard say?) How do I program this code so it works on all compilers? Thank you very much. -- Lorenzo

3 3

[type_traits] Most Unifying Proposal for operator names Was: Review Typetraits Extension.
by Joachim Faulhaber 24 Mar '11

24 Mar '11

Dear Frédéric, Operatorists, list, on occasion of the current naming discussion on operator traits I started a wiki page with an operator functor naming table that allows for an overview over names of operators, functors (and related concept names) across the standard and boost. I compared the name stems only, independent of the question of a 'has_' or 'has_operator_' prefix. Basically it's an extension of Frédéric's operator names table 1.7 from his docs, extended by proto and boost::operator names. Comparing the names I tried to find "Most Unifying Proposals" for names in column MUP: https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators Also I took a look at the current and new standard's functor class templates from header <functional>. I wonder why all the functors only use one template parameter, which restricts their use leaving out the interesting cases of functors for mixed type overloaded operators. template <class T> struct op_functor { ... } instead of template <class T, class U=T, class R=T> struct op_functor { ... } Also I don't understand, why inheritence form binary_function<T,U,R> is no longer declared, but instead of this, the redundant declaration of all associated types for every functor. Does this codereplication serve any purpose? Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 6

[bjam] auto linking fail
by Tal Agmon 24 Mar '11

24 Mar '11

Tested on windows Jamroot defines 1.47.0 outputs libs missing patch version causing auto link to fail.. -- Sent from my mobile device

1 0

[move] [ thread] ambiguous call to overloaded function
by Tal Agmon 24 Mar '11

24 Mar '11

Hello, Did anyone experience the following Revision 70494 tested on msvc2010 with headers the following headers: [code] #include< boost/thread.hpp> #include < boost/move.hpp > ... X x; boost::packaged_task<string_ptr_type> pt(boost::bind(&X::foo, boost::ref(x))); boost::unique_future<string_ptr_type> fs = pt.get_future(); boost::thread task(boost::move(pt)); fs.wait(); ... [code] outputs: .$(BOOST_ROOT)boost/move/move.hpp(304): could be 'boost::packaged_task<R> &boost::move<boost::packaged_task<R>>(T &)' or $(BOOST_ROOT)boost/thread/detail/move.hpp(44): or 'boost::detail::thread_move_t<T> boost::move<boost::packaged_task<R>>(T &)'

3 2

[XInt] CoW/Move Timings
by Chad Nelson 24 Mar '11

24 Mar '11

Below are the comparative timings with and without Copy-on-Write, and with and without Boost.Move. Times are measured in seconds, using two sets of ten integers (512, 2048, and 8192 bit). The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated modulus argument of the same size) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results in the first three columns; the fourth column is the average of the three. The compiler used was GCC 4.5.1, under Ubuntu Linux 10.10. The build was non-debug and used -O2 optimization. Otherwise, the settings were left at their defaults. The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed. The tests show pretty conclusively that Copy-on-Write, alone or in conjunction with Boost.Move, provides a noticeable speed improvement on all three sizes. They also prove that Boost.Move can work well in conjunction with it. I'll leave any further analysis to people who are probably more qualified than I. Note that the Boost.Move numbers could be a little better. The integer_t classes are move-enabled, but the internal data class is not as yet. The data class only sometimes uses return values, so the difference isn't likely to be great. I will make the updated code available on request for anyone who wants to examine the changes. 512bit CoW, no Move: 0.48, 0.47, 0.47: 0.48 No CoW, no Move: 0.61, 0.61, 0.62: 0.61 (worst) No CoW, Move: 0.57, 0.57, 0.55: 0.56 CoW, Move: 0.44, 0.44, 0.44: 0.44 (best) Review code, CoW, no Move: 0.50, 0.47, 0.47: 0.48 2Kbit CoW, no Move: 4.69, 4.79, 4.89: 4.79 (best) No CoW, no Move: 5.01, 5.19, 5.06: 5.09 (worst) No CoW, Move: 5.18, 5.00, 5.01: 5.06 CoW, Move: 4.80, 4.79, 4.86: 4.82 Review code, CoW, no Move: 4.88, 4.85, 4.94: 4.89 8Kbit CoW, no Move: 68.0, 68.8, 68.9: 68.6 No CoW, no Move: 70.4, 70.4, 70.2: 70.3 (worst) No CoW, Move: 70.9, 69.8, 69.6: 70.1 CoW, Move: 68.4, 68.2, 67.8: 68.1 (best) Review code, CoW, no Move: 68.8, 68.4, 68.8: 68.7 -- Chad Nelson Oak Circle Software, Inc. * * *

26 37