language-lawyer

Declarations in C++

橙三吉。 提交于 2020-01-30 14:13:53
问题 From what I have understood, declarations/initializations in C++ are statements with 'base type' followed by a comma separated list of declarators. Consider the following declarations: int i = 0, *const p = &i; // Legal, the so-called base type is 'int'. // i is an int while p is a const pointer to an int. int j = 0, const c = 2; // Error: C++ requires a type specifier for all declarations. // Intention was to declare j as an int and c an as const int. int *const p1 = nullptr, i1 = 0; // p1

Why do proc-macros have to be defined in proc-macro crate?

点点圈 提交于 2020-01-30 05:01:19
问题 I was trying to create a derive macro for my trait, to simplify some stuff. I've encountered some problems: the `#[proc_macro_derive]` attribute is only usable with crates of the `proc-macro` crate type and, after the small fix proc-macro=true : proc-macro` crate types cannot export any items other than functions tagged with `#[proc_macro_derive]` currently functions tagged with `#[proc_macro_derive]` must currently reside in the root of the crate` What is the reason for this behaviour? 回答1:

Is it legal to use variadic templates in operator overloading?

强颜欢笑 提交于 2020-01-30 04:17:30
问题 I would like to be able to write something along these lines: struct bar {}; template <typename ... Args> bar operator+(bar, Args ...) {} I just checked with clang/gcc and the overloaded operator is picked up both by binary expressions ( a+b ) and unary expressions ( +a ), as I would expect. However operators are more restricted than normal functions, in the sense that - for instance - you cannot overload operator+() with three arguments. Is the usage above legal and portable? EDIT To give a

Legal or out-of-bounds forming the address of the first element past the end? [closed]

半腔热情 提交于 2020-01-26 03:57:12
问题 Closed . This question needs details or clarity. It is not currently accepting answers. Want to improve this question? Add details and clarify the problem by editing this post. Closed 2 months ago . In another question I saw &studmark[STUDNO][0] where STUDNO is the size of the array. I wonder now if that code is already undefined behaviour. studmark[STUDNO] is one-past-the-end and while it may be created it must not be accessed. Is indexing that with [0] to then form the address valid? Or

Legal or out-of-bounds forming the address of the first element past the end? [closed]

冷暖自知 提交于 2020-01-26 03:57:06
问题 Closed . This question needs details or clarity. It is not currently accepting answers. Want to improve this question? Add details and clarify the problem by editing this post. Closed 2 months ago . In another question I saw &studmark[STUDNO][0] where STUDNO is the size of the array. I wonder now if that code is already undefined behaviour. studmark[STUDNO] is one-past-the-end and while it may be created it must not be accessed. Is indexing that with [0] to then form the address valid? Or

Can I use __qualname__ in a Python type hint with postponed annotation evaluation?

孤街浪徒 提交于 2020-01-24 19:55:06
问题 I like using __qualname__ for the return-type annotation of factory-style class methods, because it doesn't hardcode the classname and therefore keeps working subclasses (cf. this answer). class Foo: @classmethod def make(cls) -> __qualname__: return cls() Currently this seems to work fine, but I am not sure whether this will still be possible with the postponed evaluation of annotations (PEP 563): the PEP says that Annotations can only use names present in the module scope as postponed

Why is it allowed to static_cast a method of a derived class to a method of the base class?

核能气质少年 提交于 2020-01-24 19:33:10
问题 example struct B1{int x; void f(){x = 1;}}; struct D : B1{int x; void f(){B1::x = 2;}}; using Dmp = void(D::*)(); using B1mp = void(B1::*)(); int main() { Dmp dmp = &D::f; D d; (d.*dmp)(); // ok B1mp b1mp = static_cast<B1mp>(dmp); // hm, well that's weird B1 b1; (b1.*b1mp)(); dmp = &B1::f; // ok } And this example will compile and run just fine, and no problem will arise. But wait, now I'm going to use D::x in D::f , and now -- anything can happen at runtime. Yes, you can also static_cast a

Is static_cast<double>(std::nanf(“”)) well defined?

≡放荡痞女 提交于 2020-01-24 13:11:14
问题 Title pretty much asks it all, but to provide a MCVE: #include <cmath> int main() { float f = std::nanf(""); double d = static_cast<double>(f); return 0; } Under MSVC 2017, both f and d report as nan , but that proves nothing, since it may be that the static_cast is undefined behavior. In a similar vein, 0.0f / 0.0f produces -nan(ind) which I am going to assume is a signalling nan, does that follow the same defined / undefined rule? Ditto inf . 回答1: This looks guaranteed by the standard, we

Is static_cast<double>(std::nanf(“”)) well defined?

為{幸葍}努か 提交于 2020-01-24 13:11:05
问题 Title pretty much asks it all, but to provide a MCVE: #include <cmath> int main() { float f = std::nanf(""); double d = static_cast<double>(f); return 0; } Under MSVC 2017, both f and d report as nan , but that proves nothing, since it may be that the static_cast is undefined behavior. In a similar vein, 0.0f / 0.0f produces -nan(ind) which I am going to assume is a signalling nan, does that follow the same defined / undefined rule? Ditto inf . 回答1: This looks guaranteed by the standard, we

extending namespace std via partial template specialization

若如初见. 提交于 2020-01-24 12:13:09
问题 As far as I know, we are allowed (with some exceptions that I won't mention here) to "extend" namespace std by totally specializing a std template function such as std::swap , i.e. namespace std { template<> void swap<Foo>(Foo& lhs, Foo& rhs){...} } is perfectly valid. Since C++11, we can now partially specialize functions. I believe that we can then play the same game and extend std via partial specialization, like namespace std { template<typename T> void swap<Foo<T>>(Foo<T>& lhs, Foo<T>&