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

[C++11] Is conditional code allowed?
by Fletcher, John P 02 Feb '14

02 Feb '14

I am working on bugs in boost phoenix. I have found some problems eg. #7624 which run fine with C++11 with either Clang 3.4 or gcc 4.8.2. I also have a patch which has been suggested for bug #8704 which uses C++11. Is there a way to incorporate C++11 only code into tests or the actual headers. If so, is there an example of how to do it in Boost? Thank you John Fletcher

3 3

RTG Graph Generator
by Khaled Ammar 02 Feb '14

02 Feb '14

Hi everyone, I noticed that boost has RMAT and Erdös-Renyi graph generator but it does not include a (more) recent and realistic graph generator like RTG. RTG is based on this paper from CMU: http://www.cs.cmu.edu/~lakoglu/pubs/RTG_GraphGenerator.pdf. -- Thanks, -Khaled

1 0

[modular] and status/explicit-failures-markup.xml
by Joachim Faulhaber 01 Feb '14

01 Feb '14

Dear modularists, I've just tried to make changes to modular-boost/status/explicit-failures-markup.xml. Since I have only write permission to my own library libs/icl in modular boost, trying to push my changes failed. What is the right way to change the regression test markups in modular-boost? Best, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

3 4

[offtopic] user-defined raw string literals
by Adam Wulkiewicz 01 Feb '14

01 Feb '14

Hi, I have some idea related to the usage of UDLs in Boost.Geometry library but the way I'd like to handle it is AFAIK not supported. A little introduction first. There are many text-based languages of defining data. One of them is WKT (http://en.wikipedia.org/wiki/Well-known_text) which allows to define vector data e.g. a polygon like this: |POLYGON((30 10, 40 40, 20 40, 10 20, 30 10))| So my thought was: why not use C++11 UDLs for this purpose? There are operators in the WKT language so I should probably use string literal, put WKT in it and be happy with it. The use case could look like this: |auto ||polygon = "POLYGON((30 10,40 40,20 40,10 20,30 10))|"_wkt; Ok so now the tricky part. It should be parsed in compile-time, the type of the geometry retrieved from the string literal and proper type returned (bg::polygon<> in this case). Unfortunately string literals can't be handled as raw literals, e.g. using the variadic-template version of operator"": template <char...> void operator "" () Why? Is there a reason for this? If we had the ability to use the compile-time version with string literals it would be possible to implement various compile-time parsers, not only for the mentioned WKT. So what do you think about it? Regards, Adam

2 2

[docs][website] Can the docs on the website be xhtml + svg?
by John Maddock 01 Feb '14

01 Feb '14

I've been investigating getting better equations and graphs into the Math lib docs and one prerequisite seems to be serving up pages as XHTML rather than HTML: without that SVG's simply do not display correctly (or at all) in IE. The docbook xhtml generation seems to be working OK, but would the pages get served correctly on the current website? Thanks, John.

3 6

[conversion] Need a help with MSVC failures
by Antony Polukhin 01 Feb '14

01 Feb '14

Hi, Some of the tests for Boost.LexicalCast fail on any MSVC compiler. Unfortunately currently I have no access to Windows. Could someone please investigate the failures and tell me were to search the bug? -- Best regards, Antony Polukhin

3 8

[range] Can iterator_range also model Random Access Range?
by Mostafa 01 Feb '14

01 Feb '14

It seems that iterator_range can properly model any refinement of the Forward Range concept. Is that right? The reason I ask is that this is not very clear from the documentation, and I had to deduce this from both the iterator_range API and the Random Access Range concept definition. (See documentation at: range/reference/utilities/iterator_range.html) Thanks, Mostafa

3 6

Range Adapters (map_keys, map_values) cause undefined behavior (segv, etc) when applied to R-Values, especially in the context of BOOST_FOREACH
by Igor Lubashev 01 Feb '14

01 Feb '14

Hi! I've filed a ticket (https://svn.boost.org/trac/boost/ticket/9578) for this issue two weeks ago, but I see no action there. Does anyone else think that this (see subj) is a problem? To spare the trouble of following the link, here is the essence of the problem, as I see it. (The ticket has a simple test case attached.) When applied to r-values (for example, maps returned by value from a function), adapters do not make a copy of the r-value but just capture a reference to it. This makes the returned range_iterator dangerous, if it is used after the r-value (the temporary) is destroyed. In particular, the following use causes undefined behavior on all compilers I'd tested on: g++ (4.1.2, 4.4.3, 4.6.3) and Visual Studio (15 [VC9], 16 [VC10]). BOOST_FOREACH(const string &s, return_map_by_value() | map_keys) ... Note that the following works fine (since BOOST_FOREACH takes care of differentiating between l-values and r-values and does the right thing to r-values): BOOST_FOREACH(const MapType::value_type &v, return_map_by_value()) ... It seems that boost::range::adapters need to do a similar thing to what BOOST_FOREACH is does to identify r-values and make a copy (which the compiler is likely to optimize away). Any comments are welcome! Thanks, - Igor

3 3