- Boost - lists.preview.boost.org

[vmd] Added to new release
by Edward Diener 26 Oct '15

26 Oct '15

I would like to make sure the VMD library is added to the upcoming Boost 1.60 release. Is there anything further I have to do to affect that ?

1 0

[Hana] Postponing release to 1.61.0
by Louis Dionne 24 Oct '15

24 Oct '15

Hi, Some of you might know that I have been pushing hard to deliver Hana with the next Boost release. I have even taken the (soft) engagement to do so at CppCon in last September. However, due to some time constraints, it is now clear that Hana will not be included in Boost 1.60.0, the limit for new libraries being yesterday. I hoped really hard to make it in time for Boost 1.60.0, but the closing of the release branch ~1 month before the release date got me by surprise. All in all, this is not too bad since there are still a couple issues that must be addressed, and I believe that taking more time to address them properly will be beneficial to the community in the long term. Also, while I really wanted to make Hana available to the wider community ASAP, I do not think waiting 3 more months will be very harmful. Given the current level of C++14 support in compilers, only people on Clang >= 3.5 would have been able to use Hana, and I do not think this represents such a huge amount of potential users. As a side note, given my previous announcements, some users might find it strange not to see Hana as part of 1.60.0. Hence, I wonder whether it would be possible to include a short note with a link to this message somewhere in the release notes for 1.60.0? Regards, Louis

3 4

[detail] Compilation broken in develop and some questionable ideas
by Antony Polukhin 24 Oct '15

24 Oct '15

Hi, The commit https://github.com/boostorg/detail/commit/9fcf2ae390c7c21a9b42fd40dd5c0eec1… breaks the compilation of Boost.Filesystem: D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(126): error C2487: 'do_in': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(136): error C2487: 'do_out': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(152): error C2487: 'get_octet_count': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(156): error C2487: 'get_cont_octet_out_count': member of dll interface class may not be declared with dll interface D:\t08\run\boost_root\boost/detail/utf8_codecvt_facet.hpp(189): error C2487: 'do_length': member of dll interface class may not be declared with dll interface According to MSDN only the whole class or class separate members could be decorated with BOOST_UTF8_DECL, not both ( https://msdn.microsoft.com/en-us/library/t72ahzw1.aspx) Now the questionable part... We could theoreticaly avoid duplication of `utf8_codecvt_facet` code in libraries and even avoid code breakage if we: * move `struct utf8_codecvt_facet` to namespace `boost::detail::utf8_codecvt_facet_namespace` * mark all it's functions as inline, even the virtual ones => `inline` will implicitly mark the stuff in `struct utf8_codecvt_facet` as weak symbols, so that multiple occurences of it will be reduced to one by linker * add the using declaration `BOOST_UTF8_BEGIN_NAMESPACE using boost::detail::utf8_codecvt_facet_namespace::utf8_codecvt_facet; BOOST_UTF8_END_NAMESPACE` => using declaration will help the existing code to find class in `BOOST_UTF8_BEGIN_NAMESPACE` defined namespaces. Questionable part number two... Is it time to move Boost.Detail module into Boost.Core/Boost.Algorithm/Boost.MPL? Main points are: * Boost.Detail is really old and many people who maintained it are inactive. Moving it into rapidly developing modules will improve it's support (maybe even docs will appear! or tests!) * Nobody knows what does `Deatil` mean in that particular case. `detail::` namespace is a namespace that user must not use. However there's some cool stuff in Detail module that must be available to users, so the name Detail is obfuscating here. -- Best regards, Antony Polukhin

5 4

Painting a bikeshed ...
by Marshall Clow 21 Oct '15

21 Oct '15

In Sean Parent's CppCon keynote last week, he went through the process of implementing an algorithm he called "sort_subrange", which takes four iterators describing two ranges, one a subset of the other, and sorts the subrange - as if you had sorted the entire range. (See https://www.youtube.com/watch?v=sWgDk-o-6ZE, starting at about 31:30). I have implemented this in Boost.Algorithm (crediting Sean) - called partition_sort. However, while I was doing this, I thought of a different algorithm; one that gathered all the elements into the subrange as if the entire range was sorted, but didn't actually do the sorting. I've implemented that one, too - but I'm having a bit of trouble coming up with a name. I've used "partition_subrange", but that not that clear. Sean has suggested "elements_in_subrange" and "elements_within_subrange". Here's the declaration: template<typename Iterator, typename Pred> void partition_subrange ( Iterator first, Iterator last, Iterator sub_first, Iterator sub_last, Pred p) /// \brief Gather the elements of the subrange [sub_first, sub_last) that is /// inside the range [first, last) as if you had sorted the entire range. Any suggestions? -- Marshall

11 18

(no subject)
by Kabir Sahni 21 Oct '15

21 Oct '15

Hello! I have recently joined the mailing list and i am willing to contribute.Can anyone guide me

2 1

[metaparse] Transferring the repository to Boostorg
by Abel Sinkovics 21 Oct '15

21 Oct '15

Hi, I'd like to transfer my Metaparse repository (https://github.com/sabel83/metaparse) to Boostorg. Based on another thread on Hana, I assume I need temporary admin rights to boostorg to be able to transfer the repository. Please give me temporary admin rights (I've posted an issue for it as well: https://github.com/boostorg/admin/issues/110) or suggest another method for the repository transfer. Thanks, Abel

2 12

[Locale] New utf-8 codecvt facet in master (replacement of boost/details/utf8_codect_facet)
by Artyom Beilis 21 Oct '15

21 Oct '15

Hello, Following previous discussion regarding utf-8 facet in boost. I merged the changes to master branch. New utf8 codecvt facet that properly handles both UTF-16 and UTF-32 encoding for wchar_t (or char16_t/char32_t) is there. The major goal is to replace existing broken (*) utf8 facet existing today in boost/details/utf8_codecvt_facet.hpp/ipp It is implemented in header only so all you need is to include #include <boost/locale/utf8_facet.hpp> And install it as usual: std::locale new_locale(std::locale(),new boost::locale::utf8_codecvt<wchar_t>()); It *does not require* a separate compilation part like the one in details Note it is implemented in terms of boost::locale::generic_codecvt template<typename CharType,typename CodecvtImpl,int CharSize=sizeof(CharType)> class generic_codecvt; That has non-trivial specialization for CharSize=2 and CharSize=4 for UTF-16 and UTF-32 wchar_t/char16_t/char32_t character handling. boost::locale::generic_codecvt provides an interface for creating a range of facets for various character encodings. For example boost.locale uses it to implement various facets: - utf8 codecvt - single byte character set like ISO-8859-* or Windows-125* - wrap ICU ucnv_* and POSIX iconv APIs to create standard codecvt facet. That is why I decided to keep the implementation withing Boost.Locale library as the place that actually deals with different encoding. ----------- Once boost 1.60 will be released I encourage every library maintainer that incorporates broken boost/details/utf8_codecvt_facet.*pp to replace one with proper one from boost.locale Note: it is HEADER ONLY part and does not require any part of compiled library. Artyom Beilis (*) Current implementation does not handle utf-16 properly and can actually produce invalid utf-8

1 0

[Hana] Transferring repository to boostorg on GitHub
by Louis Dionne 19 Oct '15

19 Oct '15

Hi, I would like to know what is required from me to transfer the Hana repository from my GitHub account to boostorg. I reckon I should be added as a member of the boostorg "organization" on GitHub? Regards, Louis

2 14

Re: [boost] [interprocess] Interprocess mutex not working / throwing exception when trying to write lock
by nav999 19 Oct '15

19 Oct '15

> Hi, > > 1. Your lockWithWriteLock and lockWithReadLock create a lock, which locks > on construction and unlocks on destruction, hence when the function > returns no lock is held on the mutex. > > 2. The fact that you put a scope here makes me think that your intention > is for the lock to be unlocked at the end of this scope (which it won't, > as it is unlocked way before, as per #1). > > { > std::cout<<"Program 1: Before first locking > -------------------------- 1 v\n"; > temp.sharedMutex->lockWithWriteLock(); > const unsigned int SLEEP_TIME_IN_SECOND = 60; > std::cout<<"Program 1: sleep for "<< SLEEP_TIME_IN_SECOND << "\n"; > sleep(SLEEP_TIME_IN_SECOND); > std::cout<<"Program 1: Finished sleeping\n"; > } > > In this case though, you would perform the wait in bold while still > holding the lock, and hence preventing the 2nd program from locking it. > Once out of the scope you destroy the object right away. > > NOTE: both the issue in #1 and #2 lead to your first program possibly > deleting the mutex before the 2nd program is done with it. Which leads to > the issue you are experiencing. > > 3. If you need to have the 1st program wait for the 2nd program to be > done, then do not use sleeps, use a condition_variable. Thanks. I didn't know the lock unlocks on destruction. I had taken a cue from a post on StackOverflow: http://stackoverflow.com/questions/12439099/interprocess-reader-writer-lock… I'm using sleep only for testing purpose. The dilemma still is, how to make the mutex visible to both processes? This thread got rejected by the admin who suggested it could be posted on the users subforum, so kindly reply to my post there to continue the discussion: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-work… -- View this message in context: http://boost.2283326.n4.nabble.com/interprocess-Interprocess-mutex-not-work… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 1

[interprocess] How to know how much memory is taken up by an object allocated in boost interprocess shared memory?
by nav999 19 Oct '15

19 Oct '15

Re-posting, as the boost mailing list rejected the first post <http://boost.2283326.n4.nabble.com/How-to-know-how-much-memory-is-taken-up-…> mentioning that I had to add "[interprocess]" to the subject line. I have asked this question on stackoverflow <http://stackoverflow.com/questions/30642585/why-does-an-object-allocated-in…> , but got no response. For this program: #include <iostream> #include <boost/interprocess/mapped_region.hpp> #include <boost/interprocess/managed_shared_memory.hpp> #include <boost/interprocess/containers/list.hpp> #include <iostream> #define SHARED_MEMORY_NAME "SO12439099-MySharedMemory" #define DATAOUTPUT "OutputFromObject" #define INITIAL_MEM 650000 #define STATE_MATRIX_SIZE 4 using namespace std; namespace bip = boost::interprocess; class SharedObject { public: unsigned int tNumber; bool pRcvdFlag; bool sRcvdFlag; unsigned long lTimeStamp; }; typedef bip::allocator<SharedObject, bip::managed_shared_memory::segment_manager> ShmemAllocator; typedef bip::list<SharedObject, ShmemAllocator> SharedMemData; int main() { bip::managed_shared_memory* seg; SharedMemData *sharedMemOutputList; bip::shared_memory_object::remove(DATAOUTPUT); seg = new bip::managed_shared_memory(bip::create_only, DATAOUTPUT, INITIAL_MEM); const ShmemAllocator alloc_inst(seg->get_segment_manager()); sharedMemOutputList = seg->construct<SharedMemData>("TrackOutput")(alloc_inst); std::size_t beforeAllocation = seg->get_free_memory(); std::cout<<"\nBefore allocation = "<< beforeAllocation <<"\n"; SharedObject temp; sharedMemOutputList->push_back(temp); std::size_t afterAllocation = seg->get_free_memory(); std::cout<<"After allocation = "<< afterAllocation <<"\n"; std::cout<<"Difference = "<< beforeAllocation - afterAllocation <<"\n"; std::cout<<"Size of SharedObject = "<< sizeof(SharedObject) <<"\n"; std::cout<<"Size of SharedObject's temp instance = "<< sizeof(temp) <<"\n"; }//main The output is: Before allocation = 649680 After allocation = 649632 Difference = 48 Size of SharedObject = 16 Size of SharedObject's temp instance = 16 If the size of SharedObject and it's instance is 16 bytes, then how can the difference in allocation be 48? Even if padding had automatically been done, it's still too much to account for 3 times the size (for larger structures it goes to 1.33 times the size). Because of this, I'm unable to allocate and dynamically grow the shared memory reliably. If SharedObject contains a list which grows dynamically, that could add to the uncertainty of space allocation even more. How can these situations be safely handled? How can I know exactly how much of memory to allocate? -- View this message in context: http://boost.2283326.n4.nabble.com/interprocess-How-to-know-how-much-memory… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 4