- Is this an xvalue, too? - 1 Update
- Is this an xvalue, too? - 2 Updates
- Need to #include <string>? - 2 Updates
| Victor Bazarov <v.bazarov@comcast.invalid>: Jun 06 04:44PM -0400 On 6/6/2015 1:32 PM, Stefan Ram wrote: > So, is »s« deemed to be an xvalue above and > is being moved from? (It's kind of like a > »block return value«.) These are rhetorical, mostly: (a) What difference does it make? (b) Consider that in a regular program xvalue-ness is not observable. Those things are like const-ness, all in the head of the programmer. (c) Why don't you get the assembly output and see whether your compiler does what you think might be needed for "moving" from 's'? V -- I do not respond to top-posted replies, please don't ask |
| ram@zedat.fu-berlin.de (Stefan Ram): Jun 06 05:32PM #include <iostream> #include <ostream> #include <string> using namespace ::std::literals; int main() { ::std::string t; { ::std::string s{ "alpha"s }; t = s; } ::std::cout << t << '\n'; } »s« is used near the end of its lifetime. That should be visible for a compiler, too. So, is »s« deemed to be an xvalue above and is being moved from? (It's kind of like a »block return value«.) |
| ram@zedat.fu-berlin.de (Stefan Ram): Jun 06 06:33PM 0 To value-initialize an object of type T means: 1 2 (8.1) --- if T is a (possibly cv-qualified) class type 3 (Clause 9) with either no default constructor (12.1) or 4 a default constructor that is user-provided or deleted, 5 then the object is default-initialized; 6 7 (8.2) --- if T is a (possibly cv-qualified) class type 8 without a user-provided or deleted default constructor, 9 then the object is zero-initialized and the semantic A constraints for default-initialization are checked, and B if T has a non-trivial default constructor, the object C is default-initialized; There seem to be the following cases for T: case 0: T has no default constructor (line 3) case 1: T has a user-provided default constructor (line 4) case 2: T has a deleted default constructor (line 5) case 3: T has no user-provided or deleted default constructor (line 8) and does /not/ have a non-trivial default constructor (line B) case 4: T has no user-provided or deleted default constructor (line 8) and /does/ have a non-trivial default constructor (line B) It would be great if someone could provide an example class definition for each of those 5 cases! |
| legalize+jeeves@mail.xmission.com (Richard): Jun 06 05:51AM [Please do not mail me a copy of your followup] Victor Bazarov <v.bazarov@comcast.invalid> spake the secret code >> already required for »::std:cout << "\n"s«? >The 's' suffix is user-defined, isn't it? It's some kind of language >(library) extension or did I miss it in the Standard somewhere? It's new to C++14. <http://en.cppreference.com/w/cpp/string/basic_string/operator%22%22s> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Richard Damon <Richard@Damon-Family.org>: Jun 06 10:05AM -0400 On 6/5/15 8:03 AM, Louis Krupp wrote: > <ostream> and <stream> #includes, and then be surprised when the > remaining code doesn't compile. > Louis In C, the language standard prohibits one system header from "randomly" injecting names from other headers into the namespace, effectively prohibiting one system header from including another defined system header (they need to include "private" headers using symbols reserved for the implementation for inter-header dependencies. In C++, this doesn't work, so headers are allowed to include other headers. The fundamental difference is that in C, type names don't really matter. Code doesn't care if a type name is an actual struct or a typedef for such a struct. In C++, it matters. Yes, Good Practices say you should explicitly include what you use, and not depend on indirect dependencies, but the language standard doesn't provide any way it enforce such a rule. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment