- using #define vs const int , in error codes - 6 Updates
- Idiots - 6 Updates
| JiiPee <no@notvalid.com>: Nov 12 09:04PM On 12/11/2015 18:21, Richard wrote: >> ye I do, but I just see that some people use defines... > Yes. Ignore those people and do not emulate or copy them. They are C > programmers. You can do better with C++. But this latest one, this was from a C++ code... so in C++ code they used #defines to define contant integers... errors. |
| Vir Campestris <vir.campestris@invalid.invalid>: Nov 12 09:14PM On 12/11/2015 02:31, Öö Tiib wrote: > If the constants are used only in code then it is perhaps good idea to > avoid capitalizing them in screaming caps. Also if these are meant as > selection of values, (like your error codes) then enum is likely best. We always put #define-s in SCREAMING CAPS to remind people they shouldn't be using them. Use an enum. Preferably n enum class. Andy |
| Ian Collins <ian-news@hotmail.com>: Nov 13 11:11AM +1300 JiiPee wrote: >> programmers. You can do better with C++. > But this latest one, this was from a C++ code... so in C++ code they > used #defines to define contant integers... errors. That implies it is bad C++ code! As Richard noted, this is a bad (in a C++ context) of C programmers writing C++. There is no place for #define constants in C++ code. -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Nov 13 11:17AM +1300 Ian Collins wrote: > That implies it is bad C++ code! > As Richard noted, this is a bad (in a C++ context) of C programmers > writing C++. There is no place for #define constants in C++ code. Should read "a bad habit". -- Ian Collins |
| legalize+jeeves@mail.xmission.com (Richard): Nov 12 10:48PM [Please do not mail me a copy of your followup] no@notvalid.com spake the secret code >> programmers. You can do better with C++. >But this latest one, this was from a C++ code... so in C++ code they >used #defines to define contant integers... errors. The proof of what kind of programmer they are is in what kind of code they wrote. Just slapping ".cpp" on the end of a file doesn't mean you are writing C++ code, particularly if your code is full of C programming habits. If they are using #define for constants, they are C programmers IMO. Sorry, but if you're going to argue against that position then I don't consider you a C++ programmer. -- "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> |
| legalize+jeeves@mail.xmission.com (Richard): Nov 12 11:07PM [Please do not mail me a copy of your followup] (Richard) legalize+jeeves@mail.xmission.com spake the secret code >Sorry, but if you're going to argue against that position then I >don't consider you a C++ programmer. A slight clarification: I mean you in a generic sense here, not specifically the author of the post to which I was repsponding. -- "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> |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 12 08:29PM On 12/11/2015 19:18, Daniel wrote: > virtual void do_f() = 0; > } > seems plenty abstract to me. Perhaps you were thinking of a pure virtual class? It is only abstract in the sense that it has a pure virtual function but I wouldn't call this (in general) an "interface"; an interface consists of pure virtual functions and TRIVIAL helper functions only BUT NO CLASS INVARIANT. Advocating making all the interface's virtual functions private serves no purpose: in your example f() does nothing other than call do_f(). Perhaps you are confusing "interface" with "abstract base class"? One is a subset of the other. >> interface which would be ridiculous. > I recall many years ago reading a column in C++ Report by Scott Meyers titled never derive from a concrete class (which is a bit stronger than never derive from a standard container.) My first thought was that's ridiculous. But the arguments were sufficiently compelling that I incorporated them into my programming practices, I think for the better, and it's extremely rare that I would do that anymore. > If you want to extend the interface, why not use free functions? One indeed should prefer free functions to member functions as adding public member functions to a class reduces that class's encapsulation however there are cases when it is appropriate to augment a class's interface through derivation and advocating that you must NEVER do this for containers is idiotic (as long as the generality of the container concept is not compromised). > I have to say I'm not enthusiastic about people wrapping standard containers, either via derivement or containment. If I'm looking at somebody else's code and see std::map but can't remember the details, I can give that to google, but if I type "MrFlibblesMagicalMap", nothing comes back See comment above. >>> You don't lose anything by storing std::addressof(ref) instead, do you? >> What? Are you insane? > Possibly, not to be ruled out. But whenever I've wanted to hold onto something received in the constructor as a reference, I've held onto the pointer rather than the reference. There are other contexts, of course. If you don't require pointer nullability or modification and object assignability then there is nothing wrong with using reference members in fact one should always prefer references to pointers. >>> Happy sausages, >> First sane thing you have said. > You know, there are people who say you should *never* eat sausages. Indeed but the majority of those who say that believe in the existence of magical sky fairies. /Flibble |
| Wouter van Ooijen <wouter@voti.nl>: Nov 12 09:57PM +0100 Op 12-Nov-15 om 9:17 PM schreef Mr Flibble: >> Of course there are many situations when this design is an overkill and >> where a simple public abstract interface would do. Know your tools! > That was just nonsense mate; have you had a stroke? No stroke required, it is a well-known design pattern: Non-Virtual-Interface. Wouter |
| Daniel <danielaparker@gmail.com>: Nov 12 01:26PM -0800 On Thursday, November 12, 2015 at 3:29:29 PM UTC-5, Mr Flibble wrote: > It is only abstract in the sense that it has a pure virtual function but > I wouldn't call this (in general) an "interface" You mightn't, but Herb Sutter would, he calls it the Non-Virtual Interface Idiom (NVI). Sutter says that Guideline #1 is "Prefer to make interfaces nonvirtual." > > You know, there are people who say you should *never* eat sausages. > Indeed but the majority of those who say that believe in the existence > of magical sky fairies. My Pakistani friend who identifies as half muslim (he drinks beer but he doesn't eat pork) would respectfully demur. Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 12 10:16PM On 12/11/2015 21:26, Daniel wrote: >> It is only abstract in the sense that it has a pure virtual function but >> I wouldn't call this (in general) an "interface" > You mightn't, but Herb Sutter would, he calls it the Non-Virtual Interface Idiom (NVI). Sutter says that Guideline #1 is "Prefer to make interfaces nonvirtual." I don't care what Herb Sutter thinks. Have you ever heard of the appeal to authority logical fallacy? Not that I agree that Herb Sutter is an authority on such matters. Are you a Herb Sutter fan boy? >> Indeed but the majority of those who say that believe in the existence >> of magical sky fairies. > My Pakistani friend who identifies as half muslim (he drinks beer but he doesn't eat pork) would respectfully demur. Oh. /Flibble |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 12 10:25PM On 12/11/2015 20:57, Wouter van Ooijen wrote: >> That was just nonsense mate; have you had a stroke? > No stroke required, it is a well-known design pattern: > Non-Virtual-Interface. Again you are confusing abstract base classes (employing template method pattern) with pure interfaces. Interfaces are a subset of abstract base classes and an interface should NOT have any class invariant unlike most abstract base classes which do. /Flibble |
| Gareth Owen <gwowen@gmail.com>: Nov 12 10:31PM > On Wednesday, November 11, 2015 at 4:13:57 PM UTC-6, gwowen wrote: > Please don't swear here. You stop proselytzing and plugging your Middleware writer, and I'll stop swearing. Deal? (Also, "hell"? Really? Is it 1860 all of a sudden/) |
| 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