March 2011 - Boost - lists.preview.boost.org

[inspect] exceptions (FW: [Boost-users] no exceptions)
by Robert Kawulak 26 Mar '11

26 Mar '11

>From Boost Users ML: > From: Hochhaus, Andrew > I would like to use boost with BOOST_NO_EXCEPTIONS [1] and the g++ > -fno-exceptions flag. However, it appears that some spots in boost > library code: > > a) throw exceptions with the "raw" throw keyword [instead of > BOOST_THROW_EXCEPTION or boost::throw_exception] > b) use try ... catch blocks without "#ifnef BOOST_NO_EXCEPTIONS" guards Wouldn't it be a good idea to add checks for these to the inspect tool? Also, non-empty exception specifications are discouraged by Boost guidelines - should appropriate checks be added too? Best regards, Robert

11 48

[xint] quick review
by Domagoj Saric 25 Mar '11

25 Mar '11

Apologies for lack of proper review structure, I'm working with last bits of free time to post before the deadline... IMO, the proposed XInt, as can be downloaded from the vault, should NOT be accepted into Boost. Rationale: The reasons were mostly already covered by other boost.devel posters and pretty much all fall into the categories of a too coupled/inflexible and inefficient design. My primary concern is lack of support for true, efficient, no-fail-guarantee fixed-size integers: the provided fixed-size support still uses dynamic memory allocation (which can fail and requires/introduces EH code) and the nothrow policy does not in fact disable the use of exceptions (it only wraps and 'eats' them with try-catch blocks...which is just plain inefficient...this is like implementing malloc in terms of new instead of the other way around). For such low level operations, as fixed-sized integer arithmetic, it is quite reasonable to expect the implementation to be able to work even without linking to the CRT (i.e. no use of keywords new, virtual or throw)... This might at first be viewed as a possibly 'conditional yes' vote but since Chad has repeatedly said that he considers fixed-sized integers to be 'second class citizens' of his library I vote no for such a library... I am also not convinced by the rationale behind the different-than-built-in-behaviour (sign-magnitude, overflow NaN...). >"Chad Nelson" <chad.thecomfychair(a)gmail.com> wrote in message >news:20110302202855.5cd8067f@ubuntu... > >>On Wed, 02 Mar 2011 18:18:33 +0100 >>Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: >> >> [...] Also, it seems that the object always contains the copy count >> and a readonly boolean, which total 2 words, even if COW is disabled. > >Eliminating sixteen bits of overhead, on an integer that is almost >always going to be larger than 64 bits (and often *much* larger), seems >to be a premature optimization at best. 2 words are 64 bits on a 32 bit system and 128 bits on a 64 bit system...that's 25% of a 512 bit number. In fact, for a fixed-sized integer with disabled COW, there are, AFAICT, two redundant std:size_ts and two bools (in addition to the data pointer and dynamic memory allocation) per integer...that certainly is not so easily dismissible, especially on a 64 bit system and especially if we also consider the code that maintains those 'useless' data members...Quite to the contrary, I would sooner accuse your approach of premature pessimization (have you even examined the assembly output of your code?). In one post you complained that you are already tired of all the criticism on this list but please try to learn from this. The above misunderstanding and/or unwarranted dismissal of data layout/storage issues along with things like thinking that virtual inheritance is resolved at compile time, not knowing about the CRTP and misunderstanding of when to 'pass by value for performance' shows that you have holes in your knowledge which should make you more humble before honest criticism... You also complained about not getting enough feedback in the last iteration of your library, IMHO your attitude (of fixing your library on your own set of use cases) again may have something to do with that. I remember way back then people were already criticising the hardwired dynamic allocation and data-layout&storage coupling design. I proposed that you extract algorithms into free functions that simply take and work on data ranges as this would both eliminate template bloat (in your current design the algorithms get replicated for every integer_t instantiation) and allow for cleaner implementation of different data storage strategies. As far as I remember you gave little heed to these concerns/suggestions or complained that that would be too much time consuming to implement while OTOH you spent who knows how much time on implementing COW which AFAICT turned to be a misguided premature optimization (of an a priori inefficient design)... When I finally saw that you actually defended your hardwired dyn.mem. allocation by saying that it enables faster swaps I simply gave up on replying at that time deciding I'd wait for an official review (when boost.devel input has to be taken into consideration else you don't get accepted)... ps. I'm sorry if some/all of the above mentioned issues were already resolved (I did not manage to read through the whole discussion before the review deadline)... pps. I saw FFT being mentioned, you migh want to check out this http://drdobbs.com/cpp/199500857 ppps. You use a member-function-pointer based "unspecified bool type" implementation which produces suboptimal code on MSVC <10...IMO a plain operator bool would probably do just fine here as the built-in integral types also implicitly convert to bool... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

12 29

Unable to build boost python library in 1.46.1
by Richard Hadsell 25 Mar '11

25 Mar '11

I am trying to build the Boost 1.46.1 libraries on a Fedora 7 Linux system with the default g++ 4.1.2 and Python 2.5. The compilations do not find the python headers, producing a zillion error messages starting with one like this: In file included from ./boost/python/detail/prefix.hpp:13, from ./boost/python/converter/registrations.hpp:8, from libs/python/src/object/function_doc_signature.cpp:9: ./boost/python/detail/wrap_python.hpp:50:23: error: pyconfig.h: No such file or directory The reported compilation command looks like this: "/usr/bin/g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -fno-strict-aliasing -fno-tree-ccp -march=opteron -pthread -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_PYTHON_SOURCE -DNDEBUG -I"." -c -o "bin.v2/libs/python/build/gcc-4.1.2/release/address-model-64/instruction-set-opteron/threading-multi/object/function_doc_signature.o" "libs/python/src/object/function_doc_signature.cpp" I tried to follow the latest Getting Started instructions, which changed a bit from the last version I built (1.44.0) to build bjam: cd tools/build/v2 bootstrap.sh bjam install --prefix=../../.. cd ../../.. bin/bjam --user-config=user-config.LINUX_AMDF7 threading=multi instruction-set=opteron address-model=64 variant=release link=static,shared --stagedir=stageF7 stage My user-config.LINUX_AMDF7 file contains this: using gcc : 4.1.2 : /usr/bin/g++ : <compileflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" <linkflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" ; using python : 2.5 : /usr ; Can someone explain why the compilations are not getting the correct include path for Python (/usr/include/python2.5/)? BTW, the Getting Started page http://www.boost.org/doc/libs/1_46_1/more/getting_started/unix-variants.html in section 5.2.1 step 2 tells me to "Run bootstrap.bat". -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

4 8

Re: [boost] A possible GSOC 2011 proposal idea
by Chad Seibert 25 Mar '11

25 Mar '11

Hi, First of all, many thanks for the feedback! Much of the discussion has been in whether it is possible for me to accomplish such a task over the summer. The answer is no; a library designed to meet Boost's standards will not be done over the summer. However, a substantial amount of the work will be done over the summer and it will continue over the next year until it is satisfactory. I will then be responsible for maintaining it for as long as required. In order for you to understand the scope of this project, it must be made clear that the project references itself many times. For example, MILP's and ILP's are solved using the exact same algorithms, so for all intents and purposes, they are the same. Second of all, solving ILP's using branch and bound or cutting planes both require a strong algorithm for solving their relaxed forms, i.e. their LP relaxations. Third, the bulk of the effort in solving LP's using the refined simplex algorithm is in solving a system of linear equations. This is by far the most difficult part of the entire project and is what I intend to spend the summer doing. It will be difficult for the aforementioned reasons; hence the topic of my GSOC proposal will be efficiently solving linear systems (LS). After GSOC, I will continue my work and write LP and ILP solvers. As for the scope of solving LS, there are many different algorithms designed to do just that. In order to limit the scope, I will not consider parallel algorithms or distributed algorithms. If the Boost community thinks that these are reasonable and I should forgo solving LP in favor of solving large (> 100,000x100,000) LS, we can certainly discuss this. The following algorithms are up for consideration: * LU decomposition for small matrices * Iterative methods for large matrices, such as conjugate gradient for positive definite matrices Of course, this will all be integrated into the already existing uBLAS library. There are many issues with getting such solver to work well in practice, namely reducing fill-in, numerical stability, and performance. In any case, getting a general purpose LS solver is the first step towards getting an LP solver running. Therefore, it is the focus of my work this summer and only afterwards will I work on LP-related algorithms. One last this is that it wasn't my intent for my pre-GSOC submission to be anywhere the quality required for Boost submission. It was only there to show my support towards this project and that I'm committed fully to its success. Thanks again for your feedback! Chad

7 15

[xint] Some preliminary review notes
by Vladimir Prus 25 Mar '11

25 Mar '11

Folks, I've promised to post initial summary of Boost.Xint this Monday, but real life has interferred. I apologise. I've made a pass over review emails, and it seems that a few high-level points were raised: - Whether COW is good idea or not, and whether current COW is truly thread-safe. - Whether ET should be used - Whether data copy in "a + b + c" should be eliminated - Whether the library is "fast", in particular: - Do algorithms have best big-O complexity? - Are fixed-size integers fast enough - Whether it would be better to separate algorithms and data represetation - Whether it's possible to optimize specific cases (addition of 128-bit integers, ln+gamma, etc), by some template specializations, or other mechanism. I might have missed something, and I'd appreciate if I was set straight. Please note that we're talking about high-level issues. The number of specific comments is already too high for me to even try tracking them all. At the same time, Chad, I'd appreciate some input from you. - Could you express your current world view of those issues. Whether they are real, important, and what plan do you have about them, if any. Note that you are not required by any means to address every raised concern, but some coherent plan of action will be very important both for further development of your library and for review result. - Do you keep track of technical issues raised? Could you share that list? Thanks, -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40

2 1

[context review]
by Giovanni Piero Deretta 25 Mar '11

25 Mar '11

First of all, I think the library as some issues and it should not be accepted as it is, but see below. - What is your evaluation of the design? The interface is pretty simple and it seems fine on a first evaluation, but I think there are some issues. The first issue is that the destructor of the context class will (at least by default) happily destroy the stack. This unfortunately will leak any resource owned by any object on the stack; This is not unlike destroying an allocator before having destroyed all allocated object. A stack can only be safely deallocated if either has been completely unwound or if it doesn't own any resources (note that is not enough to just destroy any stack allocated object). Context should either: a) provide an interface to unwind the stack (by automatically trowing a special exception for example), or b) detect whether the stack has not been unwound and assert in debug mode in the destructor. As it is, is not clear the level of abstraction this class wants to be. It looks like is trying, using RAII, to manage context creation and destruction safely, giving a false sense of security. Context is neither copyable nor movable; I can understand the reason for making it non-copyable, but I see no reason why it shouldn't be movable. Without either capability it is hard to make context interoperate with existing code without forcing to dynamic allocation. Context is templated on both the context implementation and the stack. The first problem is that the concept requirements for the Stack template arguments are not stated. Second, the stack type should not be part of the context type: the primary reason for specifying different stacks is for option of having the guard page: enabling this should not change the type of Context and it should possible to specify it at runtime. Basically I'm advocating for type erasure; note that it can (and should) be implemented without additional memory allocation. The trampoline function can be defined in such a way that the custom deleter will be invoked after the stack is unwound. Regarding the CtxT type, instead of this template parameter there should be a program wide default controllable at compile time by a macro; I saw elsethread that Oliver is already leaning on this idea. As it is the context class is IMHO flawed and I'm against its inclusion in boost right. I'll be very happy to change my vote if I see a better implementation. A good abstraction layer around the low level context, among other things, should support clean unwind of the stack (or detecting an not-unwound stack), generic functors (and not just function pointers) for type safety and custom deleters. On the other hand the detail fcontext class seems a good, if maybe not complete, portable implementation of a low level ucontext-like API. I would be in favor of a simpler version of context which consists solely on the fcontext class (with a guarantee that this type is a POD), plus the make_context and swap_context functions. A user will have lower expectations from such a low level API and at the same time will give more freedom for other people to implement on top of it. A safe context class would just be one of the client of the API, other library authors could either use Context of the underlying fcontex directly depending on wether they need the speed or safety. I think this basic API could still be tweaked [but my vote won't be conditional on that] to add extra functionality: * Instead of supporting a 'fc_link' a-la ucontext, have the callback function return a new context (it is void now). 'fc_link' is useful only on some limited cases (usually when you have an external scheduler managing your contextes), while the having the callback return the 'next continuation' has more applications (note that fc_link can be implemented easily in term of the continuation returning variant, but the reverse is harder). This is very useful, for example, to implement some kind of 'exit_to' functionality (unwind the stack and restore another context), a key piece for safe context destruction. * Give to fcontext_swap the ability to exchange a parameter with the other context: fcontext_parm_t swap_fcontext( fcontext_t * ofc, fcontext_t const* nfc, fcontext_parm_t parm) where fcontext_parm_t is either union fcontext_parm_t { void * ptr; int int_; }; or simply intptr_t; Swap_fcontext saves the current context in ocf and restores the context ncf as usual; additionally, if ofc was 'captured' on a call to swap_fcontext, this call will return the value of parm on the original context. This extra parameter is equivalent to the second parameter of longjmp. If ofc was created with make_fcontext, 'parm' will be an extra parameter to the function. Note that because you can't mix and match parameterful and parameterless swap_fcontext, you should only have the former as it can be potentially implemented with little or no overhead. * Add a variant of swap_context that allows executing a function on the destination context (in this case 'parm' would be passed parameter to this function. This is mostly useful for injecting an exception on the destination context. This can be potentially implemented on top of the existing functionality, but would slow down every context switch; a possible efficient implementation would manipulate the destination stack to add a call to the function on top of it, so that the cost is paid only when required. All the previous improvements are implementable unobtrusively on top of the exiting API, but such implementations will be much less efficient. I'm suggesting that they should be part of the basic API becausecan be implemented with zero or near zero overhead when not used. - What is your evaluation of the implementation? The implementation seems reasonably efficient, but I have seen elsethread suggestions to make the constructor more expensive (read multiple memory allocations) in exchange for flexibility; this is IMHO wrong, the constructor should not be assumed to be a non critical operation. In fact I think that most of the proposals can be efficiently implemented without additional memory allocation by reusing the already available stack (which can be reused). Most of the 'throw' statements in the context class should actually be asserts. Make_fcontext requires a call to get_fcontex first, a-la ucontext: there is no reason for this, just merge get_context with make_context (and drop the unused set_fcontext). The posix ucontext wapper and the windows fiber wrapper should be made API compatible with fcontext. Regarding the assembler implementations of fcontext, I think they could be simplified if the fcontext itself was represented as a single pointer to the top of the stack. This would save some instructions to move the source address from the stack return address to the fcontext struct and back. The i386 implementation could use register calling convention to simplify the implementation and speed it up. Both the i386 and amd64 asm implementation use the 'ret' instruction to restore instruction pointer of the destination context. This will always be mispredicted (costing 20 cycles or more, easily more than the rest of the swapping code). Just jmping to the the destination will save a push and will give the CPU a chance to predict the jmp (modern CPUs have some dynamic prediction capability for indirect jumps). Bot the i386 and amd64 asm implementation save and restore the fpu control word (the amd64 both x87 and SSE2 control words). Last time I timed it, this was a relatively an expensive operation, not sure about current architectures; I do not think this should be saved and restored: the compiler will treat it as a caller clobbered variable and will take care of it in case of implicit manipulations. The user should be prohibited from changing it across a swap_fcontext call. As a minimum, there should be a compile time option to disable the saving. Note that many posix implementation of the ucontext API need to restore it (along with the full register set) because on traditional unices a context could be captured asynchronously by a signal, but it is not the case with boost.context. BTW, the current code is already inconsistent because it is saving the SSE2 control world on amd64 but not on i386. For posix systems lacking ucontext, fcontext can be implemented using the sigaltstack trick (this can actually be faster than ucontext if the non signal restoring _longjmp is used). For reference see: http://www.gnu.org/software/pth/rse-pmt.ps Finally, an implementation on top of boost threads would be nice. It will be very slow, but useful for portability and when performance is not an issue; also won't probably be much slower than ucontext. - What is your evaluation of the documentation? The documentation is very minimalist and should be expanded. It assumes the user is already familiar with the context swapping concept. The posix ucontext APIs man page are a good start. The fcontext class should be documented. The first time I read the documentation I understood that the constructor captured the current context a-la setjmp (a very bad idea, IMHO). I had to read the implementation to convince myself it was not the case. - What is your evaluation of the potential usefulness of the library? This is definitely not going to be one of the most used boost libraries, but it is a required piece to implement other libraries like coroutines, user lever threading, tasks, etc. - Did you try to use the library? With what compiler? Did you have any problems? I didn't try to use the library. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I did an in-depth study of the implementation. - Are you knowledgeable about the problem domain? I consider myself fairly experienced in this domain: As part of the GSoC project Boost.Coroutine I did some pretty in depth research on the topic and I implemented a very similar functionality; BTW, I see that Context borrows many ideas from Boost.Coroutine implementation (some of the tricks in the fiber wrapper look quite familiar); a small acknowledgement would be appreciated :). -- gpd

4 7

TTI library updated in the sandbox to version 1.4
by Edward Diener 25 Mar '11

25 Mar '11

I have updated the TTI library in the sandbox 'tti' directory to version 1.4. The TTI library, which is an abbreviation for the 'Type Traits Introspection' library, allows a programmer to introspect at compile time the inner elements of a C++ type. The introspection process depends on specifying the name of the inner element by different macros for different types of elements, and then using a generated metafunction to determine whether that element exists within the enclosing type. The inner elements which can be introspected are type, class template, member data, member function, static member data, and static member function. Changes in this release include: * Some metafunction macro names and one nullary type metafunction name have changed to provide a better separation of introspection of functions using composite and individual type syntax. * Composite syntax macros are now only used to introspect member functions and static member functions. Individual type syntax now exists for introspecting member data and static member data. * Inclusion of specific header files for faster compilation is now supported. * Addition of macro metafunction name generating macros. * Shorten the names of the test files and test header files. * Added documentation topic about introspecting function templates. The TTI library is based on the type_traits_ext portion of the Concept Traits Library, with improvements and additions, and also reproduces functionality ( without changing existing code ), for the purposes of completeness, from Boost.MPL regarding introspection of types and templates. The purpose of the library is to provide a consistent set of interfaces for doing compile-time introspection of a type, which other template metaprogrammers can use in their code. If you are at all interested in compile-time introspection of types, please take a look at the functionality of this library. There is a readme.txt in the top-level directory, for anyone browsing the sandbox. There is a build.txt file in the doc subdirectory for building the documentation and running the tests. The documentation is also included as part of the sandbox files for those who can not build the docs. The library has been tested and works with gcc 3.4.2, 3.4.5, 4.3.0, 4.4.0, 4.5.0-1, 4.5.2-1 and VC++ 8.0, 9.0, 10.0. It may also work with other compilers. This is the last release in which breaking name changes will occur. I anticipate any further release will include only possible additions of functionality, but all current interfaces are now stable and the design is set. Questions, comments, suggestions, and bug reports are all welcome.

4 6

[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