- using #define vs const int , in error codes - 13 Updates
- Overloading based on const - 6 Updates
- Idiots - 3 Updates
- Machine code!!! \o/ - 1 Update
- Comparing strings with if else - 2 Updates
| jacobnavia <jacob@jacob.remcomp.fr>: Nov 13 09:36AM +0100 Le 12/11/2015 19:21, Richard a écrit : > Yes. Ignore those people and do not emulate or copy them. They are C > programmers. You can do better with C++. I do not understand the need of C++ people to insult people that use other languages. Maybe that is a consequence of using c++ probably, an overly complex language that takes so much place in your mind that good manners and civilized behavior must be thrown out. C programmers refuse the complexity and use #defines because they are simple to use, they can be used in conditional compilation and they belong to the C tradition of how things are done. Contrary to popular beliefs among ignorant c++ users, C programmers have enums available and they use it regularly instead of defines when defines aren't appropiate. |
| jacobnavia <jacob@jacob.remcomp.fr>: Nov 13 09:38AM +0100 Le 12/11/2015 22:04, JiiPee a écrit : > But this latest one, this was from a C++ code... so in C++ code they > used #defines to define contant integers... errors. Obviously you are wrong. Please do not believe what your eyes see, do not hear what your ears perceive and go on saying what politically correct is in this newsgroup: c++ prpgrammers should not use defines. Personally, I have never seen a serious C++ program without defines. But of course, I am wrong. I will be always wrong because I program in C. |
| jacobnavia <jacob@jacob.remcomp.fr>: Nov 13 09:45AM +0100 Le 12/11/2015 23:48, Richard a écrit : > Sorry, but if you're going to argue against that position then I > don't consider you a C++ programmer. Oh my goodness. Are you implying that the poor chap is a C programmer? What an insult! Obviously I do not understand why c++ programmers need this arrogance. Maybe it is caused by too reading too much templated code: they think in templates and they use them in their everyday life with disastrous consequences. There is a for them a "C programmer" template, an obtuse and backwards looking chap, unable to load all the c++ crap into their mind. Then there is the c++ programmer template, the forward looking guru that always finds an unnamed lambda an a corresponding templated virtual class that can be added to make a simple application unreadable an incomprehensible but for the intiated. Look, there is NO NEED to insult other programmers. Just say why you think some software feature is better adapted than another one and let it be at that. Argue, instead of displaying your arrogance Mister. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 13 01:31AM -0800 On Friday, 13 November 2015 10:45:16 UTC+2, jacobnavia wrote: > > don't consider you a C++ programmer. > Oh my goodness. Are you implying that the poor chap is a C programmer? > What an insult! :D Richard was clearly trolling and managed to waste our time. Congrats Richard! Microsoft's C compiler is slightly extended C89. Windows is truly awful platform to run C on it. Microsoft's API headers however are rather FULL OF #define constants. > Look, there is NO NEED to insult other programmers. Several times I have been in situation where C++ is not available: 1) No C++ compilers or libraries for target platform. 2) C++ does not run in browser (neither does C). 3) Most bright brain in team considers C++ a root of all evil. 4) "It must written be in C" is QUALIFIER requirement. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 13 01:41AM -0800 On Friday, 13 November 2015 10:38:50 UTC+2, jacobnavia wrote: > Personally, I have never seen a serious C++ program without defines. I can confirm. Every C++ header in code-bases that I can reach has at least one '#define' in it. Shortest header from boost: http://www.boost.org/doc/libs/1_55_0/boost/noncopyable.hpp Like you see those '#define's do not define constants. |
| jacobnavia <jacob@jacob.remcomp.fr>: Nov 13 10:54AM +0100 Le 13/11/2015 10:41, Öö Tiib a écrit : > Shortest header from boost: > http://www.boost.org/doc/libs/1_55_0/boost/noncopyable.hpp > Like you see those '#define's do not define constants. Yes, you can use enum, as I often do in C. Note that I am not arguing against the use of enum for constants. What I really do not like is the implicit pejorative use of the "C programmer" here. |
| legalize+jeeves@mail.xmission.com (Richard): Nov 13 05:06PM [Please do not mail me a copy of your followup] jacob@jacob.remcomp.fr spake the secret code >> programmers. You can do better with C++. >I do not understand the need of C++ people to insult people that use >other languages. If you take that as an insult, that's your problem. The fact is that C++ has better mechanisms for named constants than preprocessor macros. C++ has had them for far longer than C has had them. There isn't any excuse for perpetuating a weaker solution from 1973. Modern C has enums and const integers as well, so even in C there is no excuse for using the preprocessor for named constants. See the C11 ISO standard; I consulted the April 12, 2011 committee draft. -- "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 13 05:08PM [Please do not mail me a copy of your followup] jacob@jacob.remcomp.fr spake the secret code >[...] c++ prpgrammers should not use defines. Not for named integral constants. There are still some valid uses of preprocessor macros and where appropriate I use them. Named integral constants is not one of those valid use cases. You've created a nice straw-man argument that you've successfully demolished. Congratulations! You've achieved absolutely nothing. -- "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 13 05:09PM [Please do not mail me a copy of your followup] jacob@jacob.remcomp.fr spake the secret code >What an insult! Waaaaaaaah. becuz my feels. -- "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 13 05:20PM [Please do not mail me a copy of your followup] jacob@jacob.remcomp.fr spake the secret code >Note that I am not arguing against the use of enum for constants. What I >really do not like is the implicit pejorative use of the "C programmer" >here. If you're programming in C++, you should use C++ idioms, not C idioms. You can program in C if you want to, I don't care. Every time some Java programmer or C# programmer tells me how shitty C++ code is, I ask them to show me the code. THEY SHOW ME C CODE. It will be full of buggy C-style string manipulation, control flow that is a giant mess because of the obsession with avoiding exceptions in the name of "efficiency" but instead causing the main path of the code to be completely obscured by all the manual checking of error codes and in-line error handling (exceptions are considered de jure in Java/C#), and many other horrible habits. Yes, it can be argued that some of these habits appear in programmers working in any language. Bad control flow structure and long methods or classes is certainly something I've seen often in C# and Java code. However, there is no denying that there is something about the profusion of examples of C code on the net and "C++" code on the net that is really C-style programming masquerading as C++ programming that gives some credence to the point made by C#/Java advocates. Programming in C is demonstrably error-prone and verbose compared to doing the same thing in C++. Yet there are certain aspects of C that are desirable: its execution model maps directly to the actual hardware that we use and it being the defacto binary API for most operating systems. C++ is really different from other languages with it's philosophy of "you don't pay for what you don't use". In Java or C# you don't really have that option. There's a price for admission to the language that C++ or C just doesn't have. When you bring your C coding habits to C++, you bring with you all the same problems that people have with C. No wonder people bitch that C++ is a horrible language and they prefer Java/C# over it when every time some "C++ programmer" creates some code on their team, they create it with C style programming habits and all the weaknesses that brings along with it. I don't care if you want to program in C. If you want to program in C++, embrace C++ and the mechanisms it has that were created based on the experience of the shortcomings of C. Using const and enum are just two tiny examples of where C++ took advantage of the weakness of C based on actual usage of C and improved upon it. These improvements are so universally acknowledged that C itself incorporated those ideas back into the C standard from C++. The very fact that modern C includes enum and const is proving my point and making you look silly by railing against me for objecting to using #define for named integral constants. -- "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> |
| scott@slp53.sl.home (Scott Lurndal): Nov 13 05:26PM >Modern C has enums and const integers as well, so even in C there is no >excuse for using the preprocessor for named constants. See the C11 ISO >standard; I consulted the April 12, 2011 committee draft. As has been pointed out to you repeatedly, not everyone can take advantage of C11 and C++14. Nor do all real-word projects limit themselves to a single language - it is not uncommon to mix C and C++. Use what is necessary for the project and don't be concerned with "language purity". |
| JiiPee <no@notvalid.com>: Nov 13 06:03PM On 13/11/2015 09:54, jacobnavia wrote: > Note that I am not arguing against the use of enum for constants. What > I really do not like is the implicit pejorative use of the "C > programmer" here. I guess people mean more like "C programmer doing C++ code with C-style"...thus mixing styles. I guess what most here want is that C++ code is done using C++ styles. But if its a C-code, then its a different matter, I guess all agree with that. |
| JiiPee <no@notvalid.com>: Nov 13 06:17PM On 13/11/2015 08:36, jacobnavia wrote: >> programmers. You can do better with C++. > I do not understand the need of C++ people to insult people that use > other languages. I think, C language should normally only be used where there is no other options, or is proven that its more efficient in something. Like its true that a class takes more space than a POD. So if there is very little memory, then maybe C is the only option and C++ programmer should also use it. But I do not see why some windows program would be done with C, as C++ makes it easier. |
| Paul <pepstein5@gmail.com>: Nov 13 05:20AM -0800 Below is a standard textbook example of overloading the [] operator based on const. However, it seems to me that both functions act as const member functions. The function with signature object& operator[](int index) seems (to me) that it should also be const. After all, it doesn't change any member objects. However, we get a compile error when we make both of these functions const (i.e by writing object& operator[](int index) const) Why can't we make both of these functions const member functions -- since both of them don't change any member objects? The call would still be unambiguous since the version would depend on the constness of the called object. Thank you for your help. Paul class object{ public: object& operator[](int index) { return objArray[index]; } const object& operator[](int index) const { return objArray[index]; } private: object* objArray; }; |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Nov 13 02:39PM +0100 On 11/13/2015 2:20 PM, Paul wrote: > Why can't we make both of these functions const member > functions -- since both of them don't change any member > objects? The compiler has already told you why. Just read its error message. Cheers & hth., - Alf |
| asetofsymbols@gmail.com: Nov 13 05:42AM -0800 For me, not for C++: Const is *not* to refer to a variable but has to refer of memory that variable occupy So references and names are constant if refer memory one can read only, and can not write. |
| Wouter van Ooijen <wouter@voti.nl>: Nov 13 02:45PM +0100 Op 13-Nov-15 om 2:20 PM schreef Paul: > private: > object* objArray; > }; The compiler is a bit more clever than just looking at the code: the first version can potentially be used by a *caller* to change the object: a[ i ] = b; More formally, in the first version, you are (in the return statement) trying to convert a const object to a non-const reference, which is not allowed. It is as if your code reads const int i = 5; int &r = i; // error! Wouter |
| Victor Bazarov <v.bazarov@comcast.invalid>: Nov 13 08:47AM -0500 On 11/13/2015 8:20 AM, Paul wrote: > } > private: > object* objArray; Did you intend class 'object' to contain a pointer to an array of data of the same type? Or is it merely for the sake of example? > }; While neither operator changes the contents of the object itself (the pointer stays as it is), the logic suggests that the contents of memory pointed to by the member (objArray) for an object declared 'const' are not supposed to change either since they are *perceived* as the "contents" (provided that the memory is somehow maintained by the object itself and thus the *full responsibility* of the object). To prevent the contents of the memory to which 'objArray' member points, from being deliberately changed, the 'const' member function returns a reference to const, while a non-const member function returns a reference to a non-const object. V -- I do not respond to top-posted replies, please don't ask |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 13 06:10PM > are constant if refer memory > one can read only, and can not > write. C++ supports both physical constness and logical constness and I think you are claiming that you should not use logical constness in C++ which is of course total nonsense. Why support logical constness? Because it allows you to define an interface that allows or disallows object mutation by different clients. It ensures that an object will not change underfoot when performing some sequence of steps and arguably can form part of a class's invariant. I use logical constness a lot more than physical constness in C++ which I suspect is the same for most C++ professionals. /Flibble |
| scott@slp53.sl.home (Scott Lurndal): Nov 13 01:50PM >On Wednesday, November 11, 2015 at 4:13:57 PM UTC-6, gwowen wrote: >Please don't swear here. Mind your own business. |
| Daniel <danielaparker@gmail.com>: Nov 13 07:07AM -0800 On Thursday, November 12, 2015 at 5:17:05 PM UTC-5, Mr Flibble wrote: > > 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? Yes, but that doesn't apply to my argument. To make my point, it is enough to show that there exist members of the C++ community that don't accept your narrow definition of abstract interface, that your's is not a universal understanding of the term within C++ (you haven't been messin' around in .net land lately, have you?) Do you know about the fallacy of posting too soon after consuming a big plate of sausages? Daniel |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 13 06:01PM On 13/11/2015 15:07, Daniel wrote: >> I don't care what Herb Sutter thinks. Have you ever heard of the appeal >> to authority logical fallacy? > Yes, but that doesn't apply to my argument. To make my point, it is enough to show that there exist members of the C++ community that don't accept your narrow definition of abstract interface, that your's is not a universal understanding of the term within C++ (you haven't been messin' around in .net land lately, have you?) You did appeal to a perceived authority but your argument was fallacious for other reasons. In C++ an interface is a type of abstract base class (i.e. a subset) that contains no class invariant and only pure virtual functions (or trivial helper functions that call the pure virtual functions). Advocating that all virtual functions must be private is at odds with interfaces and is therefore idiotic. > Do you know about the fallacy of posting too soon after consuming a big plate of sausages? How childish. /Flibble P.S. Sausages. |
| Reinhardt Behm <rbehm@hushmail.com>: Nov 14 01:16AM +0800 Daniel wrote: > It's an interesting way of framing an argument : that believing without > evidence is a virtue. > Daniel Only topped by believing against evidence. -- Reinhardt |
| Christopher Pisz <nospam@notanaddress.com>: Nov 12 07:06PM -0600 On 11/8/2015 8:29 AM, Stefan Ram wrote: > ::std::cout << isequal( "ab", "ac" )<< '\n'; > ::std::cout << isequal( "a", "" )<< '\n'; > ::std::cout << isequal( "", "a" )<< '\n'; } #include <iostream> #include <string> int main { std::string one("one"); std::string two("two"); if( one == two ) { std::cout << "Comparing strings with if else\n"; } else { // Especially, when they are already using the standard library anyway std::cout << "Why do people try to do things that are already done?\n"; } } -- I have chosen to troll filter/ignore all subthreads containing the words: "Rick C. Hodgins", "Flibble", and "Islam" So, I won't be able to see or respond to any such messages --- |
| "Öö Tiib" <ootiib@hot.ee>: Nov 13 01:03AM -0800 On Friday, 13 November 2015 03:06:46 UTC+2, Christopher Pisz wrote: > std::cout << "Why do people try to do things that are already done?\n"; > } > } Was it question or rhetoric question? I try to answer it anyway. :D 0) OP's reason "today I want to do it the LISP way!" you already quoted. 1) 'std::string' is incorrect. 1.a) Special 'std::basic_string<something_else_but_char>' is tricky to make. 2) 'icu::UnicodeString' is heavyweight: http://icu-project.org/apiref/icu4c/classicu_1_1UnicodeString.html 2.a) Packaging ICU is tricky: http://userguide.icu-project.org/packaging 3) NIH policy. We do not release software that is "not invented here"! etc. So people again roll their own 'ihibb::string' ("invented-here-in-bamboo-bush") text processing facilities. |
| 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