- Boost - lists.boost.org

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

21 Apr '15

> Message: 2 > Date: Tue, 21 Apr 2015 10:33:26 +0100 > From: Sam Kellett <samkellett(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: > <CAHK+-Fu6aYO2UwNkSvJWpn6UzmLjr+qNu+K3x8OSto8dyYGSBA(a)mail.gmail.com > > Content-Type: text/plain; charset=UTF-8 > On 20 April 2015 at 18:07, Thomas Jordan <tomjordan766(a)gmail.com> wrote: > > ValueRef doesn't expose (shared) pointers/pointees, they are a hidden, > > implementation detail. Its interface just deals in values (as shown in the > > example usage). > Absolutely! Hence the ref in the name. :) > I kept the pointer as part of the interface seeing as I saw it as a smart > pointer to replace another smart pointer, but either direction is not wrong > for sure. > The thing I like about the schrodinger_ptr is that I can carry on mutating > it while nobody else is looking, it seems with yours you would have to add > all data to it on it's construction, is that right? Yes, it is an immutable value with sharing of the underlying value object, that is pretty much the gist of it

1 0

Missing 1.58.0 tag on github.com
by Florent Guiliani 21 Apr '15

21 Apr '15

Hi, The release tag for Boost 1.58.0 is missing on github.com: https://github.com/boostorg/boost/releases Could someone please push the tag on github.com ? -- Florent

1 0

Re: [boost] [Boost-bugs] Fwd: [Boost C++ Libraries] #11211: Fusion example no longer compiles
by Joel de Guzman 21 Apr '15

21 Apr '15

Yes we should. This is a showstopper. On 4/21/15 3:06 PM, Damien Buhl wrote: > Sorry for this message, I just saw after sending that Flast already > replied about the problem : > > https://svn.boost.org/trac/boost/ticket/11211?replyto=3#comment:3 > > Shouldn't we make some bugfix release ? Because it is a seriously weird > issue. > > On 21/04/2015 09:01, Damien Buhl wrote: >> Hi Joel, >> >> Thanks for forwarding. >> >> Looks like the support for BOOST_CONSTEXPR BOOST_FUSION_GPU_ENABLED was >> added to DEFINE_STRUCT in a too strong way, which makes it impossible to >> use non-constexpr enabled types (namely std::string). >> >> I think the problem comes from the addition of BOOST_CONSTEXPR where >> BOOST_FUSION_GPU_ENABLED already was. >> >> In this commit >> https://github.com/boostorg/fusion/commit/2114bfca6c8d5e4f7fe2439346e1feddf… >> >> there is BOOST_CONSTEXPR added for the constructors and assignment >> operators. >> >> I think we have to remove the constexpr for this part, because we cannot >> add the requirements that the types the users gives to DEFINE_STRUCT are >> valid within constant expression. >> >> It also didn't come out by unit-tests runs, because our test are only >> done with int types. We have to add types which aren't constant-enabled >> to the tests for DEFINE_STRUCT and by the way for ADAPT also. >> >> I understand the idea behind adding BOOST_CONSTEXPR everywhere where >> BOOST_FUSION_GPU_ENABLED was, but actually it's not the same : on GPU >> there isn't any scenarii where one uses std::string I think, while it is >> typical in normal execution platform, and by the way BOOST_CONSTEXPR >> shouldn't be in this file. >> >> I've pushed a small commit where it then compiles for me on clang + g++ >> with C++03,11,14 : >>> https://github.com/boostorg/fusion/compare/boostorg:master...daminetreg:fea… >> >> >> Cheers, >> >> -- >> Damien Buhl >> >> On 20/04/2015 21:18, Joel de Guzman wrote: >>> Hello Kohei, Damien, >>> >>> Uh oh. Do you know what's happening here? >>> I'm getting: >>> >>> Constexpr constructor never produces a constant expression >>> >>> How did this slip? >>> >>> -------- Forwarded Message -------- >>> Subject: [Boost C++ Libraries] #11211: Fusion example no longer compiles >>> Date: Mon, 20 Apr 2015 19:01:29 -0000 >>> From: Boost C++ Libraries <noreply(a)lists.boost.org> >>> CC: boost-bugs(a)lists.boost.org >>> >>> #11211: Fusion example no longer compiles >>> -----------------------------------------------------+--------------------- >>> Reporter: Adrián Etchevarne <adrian.etchevarne@…> | Owner: djowel >>> Type: Bugs | Status: new >>> Milestone: To Be Determined | Component: fusion >>> Version: Boost 1.58.0 | Severity: Problem >>> Keywords: fusion | >>> -----------------------------------------------------+--------------------- >>> From the manual: >>> >>> {{{ >>> >>> #include <string> >>> #include "boost/fusion/adapted/struct/define_struct.hpp" >>> >>> // demo::employee is a Fusion sequence >>> BOOST_FUSION_DEFINE_STRUCT( >>> (demo), employee, >>> (std::string, name) >>> (int, age)) >>> >>> >>> int main() >>> { >>> } >>> >>> }}} >>> >>> It fails to compile with boost 1.58. With boost 1.57, compiles >>> successfully. >>> >>> g++ --std=c++11 test.cpp -I /home/saknussemm/downloads/boost_1_58_0 >>> >>> clang fails with a similar error. >>> >> _______________________________________________ >> Boost-bugs mailing list >> Boost-bugs(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-bugs >> -- Joel de Guzman http://www.ciere.com http://boost-spirit.com http://www.cycfi.com/

1 0

[convert] Help. Need promotion from 'develop' to 'master'.
by Vladimir Batov 20 Apr '15

20 Apr '15

On 04/21/2015 05:38 AM, Edward Diener wrote: > On 4/20/2015 1:10 PM, Vicente J. Botet Escriba wrote: >> Le 20/04/15 00:09, Vladimir Batov a écrit : >>> Daniel James created an entry point for 'convert' in the Boost >>> 'develop' branch and 'convert' has been sitting there for quite some >>> time. Now that Boost 1.58.0 has been released I would like to have >>> 'convert' promoted from 'develop' to 'master' so that 'convert' would >>> make it to 1.59. Is there anything that *I* can/need to do to have an >>> entry point created for 'convert' in the Boost 'master' branch? >> I would start a new thread and add you review manager. It is the review >> manager that should check everything is okay. > I was the review manager for 'convert' and it was accepted into Boost. > It has been on 'develop' and been regression tested. > > I myself am not sure of the process of moving a library from 'develop' > to 'master' so maybe someone dealing with the boostorg/boost project > can comment. > > My educated guess is that it would involve a fork of boostorg/boost, a > local 'pull --rebase' from that fork, changes locally that add the > library submodule to 'master' with the necessary commit, a 'push' back > to the fork, and then a pull request so that it shows up at > boostorg/boost and eventually gets merged into the superproject. I > believe part of the local changes are also that status/jamfile.v2 has > to be changed so that the library's tests are added to it. I would expect the master-branch-related "procedure" to be the same as for "develop". As I understand, I myself cannot create an entry point for the library (which is reasonable) and Daniel did that for me in the develop branch. So, I suspect, someone with super-duper permissions would need to step in. Any help in the matter would be greatly appreciated. Tnx, V.

1 0

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