May 2014 - Boost - lists.preview.boost.org

[smart_ptr] Proposal to add new memory order constants
by Andrey Semashev 21 May '14

21 May '14

Hi, I have a proposal to add new constants to the memory_order enum: memory_order_hle = 16, memory_order_hle_acquire = memory_order_hle | memory_order_acquire, memory_order_hle_release = memory_order_hle | memory_order_release These constants can be used to support Intel HLE (Hardware Lock Elision) [1] in Boost.Atomic and then reused by Boost.Sync. The meaning of these constants is Intel-specific (for now): the memory_order_hle_acquire operation has memory_order_acquire ordering and also starts a transaction; memory_order_hle_release operation has memory_order_release ordering and also commits the transaction. On other targets memory_order_hle flag is ignored and memory_order_hle_acquire and memory_order_hle_release are equivalent to memory_order_acquire and memory_order_release, respectively. The support for these constants can be implemented in the following Boost.Atomic backends: - all x86 assembler-based backends. - gcc __atomic* builtins support __ATOMIC_HLE_ACQUIRE and __ATOMIC_HLE_RELEASE flags (at least, gcc 4.8 and Intel compiler 14.0.3 for Linux). - MSVC x86_64 supports Interlocked intrinsics with _HLEAcquire and _HLERelease suffixes. There are also _Store_HLERelease, _Store64_HLERelease and _StorePointer_HLERelease. Unfortunately, these only cover 32 and 64-bit types, for other types regular atomics will be used (i.e. HLE won't be used). For 32-bit x86 asm blocks are also a possibility; all types can have HLE support. BTW, maybe Boost.Atomic is a better place for memory_order.hpp? What do you think? [1] https://software.intel.com/sites/products/documentation/doclib/stdxe/2013/c…

2 7

[filesystem] Request for comments on proposed relative() function
by Beman Dawes 20 May '14

20 May '14

There are two open tickets requesting a relative() function, and also a National Body (I.E official) comment against the Filesystem TS (which is due to finalize at the June C++ committee meeting). The committee's Library Working Group has indicated they would like to add such a function. With help from Jamie Allsop, I've put together a proposal. See attached for docs. See https://github.com/boostorg/filesystem/tree/feature/relative for a branch of filesystem with the implementation and some relative() tests added. Comments appreciated. --Beman

9 37

Viewing the group via http://post.gmane.org misbehaving again.
by Vladimir Batov 20 May '14

20 May '14

For example, Edward's thread (started May 12th) [boost] Boost review of the 'convert' library starts tomorrow May 21 shows only 2 messages in post.gmane.org. Google https://groups.google.com/forum/#!topic/boost-developers-archive/40it9qkZUhA show all 6 messages. I see the same problem -- missing messages -- in other convert-related threads that I follow.

3 2

Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names
by Charousset, Dominik 20 May '14

20 May '14

The serialization and uniform name really boils down to the uniform_type_info class: Uniform names are simply a necessity if you need to identify a type based on its name. The goal is to send any kind of value to a remote machine and being able to deserialize it. If you have platofrm-independent names, you can simply prefix the binary serialized value with its type name and then get the RTTI (uniform_type_info) from the type name and deserialize the rest of the data. Boost.Actor is a bit more cleverer than that and maintains a list of type ids for each node it's connected to. Whenever you send a message with a type you didn't use beforehand, you send the type name along with its newly generated, unique ID and only use that ID going forward. But that's just an optimization. When talking about stateless communication (e.g. UDP), you can't do this and have to generate self-consistent messages. The fact that we even have to do this, is because std::type_info::name() is utterly useless. It returns a mangled name on GCC/Clang and a more sophisticated version of the type name on MSVC. The uniform name is the type name as it appears in code. So the first part of generating the uniform name is to demangle the platform-dependent name (https://github.com/Neverlord/boost.actor/blob/master/src/demangle.cpp) After that, we need to decompose the whole thing and make sure that qualifiers are always in the same order etc (https://github.com/Neverlord/boost.actor/blob/master/src/to_uniform_name.cpp) All this really is only aiming at having at type_info that is actually useful, i.e., name() returns *the exact same string* on each platform and it provides you with an interface for (1) generating values, (2) serializing and deserializing values, and (3) compare values. When generating a value through an uniform_type_info, you'll get a uniform_value, which is bascially a wrapper keeping {uniform_type_info*, void*}. Since we need a way to pass a serializer to a uniform_type_info instance, we can't use a templated approach as the archives in boost.serialization. The serialization classes in use (https://github.com/Neverlord/boost.actor/blob/master/boost/actor/serializer…) operate on sequences and primitive types. With the begin_object member function you also have a way of define serialization recursively, but I don't know if it's really needed to be honest. The write_tuple member function is probably not needed either, since you can simply just write the values one by one. However, it does give you a way of grouping values representing a single member together, which can be quite helpful when serializing to strings for instance. By the way, each announced type in Boost.Actor implicitly has a to_string(), which simply passes the value to a string serializer. There's also a from_string() that passes the input to a string deserializer, which gives you a simple way of injecting messages to the system. But the whole string serialization is not really fleshed out and the format not well defined. ________________________________________ From: Boost [boost-bounces(a)lists.boost.org] on behalf of Hartmut Kaiser [hartmut.kaiser(a)gmail.com] Sent: Tuesday, May 13, 2014 20:46 To: boost(a)lists.boost.org Subject: Re: [boost] Is there any interest in a library for actor programming? serialization + uniform names I'd be interested in hearing more details about this. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > -----Original Message----- > From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrzej > Horoszczak > Sent: Tuesday, May 13, 2014 8:16 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Is there any interest in a library for actor > programming? serialization + uniform names > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

4 5

Call for Review: Boost.Test documentation rewrite
by legalize+jeeves＠mail.xmission.com 19 May '14

19 May '14

[Please do not mail me a copy of your followup] Boost.Test documentation rewrite: <http://user.xmission.com/~legalize/tmp/boost.test/libs/test/doc/html/> Please post all comments to this list. I've been working on this as time permits for a number of months and I think now things are "finished" enough to warrant wider review. It is a true rewrite using quickbook; I generally used the implementation source code as the answer to my questions about things while writing the documentation. Early snapshots were reviewed by Tom Kent, Alexander Lamaison, Paul A. Bristow and Julian Gonggrijp. A special thanks to them for providing me with useful feedback and suggestions. The main thing that still remains to be added is a detailed explanation of the floating-point comparison algorithms used by BOOST_REQUIRE_CLOSE, BOOST_REQUIRE_CLOSE_FRACTION and BOOST_REQUIRE_SMALL. The corresponding examples also need to be updated. The existing online documentation has had all the math symbols stripped out of it, so it is pretty useless. I'm probably just going to typeset the formulas with LaTeX and then capture them as images that are included in the documentation. (See <https://svn.boost.org/trac/boost/ticket/9539>) I'm guessing that modular boost should allow me to clone libs/test, make all my changes there and then issue a pull request, but I'm not sure how far along things are with the git transition? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

14 48

Trac request states - suggestion
by Neil Groves 19 May '14

19 May '14

Dear Boost Developers, While working with Trac to maintain Boost.Range I find that I frequently have solved issues but they are not ready to be merged to master due to the release schedule. I haven’t noticed a way in Trac to denote that the issue is fixed and waiting to be merged. This means that I frequently look up tickets that I have forgotten I have fixed. It also means that I have a sub-optimal process for merging to master. I wondered if we might be able to squeeze in a “fixed in branch” field. It would help me considerably. Do other developers think this would help? Do you solve this in another, perhaps better way? I’m happy to lend development time to get this done if there is consensus and we can risk me having write access to Trac code! Thanks, Neil Groves

5 5

Re: [boost] [algorithm] Review Request: edit_distance
by Ahmed Charles 19 May '14

19 May '14

Marshall will probably be busy for the next few weeks. Have you asked Ron about review manager approval? ________________________________ From: Erik Erlandson Sent: 4/14/2014 7:20 PM To: boost(a)lists.boost.org Subject: Re: [boost] [algorithm] Review Request: edit_distance ----- Original Message ----- > > > > - Have you looked at the supposedly better algorithm "An O(NP) > > > > Sequence Comparison Algorithm" by Sun Wu, Udi Manber, and Gene > > > > Myers ? > > > > > I've been doing more cross-testing and benchmarking against the current > > O(ND) > > version. The latest O(NP) prototype is passing randomized cross-testing > > and is now about 25% faster than the O(ND) baseline. My latest prototype code based on O(NP) is now running about 35% faster than O(ND) in my benchmarking: https://github.com/erikerlandson/algorithm/blob/order_np_alg/include/boost/… > > I wrote up a blog post that describes the various ideas I applied to get this > result: > > http://erikerlandson.github.io/blog/2014/02/20/a-bi-directional-variation-o… _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

think-cell is using boost
by Volker Schöch 19 May '14

19 May '14

Hi, We would like to be listed in the Shrink Wrapped Boost section on the boost.org website: http://www.boost.org/users/uses_shrink.html · The name of the Application/Product/Service. think-cell · The name of the company (where appropriate). think-cell · A paragraph describing the Application/Product/Service. think-cell was founded in 2002 in Berlin and is today the leading vendor of productivity software for professional PowerPoint users. Its product suite covers the complete process of presentation creation - from analysis and preparation of business data to the graphical rendering of qualitative and quantitative results. Most international business consulting firms, as well as a large number of the well-known industrial global leaders, are among think-cell's customers. · Any information you can provide about which parts of Boost you used, along with any comments you may have on how Boost helped your product development. C++ is a great and versatile programming language, but only with boost it is a powerful development tool that facilitates really efficient programming. Our code is beautiful, concise and easily maintainable thanks to the following boost libraries: Algorithm, Assign, Config, Conversion, CRC, Date Time, Format, Fusion, Geometry, Integer, Interprocess, Intrusive, Iostreams, Iterator, Math Common Factor, Math/Special Functions, MPL, Multi-Array, Multi-Index, Numeric Conversion, Operators, Optional, Phoenix, Preprocessor, Proto, Range, Smart Ptr, Spirit, String Algo, Swap, Tribool, Tuple, Variant If you are looking for more information on what development problems we are facing every day go to our C++ Developer job posting<http://www.think-cell.com/career/jobs/development.shtml>. · URLs to your company's home page, and the home page of the Application/Product/Service if there is one. http://www.think-cell.com/ Thanks! Volker -- Volker Schöch | vschoech(a)think-cell.com<mailto:vschoech@think-cell.com> Senior Software Engineer We are looking for C++ Developers: http://www.think-cell.com/career ________________________________ think-cell Software GmbH http://www.think-cell.com<http://www.think-cell.com/> Chausseestr. 8/E phone / fax +49 30 666473-10 / -19 10115 Berlin, Germany US phone / fax +1 800 891 8091 / +1 212 504 3039 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schödl

1 0

Crisis, What Crisis ?
by Francisco José Tapia 18 May '14

18 May '14

When , in previous days, I had read messages about the dead of Boost, I stopped to think about it. I think Boost is not dead, even , it have an excellent health, but have problems related with the growth , in the same way than when a young, pass to be adult. Many things must be done in a different way. Every day I see new developers proposing new ideas. If one day, you don't see new ideas and new developers you can certificate the death of Boost. The value of Boost compared with other libraries is that the code is tested, and a company trust in Boost and use their libraries in their internal process and applications, this is not true with many others libraries. I think we must separate the interest of the Boost users and the Boost developers. The developers, usually, are people with great level of knowledge and experience , and the users usually don't have that level. Due this , many times times, the interest of the developers and the users don't agree. Many of the new libraries proposed, in absence of a detailed explanation, are incomprehensible by the majority of the users. If you don't improve the design of the opponent, copy it. Perhaps we must learn about others web as stack overflow , and extract ideas for our web system. I think we must extend the mechanism used for the errors, to the consults of the users. Must be easy and don't need to inscribe. The actual mechanism of the list , I think is appropriate for the developers. Many of the Boost libraries are included in the C++ standards, this show the quality of the library. But I don't think that the people use a boost library, being included in the standard and provided by the compiler. I think we must design an ordered close of that libraries, and locate in a part for to provide utility to the users of old compilers. This reduce the number of libraries and help to improve the clarity and simplicity of the library. Boost had become a very big structure, and perhaps , the actual procedures for to take decisions are not appropriate, in the same way that there are people with a great knowledge and experience and other just arrived, and their opinions can have the same value. I think it is a good idea to create an executive board, elected between the Boost members, in order to take the important decisions. One of the first decisions is what to do with the libraries pending of revision, and the acceptance of new libraries without reviewer. As commented before, we can have libraries very interesting for the developers, and uninteresting for the users, and the opposite. My library COUNTERTREE,( parallel algorithms over Red-Black trees, with random access iterators) is waiting since near two years ago. It's something new, don't exist nothing similar. I had showed to companies (Intel , Google, Valve ...), universities (Stanford, Texas A&M, Carlos III , Stony Brook...) and people of the C++ environment ( Scott Meyers, P.J.Plauger , ) , with a great acceptation. But in their home, Boost, is waiting since near two years, and a good idea stopped is a dead idea. I would like to know if it is interesting in Boost, in order to continue with the development ( there are many algorithms and functionality for to do ), or if it is not interesting, spend my time in others questions, leaving frozen the code. These are only my opinions, open to discuss and new ideas. I am sorry , because the English is not my native language, and it's hard for me to express the details of my ideas. Anyway, I offer my work and my collaboration, for to improve OUR Library. If I can be useful, please, say me and I will try. Yours Francisco Tapia fjtapia(a)gmail.com You can find the code and the documentation in my web pages in dropbox https://dl.dropboxusercontent.com/u/8437476/works/countertree_2.0/index.html or if you prefer in a git format https://github.com/fjtapia/countertree_2.0

1 0

Re: [boost] [Boost-users] Stability of serialization across boost versions
by Brian Wood 18 May '14

18 May '14

Sohail Somani > On 18/05/2014 4:34 AM, John Maddock wrote: >>> Any feedback or suggestions other than not using boost for serialization? >> >> It was my understanding that stuff like that should be supported, if you >> have a test case then filing a bug report would seem to be in order? > > Based on the error, it seems like what is happening is that a newer > version of Boost is attempting to communicate with an older version of > Boost. The actual exception is from the archive itself, IIUC. The > library has explicitly said this is not supported, unfortunately. > > To the OP, I'd suggest not upgrading Boost serialization or requiring > upgrading in lockstep. Upgrading multiple hosts in random order means > new communicating with old. This is an unsupported use case. I have a serialization option. It isn't a Boost library, but it has support for some Boost types and we're willing to add support for other Boost types. -- Brian Ebenezer Enterprises - "He who *refreshes* *others* will *himself* be refreshed." Proverbs 11:25 http://webEbenezer.net

1 0