|
Ublas :
|
- Next message: sguazt: "Re: [ublas] patches for #7297, #7296, #6514, #6511 on trunk - please verify"
- Previous message: Gunter Winkler: "Re: [ublas] patches for #7297, #7296, #6514, #6511 on trunk - please verify"
- In reply to: Gunter Winkler: "Re: [ublas] broken coordinate_matrix::sort with gcc 4.7 (was: patches for #7297, #7296, #6514, #6511 on trunk - please verify)"
- Next in thread: sguazt: "Re: [ublas] broken coordinate_matrix::sort with gcc 4.7 (was: patches for #7297, #7296, #6514, #6511 on trunk - please verify)"
- Reply: sguazt: "Re: [ublas] broken coordinate_matrix::sort with gcc 4.7 (was: patches for #7297, #7296, #6514, #6511 on trunk - please verify)"
Gunter Winkler wrote:
> Looks like this hack does not work with gcc 4.7 any more. Maybe we can
> improve coordinate_matrix::sort() somehow to use the zip_iterator. (see
> storage_sparse.hpp:4396)
My conclusion in <http://lists.boost.org/MailArchives/ublas/2011/12/5123.php> was that we need an implementation of "std::inplace_merge" guaranteed to accept our iterators. Basically any existing implementation could be used, as long as the licensing conditions allow this.
As a side note, inplace_merge is cheating anyway, allocates temporary memory, and will only fall back to a true inplace_merge if this fails.
Regards,
Thomas
- Next message: sguazt: "Re: [ublas] patches for #7297, #7296, #6514, #6511 on trunk - please verify"
- Previous message: Gunter Winkler: "Re: [ublas] patches for #7297, #7296, #6514, #6511 on trunk - please verify"
- In reply to: Gunter Winkler: "Re: [ublas] broken coordinate_matrix::sort with gcc 4.7 (was: patches for #7297, #7296, #6514, #6511 on trunk - please verify)"
- Next in thread: sguazt: "Re: [ublas] broken coordinate_matrix::sort with gcc 4.7 (was: patches for #7297, #7296, #6514, #6511 on trunk - please verify)"
- Reply: sguazt: "Re: [ublas] broken coordinate_matrix::sort with gcc 4.7 (was: patches for #7297, #7296, #6514, #6511 on trunk - please verify)"