- neos - 3 Updates
- C++ move constructors - 13 Updates
- About TSO... - 1 Update
- C++ move constructors - 1 Update
| Ike Naar <ike@sdf.lonestar.org>: Mar 04 03:57PM > The sky is blue. Half of the time it's black. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 04 08:04AM -0800 On Monday, March 4, 2019 at 10:57:47 AM UTC-5, Ike Naar wrote: > On 2019-02-27, Anonymous Reactionary <anonymous@internet.everywhere> wrote: > > The sky is blue. > Half of the time it's black. Depends on where you are. It's also never truly black. And of the small number of photons entering our atmosphere in the darker hours, more of the blue are being scattered ... making the sky blue contin- ually, just at varying degrees of perceptible illumination to our eyes and equipment. -- Rick C. Hodgin |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Mar 04 03:00PM -0800 On 3/4/2019 7:57 AM, Ike Naar wrote: > On 2019-02-27, Anonymous Reactionary <anonymous@internet.everywhere> wrote: >> The sky is blue. > Half of the time it's black. Looking straight up on a dark, clear night tends to look "brighter" than looking off into a distant horizon. |
| blt_4f6dkyzs@yds5iz0up4o1.gov.uk: Mar 04 10:03AM Regarding the 2011 move constructors - do compilers actually generate different code for the given class compared to if it had a standard copy constructor, or are the && move semantics simply a way of indicating to any maintenance coders that this constructor will do a move not a copy? ie would the object code for these skeleton constructors: myclass(const myclass &rhs) { // Do nothing } myclass(const myclass &&rhs) { // Do nothing } be different? |
| "Öö Tiib" <ootiib@hot.ee>: Mar 04 03:00AM -0800 > // Do nothing > } > be different? You seem bit confused, sorry. It is hard to decide from where to start. 1) Perhaps first thing is that ... rvalue reference to const is confusing construct and so there is hard to see any usage for it. 2) Second is that you used it as parameter of constructor. It is not possible to move from const object so the second constructor of yours is *not* move constructor. No "move semantics" involved. 3) Third thing is that C++ compilers !typically! generate no code for (and even optimize out the calls of) functions that do nothing. However that (and anything concerning object code and even existence of such) is not in any way required by standard. Toolchain that targets asm.js for example generates JavaScript not object code. So your question about object code also does not make any sense. |
| Sam <sam@email-scan.com>: Mar 04 07:07AM -0500 > different code for the given class compared to if it had a standard copy > constructor, or are the && move semantics simply a way of indicating to any > maintenance coders that this constructor will do a move not a copy? The copy and move constructors will generate whatever code is necessary to implement the copy and move constructors, as written. > // Do nothing > } > be different? That's implementation defined. A compiler may generate no code for either constructor. Or the compiler can choose one of these constructors to implement the Sieve of Eratosthenes, and immediately throw away the results in a manner that's not observable. That, of course, is unlikely, but is certainly permitted. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 04 01:19PM +0100 On 04.03.2019 13:07, Sam wrote: >> maintenance coders that this constructor will do a move not a copy? > The copy and move constructors will generate whatever code is necessary > to implement the copy and move constructors, as written. The original code defines a copy constructor that default-initializes all members that don't have initializers, which for POD such members means doing nothing. It also defines a weird constructor taking `T const&&` argument, with the same empty implementation. >> be different? > That's implementation defined. A compiler may generate no code for > either constructor. No, the general rule for a constructor is that a member that's not explicitly initialized, either in the constructor or by having an initializer, is default-constructed. > to implement the Sieve of Eratosthenes, and immediately throw away the > results in a manner that's not observable. That, of course, is unlikely, > but is certainly permitted. Where did you get that from? Cheers!, - Alf |
| blt_u2a1Gabl68@x5ei40.com: Mar 04 12:35PM On Mon, 4 Mar 2019 03:00:05 -0800 (PST) >> be different? >You seem bit confused, sorry. It is hard to decide from where >to start. Im not confused, I'm simply asking if using && instead of just & changes compiler behaviour in any way or its simply syntatic sugar to make the intention of the code clearer for developers. >that targets asm.js for example generates JavaScript not object >code. So your question about object code also does not make any >sense. Javascript? What? What do you think the .o files generated by C/C++ compilers are? |
| blt_jzfbbiv_8L@upb.ac.uk: Mar 04 12:37PM On Mon, 04 Mar 2019 07:07:30 -0500 >> maintenance coders that this constructor will do a move not a copy? >The copy and move constructors will generate whatever code is necessary to >implement the copy and move constructors, as written. Thanks, very helpful. Not. Clearly my question was too sophisticated, I'll rephrase: Does using && instead of & change the object code generated by the compiler if no other part of the code is changed? |
| "Öö Tiib" <ootiib@hot.ee>: Mar 04 05:11AM -0800 > Im not confused, I'm simply asking if using && instead of just & changes > compiler behaviour in any way or its simply syntatic sugar to make the > intention of the code clearer for developers. Indeed you may be are not confused but just pretending to be stupid. Perhaps you erased my explanations 1) and 2) to confuse things up a bit and then reiterate your nonsensical questions. I can repeat: 1) Perhaps first thing is that ... rvalue reference to const is confusing construct and so there is hard to see any usage for it. 2) Second is that you used it as parameter of constructor. It is not possible to move from const object so the second constructor of yours is *not* move constructor. No "move semantics" involved. > >sense. > Javascript? What? What do you think the .o files generated by C/C++ compilers > are? Yes, JavaScript. For code meant to run in web browser. Have you ever seen a web browser? Well Firefox (from version 22), Safari (from version 3.1), Edge (from version 13) fully support asm.js. Chrome (from version 36) and Opera (from version 15) support asm.js partially. You are talking about particular compiler implementation (perhaps for particular platform) that generates .o files. Without mentioning those things the questions about object code generation make no sense. |
| "Öö Tiib" <ootiib@hot.ee>: Mar 04 05:20AM -0800 On Monday, 4 March 2019 14:19:24 UTC+2, Alf P. Steinbach wrote: > No, the general rule for a constructor is that a member that's not > explicitly initialized, either in the constructor or by having an > initializer, is default-constructed. Unfortunately it is way more complex and complicated than that. Consider: #include <iostream> struct BadCopier { int meaning; long number; BadCopier() : meaning(42) , number(666) { } // Copy constructor like in OP BadCopier(BadCopier const&) { } }; int main() { BadCopier a; BadCopier b {a}; std::cout << "a.meaning = " << a.meaning << "\n" << "a.number = " << a.number << "\n"; // undefined behavior follows std::cout << "b.meaning = " << b.meaning << "\n" << "b.number = " << b.number << "\n"; } a.meaning = 42 a.number = 666 b.meaning = 4196608 b.number = 4196032 It apparently did nothing (gcc 8.2.0). |
| David Brown <david.brown@hesbynett.no>: Mar 04 02:27PM +0100 > Clearly my question was too sophisticated, I'll rephrase: Does using && instead > of & change the object code generated by the compiler if no other part of the > code is changed? The answer is then equally clear - "maybe - it depends". If the source code is doing something different, the object code may be different. But it may also be the same if that achieves the correct result in the end. Or the compiler might generate different code - or no code - in different circumstances. Or the compiler might see that although you have written "copy", in the particular use-case it can do a "move" for greater efficiency. Or one compiler might handling things one way, a different compiler might do something else. Or it might be affected by flags. There are all sorts of things that affect the generated code. You can't break it down and say "how does the compiler implement this feature" - it doesn't even make sense to talk about "the compiler" when there are many different toolchains used. I recommend that you take some samples of what you really mean, and try them out. An excellent tool is <https://godbolt.org> - it's an online compiler that shows the generated assembly neatly. (You can choose from a variety of compilers and target processors - pick whatever suits you best.) Don't forget to choose suitable command-line options, especially to enable optimisation. (Without optimisation, such tests are meaningless.) |
| scott@slp53.sl.home (Scott Lurndal): Mar 04 01:58PM >Clearly my question was too sophisticated, I'll rephrase: Does using && instead >of & change the object code generated by the compiler if no other part of the >code is changed? That should be a very simple experiment for you to try. |
| blt_x7a_dW@uif_e90m4cobh00lil.net: Mar 04 04:16PM On Mon, 4 Mar 2019 05:11:47 -0800 (PST) >seen a web browser? Well Firefox (from version 22), Safari (from >version 3.1), Edge (from version 13) fully support asm.js. Chrome (from >version 36) and Opera (from version 15) support asm.js partially. Fascinating. >You are talking about particular compiler implementation (perhaps for >particular platform) that generates .o files. Without mentioning those >things the questions about object code generation make no sense. This is a C++ group, I have no idea why you're talking about javascript and browsers. Are you drunk? |
| blt_i5@taxzz.net: Mar 04 04:19PM On Mon, 04 Mar 2019 13:58:11 GMT >>of & change the object code generated by the compiler if no other part of the >>code is changed? >That should be a very simple experiment for you to try. It is, and I have and the answer to appears to be no, ie && is just syntactic sugar and does nothing different to &. However I wanted to know if in any situations it might be more than that. |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 04 09:38PM +0200 > Clearly my question was too sophisticated, I'll rephrase: Does using && instead > of & change the object code generated by the compiler if no other part of the > code is changed? If you accept "no object code generated" to qualify as "change of object code" then the answer is yes: void foo(int& x) {} int main() { foo(long(1)); } Does not compile, so no object code generated. void foo(int&& x) {} int main() { foo(long(1)); } Compiles and works fine. I am pretty sure someone can also make an example with two valid programs having different observable behavior (so different object codes), probably via some template magic. |
| Horizon68 <horizon@horizon.com>: Mar 04 10:58AM -0800 Hello... Bruce Hoult wrote > have, and how tightly they must be coupled. It seems to > work ok out to at least 32 cores, or 64 cores. > A thousand might be a different matter. ARM cores for cloud & server workloads? If performance suffering of 3% ~ 6% is acceptable, TSO could be considered as an alternative for its simpler programming model. About SC and TSO and RMO hardware memory models.. I have just read the following webpage about the performance difference between: SC and TSO and RMO hardware memory models I think TSO is better, it is just around 3% ~ 6% less performance than RMO and it is a simpler programming model than RMO. So i think ARM must support TSO to be compatible with x86 that is TSO. Read more here to notice it: https://infoscience.epfl.ch/record/201695/files/CS471_proj_slides_Tao_Marc_2011_1222_1.pdf About memory models and sequential consistency: As you have noticed i am working with x86 architecture.. Even though x86 gives up on sequential consistency, it's among the most well-behaved architectures in terms of the crazy behaviors it allows. Most other architectures implement even weaker memory models. ARM memory model is notoriously underspecified, but is essentially a form of weak ordering, which provides very few guarantees. Weak ordering allows almost any operation to be reordered, which enables a variety of hardware optimizations but is also a nightmare to program at the lowest levels. Read more here: https://homes.cs.washington.edu/~bornholt/post/memory-models.html Memory Models: x86 is TSO, TSO is Good Essentially, the conclusion is that x86 in practice implements the old SPARC TSO memory model. The big take-away from the talk for me is that it confirms the observation made may times before that SPARC TSO seems to be the optimal memory model. It is sufficiently understandable that programmers can write correct code without having barriers everywhere. It is sufficiently weak that you can build fast hardware implementation that can scale to big machines. Read more here: https://jakob.engbloms.se/archives/1435 Thank you, Amine Moulay Ramdane. |
| ram@zedat.fu-berlin.de (Stefan Ram): Mar 04 02:39PM main.cpp #include <iostream> #include <ostream> struct C { C(){ ::std::cerr << "A\n"; }; C( C && c ){ ::std::cerr << "B\n"; } }; int main() { C{ C{} }; } Transcript A Expected by the programmer A B Say what now? |
| 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