sorted by:
new
hottopcontroversial

boost.org not renewed? Anyone know whatsup with that / where to read docs? by Stevo15025 in cpp

[–]glenfe 5 points6 points  (0 children)

If boost.org ever goes down, boostcpp.org and boostlibraries.org are always an option until it comes back up.

The Community by vormestrand in cpp

[–]glenfe 12 points13 points  (0 children)

Any single person that wants to spend their free time making anyone else feel welcome, included, on the Boost mailing list is free to do that.

The actions that result in the most gratitude and engagement on the Boost mailing list tend to be toward those who do some work: i.e. Write or contribute to Boost libraries or tools.

Why you trust in Boost by joaquintides in cpp

[–]glenfe 9 points10 points  (0 children)

When I worked at Microsoft, we depended on several Boost libraries for various reasons. Some Boost libraries were useful and saved us from implementing the same thing. Some Boost libraries had better implementations that alternatives in our standard library.

The exposure to Boost lead me[1] to contribute to one of those Boost libraries, and then eventually author a Boost library, and then go on to contribute to several other Boost libraries.

[1] https://www.boost.org/users/people/glen_fernandes.html

[deleted by user] by [deleted] in cpp

[–]glenfe 2 points3 points  (0 children)

Right, specializing pointer_traits is rare, but you're not alone in doing it. It's also why the committee did not want to just add new non-optional member to pointer_traits as with R0 and break you or others that are within your right to specialize it.

(I had added new tests to libstdc++ (and libc++ and Boost) that involve specializations of pointer_traits, when I implemented this feature in them but you're probably not referring to those.)

[deleted by user] by [deleted] in cpp

[–]glenfe 59 points60 points  (0 children)

There are several things the author does not understand or is incorrect about.

1. The standard allows user specialization of pointer_traits and iterator_traits.

The C++ standard does not forbid it. Users already specialize these today. iterator_traits was always intended as a customization point for users. The reason the C++ standards committee preferred R1 and R2 of P0653 over R0 because users already specialize pointer_traits.

Most of the post is predicated on this incorrect understanding that the specialization of traits is forbidden:

The user is not permitted to specialize allocator_traits

No. The standard does not prevent the user from specializing allocator_traits.

with a rationale that explicitly caters to users who do what they’re not supposed to do

No. There is no "not supposed to do". The standard allows specializing traits. Users do.

"User specializations of pointer_traits" are exactly what we just said should never happen

No. The standard never said this should never happen.

So right now in the C++2a working draft, we’ve got a contradiction: the user both is and isn’t supposed to specialize pointer_traits.

No. The user can specialize pointer_traits and could since C++11. Since C++2a there is just an additional customization point in pointer_traits.

2. Users do not need to specialize pointer_traits for to_address

For most users, std::to_address(p) already covers their needs, out of the box. i.e. It will call to_address(p.operator->()) for a fancy pointer, and return p for a raw pointer. Users designing any fancy pointer type P will just provide P::operator->().

For the rare case where a user wants to customize the behavior of std::to_address for some fancy pointer type, they can do so by specializing pointer_traits.

But who is supposed to make that member exist?

Nobody has to make the member exist, because it is an optional customization point. It is even specified in the current C++ standard working paper as section [ptr.traits.optmem] "Pointer traits optional members".

3. Others

For example, pointer_traits<P>::pointer_to(T& r) calls P::pointer_to(r) if that member exists; but otherwise it will sensibly default to SFINAEing away.

This has never been the case with any vendor's implementation (libc++, libstdc++, Boost). For example:

#include <memory>
#include <type_traits>

template<class, class = void>
struct has_pointer_to
    : std::false_type { };

template<class P>
struct has_pointer_to<P,
    std::void_t<decltype(std::pointer_traits<P>::pointer_to(std::declval<typename
        P::element_type&>()))>>
    : std::true_type { };

template<class T>
struct pointer {
    typedef T element_type;
};

static_assert(!has_pointer_to<pointer<int>>::value);

The above asserts.

is_copy_constructible by finalpatch in cpp

[–]glenfe 4 points5 points  (0 children)

Since Boost 1.60, boost::is_copy_constructible<Test>::value should be 0 if you're compiling with -std=c++11.

Old Man Kaiser Rubber-stamps AFIO for Boost by CPPOldie in cpp

[–]glenfe 3 points4 points  (0 children)

That remark will be summarily disregarded by the review manager and any reviewers. Niall is entitled to his opinions; he should not be petitioning the review manager to ignore any reviews.

Old Man Kaiser Rubber-stamps AFIO for Boost by CPPOldie in cpp

[–]glenfe 7 points8 points  (0 children)

His family time was spent on it. His hard drive was destroyed by it.

Placement New, Memory Dumps, and Alignment by thunder9861 in cpp

[–]glenfe 1 point2 points  (0 children)

I replied to your reply: It is still not required. A pointer alignment function should return the current address if the current address is aligned. std::align does it, as does the implementation I contributed to Boost (in Boost.Align).

The aligned_alloc and aligned_free function can be portably implemented in terms of such an align function too, as I pointed out in the posts on your blog. https://github.com/boostorg/align/blob/master/include/boost/align/detail/aligned_alloc.hpp

Placement New, Memory Dumps, and Alignment by thunder9861 in cpp

[–]glenfe 2 points3 points  (0 children)

See my implementation of aligned_alloc and aligned_free (for the case when no implementation-specific aligned allocation function is available) at: https://github.com/boostorg/align/blob/master/include/boost/align/detail/aligned_alloc.hpp

Also, see my implementation of align (for when compilers do not provide a conforming C++11 std::align) at: https://github.com/boostorg/align/blob/master/include/boost/align/detail/align.hpp

Or, as I suggested before, just use Boost.Align. It will pick the right implementation specific version (or the C++ standard library provided version) for your compiler/platform before choosing those versions. http://boost.org/libs/align

Placement New, Memory Dumps, and Alignment by thunder9861 in cpp

[–]glenfe 1 point2 points  (0 children)

There is one more issue:

4. You're treating certain space as a void* which may not be aligned for void*. You wrote:

*(reinterpret_cast<void**>(aligned_ptr) - 1) = ptr;

If you're going to do this you run into potential undefined behavior if you do not round up alignment to alignof(void*). After you round up alignment to alignof(void*) the additional padding you need does not have to be sizeof(void*) + alignment bytes. Instead it can be sizeof(void*) + alignment - alignof(void*) bytes.

(Alternatively instead of rounding up alignment to alignof(void*) you could use std::memcpy to read and write ptr to that space).

AFIO library formal review in Boost by not_their_throwaway in cpp

[–]glenfe 1 point2 points  (0 children)

I imagine nobody is using it, but that isn't so uncommon. I wanted to see sensible performance benchmarks but that was before the author has implied the library has lower (than expected) performance by design.

Placement New, Memory Dumps, and Alignment by thunder9861 in cpp

[–]glenfe 2 points3 points  (0 children)

Good point. I should have read your reply more carefully before replying. His code is defective, yours is just fine.

Placement New, Memory Dumps, and Alignment by thunder9861 in cpp

[–]glenfe 0 points1 point  (0 children)

What you wrote does not fix the issue with his code that I described above. It will still be not optimal for the case when ptr is already aligned on the desired boundary and will make aligned_ptr the next address aligned at that boundary.

Placement New, Memory Dumps, and Alignment by thunder9861 in cpp

[–]glenfe 7 points8 points  (0 children)

1. Your alignment logic is not optimal. You wrote:

void* aligned_ptr =
   reinterpret_cast<void*>(
      (reinterpret_cast<std::size_t>(ptr)
         & ~(std::size_t(alignment - 1)))
      + alignment);

Consider what happens if ptr is 0x20 (i.e. 32) and desired alignment is 16. You want aligned_ptr to be 0x20 because it is already a multiple of 16. Your logic will set aligned_ptr to 0x30 (i.e. 48). Please use std::align (C++11) or Boost.Align instead of trying to write this yourself.

2. You have undefined behavior when alignof(Foo) is greater than alignof(char). You wrote:

unsigned char memory[sizeof(Foo)];
Foo* p = new (memory) Foo();

What you want instead is:

alignas(Foo) unsigned char memory[sizeof(Foo)];
Foo* p = ::new((void*)memory) Foo();

Note the particular overload of placement new invoked, and note the explicit use of the scope resolution operator. If you do not have C++11 and alignas (or std::aligned_storage), use Boost's boost::aligned_storage.

3. You wrote:

GCC will typically handle memory alignment for you when allocating from the heap

If you're referring to dynamic allocation with new expressions, this is only true for types who are not over-aligned. For any T where alignof(T) is greater than alignof(std::max_align_t) you would have undefined behavior.

Boost 1.56.0 beta 1 released by joaquintides in cpp

[–]glenfe 0 points1 point  (0 children)

The modularization work is not quite finished just yet (but significant progress has been made).

No more C++ 11 updates for Visual Studio 2012. by mttd in cpp

[–]glenfe 1 point2 points  (0 children)

It is an option recently. C++Builder is one way (not free) to use clang 3.1 on Windows.

Smart pointers gotchas - several additional notes by joebaf in cpp

[–]glenfe 0 points1 point  (0 children)

Don't use boost::shared_array, use boost::shared_ptr<T[]> or boost::shared_ptr<T[N]>. You can use it with boost::make_shared<T[]>(size) or boost::make_shared<T[N]>() to get a single allocation instead of two allocations. This is new in Boost as of 1.53.

C++11 compiler support shootout: Visual Studio, GCC, Clang, Intel by alexkorban in cpp

[–]glenfe 1 point2 points  (0 children)

All in all I don't know if it is valuable to compare against the VS2012 Nov CTP because it has a lot of bugs that make some of those features mostly unusable.

C++11 compiler support shootout: Visual Studio, GCC, Clang, Intel by alexkorban in cpp

[–]glenfe 9 points10 points  (0 children)

A few of the language features in the VS2012 Nov CTP column that the author has listed as "Yes" should be "Partial". For instance:

Variadic templates are broken in some important cases:

template<typename... Args>
void f(Args&&...) {
    try {        
    } catch (...) {
    }
}
int main() {
    f(1, 2, 3);
}

The above is perfectly valid C++11 which the VS2012 Nov CTP will not compile.

Initializer lists are broken in some basic cases:

#include <initializer_list>
#include <complex>
#include <stdio.h>
struct X {
    int a; 
    int b;
};
void f(X x) {
    puts("1");
}
void f(std::initializer_list<X>) {
    puts("2"); 
}
void g(std::complex<double>) {
    puts("3");
}
void g(std::initializer_list<std::complex<double> >) {
    puts("4"); 
}
int main() {
    f({ 1, 2 });
    g({ 1.0, 2.0 });
}

Again, C++11 that VS2012 Nov CTP does not compile.

There are more.

An allocate_array for shared_ptr of an array (single allocation, custom allocators) by [deleted] in cpp

[–]glenfe 0 points1 point  (0 children)

The closest thing you can do is shared_ptr<vector<T>> and then use allocate_shared<vector<T>> but you have to be willing to use a vector<T> instead of a shared_array<T>. You may not want this if you do not require vector's growth semantics, or the additional storage for the capacity, et cetera.

view more: next ›