Comments on: C for C++ programmers why stop at C++. Go on to C#. If C++ is the Hammer, C# is an hydraulic hammer. why stop at C++. Go on to C#. If C++ is the Hammer, C# is an hydraulic hammer.

]]>
By: chris/2011/02/09/c-for-c-programmers/#comment-322 chris Fri, 11 Feb 2011 11:53:32 +0000 Enumeration *constants* have type int.An enumerated type is compatible with an implementation-defined integer type.So, for example, afterenum my_enum { ME_X };sizeof(enum my_enum) may equal sizeof(char), that is, 1, if the implementation defines (and documents) it like that. All the while "sizeof ME_X" will equal sizeof(int). Enumeration *constants* have type int.An enumerated type is compatible with an implementation-defined integer type.So, for example, afterenum my_enum { ME_X };sizeof(enum my_enum) may equal sizeof(char), that is, 1, if the implementation defines (and documents) it like that. All the while “sizeof ME_X” will equal sizeof(int).

]]>
By: lacos/2011/02/09/c-for-c-programmers/#comment-320 lacos Thu, 10 Feb 2011 20:45:36 +0000 I can totally understand people advocating DoD designs and clean interfaces and all those things as reasons to use C, but why not just use C++ without objects. Take C++, throw away objects, operator overloading, templates (although i wouldn't, templates are awesome when used properly), and #define virtual to a funny or insulting error message of your choice. Now you're left with C, only with far better type safety, type based alias analysis (yes, i really just said that, but I write compilers and i know how much this helps optimize code), function overriding, and you can still #include all the other files in your code base without having lots of #ifdef __cplusplus everywhere which you would maybe need if you really were compiling C.I'm not saying don't code in C, i'm just saying that coding in that style, in C, but in a C++ compiler will likely be a far better idea. At the very least you are likely to have more portable code because Visual Studio has far better C++ support than C. I can totally understand people advocating DoD designs and clean interfaces and all those things as reasons to use C, but why not just use C++ without objects. Take C++, throw away objects, operator overloading, templates (although i wouldn’t, templates are awesome when used properly), and #define virtual to a funny or insulting error message of your choice. Now you’re left with C, only with far better type safety, type based alias analysis (yes, i really just said that, but I write compilers and i know how much this helps optimize code), function overriding, and you can still #include all the other files in your code base without having lots of #ifdef __cplusplus everywhere which you would maybe need if you really were compiling C.I’m not saying don’t code in C, i’m just saying that coding in that style, in C, but in a C++ compiler will likely be a far better idea. At the very least you are likely to have more portable code because Visual Studio has far better C++ support than C.

]]>
By: petecubano/2011/02/09/c-for-c-programmers/#comment-319 petecubano Thu, 10 Feb 2011 20:32:35 +0000 I totally agree with your post. I have done C++ for 13 years or so and still do it professionally but I have rediscovered the beauty of C. Doing a sort of hobby DOD 2D game engine in C now, a rewrite from a C++ OO engine. It is quite a lot of fun and to my amazement it is not really much more difficult or require any significant more amount of code. Maybe even less. I tried to detail here why I think the mantra “C++ is a better C” is wrong: I am not arguing that C is a better language than C++. Collections etc is awkward to do in C compared to C++. What changed these last 10 years or so is that I don’t believe in single language application development. I would do my high level stuff in lua, scheme, python and so on. Where those languages are not suited C usually fits in nicely. In a two language development environment I think C++ is way too much mental overload. C++ is a huge language. You can probably keep all of C and Lua in your head with a fraction of the effort of keeping C++ in your head. The beauty of C is that has a very well defined and clear focus. It is so clear what it doesn’t do well that you are forced into thinking about multi-language development and using tools. C++ is so big and powerful that it tricks you into thinking it is a silver bullet that can solve all problems.

]]>
By: Admiral Firebeard/2011/02/09/c-for-c-programmers/#comment-316 Admiral Firebeard Thu, 10 Feb 2011 14:13:33 +0000 Looks like your blog also mangles comments. I said that C++ does not do message passing. It calls functions, much like C - except that virtual functions take an additional table lookup. Looks like your blog also mangles comments. I said that C++ does not do message passing. It calls functions, much like C – except that virtual functions take an additional table lookup.

]]>
By: unwesen/2011/02/09/c-for-c-programmers/#comment-314 unwesen Thu, 10 Feb 2011 12:45:13 +0000 I'm actually not sure how I would structure game code these days without any form of polymorphism.. manually creating jump tables for every type of game object sounds like a drag... I know engine code lends itself to C fine, but I think it would take me a while to get my C legs again if I had to do game code in C. I’m actually not sure how I would structure game code these days without any form of polymorphism.. manually creating jump tables for every type of game object sounds like a drag… I know engine code lends itself to C fine, but I think it would take me a while to get my C legs again if I had to do game code in C.

]]>
By: James Podesta/2011/02/09/c-for-c-programmers/#comment-312 James Podesta Thu, 10 Feb 2011 11:09:28 +0000 @James Podesta I'm the opposite in some ways with constructors, especially when it comes to memory management - in my view, constructors/destructions should be fail resistant, so memory management should never be in them! Iv'e lost count of how many hours I have wasted trying to discover why things were failing etc and it turned out to be a constructor/destructor that failed, without any checks/state being passed up the chain for the callee to handle it.Still, it obviously means that if you fail to call Init/DeInit, it breaks horribly ;) And yeah, inheritance needs to be handled very strictly. @James Podesta I’m the opposite in some ways with constructors, especially when it comes to memory management – in my view, constructors/destructions should be fail resistant, so memory management should never be in them! Iv’e lost count of how many hours I have wasted trying to discover why things were failing etc and it turned out to be a constructor/destructor that failed, without any checks/state being passed up the chain for the callee to handle it.Still, it obviously means that if you fail to call Init/DeInit, it breaks horribly ;) And yeah, inheritance needs to be handled very strictly.

]]>
By: Jaymin Kessler/2011/02/09/c-for-c-programmers/#comment-310 Jaymin Kessler Thu, 10 Feb 2011 05:18:39 +0000 I will say, the one thing I would really miss using C is constructors and destructors. I had to work on Microsoft GameRoom recently, and all the emulator DLLs were in pure C with Init() and Deinit() functions instead of constructors. A long way down the track, some actual essential memory clean up work was added to the Deinit() method, but we soon found out most of the programmers had forgotten to call it. To make matters worse, they were still using Inheritance, but just not constructors/destructors, so often they weren't correctly calling Deinit() on their parents. This was never noticed when Deinit() did no actual work and so no-one realised there was a problem.Maybe they should have kept Constructors when they decided to throw them out 10 years before they were invented.. p.s. One thing worth noting with C++.. The features are viral. Once you start using any of it, you find you keep needing to use more and more of it for it to hold together as a language.p.p.s. I'm not advocating for or against C or C++ here. I generally use C++ myself but I respect anyone who chooses to stick with C. I'd love to try C again if I switched jobs to a place that only used C but I see changing languages as always a side-ways step. You gain some advantages, you lose others, but generally you can still get the job done. I will say, the one thing I would really miss using C is constructors and destructors. I had to work on Microsoft GameRoom recently, and all the emulator DLLs were in pure C with Init() and Deinit() functions instead of constructors. A long way down the track, some actual essential memory clean up work was added to the Deinit() method, but we soon found out most of the programmers had forgotten to call it. To make matters worse, they were still using Inheritance, but just not constructors/destructors, so often they weren’t correctly calling Deinit() on their parents. This was never noticed when Deinit() did no actual work and so no-one realised there was a problem.Maybe they should have kept Constructors when they decided to throw them out 10 years before they were invented.. p.s. One thing worth noting with C++.. The features are viral. Once you start using any of it, you find you keep needing to use more and more of it for it to hold together as a language.p.p.s. I’m not advocating for or against C or C++ here. I generally use C++ myself but I respect anyone who chooses to stick with C. I’d love to try C again if I switched jobs to a place that only used C but I see changing languages as always a side-ways step. You gain some advantages, you lose others, but generally you can still get the job done.

]]>
By: James Podesta/2011/02/09/c-for-c-programmers/#comment-308 James Podesta Thu, 10 Feb 2011 00:30:10 +0000 This exemplifies the advice that it's better to be funny and right than just right. Great article. This exemplifies the advice that it’s better to be funny and right than just right. Great article.

]]>
By: LarryD/2011/02/09/c-for-c-programmers/#comment-306 LarryD Thu, 10 Feb 2011 00:23:15 +0000 It's a somewhat widely held misconception that DOD and OOP are mutually exclusive. You are taking that one step further and suggesting that DOD and C++ are also mutually exclusive. Data Oriented Design is a programming paradigm that emphasizes the importance of data organization and the impact of data layout on processing efficiency, and that's about it. I don't see how this can be in contrast with OOP let alone C++. Incorrect use of both can go against DOD principals and best practices but their use, merely and in and out of themselves, can't.I mostly think that these somewhat radical stances are the anti-thesis of 90s OOP FTW mentality and the two will soon cancel each other out for a more practical solution. It’s a somewhat widely held misconception that DOD and OOP are mutually exclusive. You are taking that one step further and suggesting that DOD and C++ are also mutually exclusive. Data Oriented Design is a programming paradigm that emphasizes the importance of data organization and the impact of data layout on processing efficiency, and that’s about it. I don’t see how this can be in contrast with OOP let alone C++. Incorrect use of both can go against DOD principals and best practices but their use, merely and in and out of themselves, can’t.I mostly think that these somewhat radical stances are the anti-thesis of 90s OOP FTW mentality and the two will soon cancel each other out for a more practical solution.

]]>
By: mmalex/2011/02/09/c-for-c-programmers/#comment-304 mmalex Wed, 09 Feb 2011 23:35:47 +0000 : loved the article. the off hand comment about using the pain to minimise virtual function calls lazy use and restricting to only required uses is spot on. In the end, the key point that grumpy would probably agree with is that focus on data as a paradigm shift is more important than C vs C++; that said, C makes it so much easier to make that focus, and C++ (especially for beginners) always does seem to be taught as ‘C with classes’, which means most C++ code is precisely crap.anyway, generic programming with templates with C++ is possible but the syntax is hardly nice – the parsing of templates means that every time the compiler sees a < it has to decide if its an operator or template argument -> slow compile times. SUCKS! etc

]]>
By: Dillon W./2011/02/09/c-for-c-programmers/#comment-303 Dillon W. Wed, 09 Feb 2011 23:21:31 +0000 re. generic programming, you just traded C++'s literally zero-overhead generic `std::sort` for `qsort` which in the general case can't inline calls to its comparer, and so suffers a noticeable overhead. For what gain? It's less generic *and* less performant. Yay, I guess.(And if you consider the hallmark of C++ to be virtual functions, then maybe you weren't doing C++ at all, but merely C-with-classes.)I really don't see the point in using C over C++. Being picky about which C++ features you use and which ones you leave out, sure, that makes sense. There is a lot of cruft in C++, and a lot of features that I'd avoid like the plague. But why throw away the genuine advantages as well? But when that is said there is a lot of value in sticking to a more narrow feature set, and in some cases, even going 100% C. re. generic programming, you just traded C++’s literally zero-overhead generic `std::sort` for `qsort` which in the general case can’t inline calls to its comparer, and so suffers a noticeable overhead. For what gain? It’s less generic *and* less performant. Yay, I guess.(And if you consider the hallmark of C++ to be virtual functions, then maybe you weren’t doing C++ at all, but merely C-with-classes.)I really don’t see the point in using C over C++. Being picky about which C++ features you use and which ones you leave out, sure, that makes sense. There is a lot of cruft in C++, and a lot of features that I’d avoid like the plague. But why throw away the genuine advantages as well? But when that is said there is a lot of value in sticking to a more narrow feature set, and in some cases, even going 100% C.

]]>