- Boost - lists.preview.boost.org

open for merge?
by Oliver Kowalke 20 Apr '15

20 Apr '15

Hello, is boost open for merging into branch master after the release (unfortunately no entry in the calendar as it was available for previous releases)? thx, Oliver

1 0

DLL library: In search for Review Manager
by Antony Polukhin 20 Apr '15

20 Apr '15

Hi, Boost.DLL library seems ready, users use it and do not complain. Is there anyone wishing to help with review and become a Review Manager? Boost.DLL is a C++98 library for comfortable work with DLL and DSO. Library provides a portable across platforms way to: - load libraries at runtime - import and export any native functions and variables - make alias names for C++ mangled functions and symbols - query libraries/objects and executables for sections and exported symbols - self loading and self querying - getting program and module location by exported symbol Github: https://github.com/apolukhin/Boost.DLL Docs: http://apolukhin.github.io/Boost.DLL/index.html -- Best regards, Antony Polukhin

4 6

Re: [boost] [ValueRef]
by THOMAS JORDAN 20 Apr '15

20 Apr '15

> Message: 11 > Date: Mon, 20 Apr 2015 13:22:35 +0300 > From: Andrey Semashev <andrey.semashev(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] Interest in a new library for immutable values with internal sharing? > Message-ID: <1988978.ROPBOsQPor@lastique-pc> > Content-Type: text/plain; charset="us-ascii" > On Monday 20 April 2015 11:04:22 THOMAS JORDAN wrote: > > Hi, > > I'd like to gauge whether there might be any interest in a new Boost > > library comprising a generic, non-intrusive, wrapper class for creating > > immutable/const values with sharing of the underlying object via internal > > reference counting. > Is this similar to Boost.Flyweight? It is similar in that both provide a 'smart' handle which can be used pretty much as a drop in for the wrapped type. However, Boost.Flyweight requires the wrapped type to be hashable. Also, there is a level of indirection with Flyweight which can mean that unnecessary temps may need to be created to do the initial lookup (and addition) to the Flyweight store, unless you use the Flyweight key-map interface. ValueRef does not use 'flyweighting.' That is, if there are two ValueRefs created independently with the same value, e.g., ValueRef<std::vector<int> > v1(10,10), v2(10,10); there will be two separate wrapped vector<int> objects - it is only when copying/assigning that sharing takes place. It is simpler than Flyweight and is essentially intended to be a more value-orientated option to shared-ptr-to-const. Another (less significant) difference is that ValueRef currently has no dependency on MPL, which I believe Flyweight does, though that could well change if needed.

2 1

Re: [boost] Feedback on Boost.Http
by Brian Wood 20 Apr '15

20 Apr '15

Vin?cius dos Santos Oliveira: > I recently submitted an HTTP server library to Boost Incubator and I'd > appreciate feedback: > http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460 <http://rrsd.com/blincubator.com/bi_library/http/?gform_post_id=1460> > > I intend to submit to Boost later. > > This is the library that I developed during GSoC 2014 and I made several > improvements (new features, bug fixes, better and extended > documentation...) after the end of GSoC. There are a few improvements that > I still want to do, but none of them would be a barrier for Boost > integration, in my opinion. > > This library doesn't have a builtin request router, opposed to several > libraries out there, then you can use whatever routing style you wish > (tree-based, middleware-based, no router...). > > Also, it follows Boost active style, then you can build your own scheduler > around it (prioritize requests from certain IPs, defer acceptance of new > connections during server high load, reuse prior constructed objects...). > > The library follows Asio threading model, then you also choose whether you > will handle all requests from the same thread (useful for embedded devices) > or multiples ones. The library is fully async, then one thread is not a > problem. > > It has a powerful and flexible file server API, supporting range-based > requests, conditional requests, support for ETags and so on. > > After the GSoC, I had the chance to add tests for asynchronous abstractions > and now the implementation is much more trustable and stable. The choice to > reuse an existing HTTP parser (the Node.js's C parser) also helps a lot. > > The simple message-based API helps to support HTTP pipelining, allocation > fine tuning and much more. Besides HTTP pipelining, HTTP chunking (and > other modern features like 100-continue and HTTP Upgrade) are also > supported. > Do you have any users? If you don't have users, I suggest you become the first user by developing an application. -- Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net

4 3

Boost.locale update
by Maks Naumov 20 Apr '15

20 Apr '15

Any plans to update the Boost.Locale ? In https://github.com/boostorg/locale/pulls there are some fixes.

1 0

[ValueRef] Interest in a new library for immutable values with internal sharing?
by THOMAS JORDAN 20 Apr '15

20 Apr '15

Hi, I'd like to gauge whether there might be any interest in a new Boost library comprising a generic, non-intrusive, wrapper class for creating immutable/const values with sharing of the underlying object via internal reference counting. This new class would be called ValueRef (or possibly just Value), and it would effectively provide an assignable/swappable 'reference'/handle to shared, const values. It can be considered an effective alternative to the commonly used shared-pointer-to-const idiom, providing cleaner and more explicit value semantics, whilst also hiding calls to 'new' as an internal implementation detail. In a nutshell, ValueRef adapts a regular type T to give a new type ValueRef<T> with const T value semantics and uses reference counting of an underlying object on the heap internally to reduce copying overhead. ValueRef will spawn off a new copy of the wrapped object (if necessary) if the ValueRef is assigned another ValueRef or another object of type T. Const functions of T do not incur any overhead of counter access or copy and are invoked by either * or -> syntax. Forwarding constructors are provided which permit the wrapped value to be constructed in place, and conversion operator allows inter-operation with values of the unwrapped type. ValueRef also provides the common relational operators. I have so far implemented a rough (C++03-only so far) version of this (based on a stripped down version of Adobe::copy_on_write library) and a test suite and it seems to work okay. Example usage: /* type of ValueRef wrapped std::vector<int> */ typedef ValueRef<std::vector<int> > ValueRefVecType; /* create vector of 10 elements via forwarding constructor */ ValueRefVecType valueRefVector1(10,1); /* non-mutating/const op */ assert( valueRefVector1->size() == 10 ); /* non-mutating/const op */ assert( (*valueRefVector1)[0] == 1 ); /* error - compilation failure occurs calling a non-const op */ (*valueRefVector)[0] = 2; /* copy ctor */ ValueRefVecType valueRefVector2(valueRefVector1); /* test for equality */ assert( valueRefVector1 == valueRefVector2 ); /* test for equality (implicit conversion) */ assert( valueRefVector2 == std::vector<int>(10,1) ); /* valueRefVector1 and valueRefVector2 share same std::vector */ assert( valueRefVector1.identity(valueRefVector2) ); /* ref count is no longer one */ assert( !valueRefVector1.unique_instance() ); /* new value */ valueRefVector1 = std::vector<int>(5); /* non-mutating/const */ assert( valueRefVector1->size() == 5 ); /* test for equality - value semantics */ assert( !(valueRefVector1 == valueRefVector2) ); /* valueRefVector1 and valueRefVector2 do not share same std::vector */ assert( !valueRefVector1.identity(valueRefVector2) ); I am not aware of anything else current that provides this functionality. Regards, Tom

3 2

[release] Python 3 build problems
by Daniel James 20 Apr '15

20 Apr '15

Hi, Is there anyone who can write a brief description of the build problem with python 3 for the release notes? We probably should say something. thanks, Daniel

4 12

[regex] Support for Perl's (*SKIP)
by Sei Lisa 20 Apr '15

20 Apr '15

I'd like to see support for Perl's (*SKIP) regex verb in Boost. There are a number of verbs, but that one has an interesting and frequent use case: it enables searching for an expression but only outside of some contexts. There is a page called "The best regex trick" with details about the process and a number of examples. I can't link to it as this is my first message (I attempted before but it was rejected). It explains how to do it with and without (*SKIP). I've seen several questions in Stack Overflow asking how to accomplish that task, so it seems it's quite frequent to run into that need. Let's say for example that we want to find the string 'foo' as an identifier in C. This is a crude example of a Perl regex that does it (a real one might need to be more elaborate; in particular, backslashes for line continuation are not considered): (?x-s) (?# free spacing, dot doesn't match newline) (?://.*+ (?# eat single-line comment text) |/\*[\S\s]*?\*/ (?# eat multi-line comment text) |"(?:\\.|[^"\n])*+" (?# eat string text) )(*SKIP)(?!) (?# skip these) |\bfoo\b (?# match this) regex::search will match that expression only when foo is present outside of a string or comment. Without (*SKIP), it can be done only by calling regex::search multiple times, using an expression like this: (?-s)//.*+|/\*[\S\s]*?\*/|"(?:\\.|[^"\n])*+"|(\bfoo\b) and ignoring every match where group 1 wasn't matched. That's presumed to be slower, and certainly more inconvenient for the programmer. Support for this particular use case would be a great feature to have in the regex engine. Sei

2 3

[master] Open for 1.59?
by Joaquin M Lopez Munoz 20 Apr '15

20 Apr '15

Is master already open for commits towards Boost 1.59? Thank you, Joaquín M López Muñoz Telefónica

1 0

[config] BOOST_SYMBOL_VISIBLE on MinGW
by Robert Ramey 20 Apr '15

20 Apr '15

I made adjustments so that the serialization library on Develop branch will build with default visibilty = hidden. There is a little more to this than one would think. Basically I used BOOST_SYMBOL_VISIBLE on all "exported" classes (and their base classes) and BOOST_ARCHIVE_DECL ( defined as either BOOST_ARCHIVE_IMPORT or BOOST_ARCHIVE_EXPORT) on exported/visible member functions. This seems to give me what I need in that things build and test for gcc, clang, MSVC. EXCEPT for gcc under MinGW. see http://www.boost.org/development/tests/develop/developer/output/MinGW-32%20… The message seems to indicate to me that I should have BOOST_SYMBOL_VISIBLE on the class declaration - which seemed to resolve similar compilation errors with GCC on other platforms. Poking around config/compiler/gcc.hpp and config/plaform/w32.hpp It seems to me that this scheme things look OK - that is it looks that BOOST_SYMBOL_VISIBILITY should be defined as __attribute__((__visibility__("default"))) I'm also puzzled by the fact that the linker craps out only on this on declaration. Any help appreciated. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/config-BOOST-SYMBOL-VISIBLE-on-MinGW-tp4… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2