- Boost - lists.boost.org

[config] Configuring for C++14 and later library features.
by John Maddock 24 Apr '15

24 Apr '15

Folks, I have an open PR for adding BOOST_NO_CXX14_INTEGER_SEQUENCE (https://github.com/boostorg/config/pull/58) Unfortunately, the correct way to check for std::integer_sequence is to include <utility> and then check for __cpp_lib_integer_sequence. The problem is that we went to some lengths to remove dependencies on <utility> in https://github.com/boostorg/config/pull/40. Further, if we get requests for more such feature-detection macros, we would end up including the whole std lib (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3745#recs.cpp14) This doesn't look acceptable to me, but what to do? The only solution I can see is to simply not support these features in Boost.Config, but rather rely on users needing these features checking the std detection macros directly. Which will work up until someone implements a feature without defining the appropriate macro :( Thoughts? Thanks, John.

7 10

Re: [boost] [thread] Windows compilation broke with 8853a4c
by Jürgen Hunold 24 Apr '15

24 Apr '15

Hi Vicente, On Mittwoch, 22. April 2015 22:50:05 Vicente J. Botet Escriba wrote: > I have rolled back the changes. Please let me know if it works now on > develop. Yes, everything is working again. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

1 0

Git tag for 1.58
by Brian Ravnsgaard Riis 24 Apr '15

24 Apr '15

Hi, 1.58 is still not tagged in the git repo. Does anyone know the sha1 of the relevant commit...? Regards, Brian

1 0

[config] gcc,msvc,mingw visibility
by Robert Ramey 24 Apr '15

24 Apr '15

I've been enabling limited gcc visibility so that it works similarly to msvc *_DECL attributes and will export from the DLL/DSO only those symbols which need to be exported. I've had a lot of difficulty with this. I followed the instructions http://www.boost.org/doc/libs/1_58_0/libs/config/doc/html/boost_config/boos… which more or less boil down to using BOOST_SYMBOL_EXPORT when functions are exported, BOOST_SYMBOL_IMPORT when functions are imported, and BOOST_SYMBOL_VISIBLE on class declarations. I set my Jamfile.v2 in the library build to enable gcc visibility=hidden and let her rip. After the more or less normal back and forth it seemed that the library built and work on all platforms/compilers. .... EXCEPT Mingw. Hmmmm - this shouldn't be too tough, just look at how the other libraries did it. Turns out that it seems that no boost libraries actually enable gcc visibility in their builds - at least as far as I can tell. (I didn't dig into the depths of jam tools files). After a fair amount of research I concluded that for windows platforms - regardless of whether they are built with minnow (gcc) or mdvc, one needs to define BOOST_SYMBOL_VISIBLE as BOOST_SYMBOL_IMPORT or BOOST_SYMBOL_IMPORT which of course makes things more complicated. So here is what I came up with. My questions are: a) did I do this right? b) is there a simpler way c) if the answer to the above is no - can the documentation be updated? Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/config-gcc-msvc-mingw-visibility-tp46747… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3

[boost.serialization] Problem when serializing a wide char on version 1.58.0
by Marco Oman 23 Apr '15

23 Apr '15

Hi to all, I am having a problem with boost serialization on version 1.58.0 The code at the end of the post is nearly the same found at the beginning of the page libs/serialization/doc/index.html (the 'Very simple case'). The only relevant difference is the use of the wide char version of archive (and fstream) and an additional 'name' text field in the sample structure. This text contains a cyrillic character (the capitol 'D') The problem I am having with this code is that it throws an exception when using version 1.58.0, while everything is OK if I compile/link against version 1.57.0 The problem seems to be related with character conversion: the library seems to convert non ascii chars to local default codepage, instead of UTF-8. So everything looks fine as long as I use characters convertable to my codepage. I gave a look at the differencies between the two versions, but they are definitely beyond my reach... Tests done on windows with MSVC2013 and MSVC2008 Marco #include <fstream> // include headers that implement a archive in simple text format #include <boost/archive/text_woarchive.hpp> #include <boost/archive/text_wiarchive.hpp> ///////////////////////////////////////////////////////////// // gps coordinate // // illustrates serialization for a simple type // class gps_position { private: friend class boost::serialization::access; // When the class Archive corresponds to an output archive, the // & operator is defined similar to <<. Likewise, when the class Archive // is a type of input archive the & operator is defined similar to >>. template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & degrees; ar & minutes; ar & name; ar & seconds; } int degrees; int minutes; std::wstring name ; float seconds; public: gps_position(){}; gps_position(int d, int m, float s, const std::wstring &n) : degrees(d), minutes(m), seconds(s), name(n) {} }; int main() { // create and open a character archive for output std::wofstream ofs("filename"); // create class instance const gps_position g(35, 59, 24.567f, L"AДbc"); // save data to archive { boost::archive::text_woarchive oa(ofs); // write class instance to archive oa << g; // archive and stream closed when destructors are called } // ... some time later restore the class instance to its orginal state gps_position newg; { // create and open an archive for input std::wifstream ifs("filename"); boost::archive::text_wiarchive ia(ifs); // read class state from archive ia >> newg; // archive and stream closed when destructors are called } return 0; }

1 0

[OpenOffice] [Boost_Document_Library] [GSoC'15] Unable to compile and run the examples in the OpenOffice SDK
by Abhinav Tripathi 23 Apr '15

23 Apr '15

I know this question should be sent to OpenOffice forum. I sent it to their dev list but did not get any response so i am mailing it here in hope to get a response. . I downloaded The OpenOffice 4.1.1 deb files and Sdk 4.1.1 deb file... I used dpkg from command line to install all the deb files.. They got installed in /opt/openoffice4 and Sdk in /opt/openoffice4/sdk . I had to use deb files from the website because i couldn't download it from the apt-get... It showed errors like could not find... I am Using Ubuntu 14.10! When i tried to compile any example in /opt/openoffice4/sdk/examples/DevelopersGuide/ProfUNO/ i got many errors.. . To overcame some of these i did : 1. copied all files from /opt/openoffice4/sdk/bin/ to my root folder /bin/ because the error said /bin/cppumaker : command not found 2. Used a conf file to load all libraries in linux linker cache... using sudo ldconfig because g++ showed error that libreg.so.3 was not found! 3. copied the types.rdb file from sdk folder to my root folder / because it said something about registries not loaded. 4. made a few variables in the makefile like OO_SDK_HOME, JAVA_HOME, JAVA_BIN to allow compilation... 5. Made folder for each example in /opt/openoffice4/sdk/LinuxExamples.out/bin folder because g++ always gave the error that the there was no file or folder of the name of the example that i was compiling. . Now, i am able to compile the examples but when i try to run them with : make office_connect.run or anything like that then again i am getting errors regarding command not found. cd ../../../../LINUXexample.out/bin && office_connect /bin/sh: 1: office_connect: not found Makefile:100: recipe for target 'office_connect.run' failed make: *** [office_connect.run] Error 127 I think it is because of this line in the makefile : %.run: $(OUT_BIN)/%$(EXE_EXT) cd $(subst /,$(PS),$(OUT_BIN)) && $(basename $@) I have no experience of Makefiles and also i am new to openoffice sdk... I am guessing that these errors are happening beacause i installed the packages manually from dpkg instead of using apt-get... Also, i did use setsdkenv_unix once but i think it didnt work as expected as the variables in Makefile are NOT set.. . . It took me nearly a week to figure out these errors and now my patience is wearing out. I know that there has to be an elegant solution to this problem. Please help! . Abhinav

2 4

[Git] Pull requests and rebasing
by John Maddock 22 Apr '15

22 Apr '15

So I have a rebase vs pull question: Lets say I have a PR, if I merge that to my local tree using "git pull --rebase remote-repro branch-name" then I get a nice clean history locally without those pesky merge commits cluttering everything up. But... Now I can't fast-forward when I push to the remote, *because I've changed the existing history of the develop branch*. Would this not be a) bad form, and b) potentially dangerous to push to the remote develop branch? Still don't understand Git yours, John.

6 7

[typeof][CMT] Could the maintenance team please review and merge a trivial pull request?
by Adam Wulkiewicz 22 Apr '15

22 Apr '15

Hi, There is one trivial PR hanging for nearly a year now: https://github.com/boostorg/typeof/pull/1 In those 2 lines of code namespace boost was explicitly added in front of enable_if and disable_if. This allows msvc8 to compile the tests when Boost.Test and Boost.TypeOf are both used. Could you please have a look at it? Regards, Adam

3 4

Re: [boost] [ValueRef] Interest in a new library for immutable values with internal sharing?
by Thomas Jordan 22 Apr '15

22 Apr '15

> Message: 2 > Date: Mon, 20 Apr 2015 15:40:37 +0100 > From: Sam Kellett<samkellett(a)gmail.com> > > To:boost@lists.boost.org > Subject: Re: [boost] [ValueRef] Interest in a new library for > immutable values with internal sharing? > Message-ID: > <CAHK+-Fsy1-sCuMuz+hpjNC2ogAbxUazNY0Qt3xL__bndzkwduw(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > I had a similar idea for a new smart pointer that would aim to obsolete the > shared_ptr-to-const idiom. The problem I found with that idiom is that it > only guarantees that you can't change it. There's no promise that somebody > else doesn't have a non-const ref to the data and so it could in the worst > case completely change from under your feet (even if you know it won't get > destroyed). 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).

3 2

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

22 Apr '15

> Message: 7 > Date: Tue, 21 Apr 2015 15:37:56 +0000 (UTC) > From: Joaquin M Lopez Munoz <joaquin(a)tid.es> > To: boost(a)lists.boost.org > Subject: Re: [boost] [ValueRef] > Message-ID: <loom.20150421T164358-569(a)post.gmane.org> > Content-Type: text/plain; charset=utf-8 > THOMAS JORDAN <tomjordan766 <at> gmail.com> writes: > > > > > Message: 7 > > > Date: Mon, 20 Apr 2015 18:39:57 +0000 (UTC) > > > From: Joaquin M Lopez Munoz <joaquin <at> tid.es> > > > > > Boost.Flyweight uses move semantics and perfect fwd ction where > > > available, > > > I don't see how another solution can do better on this front > > > > Agreed, I'll withdraw that statement. However, as I said in the O.P., the > > ValueRef implementation I have done is currently only C++03. It uses a > > combination of N x forwarding constructor overloads taking arguments by > > const reference, and the client can use reference wrappers to forward to > > lvaluesto do the non-perfect forwarding (as boost.shared_ptr make_shared > > does) . The intention in the final library would be to support > > C++11/perfect forwarding and possibly Boost.Move for C++03 move semantics. > > So they would be equivalent in that regard. > Understood. Boost.Flyweight does in fact this something similar, > you might want to take inspiration from > http://boost.org/boost/flyweight/detail/perfect_fwd.hpp > > > Boost.Flyweight is indeed heavier on the include side than some > > > people might be comfortable with. > > > > I think this is my concern with having Boost Flyweight as the only option > > for what is a relatively simple type. ValueRef is currently about 350 > > lines of easy-to-understand code in a single header file, and has no > > dependencies on MPL or any other Boost or std libraries, with the > > exception of an atomic library. > > It is intended in particular as a lightweight, clean replacement for > > shared-ptr-to-const, which I see used a lot in code [...] > Of course I don't want to disregard the merit of a lightweight approach > to implementing this idiom. I'm curious: why are you implementing > this from scracth, using atomic etc. rather than wrapping > boost::shared_ptr? The latter, seems to me, is going to be much less > code on your side and the dependencies on the lib are not that many: > http://www.pdimov.com/tmp/report-b1adfee/smart_ptr.html I was inaccurate when I said that ValueRef did not depend on any std libraries, in fact it depends on <memory> for std::allocator<T>. I've modified it to use boost::shared_ptr and boost::allocate_shared (though still just with C++03 forwarding constructors at the moment) - it was trivial, and reduces the LOCS by ~half. > Joaqu?n M L?pez Mu?oz > Telef?nica Tom

1 0