c++-standard-library

Is providing a private constructor for initializer_list conforming?

懵懂的女人 提交于 2019-12-04 03:05:28
问题 This draft standard shows the synopsis for initializer_list . It has no private constructor. But two standard library implementations I have looked at, libstdc++ and libc++, both provide private constructors: // The compiler can call a private constructor. constexpr initializer_list(const_iterator __a, size_type __l) : _M_array(__a), _M_len(__l) { } _LIBCPP_ALWAYS_INLINE _LIBCPP_CONSTEXPR_AFTER_CXX11 initializer_list(const _Ep* __b, size_t __s) _NOEXCEPT : __begin_(__b), __size_(__s) {} I

Why is there no definition of the constant pi in the C++11 standard? [closed]

徘徊边缘 提交于 2019-12-04 02:47:18
问题 Closed . This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 6 years ago . I find it quiet annoying that I have to use the macro _USE_MATH_DEFINES in order to get the value of pi into my program. Or I need to define it myself in one of my own headers. Or I have to use boost and all that. It just annoys me, that there isn't a standard c++ header

are there any plans in C++ standard to address inconsistency of initializer list constructors?

三世轮回 提交于 2019-12-04 01:52:12
initializer list constructors in C++ often cause trouble; for example using std::vector; using std::string; vector<string> v{3}; // vector of three empty strings vector<int> u{3}; // vector of one element with value 3 (Just to clarify, I mean <int> constructor is an initializer list constructor, while the <string> one is not .) The int case matches the initializer list constructor, while the string case doesn't. This is somewhat ugly, and often causes trouble. It was also noted in an early chapter (item 7) in Scott Meyers' Effective Modern C++, and he describes it as a somewhat unpleasant part

Is it permissible for standard library implementation to have class definition that is different from the C++ standard?

谁都会走 提交于 2019-12-04 01:06:37
The following code successfully compiled with clang and MSVC but fail to compile in GCC 6.1.0. #include <memory> template<typename R, typename T, typename... Args> T* test(R(T::*)(Args...) const) { return nullptr; } int main() { using T = std::shared_ptr<int>; T* p = test(&T::get); } with the following error message prog.cc: In function 'int main()': prog.cc:13:16: error: invalid conversion from 'std::__shared_ptr<int, (__gnu_cxx::_Lock_policy)2u>*' to 'T* {aka std::shared_ptr<int>*}' [-fpermissive] T* p = test(&T::get); ~~~~^~~~~~~~~ The problem is that libstdc++ implemented std::shared_ptr

How can unique_ptr have no overhead if it needs to store the deleter?

[亡魂溺海] 提交于 2019-12-03 22:10:45
First take a look at what C++ Primer said about unique_ptr and shared_ptr : $16.1.6. Efficiency and Flexibility We can be certain that shared_ptr does not hold the deleter as a direct member, because the type of the deleter isn’t known until run time. Because the type of the deleter is part of the type of a unique_ptr , the type of the deleter member is known at compile time. The deleter can be stored directly in each unique_ptr object. So it seems like that the shared_ptr does not have a direct member of deleter, but unique_ptr does. However, the top-voted answer of another question says: If

Deprecation of std::allocator<void>

自闭症网瘾萝莉.ら 提交于 2019-12-03 17:41:29
问题 Related: Why do standard containers require allocator_type::value_type to be the element type? It is said that the following has been deprecated since C++17: template<> struct allocator<void>; I wonder whether it is deprecated because the primary template alone is now able to accommodate allocator<void> , or the use-case of allocator<void> is deprecated. If latter, I wonder why. I think allocator<void> is useful in specifying an allocator not bound to a specific type (so just some schema

Why is `std::byte` an enum class instead of a class?

孤者浪人 提交于 2019-12-03 15:19:56
问题 std::byte is an abstraction that is supposed to provide a type safe(r) access to regions of memory in C++, starting with the new standard 17. However, it's declared this way according to http://en.cppreference.com/w/cpp/types/byte: enum class byte : unsigned char {} ; That is, it is an enum class without any enumerations. Since usually the purpose of enums is to provide a restricted set of enumerations, this seems a bit strange. A class with a private unsigned char member seems like the more

Most efficient way to assign values to maps

谁都会走 提交于 2019-12-03 11:05:17
Which way to assign values to a map is most efficient? Or are they all optimized to the same code (on most modern compilers)? // 1) Assignment using array index notation Foo["Bar"] = 12345; // 2) Assignment using member function insert() and STL pair Foo.insert(std::pair<string,int>("Bar", 12345)); // 3) Assignment using member function insert() and "value_type()" Foo.insert(map<string,int>::value_type("Bar", 12345)); // 4) Assignment using member function insert() and "make_pair()" Foo.insert(std::make_pair("Bar", 12345)); (I know I could benchmark and check compiler output, but this question

Should an STL container avoid copying elements into themselves when the container is copied into itself?

主宰稳场 提交于 2019-12-03 10:52:42
问题 The question is about self-assignment. For example copying a vector into itself: std::vector<std::string> vec(5, "hello"); vec = vec; Should the code above perform 5 assignment operations of strings into themselves, or just do nothing? I mean whether the following checking is valid: std::vector operator=(const std::vector &rhs) { if (this == &rhs) { return *this; } ... } I'm working on my own implementation of std::variant class (just for fun) and interested if I should add a self-assignment

What is the difference between shuffle and random_shuffle c++

爱⌒轻易说出口 提交于 2019-12-03 10:40:34
The function std::shuffle has been introduced in C++11: template< class RandomIt, class URNG > void shuffle( RandomIt first, RandomIt last, URNG&& g ); and it has the same signature as one of the overloads of std::random_shuffle which was also introduced in C++11: template< class RandomIt, class RandomFunc > void random_shuffle( RandomIt first, RandomIt last, RandomFunc&& r ); The difference is in the third parameter where: URNG must meet the requirements of UniformRandomNumberGenerator Is this all? Is the difference just that shuffle performs an extra compile time check? Is the behavior