Talk:cpp/types/aligned storage

In the destructor of the example class static_vector, wouldn't it be better to destruct the objects in the inverse order of their construction? 81.174.151.117 01:25, 5 June 2012 (PDT)
 * It would make it match the behavior of arrays, but not necessarily other containers. It's a wiki, you can make that edit yourself if you think it's warranted. --Cubbi 05:27, 5 June 2012 (PDT)

Is "typedef" really required in possible implementation?
 * No, I suppose it could define the member type in any other way (edited to drop typedef). Note that this is not a complete implementation: it doesn't satisfy the default Align requirements (see real implementations in LLVM libc++ and GNU libstdc++ to see how it's done. --Cubbi (talk) 13:07, 29 December 2013 (PST)

Example program does not work with Clang 3.4/GCC 4.8.3 or VC++2015 Preview
$ clang++ -v clang version 3.4.2 (tags/RELEASE_34/dot2-final) Target: x86_64-pc-linux-gnu Thread model: posix Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3

$ clang++ -std=c++11 algned_storage.cpp algned_storage.cpp:9:10: error: no template named 'aligned_storage_t' in     namespace 'std'; did you mean 'aligned_storage'? std::aligned_storage_t data[N]; ^~        aligned_storage /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/include/g++-v4/type_traits:1693:12: note: 'aligned_storage' declared here struct aligned_storage ^ 1 error generated.

$ g++ --version g++ (Gentoo 4.8.3 p1.1, pie-0.5.9) 4.8.3 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

g++ -std=c++11 algned_storage.cpp algned_storage.cpp:9:5: error: ‘aligned_storage_t’ in namespace ‘std’ does not name a type std::aligned_storage_t data[N]; ^ algned_storage.cpp: In member function ‘void static_vector::emplace_back(Args&& ...)’: algned_storage.cpp:18:13: error: ‘data’ was not declared in this scope new(data+m_size) T(std::forward(args)...); ^ algned_storage.cpp: In member function ‘const T& static_vector::operator[](std::size_t) const’: algned_storage.cpp:25:64: error: ‘data’ was not declared in this scope return *static_cast(static_cast(data+pos)); ^ algned_storage.cpp: In destructor ‘static_vector::~static_vector’: algned_storage.cpp:32:60: error: ‘data’ was not declared in this scope static_cast(static_cast(data+pos))->~T;

The following correction sare needed to make this program work. The following line:

std::aligned_storage_t data[N];

Need to be changed to:

std::aligned_storage::type data[N];

I am happy to make the change, but my last attempt was reverted. Could the person who reverted that change (Cubbi) please double check that the example program works and does actually not produce stack corruption. 24.19.132.10 23:55, 30 November 2014 (PST)


 * As this page mentions, std is a C++14 type alias. I don't see a reason to turn this example into a C++11 example, especially given that the "Run this code" button executes it. It works as written with both GCC/libstdc++ and Clang/libc++ today. (also, the edit I revered made the program ill-formed in every standard)--Cubbi (talk) 03:31, 1 December 2014 (PST)


 * You're right, the edit I made was wrong I didn't notice the _t at the end. While I agree that the example that you have works with C++14, using aligned_storage and the nested type works with both C++11 and C++14. I'm sure there are many users who don't yet have access to C++14 at their workplaces and having an example for C++11 users seems like it might be useful to them. FWIW, GCC 4.8.3 breaks even with -std=c++1y. Amongst code I've reviewed I've seen two failure modes: 1. Drop the _t (as a result of a suggestion from the IDE/Clang) and end up corrupting the stack; 2. Use Boost. I see both of them as worse outcomes, than having an extra documented example for C++11. Thoughts? Also, I think this page should go under aligned_storage_t, since that is the typedef that it's describing.

$ g++ -std=c++1y algned_storage.cpp algned_storage.cpp:9:5: error: ‘aligned_storage_t’ in namespace ‘std’ does not name a type std::aligned_storage_t data[N]; ^ algned_storage.cpp: In member function ‘void static_vector::emplace_back(Args&& ...)’: algned_storage.cpp:18:13: error: ‘data’ was not declared in this scope new(data+m_size) T(std::forward(args)...); ^ algned_storage.cpp: In member function ‘const T& static_vector::operator[](std::size_t) const’: algned_storage.cpp:25:64: error: ‘data’ was not declared in this scope return *static_cast<const T*>(static_cast<const void*>(data+pos)); ^ algned_storage.cpp: In destructor ‘static_vector<T, N>::~static_vector’: algned_storage.cpp:32:60: error: ‘data’ was not declared in this scope static_cast<const T*>(static_cast<const void*>(data+pos))->~T;


 * cppreference attempts to document C++, not any particular versions of any particular compilers. The example compiles with current released versions of both gcc/libstdc++ and clang/libc++, and that's more than you can ask for sometimes (there are many strictly C++11 examples throughout this wiki that fail to compile with gcc). That said, I won't revert a working example if you care to switch to ::type, I don't see it as diminishing the value of the example (other than exposing a Visual Studio 2015 incompleteness, apparently: you should report that at Micrsoft Connect if nobody else did). The revert was really just a semi-automatic "this user didn't even press 'Run this code'" reaction. Now if you know of a current compiler version that corrupts the stack somehow, but not with boost? This may be worth bringing up with the vendor (and if it's been reported, mentioning it in the Notes section of this page) --Cubbi (talk) 04:00, 3 December 2014 (PST)


 * Cppreference:FAQ states that the primary focus of the site is C++11, which is the source of my confusion. Anyway, I have fixed the example to work with C++11 and verified that it works with GCC-4.7, GCC-4.8, GCC-4.9, VS2015 preview, Clang-3.4 and Clang-3.5. Thanks for catching the error in my first submit, that was tardiness on my part.