- Boost - lists.boost.org

Embedding manifest into the regression tests (was: [testers] [log] Problems with tests)
by Sergey Cheban 13 May '13

13 May '13

On 13.05.2013 13:23, Andrey Semashev wrote:> On Mon, May 13, 2013 at 12:58 PM, Sergey Cheban <s.cheban(a)drweb.com> wrote: >> The problem is related to the fact that MS Windows (at least, Windows >> Server 2012) requires elevation for the execulables with names that >> match the *patch*.exe mask. So, util_dynamic_type_disPATCHer and >> util_static_type_disPATCHer require elevation. > lol, what a wonderful and obvious security policy on MS part, isn't > it? :) I've found that the same tests succeeded for the msvc-9.0 toolset. It is because the manifest file is generated for this toolset. I've found that the "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\include\crtdefs.h" file contais the following: =============================================== #pragma comment(linker,"/manifestdependency:\"type='win32' " \ "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".DebugCRT' " \ "version='" _CRT_ASSEMBLY_VERSION "' " \ "processorArchitecture='x86' " \ "publicKeyToken='" _VC_ASSEMBLY_PUBLICKEYTOKEN "'\"") =============================================== and the "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\crtdefs.h" and "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\crtdefs.h" contain no such code. The bjam scripts embed the manifest into the executable if it was generated by the linker. And the linker generates the manifest by default if the /manifestdependency option was specified. May be, it is reasonable to add the "/MANIFEST" to the linker options explicitly. Btw, I see the following in the msvc.jam: ================================================ if [ MATCH ^([67]) : $(version) ] { .... } else { .... # Make sure that manifest will be generated even if there is no # dependencies to put there. toolset.flags $(toolset).link LINKFLAGS $(conditions)/<embed-manifest>off : /MANIFEST ; } ================================================ -- Sergey Cheban

3 6

Re: [boost] Live read-only GIT mirrors of Boost trunk SVN
by Niall Douglas 13 May '13

13 May '13

> on Thu May 09 2013, Niall Douglas <ndouglas-AT-blackberry.com> wrote: > > Just to be clear and for the record, I have no compelling arguments, > > no plan for migration, and I am in no way criticizing your work, your > > leadership, nor suggesting the throwing away of any planning or > > coding. I apologise unreservedly if anything in my words appeared that > > way. I am absolutely sure that you have given this the very deepest of > > thought and I - as always actually - trust your judgment. I am simply confused. > > OK. I don't know how to un-confuse you, though, sorry. > [snip] > Unfortunately for my workload, the community begs to differ. The lightbulb has switched on: I had been confused because I had thinking the migration was based on technical arguments. I now realize the arguments are mostly non-technical, so I am now deconfused. Thanks for the illumination. > > We can talk about this at C++ Now next week, but if we were to > > coordinate our efforts and I have definite approval and support from > > Boost SC, I have no objection to volunteering for this. > > I don't see what difference approval from the steering committee makes. > If you think it would be helpful, you can go ahead. A two way mirror would need changes to the main Boost SVN installation. Changes which could lose data and cause outages. It's not something I'd proceed with without unanimous support, especially for moral support if data loss did occur. > > That probably is unacceptable to you given your apparent plans. > > Yeah, we want to get this thing over with. Thanks for the suggestions, though. I understand entirely now. Sorry it took a while. Do get in touch if you need it. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

Re: [boost] Git Modularization Ready for Review
by Niall Douglas 13 May '13

13 May '13

> It's a question of degree. Daniel et. al.'s recent work shows that you > can keep that loss pretty low. "Where there's a will there's a way?" Agreed. With enough effort anything is possible. But tough on those tasked with the grunt work. > >> What happens in a few years time when Git is replaced with the next big > > thing? > >> Do we lose the history again? And then again when that gets replaced too? > > > > That's exactly what happens. Bitrot is always inevitable in the long run. > > Here call it "non-fatal bitrot" :) > > > > My only red line is corruption of past and present source code releases. It > > must *always* be possible to check out tag X and build release X. > > So why have a VCS at all? Named tarballs meet your red line. VCS is for workflow and collaboration. Optionally for blaming bugs through automated regression analysis. They can be useful for generating some interesting stats. And yes, I do use named tarballs (or ZFS snapshots more recently) of the VCS store exactly for history preservation. VCSs aren't for history preservation, especially as they're usually not bitrot tolerant. > > Well, the Git way of helping stuff get out of step is that everyone gets > > their own full copy of the whole repo, and their copy is just as important > > as anyone else's copy. You clone, you develop and test, and optionally push > > changes elsewhere which could be your friend, your team, your employer, or > > of course some central authoritative copy. > > That works for a monolithic project. Boost is not monolithic but it's > single repo model was forcing it to act like one. As well as making > life a little easier for library developers, the modularisation effort > should help end users too. For a while now people have been wanting to > take only what they need from Boost and ignore the rest. It's > especially important in commercial environments where manager (rightly > or wrongly) are reluctant to depend on huge quantities of unreviewable > code with unknown interactions. Modularisation won't solve the problem > overnight but it helps. I disagree with pretty much all of this. And I think modularization, as currently proposed if I understand it correctly, actually makes those feared interactions much worse and/or much more work to avoid. > > So I'm afraid I just don't get the present design for a library as > > small and as tightly integrated as Boost. > > You must be talking about some other Boost. It's all subjective. I agree there are a chunk of Boost libraries which are fairly standalone and I have no problem with those being turned into git submodules. > > I'm a great believer in refusing to let programmers commit code which breaks > > other code rather than nagging them later to fix an earlier commit. The > > point of failure notification ought to be as close to cause as > > possible. > > Surely the developer sees the breakage the moment they update the > versions of the other libraries they are working against. And then they > can fix it at their leisure while early adopters get to use their code > with the previous version of the conflicting library. My point is this isn't automatic. It requires programmers not to be lazy. That hasn't been hugely successful in the past. > When you are talking about breakages are you talking about merge > conflicts or compile/test-failures? Up till now I've assumed you mean > the latter. But now I'm thinking you might be asking what happens if > the developer of library X makes a change to header H and developer Y > also makes a change to _the same header_? No that's easily detectable. My concern is when modifications to submodule A and submodule B cause arbitrary C in some submodule D to suddenly fail. > The way the modularisation works, I'm not even sure this is possible. > The libraries are meant to be self-contained so you only ever change > your own headers. It's a good question and one I hand't thought about. > Perhaps the people working on this can weigh in here. Git submodules are too loosely coupled for anything but loosely coupled, fairly standalone libraries. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

[chrono/date] name of getters - error: changes meaning of
by Vicente J. Botet Escriba 13 May '13

13 May '13

Hi, Naming the getters with the same name as the type chrono::year year() const; results in a lot of error with gcc <= 4.8.0 ../../../boost/chrono/date/ymd_date.hpp:267:7: erreur: declaration of ‘boost::chrono::year boost::chrono::ymd_date::year() const’ [-fpermissive] ../../../boost/chrono/date/year.hpp:36:11: error: changes meaning of ‘year’ from ‘class boost::chrono::year’ [-fpermissive] When I add -fpermissive I get yet the warning ../../../boost/chrono/date/year.hpp:36:11: attention : changes meaning of ‘year’ from ‘class boost::chrono::year’ [-fpermissive] Do someone how to get ride of this warning/spam? In addition, no way to make it working with gcc-4.2.1. No issue with clang-3.1, 3.2. Not checked with msvc. Is this a bug on gcc? Best, Vicente

2 1

[chrono/date] class names
by Vicente J. Botet Escriba 13 May '13

13 May '13

Hi, I would like to fix the names of date classes for the different representations. I'm not saying that all the representations need to be provided for a first release. Here it is my proposal. The following are unchecked and non contextual dates classes * calendar_date: field based representation of year + month + day. * serial_date: days based representation * ordinal_date: field based representation of year + day_of_year * week_date: field based representation of year + week + weekday Checked dates classes names just add a checked_ prefix to the corresponding unchecked date classes. * checked_calendar_date: field based representation of year + month + day. * checked_serial_date: days based representation * checked_ordinal_date: field based representation of year + day_of_year * checked_week_date: field based representation of year + week + weekday We can also have an alias date template <typename Tag = serial, validity=validity::unchecked> class date; so that date<calendar> ~ calendar_date date<serial> ~ serial_date date<> ~ serial_date ... I'm, open of course, to other defaults for these parameters, if the idea of an alias is accepted. For the time been a single contextual date class should be enough, as all the contextual information is relative to the year/month/day representation. * contextual_date: field based representation of year + month + day + context-meta-data Comments, critics and suggestions are welcome. Best, Vicente

3 9

[any][quickbook] Recent compile failure gcc vs. clang..
by Rene Rivera 13 May '13

13 May '13

Not sure when this started failing other than it was some time this past week.. ===== Froggy:quickbook grafik$ pwd /Users/grafik/devroots/Boost/trunk/tools/quickbook Froggy:quickbook grafik$ b2 toolset=clang ...patience... ...patience... ...found 1735 targets... Froggy:quickbook grafik$ b2 toolset=darwin ...patience... ...patience... ...found 1735 targets... ...updating 3 targets... darwin.compile.c++ ../../bin.v2/tools/quickbook/src/darwin-4.2.1/release/link-static/quickbook.o ../../boost/any.hpp: In function ‘ValueType boost::any_cast(boost::any&) [with ValueType = const int&]’: ../../boost/any.hpp:308: instantiated from ‘ValueType boost::any_cast(const boost::any&) [with ValueType = const int&]’ ../../boost/program_options/variables_map.hpp:69: instantiated from ‘const T& boost::program_options::variable_value::as() const [with T = int]’ src/quickbook.cpp:387: instantiated from here ../../boost/any.hpp:292: error: forming reference to reference type ‘const int&’ ../../boost/any.hpp:294: error: forming reference to reference type ‘const int&’ ../../boost/any.hpp: In function ‘ValueType boost::any_cast(boost::any&) [with ValueType = const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&]’: ../../boost/any.hpp:308: instantiated from ‘ValueType boost::any_cast(const boost::any&) [with ValueType = const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&]’ ../../boost/program_options/variables_map.hpp:69: instantiated from ‘const T& boost::program_options::variable_value::as() const [with T = std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >]’ src/quickbook.cpp:421: instantiated from here ../../boost/any.hpp:292: error: forming reference to reference type ‘const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&’ ../../boost/any.hpp:294: error: forming reference to reference type ‘const std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&’ ../../boost/any.hpp: In function ‘ValueType boost::any_cast(boost::any&) [with ValueType = const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&]’: ../../boost/any.hpp:308: instantiated from ‘ValueType boost::any_cast(const boost::any&) [with ValueType = const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&]’ ../../boost/program_options/variables_map.hpp:69: instantiated from ‘const T& boost::program_options::variable_value::as() const [with T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >]’ src/quickbook.cpp:438: instantiated from here ../../boost/any.hpp:292: error: forming reference to reference type ‘const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&’ ../../boost/any.hpp:294: error: forming reference to reference type ‘const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&’ ../../boost/system/error_code.hpp: At global scope: ../../boost/system/error_code.hpp:222: warning: ‘boost::system::posix_category’ defined but not used ../../boost/system/error_code.hpp:223: warning: ‘boost::system::errno_ecat’ defined but not used ../../boost/system/error_code.hpp:224: warning: ‘boost::system::native_ecat’ defined but not used "g++" -ftemplate-depth-300 -O3 -finline-functions -Wno-inline -Wall -gdwarf-2 -fexceptions -g0 -DBOOST_ALL_NO_LIB=1 -DBOOST_DETAIL_CONTAINER_FWD -DBOOST_FILESYSTEM_NO_DEPRECATED -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"../.." -c -o "../../bin.v2/tools/quickbook/src/darwin-4.2.1/release/link-static/quickbook.o" "src/quickbook.cpp" ...failed darwin.compile.c++ ../../bin.v2/tools/quickbook/src/darwin-4.2.1/release/link-static/quickbook.o... ...skipped <p../../bin.v2/tools/quickbook/src/darwin-4.2.1/release/link-static>quickbook for lack of <p../../bin.v2/tools/quickbook/src/darwin-4.2.1/release/link-static>quickbook.o... ...skipped <p../../dist/bin>quickbook for lack of <p../../bin.v2/tools/quickbook/src/darwin-4.2.1/release/link-static>quickbook... ...failed updating 1 target... ...skipped 2 targets... ===== Seems some of the std::any conformance changes broke for the GCC included in the Xcode 4.6.2. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

4 6

Re: [boost] [config] BOOST_FORCEINLINE for clang
by Daryle Walker 13 May '13

13 May '13

I didn’t know that the GCC emulation went that deep. Anyway, I think that Clang should eventually wean away from being a GCC copycat, and that comment would be necessary. And if that doesn’t happen, another maintainer may wonder about Clang support, not knowing the details on Clang’s GCC emulation, and seeing the comment will save a trip to this mailing list. Sent from Windows Mail From: Mathias Gaunard Sent: ‎Monday‎, ‎May‎ ‎13‎, ‎2013 ‎5‎:‎45‎ ‎AM On 13/05/13 07:12, Daryle Walker wrote: > You should include a comment in the GCC section that it also works for Clang, > due to Clang's GCC emulation. That way, later maintainers won't be wondering > if Clang support should be added. (And help debugging if Clang ever stops > emulating GCC by default.) Isn't it common knowledge that Clang is compatible with GCC and pretends to be GCC 4.2, and that therefore most GCC-specific code will just work with Clang out of the box?

1 0

boost modularization questions
by Eric Cornelius 13 May '13

13 May '13

Hi all, Out of curiosity, is the plan to move to a git pull-request model once the modularization process is complete? Or is github being used simply as a convenient mirror and interface for browsing code and history? Also, I have some changes to the Jamroot and boostcpp.jam files for improving modularization builds, which aggregate all the public headers from modules into the standard boost/... layout within the install/include directory, as well as implicitly setting up include paths during the initial build process. https://github.com/EricMCornelius/boost/commit/cdc08a1afa4b3df85997d54d9e6a… Cheers, Eric Cornelius

3 2

Boost range - Add variadic join/zip
by Gonzalo BG 12 May '13

12 May '13

Code available here: https://gist.github.com/gnzlbg/5547905 Let, std::array<double,4> a = {{ 1, 2, 3, 4 }}; std::list<int> b = { 11, 22, 33, 44 }; std::deque<int> c = { 111, 222, 333, 444 }; std::vector<int> d = {1111,2222,3333,4444 }; If the values stored in a container have the same type, I would like to iterate over different containers as if it were a single one, and: /// - modify its value for(auto&& i : join(b,c,d)) { i += 1; } /// - use it with boost algorithms boost::transform(join(b,c,d),begin(join(b,c,d)),[&](int j){ return j * 2; }); /// - and read it for(const auto& i : join(b,c,d)) { std::cout << i << "\n"; } Another problem I usually face is manipulating data that has different types. This data is usually stored in different containers for efficiency, but it does belong together. Zip can be used to iterate throw a row of this kind of table-like data structure: for(const auto& t : zip(a,b,c,d)) { std::cout << t << "\n"; } However, boost's zip_iterators are not writable. I don't really think it would be possible to make them writable, but that would allow code like this: typedef decltype(*begin(zip(a,c,d))) tIt; boost::sort(zip(a, c, d), [](const tIt& i, const tIt& j){ return boost::get<0>(i) > boost::get<0>(j); }); which sorts the three containers in lock-step after the values in the first container (a). Some parts of this code can be implemented with minor extensions to boost range. A variadic join might look like this: template<class C> auto join(C&& c) -> decltype(boost::make_iterator_range(c)) { return boost::make_iterator_range(c); } template<class C, class D, class... Args> auto join(C&& c, D&& d, Args&&... args) -> decltype(boost::join(boost::join(boost::make_iterator_range(std::forward<C>(c)), boost::make_iterator_range(std::forward<D>(d))), join(std::forward<Args>(args)...))) { return boost::join(boost::join(boost::make_iterator_range(std::forward<C>(c)), boost::make_iterator_range(std::forward<D>(d))), join(std::forward<Args>(args)...)); } A variadic zip is more complicated. If we want write access we cannot use boost zip_iterator. Still one can use Anthony Williams' TupleIterator: template <class... T> auto zip(T&&... c) -> boost::iterator_range< decltype(iterators::makeTupleIterator(std::begin(std::forward<T>(c))...))> { return boost::make_iterator_range (iterators::makeTupleIterator(std::begin(std::forward<T>(c))...), iterators::makeTupleIterator(std::end(std::forward<T>(c))...)); } For read-only access one could use boost::zip_iterator, but I think write-access is _really_ important (e.g. sort wouldn't work). Would it be possible to add similar functionality to boost range? This code wouldn't work without the help of everyone who participated in the following SO discussions: - http://stackoverflow.com/questions/14366576/boostrangejoin-for-multiple-ran… - http://stackoverflow.com/questions/13840998/sorting-zipped-locked-container… and without Anthony Williams's tupleIterator. See also http://www.justsoftwaresolutions.co.uk/articles/pair_iterators.pdf Bests, Gonzalo BG

5 9

[chrono/date] conversion between concrete dates
by Vicente J. Botet Escriba 12 May '13

12 May '13

Hi, as the conversion between concrete dates could be expensive I guess that these conversion must be explicit. But this has some consequences when used the implicit conversion was hidden a not efficient implementation, e.g. date ISO_week_start = mon <= jan/day(4)/y; jan/day(4)/y should be ymd_date as is the efficient representation. The date generator was declared as date operator<=(weekday wd, date x); but it works efficiently only for days_date. If we provide only the functions that are efficient we should declare it as days_date operator<=(weekday wd, days_date x); So the preceding expression would need an explicit conversion days_date ISO_week_start = mon <= days_date(jan/day(4)/y); Do we want to go on this direction? A radical alternative to the explicit construction, if we want to make evident that the conversion operation could be expensive, is to use a compute_ factory days_date ISO_week_start = mon <= compute_days_date(jan/day(4)/y); Best, Vicente P.S. the generator function is just an example needing explicit conversion.

4 18