- initializer_list - 3 Updates
- Why not designated initializers in C++? - 2 Updates
- OOP Golden Rule - 2 Updates
- include right Headers - 7 Updates
| Daniel <danielaparker@gmail.com>: Jul 27 04:33AM -0700 Consider struct Q { Q() = default; Q(Q const&) { std::cout << "copy-constructor" << std::endl; } Q(std::initializer_list<Q>) { std::cout << "initializer_list constructor" << std::endl; } }; int main() { Q q; Q q2 = Q{ q }; } which is an example taken from http://en.cppreference.com/w/cpp/language/list_initialization, in the Notes section. According to cppreference, the initializer-list constructor (not copy constructor), should be called. But with Visual C++ 2015 Update 3, it is the copy constructor that is called. Which is right? Thanks, Daniel |
| "Öö Tiib" <ootiib@hot.ee>: Jul 27 07:31AM -0700 On Wednesday, 27 July 2016 14:33:23 UTC+3, Daniel wrote: > constructor), should be called. > But with Visual C++ 2015 Update 3, it is the copy constructor that is called. > Which is right? Avoid relying on side effects of such list-move-copy-constructors since behavior in standard (and so in compilers) may change on patch-to-patch level for some time. I think the committee is trying really hard to make the initialization to work. It may be is possible but it will take time. The particular behavior of MSVC that you describe seems to be most likely conforming with fix of a defect #1467 of standard: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1467 The resulting unclarity that you complain about it already opened as issue #2137. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2137 IOW the outcome that you describe may be is unintended result of given fix and so subject of further changes or not but MSVC seems to conform in some sense right now. ;-) |
| Daniel <danielaparker@gmail.com>: Jul 27 12:57PM -0700 On Wednesday, July 27, 2016 at 10:32:06 AM UTC-4, Öö Tiib wrote: > IOW the outcome that you describe may be is unintended result of given > fix and so subject of further changes or not but MSVC seems to conform > in some sense right now. ;-) Thanks. I share the concerns of the author of issue #2137. Daniel |
| Jerry Stuckle <jstucklex@attglobal.net>: Jul 26 04:43PM -0400 On 7/26/2016 3:38 PM, Mr Flibble wrote: > Washington D.C. Metro AreaConstruction > Current > SmarTech Homes, Inc. So what? Once again, just because I have an address in Maryland doesn't mean my company has to be incorporated in Maryland. We have a Holiday Inn just down the street. It has a Maryland address. But Holiday Inn isn't incorporated in Maryland. The same with IBM - several offices here in Maryland, with Maryland addresses. You're only showing your stoopidity, Fibbie. > You've used that line before mate; it didn't work then and it won't work > now. > /Flibble Hey, the truth hurts, doesn't it. But you're quick to say someone else is a fraud because you think everyone is as crooked as you are. I have run into trolls before on the internet, but I can't say I have ever run into one as stoopid as you are, Fibbie. However, you ARE entertaining! Trying to dig up stuff which is out there in plain sight, and thinking you've found some secret! ROFLMAO! Go back to your ditch digging. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Daniel <danielaparker@gmail.com>: Jul 27 12:51PM -0700 On Tuesday, July 26, 2016 at 2:47:23 PM UTC-4, Jerry Stuckle wrote: > Sorry, Fibbie. Actually, the affectionate, pet form for Flibble is "Flibbie", not "Fibbie." Just trying to be helpful, Daniel |
| Daniel <danielaparker@gmail.com>: Jul 27 12:37PM -0700 On Tuesday, July 26, 2016 at 4:50:56 PM UTC-4, Mr Flibble wrote: > Example: a weapon class is fine but a sword class > and a knife class are not as there are no intrinsic differences > between a knife and a sword. It depends. Supposing the base class had an abstract method slashNeck, a derived knife class might print "F**k!!!", while a derived sword class might print, well, nothing. Generally the decision about whether a class is needed depends on purpose. Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 27 08:44PM +0100 On 27/07/2016 20:37, Daniel wrote: > It depends. Supposing the base class had an abstract method slashNeck, a derived > knife class might print "F**k!!!", while a derived sword class might print, well, > nothing. Generally the decision about whether a class is needed depends on purpose. "It depends" applies to most if not all generalizations. My generalization is still a good rule of thumb. :) /Flibble |
| Geoff <geoff@invalid.invalid>: Jul 26 02:48PM -0700 On Tue, 26 Jul 2016 15:36:02 -0400, Jerry Stuckle >That still doesn't answer my question. Show me where this particular >example DOESN'T work. >You can't, so you try to evade the question. It doesn't matter where it doesn't work. It's bad practice given the simplicity of the correct method and that method is standard compliant and GUARANTEED to work correctly ALWAYS, there is absolutely no reason not to name your include guard portably and correctly and keep your symbols within their proper name space. Modern practice dictates that contemporary advice should advise against leading underscores followed by an uppercase letter since this has been reserved to the implementation for many years. Usage such as you advise is bad practice in the face of the standard, your insistence on that usage is ill-advised and makes you a propagator of cargo cult. It also marks you as ignorant of modern, correct practices. |
| Jerry Stuckle <jstucklex@attglobal.net>: Jul 26 11:39PM -0400 On 7/26/2016 5:48 PM, Geoff wrote: > your insistence on that usage is ill-advised and makes you a > propagator of cargo cult. It also marks you as ignorant of modern, > correct practices. I never said it was good practice. I just want you to show where it fails. And BTW - there is nothing wrong with the "cargo cult" as you call it. It is used by a number of large companies as part of their programming style. But then they've also been doing it for over 30 years and see no reason to go back and change all that code due to a standards change which doesn't affect them. And these are not small companies - you would most probably recognize every one I am thinking of - including some big ones in the computer field. That's why I want you to show where it fails. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: Jul 27 05:50PM +1200 On 07/27/16 03:39 PM, Jerry Stuckle wrote: >> propagator of cargo cult. It also marks you as ignorant of modern, >> correct practices. > I never said it was good practice. I just want you to show where it fails. It'll fail when, as it is entitled to do, your implementation introduces a conflicting symbol in its reserved namespace. -- Ian |
| Jerry Stuckle <jstucklex@attglobal.net>: Jul 27 08:54AM -0400 On 7/27/2016 1:50 AM, Ian Collins wrote: >> fails. > It'll fail when, as it is entitled to do, your implementation introduces > a conflicting symbol in its reserved namespace. So, you should be able to show where it fails then. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 27 05:23PM +0100 On 27/07/2016 13:54, Jerry Stuckle wrote: >> It'll fail when, as it is entitled to do, your implementation introduces >> a conflicting symbol in its reserved namespace. > So, you should be able to show where it fails then. Compilation will fail where it tries to compile anything defined in your header that was skipped because your header guard was defined by the implementation in one of its header files that you included (either directly or indirectly) before your header file. /Flibble |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 27 05:26PM +0100 On 27/07/2016 17:23, Mr Flibble wrote: > header that was skipped because your header guard was defined by the > implementation in one of its header files that you included (either > directly or indirectly) before your header file. Or alternatively compilation will fail where it tries to compile anything defined in the implementation's header files that was skipped because it used the same header guard as your header guard in your header file was included before the implementation's header file was included (either directly or indirectly). /Flibble |
| Paavo Helde <myfirstname@osa.pri.ee>: Jul 27 10:01PM +0300 On 27.07.2016 19:26, Mr Flibble wrote: > because it used the same header guard as your header guard in your > header file was included before the implementation's header file was > included (either directly or indirectly). Concrete examples (MSVC2103): // File PeopleConcert.h #ifndef _PPLCONCRT_H #define _PPLCONCRT_H class PeopleConcert { public: void Organize() {} }; 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment