- Boost - lists.preview.boost.org

[date_time] Merge to release?
by Daniel James 01 Mar '15

01 Mar '15

There are some outstanding changes on date_time's develop branch which seem safe to me. If there are no objections I'll merge them soon. Daniel

1 0

Re: [boost] [Boost-interest] Biicode dependendy manager with Boost support
by Vicente J. Botet Escriba 27 Feb '15

27 Feb '15

Le 20/02/15 20:54, JOAQUIN M. LOPEZ MUÑOZ a écrit : > Hi, > > The folks at biicode (biicode.com) a C/C++ dependency manager, have just > announced support for Boost: > > http://blog.biicode.com/dependency-management-boost-libraries/#more-2086 > > Biicode allows for easy multiplatform component tracking and builiding > thanks to their file-based dependency detection and CMake autogeneration > magic. Now, these capabilities can be used to make it easier to work with > Boost libraries. > Thanks Joaquin for the announce. I was wondering if we couldn't use it as a starting point of our modularization activity. Some questions: * Is the file-based dependency manager what Boost is looking for its own module dependencies detection? * Could an author state explicitly its dependencies on other libraries (versions)? * It Biicode open source? * How its CMake autogeneration and bjam interact? Best, Vicente

4 4

VMD library accepted
by Steven Watanabe 27 Feb '15

27 Feb '15

AMDG The VMD library submitted by Edward Diener is ACCEPTED into Boost. I apologize for the long delay for this announcement. Thanks to everyone who participated in the formal review * Nial Douglass * Bjorn Reese * Rodrigo Madera * Zhou Zhenghui * Matt Calabrese * Paul Mensonides Reviews for the library were generally positive. The library was considered to be a useful set of tools for macro programmers. Paul expressed concern about the way the the library handles v-sequences and v-identifiers. After some discussion, Edward has agreed that the interface could be significantly improved. Work Items: * Add examples and improved motivation in the documentation * Update the v-identifier/v-sequence interface based on Paul's comments * Fix inaccurate statements about Boost.Preprocessor per Paul In Christ, Steven Watanabe

1 0

[1.58] Any plans to merge the super-project to master?
by John Maddock 26 Feb '15

26 Feb '15

Is the Boost super-project going to be merged to master, Jamroot in particular has several important unmerged changed. Thanks, John.

1 0

Re: [boost] [mpl] multiset
by Ganesh Prasad 25 Feb '15

25 Feb '15

> Aside from that, I?ve been also in contact with Louis discussing the > idea of porting metalog to Hana as a use case. Perhaps logic > predicates could prove a useful add on to Hana as well. Porting metalog to hana as an add on might be a good idea, but I quite disagree from the user's point of view. Hana is a beautifully designed library and it does precisely what it's designed for. In short it has good modularity. And , indeed, libraries are supposed to be highly modular. So, it might be better to keep metalog as a separate entity and provide good interoperability between Hana and metalog. Best wishes Ganesh Prasad

1 0

Cannot add any file to GIT "libgit2 returned: Invalid data in index - invalid entry"
by Paul A. Bristow 25 Feb '15

25 Feb '15

Cannot add any new file to GIT repo :-( "libgit2 returned: Invalid data in index - invalid entry" Have recently locally committed changes to an existing Boost.Math sub-module (commit OK). (But realized that I had forgotten to add a few new files, so tried to add and recommit, but failed at the add stage). git status shows expected untracked files and ends: nothing added to commit but untracked files present (use "git add" to track) I:\modular-boost\libs\math> .gitignore is the standard modular-boost issue and looks OK. I:\modular-boost\libs\math>git version git version 1.9.5.msysgit.0 Suggestions? Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

2 3

[date_time] Re: [Boost-docs] Pull request #22 on boostorg/date_time
by Rene Rivera 25 Feb '15

25 Feb '15

You emailed the wrong list. On Tue, Feb 24, 2015 at 9:41 PM, Aaron Brooks <brooksaar(a)gmail.com> wrote: > Hi, > > Could I get someone to pull in my changes to date_time? > https://github.com/boostorg/date_time/pull/22 > > Just a small fix - fixes references to date_from_tm in the ptime doc, but > the bug has been open for 10 months and it tripped me up. > > Thanks, > Aaron > > _______________________________________________ > Boost-docs mailing list > Boost-docs(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-docs > > -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

Re: [boost] [mpl] multiset
by Ganesh Prasad 25 Feb '15

25 Feb '15

> It is not my intention to deprecate MPL. I'm just looking for some > meta-programming utilities that can be proposed to the C++ standard. > > Vicente MPL and 'something else which does exactly the same thing' can co-exist (?), though users are familiar with MPL. Metaprogramming can be made easier with an alternative syntax, like Hana does. But functional is not the only solution. We can try with a Logic oriented syntax. C++ supports almost every major paradigm out there, except for logic (like prolog). And wrapping a logic oriented syntax over metaprograms would actually help programmers to handle complex inheritance patterns conveniently. Well, it's just an idea. I had tried with functional syntax (from scratch) about one year ago. And I have been thinking about a logic oriented syntax (I had even considered something like JQuery, though I rejected that idea eventually). It would be great if the logic programming idea could be acceptable for GSoC, I would be more than happy to work on it. Here is the link to my attempt at functional syntax over metaprogramming. https://github.com/GnsP/GNS--META_LISCPP Also, Bruno C. O. Dutra has worked in a very similar field, in fact he has already implemented a compile time logic library. Best Wishes Ganesh Prasad

2 1

[Context] RFR: Add support for ARM aarch64 architecture
by Edward Nevill 25 Feb '15

25 Feb '15

Hi, I hope this is the right place to post this. The following patch adds support for ARMs aarch64 architecture on Linux (there is existing iOS support for aarch64). I have run the context regression test on this on an aarch64 board running Ubuntu 14.04 with gcc 4.9.1 and it passes all OK. Could someone please review this patch and if OK push it? Many thanks, Ed. --- CUT HERE --- commit bd34672217ff3bcee185f9c7383179342ec2fe9b Author: Edward Nevill <edward.nevill(a)linaro.org> Date: Mon Feb 23 14:37:45 2015 +0000 Add support for ARM aarch64 architecture diff --git a/build/Jamfile.v2 b/build/Jamfile.v2 index 80d1c46..edd4400 100644 --- a/build/Jamfile.v2 +++ b/build/Jamfile.v2 @@ -253,6 +253,14 @@ alias asm_context_sources <toolset>darwin ; +alias asm_context_sources + : [ make asm/make_arm64_elf_gas.o : asm/make_arm64_elf_gas.S : @gas ] + [ make asm/jump_arm64_elf_gas.o : asm/jump_arm64_elf_gas.S : @gas ] + : <address-model>64 + <architecture>arm + <binary-format>elf + ; + # MIPS # MIPS/O32/ELF alias asm_context_sources diff --git a/config/arm.cpp b/config/arm.cpp index 6a83737..6eece0b 100644 --- a/config/arm.cpp +++ b/config/arm.cpp @@ -6,7 +6,7 @@ // accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) -#if !defined(__arm__) && !defined(__thumb__) && \ +#if !defined(__aarch64__) && !defined(__arm__) && !defined(__thumb__) && \ !defined(__TARGET_ARCH_ARM) && !defined(__TARGET_ARCH_THUMB) && \ !defined(_ARM) && !defined(_M_ARM) #error "Not ARM" diff --git a/src/asm/jump_arm64_elf_gas.S b/src/asm/jump_arm64_elf_gas.S new file mode 100644 index 0000000..3e0e2c2 --- /dev/null +++ b/src/asm/jump_arm64_elf_gas.S @@ -0,0 +1,128 @@ +/******************************************************* + * * + * ------------------------------------------------- * + * | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | * + * ------------------------------------------------- * + * | 0x0 | 0x4 | 0x8 | 0xc | 0x10| 0x14| 0x18| 0x1c| * + * ------------------------------------------------- * + * | d8 | d9 | d10 | d11 | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | * + * ------------------------------------------------- * + * | 0x20| 0x24| 0x28| 0x2c| 0x30| 0x34| 0x38| 0x3c| * + * ------------------------------------------------- * + * | d12 | d13 | d14 | d15 | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | * + * ------------------------------------------------- * + * | 0x40| 0x44| 0x48| 0x4c| 0x50| 0x54| 0x58| 0x5c| * + * ------------------------------------------------- * + * | x19 | x20 | x21 | x22 | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | * + * ------------------------------------------------- * + * | 0x60| 0x64| 0x68| 0x6c| 0x70| 0x74| 0x78| 0x7c| * + * ------------------------------------------------- * + * | x23 | x24 | x25 | x26 | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | * + * ------------------------------------------------- * + * | 0x80| 0x84| 0x88| 0x8c| 0x90| 0x94| 0x98| 0x9c| * + * ------------------------------------------------- * + * | x27 | x28 | FP | LR | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 40 | 41 | 42 | 43 | | | * + * ------------------------------------------------- * + * | 0xa0| 0xa4| 0xa8| 0xac| | | * + * ------------------------------------------------- * + * | PC | align | | | * + * ------------------------------------------------- * + * * + *******************************************************/ + + .cpu generic+fp+simd + .text + .align 2 + .global jump_fcontext + .type jump_fcontext, %function +jump_fcontext: + # prepare stack for GP + FPU + sub sp, sp, #0xb0 + +# Because gcc may save integer registers in fp registers across a +# function call we cannot skip saving the fp registers. +# +# Do not reinstate this test unless you fully understand what you +# are doing. +# +# # test if fpu env should be preserved +# cmp w3, #0 +# b.eq 1f + + # save d8 - d15 + stp d8, d9, [sp, #0x00] + stp d10, d11, [sp, #0x10] + stp d12, d13, [sp, #0x20] + stp d14, d15, [sp, #0x30] + +1: + + # save x19-x30 + stp x19, x20, [sp, #0x40] + stp x21, x22, [sp, #0x50] + stp x23, x24, [sp, #0x60] + stp x25, x26, [sp, #0x70] + stp x27, x28, [sp, #0x80] + stp x29, x30, [sp, #0x90] + + # save LR as PC + str x30, [sp, #0xa0] + + # store RSP (pointing to context-data) in first argument (x0). + # STR cannot have sp as a target register + mov x4, sp + str x4, [x0] + + # restore RSP (pointing to context-data) from A2 (x1) + mov sp, x1 + +# # test if fpu env should be preserved +# cmp w3, #0 +# b.eq 2f + + # load d8 - d15 + ldp d8, d9, [x0, #0x00] + ldp d10, d11, [x0, #0x10] + ldp d12, d13, [x0, #0x20] + ldp d14, d15, [x0, #0x30] + +2: + + # load x19-x30 + ldp x19, x20, [sp, #0x40] + ldp x21, x22, [sp, #0x50] + ldp x23, x24, [sp, #0x60] + ldp x25, x26, [sp, #0x70] + ldp x27, x28, [sp, #0x80] + ldp x29, x30, [sp, #0x90] + + # use third arg as return value after jump + # and as first arg in context function + mov x0, x2 + + # load pc + ldr x4, [sp, #0xa0] + + # restore stack from GP + FPU + add sp, sp, #0xb0 + + ret x4 + .size jump_fcontext,.-jump_fcontext + +# Mark that we don't need executable stack. +.section .note.GNU-stack,"",%progbits diff --git a/src/asm/make_arm64_elf_gas.S b/src/asm/make_arm64_elf_gas.S new file mode 100644 index 0000000..5a6914f --- /dev/null +++ b/src/asm/make_arm64_elf_gas.S @@ -0,0 +1,80 @@ +/******************************************************* + * * + * ------------------------------------------------- * + * | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | * + * ------------------------------------------------- * + * | 0x0 | 0x4 | 0x8 | 0xc | 0x10| 0x14| 0x18| 0x1c| * + * ------------------------------------------------- * + * | d8 | d9 | d10 | d11 | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | * + * ------------------------------------------------- * + * | 0x20| 0x24| 0x28| 0x2c| 0x30| 0x34| 0x38| 0x3c| * + * ------------------------------------------------- * + * | d12 | d13 | d14 | d15 | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | * + * ------------------------------------------------- * + * | 0x40| 0x44| 0x48| 0x4c| 0x50| 0x54| 0x58| 0x5c| * + * ------------------------------------------------- * + * | x19 | x20 | x21 | x22 | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | * + * ------------------------------------------------- * + * | 0x60| 0x64| 0x68| 0x6c| 0x70| 0x74| 0x78| 0x7c| * + * ------------------------------------------------- * + * | x23 | x24 | x25 | x26 | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | * + * ------------------------------------------------- * + * | 0x80| 0x84| 0x88| 0x8c| 0x90| 0x94| 0x98| 0x9c| * + * ------------------------------------------------- * + * | x27 | x28 | FP | LR | * + * ------------------------------------------------- * + * ------------------------------------------------- * + * | 40 | 41 | 42 | 43 | | | * + * ------------------------------------------------- * + * | 0xa0| 0xa4| 0xa8| 0xac| | | * + * ------------------------------------------------- * + * | PC | align | | | * + * ------------------------------------------------- * + * * + *******************************************************/ + + .cpu generic+fp+simd + .text + .align 2 + .global make_fcontext + .type make_fcontext, %function +make_fcontext: + # shift address in x0 (allocated stack) to lower 16 byte boundary + and x0, x0, ~0xF + + # reserve space for context-data on context-stack + sub x0, x0, #0xb0 + + # third arg of make_fcontext() == address of context-function + # store address as a PC to jump in + str x2, [x0, #0xa0] + + # save address of finish as return-address for context-function + # will be entered after context-function returns (LR register) + adr x1, finish + str x1, [x0, #0x98] + + ret x30 // return pointer to context-data (x0) + +finish: + # exit code is zero + mov x0, #0 + # exit application + bl _exit + + .size make_fcontext,.-make_fcontext + +# Mark that we don't need executable stack. +.section .note.GNU-stack,"",%progbits

2 7

Friend class with namespace gives compiler error for C6000 TI
by Alin Popa 25 Feb '15

25 Feb '15

Hi, I compile my project with boost header only files, the compiler is C6000 Texas Instruments. The compile errors occurs for example in "boost/algorithm/string/find_iterator.hpp" I have extracted the cause of the problem in the next example code: namespace boost { namespace iterators { class iterator_core_access { public: iterator_core_access(){} ~iterator_core_access(){} }; } using iterators::iterator_core_access; } class testFriend { private: // don't work, compiler error: error: namespace "boost" has no actual member "iterator_core_access" friend class ::boost::iterator_core_access; // here is the problem // it works, compiles ok, this was my cure //friend class ::boost::iterators::iterator_core_access; }; int main () { // it works ::boost::iterator_core_access a; return 0; } Do you guys know what is the reason of this ? With msvc and g++ works fine. Thanks and best regards, Alin

2 1