- Stackoverflow - a fascist web-site. - 1 Update
- using #define vs const int , in error codes - 5 Updates
- Idiots - 3 Updates
| Geoff <geoff@invalid.invalid>: Nov 13 03:03PM -0800 On Sun, 8 Nov 2015 06:54:14 -0800 (PST), Vlad from Moscow >Very often titles of questions do not reflect the contents and the meanings of the questions. >Many programmers incorrectly call any character array like a string. And in the case of the posted question, the questioner also has a problem with how strings are compared, hence his error of writing if(ckey==key). Clearly he has the wrong idea about how to compare strings, which is his INTENT as stated in the title of the topic but his implementation exposes errors in his comprehension. Your answer didn't correct those misconceptions but rather created more confusion. Hence the down-votes. A correct answer would have been to explain the concept of C strings being terminated in with null characters, sizing arrays for that concept and use the standard library functions to perform the string compares of properly sized, nul-terminated strings. |
| legalize+jeeves@mail.xmission.com (Richard): Nov 13 06:48PM [Please do not mail me a copy of your followup] no@notvalid.com spake the secret code >> 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. As I've said elsewhere: I don't care if you program in C. Please be honest with yourself and everyone else when you write C-style code: don't call it C++ code. Using the excuse that C++ is backwards compatible with C is just that -- an excuse for writing C code. As for the efficiency argument, it has been shown a bunch of times how C++ can produce more efficient code than C. Boost.Spirit's example of parsing integers faster than atoi is just one example. The reason C++ can achieve this is because C++ has a richer type system and more information about types means the compiler can reason more explicitly and expertly about how to treat those types. Inline functions and generic algorithms, const, references, move semantics, and many other features of modern C++ give the compiler many more opportunities for optimization and optimizations that can be applied over larger contexts. In the worst case, C++ is no less efficient than C. In the best case, C++ is more efficient than C. -- "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 06:54PM [Please do not mail me a copy of your followup] slp53@pacbell.net spake the secret code >As has been pointed out to you repeatedly, not everyone can take >advantage of C11 and C++14. enum and const have been in C++ since the beginning. They do not require C++14, C++11 or even C++03. I did a little bit of googling to find out when enums were formally added to the C language, but wikipedia and other articles didn't give a chronology. I'm willing to bet that enums appeared in C before C11 and even before officially appearing in the standard were widely supported in available implementations of C compilers such as gcc, MSVC, etc. >Nor do all real-word projects limit >themselves to a single language - it is not uncommon to mix C >and C++. Then you don't have a C++ code base. You have a C code base with some C++. Of course you are held down by your weakest common denominator. >Use what is necessary for the project and don't be concerned with >"language purity". Nice straw man. Nowhere have I ever advocated language purity. Only you have said that in response to my posts advocating habits that are driven by the pragmatic concerns of real-world programming. Avoid error-prone facilities and use facilities that are created explicitly to replace those that are error-prone with something that is less error-prone. -- "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 06:55PM [Please do not mail me a copy of your followup] slp53@pacbell.net spake the secret code >As has been pointed out to you repeatedly, not everyone can take >advantage of C11 and C++14. Also, you're moving the goal post here. Such restrictions were never mentioned in the original post where the question was posed in a general way. -- "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> |
| Ian Collins <ian-news@hotmail.com>: Nov 14 09:09AM +1300 Scott Lurndal wrote: > 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++. I think you missed the point. In both C and C++ a better alternative to #defines for error codes exists and has existed for decades: a simple enum. -- Ian Collins |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Nov 13 09:32PM legalize+jeeves@mail.xmission.com (Richard) writes: <snip> > I did a little bit of googling to find out when enums were formally > added to the C language, but wikipedia and other articles didn't give > a chronology. According to Dennis Ritchie: "During 1973-1980, the language grew a bit: the type structure gained unsigned, long, union, and enumeration types, and structures became nearly first-class objects (lacking only a notation for literals)."[1] enums are not in the first edition of "The C Programming Language" (1978) but were in many compilers shortly after, and they are there in the first ANSI standard of 1989. [1] This is from "The Development of the C Language" which is probably still available via Dennis Ritchie's Bell Labs/Lucent Technologies web pages, but it's moved about a bit and I can't find a URL at the moment. <snip> -- Ben. |
| Daniel <danielaparker@gmail.com>: Nov 13 10:27AM -0800 On Friday, November 13, 2015 at 1:01:56 PM UTC-5, Mr Flibble wrote: > 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. Source? |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Nov 13 06:44PM On 13/11/2015 18:27, Daniel wrote: >> functions). Advocating that all virtual functions must be private is at >> odds with interfaces and is therefore idiotic. > Source? HP Sauce or ketchup with my sausages. /Flibble |
| Daniel <danielaparker@gmail.com>: Nov 13 11:11AM -0800 On Friday, November 13, 2015 at 1:44:56 PM UTC-5, Mr Flibble wrote: > >> functions). > > Source? > HP Sauce or ketchup with my sausages. Fibble-fable nonsense! Daniel |
| 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