El 09/06/2014 10:11, Vicente J. Botet Escriba escribió:

Le 04/06/14 13:27, Vicente J. Botet Escriba a écrit :

...

|What about creating a Memory module containing| most of the things the standard defines in <memory> except maybe what is already in SmartPptr, e.g.

||* boost/interprocess/allocators/*|| |* boost/intrusive/pointer_traits.hpp | Any comments on this new module? Ion?

Thanks for the ping, I'm not closely following modularization threads. Interprocess allocators are only usable by Interprocess users, I don't think they should be outside. intrusive::pointer_traits is usable from other libraries. Container uses it extensively, but Container heavily depends on Intrusive. I don't know if other libraries use it. We also have a portable allocator_traits implementation in Boost.Container that might be reusable by other boost containers. We need to see real use cases to see if this class makes sense in Boost.Memory or its place should be Container. For Boost 1.56 we'll have new allocators in Boost.Container, and those take advantage of Boost.Container internals to offer reallocation, burst allocation, etc. They could be usable by other Boost containers, but they are still experimental and unless there is a strong need for that, I would not move them to a new module now. pointer_traits offers extensions not found in std::pointer_traits (like pointer casting). We need to to carefully think about this (Boost.Intrusive needs to make some conversions not covered by std::pointer_traits). In any case, if reusable, I would make a new library (with documentation and test cases), not only a new git module. So my opinion is: Don't move interprocess allocators, let's see if a strong need arises for a common pointer_traits/allocator_traits and we'll think about solutions. Best, Ion

Le 09/06/14 17:21, Glen Fernandes a écrit :

Vicente J. Botet Escriba wrote:

...

What about creating a Memory module containing most of the things the standard defines in <memory> except maybe what is already in SmartPptr, e.g. I'd prefer keeping align() and aligned_alloc() in Boost.Align.

It is up to you, you are the owner. I'm most for small modules that big ones. I want the intrusive and container memory related in a separated library to minimize the dependencies. Best, Vicente

Peter Dimov wrote:

Hypothetically speaking, it would've been nice if everything related to alignment, such as boost::alignment_of, boost::type_with_alignment, boost::aligned_storage, were part of Boost.Align. This makes sense from both classification/user perspective and from dependency perspective.

I certainly wouldn't object to an (or the current) alignment_of being part of Boost.Align. It could look something like: http://github.com/glenfe/align/tree/alignment_of (throwaway "alignment_of" branch). ( http://github.com/glenfe/align/commit/c0b119a6fe ). I've been distracted a little from the modularization effort by a newborn and paternity leave; I'll get more involved after the release and lockdown is lifted. Glen

Peter Dimov wrote:

I suspect that the macro doesn't have one leading underscore

Good catch, it needed to be __CODEGEARC__

Well congratulations then. :-)

Thanks! :-)

I suggest we just prohibit references. We'll probably have to prohibit abstract types, too.

In that case should I keep it within boost::alignment::detail:: ? -- If it was effectively an alignment_of-equivalent, it could live within boost::alignment:: -- Glen

Glen Fernandes wrote:

In that case should I keep it within boost::alignment::detail:: ? -- If it was effectively an alignment_of-equivalent, it could live within boost::alignment:: --

No, I would like it to not be an implementation detail. We want to use it in smart_ptr. Let's follow the standard on references, then. It's not possible to place a reference in aligned_storage, so there's no alternative use case. Also, to be standard conforming, template<class T> struct alignment_of<T[]>: alignment_of<T> {};

Peter Dimov wrote:

Also, to be standard conforming,

template<class T> struct alignment_of<T[]>: alignment_of<T> {};

I was under the impression that only complete types were required (i.e. only what you can use with alignof). Glen

Peter Dimov wrote:

Yes, but T[] is an exception.

5.3.6 Alignof [expr.alignof] 1 An alignof expression yields the alignment requirement of its operand type. The operand shall be a type-id representing a complete object type or an array thereof or a reference to a complete object type. 2 The result is an integral constant of type std::size_t. 3 When alignof is applied to a reference type, the result shall be the alignment of the referenced type. When alignof is applied to an array type, the result shall be the alignment of the element type.

When T is a complete object type, T[] is an array thereof, so it's allowed. I think.

Ah, I see. g++ appears to agree with the above (though, clang does not). Glen

On Tue, Jun 10, 2014 at 4:48 AM, Peter Dimov wrote:

Clang has this to say:

Fixed. All your new tests now also pass with g++ and clang with c++03 and c++11. I've also filed a clang bug for alignof( T[] ). There are some warnings in the test with clang in c++03 mode, but they are only because the test uses offsetof() which I will change shortly. Glen

Glen Fernandes wrote:

Fixed. All your new tests now also pass with g++ and clang with c++03 and c++11.

Why have you removed the use of BOOST_TEST_EQ, by the way? Now we can't see what the differing values are when a test fails.

Peter Dimov wrote:

I thought that the use of offsetof as a test was pretty clever, actually. Not sure what you're going to replace it with.

Was going to replace it with a handwritten offsetof macro that would never be a built-in.

we just made that public on Clang in C++03 mode to make it happy.

Done.

Why have you removed the use of BOOST_TEST_EQ, by the way? Now we can't see what the differing values are when a test fails.

No good reason; it's back.

The good news is that msvc-12.0 passes everything. The not so good news is that msvc-8.0 fails ~1600 tests and msvc-10.0 fails ~2400. :-)

Taking a look now; I suspect it's because it is using std::alignment_of in the cxx11-version on VC12, and __alignof is yielding values of 1 for things in the msvc-version on VC10 and lower. Glen

Glen Fernandes wrote:

I certainly wouldn't object to an (or the current) alignment_of being part of Boost.Align.

The standard says that alignof(T&) == alignof(T), but - unless we can think of examples in which we (1) genuinely need to use alignment_of on a reference type and (2) have it return the alignment of the referent and not the one of the reference itself - I suggest we just prohibit references. We'll probably have to prohibit abstract types, too. The standard says that they are allowed as well. So we have to tighten our requirements either way, and I think it makes sense to constrain ourselves to what we actually use.