- Why not designated initializers in C++? - 9 Updates
- include right Headers - 7 Updates
- "Code behaving differently in C90, C99, C11, C++98, and C++11" - 3 Updates
- Nice graphs, how to write? - 1 Update
- initializer_list member and constexpr - 1 Update
- Prohibit calling a function with a derived class object - 4 Updates
| Ian Collins <ian-news@hotmail.com>: Jul 21 08:45AM +1200 On 07/21/16 02:43 AM, Jerry Stuckle wrote: >>> one. >> It's the only one pertinent to C++ classes. > And it violates encapsulation. So it's not a proper object. The relevance of this to aggregate initialisation is? >> struct S { int n; } s {0}; // Aggregate > Ah, but a structure is not an object. So you're not doing OO > programming. You might as well be using C. class C { int n; } c {0}; // Not an aggregate class S { public: int n; } s {0}; // Aggregate Happy now? -- Ian |
| Ian Collins <ian-news@hotmail.com>: Jul 21 08:40AM +1200 On 07/21/16 03:39 AM, Jerry Stuckle wrote: > It is designed as an OO language. Yes, it can be used as a functional > language - but that is not its design, and people shouldn't complain if > it doesn't contain some of the functional language features they want. "C++ was designed to support a range of styles that I considered fundamentally good and useful. Whether they were object-oriented, and in which sense of the word, was either irrelevant or a minor concern" http://www.stroustrup.com/oopsla.pdf -- Ian |
| Jerry Stuckle <jstucklex@attglobal.net>: Jul 19 04:47PM -0400 On 7/19/2016 10:30 AM, Öö Tiib wrote: > deprecate that (B) in both C and C++. *However* that is not up to me. > So I use what C++ has, positional initializers and positional > arguments. Using '{ .a = 10, .c = 30 }' exposes the private members of the class, and is a violation of encapsulation. Additionally, the parameter values are not validated, creating a potentially invalid object. That's why we have constructors. They hide private members and validate the values to ensure the object is properly constructed, or, if it is impossible to construct a valid object at this time, the constructor can mark the object as invalid until it has been made valid. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 21 11:18PM +0100 On Thu, 21 Jul 2016 13:44:44 -0700 (PDT) > On Wednesday, July 20, 2016 at 7:18:48 PM UTC-5, Chris Vine wrote: >> On Wed, 20 Jul 2016 15:53:10 -0700 (PDT) >> woodbrian77@gmail.com wrote: [snip] > relevant. The history/roots have to be considered or those > working on the standard end up navel-gazing -- focused on > their own thoughts and feelings. Sorry Brian, you are still wrong. The point you haven't grasped is that these types are called 'aggregates' in the C standard, and it would be highly misleading to call them anything else in the C++ standard because they are types which can be initialized in C++ in the same way that 'aggregates' can be in C. They are part of the C interface which is accepted in C++, for very good reason. That was a decision that the C++ standard committee took in full knowledge of the background and not as a consequence of (your pathetic reference to) "navel gazing". There are things wrong with C++, mainly because of the piece-meal organic way in which development of it has (of necessity) taken place. But it annoys me that someone without much of a clue like you can mouth off about "detachment from reality", particularly given some of your postings to this group. I would not trust your judgement on any matters relating to C++, and for that matter on your various off topic nonsense on this group as well. |
| Ian Collins <ian-news@hotmail.com>: Jul 20 09:32AM +1200 On 07/14/16 05:54 AM, Bo Persson wrote: > The official explanation (not mine) is that C++ already has constructors > for initializing objects. Adding even more ways would make the language > even more complicated. That is true, but there already are initialisation rules that only apply to PODs. The most common use case for designated initialisers would be to initialise structs originating from C headers. -- Ian |
| Ian Collins <ian-news@hotmail.com>: Jul 22 08:35AM +1200 On 07/22/16 04:50 AM, Mr Flibble wrote: >> C++ is the topic of this group. > Ian, it seems obvious to me that Jerry Stuckle is a fucktarded troll so > why do you engage it? Possibly for the same reason you engage Ramine! -- Ian |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 21 05:50PM +0100 On 21/07/2016 04:42, Ian Collins wrote: > international standard which defines the terms C++ programmers use when > discussing their language of choice. > C++ is the topic of this group. Ian, it seems obvious to me that Jerry Stuckle is a fucktarded troll so why do you engage it? /Flibble |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 26 06:13PM +0100 On 25/07/2016 22:09, Jerry Stuckle wrote: >> /Flibble > It's a placeholder. That's all. It's not selling anything; it's not > offering anything. But it isn't a placeholder is it? It even has contact details. You are obviously a scammer/fraudster. > And just because it's not a Maryland company does not mean it's not a > company in some other state. MD is in the contact details. > Stoopid is as stoopid does. Irony in that statement; you ever heard of psychological projection mate? /Flibble |
| Jerry Stuckle <jstucklex@attglobal.net>: Jul 26 02:47PM -0400 On 7/26/2016 1:13 PM, Mr Flibble wrote: >> offering anything. > But it isn't a placeholder is it? It even has contact details. You are > obviously a scammer/fraudster. Sure, lots of placeholders have contact details. >> And just because it's not a Maryland company does not mean it's not a >> company in some other state. > MD is in the contact details. The location is in the contact details. That doesn't mean it has to be incorporated in Maryland - or even incorporated. Epic fail - just like you always are. >> Stoopid is as stoopid does. > Irony in that statement; you ever heard of psychological projection mate? > /Flibble You're the one who knows all about fraud. And your "website" is still a piece of shit - just like you. Sorry, Fibbie. You're only making a bigger fool of yourself with every post. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: Jul 25 08:54PM -0400 On 7/25/2016 6:50 PM, red floyd wrote: > violation of the Standard. Any vendor is free in the future to create > a #define __SUB3_H_INCLUDED, which will break your code. > My personal usage for include guards is FILE_H_ As I said - it was an EXAMPLE. But you also can't show where it DOESN'T WORK. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| David Brown <david.brown@hesbynett.no>: Jul 26 10:20AM +0200 On 25/07/16 22:19, Vir Campestris wrote: > _both_ the include guards and the #pragma - the guards always work, but > the #pragma may be faster - Visual Studio's compiler at the time didn't > even _open_ the file on the second occurrence, never mind parse it. I haven't tried any benchmarks, but according to the Wikipedia page many compilers (such as gcc, clang, icc, and MSVC) have optimisations to make simple #include guards as fast as possible. Of course, that is for current compilers - it is quite possible that #pragma once was faster when you were doing this work. I don't think there will be any direct harm in using both methods, but the standard #include guard will be supported by IDE's, programmers' editors, linters, build utilities, or any other tool that does basic C pre-processing on files. Such tools are less likely to support #pragma once. So if you first have the #include guards, and using #pragma once makes little speed difference in practice (I have no benchmarks to confirm this, and it may vary between compilers), then the #pragma is superfluous and it is potentially confusing to have two different methods of doing the same thing in the code. Perhaps one day we will get a single standardised module system for C++, and this will all be a thing of the past... |
| Juha Nieminen <nospam@thanks.invalid>: Jul 26 09:48AM > Perhaps one day we will get a single standardised module system for C++, > and this will all be a thing of the past... Objective-C(++) has the #import directive. If the same file is #imported a second time during the compilation of a file, it's completely skipped. I have found #import to be quite practical because it saves you from having to write any inclusion guards at all. (If there are some rare circumstances where you really *need* to include a file twice, eg. to replicate the same data in two places, you can still use #include for that.) --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| D Laboratory <dlaboratory@126.com>: Jul 26 07:27PM +0800 > 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment