c++14 | 易学教程

Surprise in template parameter substitution?

阅读更多关于 Surprise in template parameter substitution?

问题 N3690, § 14.8.2 paragraph 3 has this pretty mind blowing example: template <class Z> void h(Z, Z*); // #5: function type is h(int, const int*) h<const int>(1,0); Question: why is it not h(const int, const int*) ? From what know, Z = const int , so every occurence of Z in the template declaration can be read as const int , or am I missing something? Why pointer is different? I remember that when parameter has T& or T* it preserves cv-qualifiers of T , but I don't see any possibility to apply

Prevent the creation of temporary objects

阅读更多关于 Prevent the creation of temporary objects

I have the same question that was asked over here five years ago: Disallowing creation of the temporary objects The reason I am asking it again is that I am specifically interested in C++11 and C++14 techniques for preventing the construction of temporaries. One idea is to use "rvalue reference for *this": class ScopedLock { public: void enable() && = delete; void enable() & { is_enabled = true; } ~ScopedLock() { if (!is_enabled) { std::cerr << "ScopedLock misuse." << std::endl; std::terminate(); } } private: bool is_enabled = false; }; int main() { // OK ScopedLock lock; lock.enable(); //

Is there a weak_ptr equivalent to shared_from_this?

阅读更多关于 Is there a weak_ptr equivalent to shared_from_this?

问题 I have a class which I know will always be owned by a std::shared_ptr . However passing shared_ptr or even weak_ptr to functions and methods that don't need ownership or lifetime guarantees creates unnecessary overhead. To get around this I often pass raw pointers to functions. The class itself inherits from std::enable_shared_from_this so if the function needs to take ownership of the pointer it can use a method of the class to get a shared_ptr . This is all working beautifully. However

Where in C++14 Standard does it say that a non-constexpr function cannot be used in a definition of a constexpr function?

阅读更多关于 Where in C++14 Standard does it say that a non-constexpr function cannot be used in a definition of a constexpr function?

问题 For example the code below doesn't compile unless incr() is declared constexpr : int incr(int& n) { return ++n; } constexpr int foo() { int n = 0; incr(n); return n; } Looking at §7.1.5/3 in C++14 we have: The definition of a constexpr function shall satisfy the following constraints: (3.1) — it shall not be virtual (10.3); (3.2) — its return type shall be a literal type; (3.3) — each of its parameter types shall be a literal type; (3.4) — its function-body shall be = delete, = default, or a

Signed bit field in C++14

阅读更多关于 Signed bit field in C++14

问题 I believe that until C++14 a bit field of a struct declared as int was still interpreted as either signed or unsigned , the interpretation being implementation defined. Reference: http://en.cppreference.com/w/cpp/language/bit_field. Is this still the case in C++14? I.e., is the code below guaranteed to work as inteded? #include <iostream> struct X { int f:3; }; int main() { X x; x.f = -2; // is this going to be indeed signed? It seems so. std::cout << x.f << std::endl; // displays -2 } 回答1:

Writing to different offsets in array always well defined

阅读更多关于 Writing to different offsets in array always well defined

问题 In this question it was brought up that writing to two different offsets in a char array concurrently would imply a data race, since some processors such as Alpha don't have byte-wise addressing so it'd be hard to implement this. I certainly see that this would very much slow down writing bytes on alpha processors (basically involving a LL/SC), but as I understand the C++ standard every field in an array is its own memory location (although from reading §1.7, I could also see the whole array

Are trigraphs still valid C++?

阅读更多关于 Are trigraphs still valid C++?

问题 We all know about the historical curiosity that is digraphs and trigraphs, but with all the changes made to C++ in recent years I'm curious: are they valid C++14? How about C++17? 回答1: Trigraphs are currently valid, but won't be for long! Trigraphs were proposed for deprecation in C++0x, which was released as C++11. This was opposed by IBM, speaking on behalf of itself and other users of C++, and as a result trigraphs were retained in C++0x. Trigraphs were then proposed again for removal (not

Return type deduction with an explicit prototype in C++

阅读更多关于 Return type deduction with an explicit prototype in C++

问题 I've been playing with the return type deduction supported in g++ with -std=c++1y. If you prototype a function with an explicit return type, and then later try to define the function with return type deduction, the compiler complains of an ambiguous old declaration: std::string some_function(); ... auto some_function(){ return std::string{"FOO"}; } //fails to compile Is there a good reason why this doesn't work? My rationale for using return type deduction in the definition is to keep the

C++ block scope extern declaration linkage, confusing C++ standard explanation

阅读更多关于 C++ block scope extern declaration linkage, confusing C++ standard explanation

问题 Standards N3242 (C++ 11 draft) and N3797 (C++ 14 draft) both have the same paragraph. § 3.5 Program and linkage [basic.link] ¶ 6 The name of a function declared in block scope and the name of a variable declared by a block scope extern declaration have linkage. If there is a visible declaration of an entity with linkage having the same name and type, ignoring entities declared outside the innermost enclosing namespace scope, the block scope declaration declares that same entity and receives

Check whether equal string literals are stored at the same address

阅读更多关于 Check whether equal string literals are stored at the same address

问题 I am developing a (C++) library that uses unordered containers. These require a hasher (usually a specialization of the template structure std::hash) for the types of the elements they store. In my case, those elements are classes that encapsulate string literals, similar to conststr of the example at the bottom of this page. The STL offers an specialization for constant char pointers, which, however, only computes pointers, as explained here, in the 'Notes' section: There is no