Just another C vs C+ vs C++ debate

This is a discussion on Just another C vs C+ vs C++ debate within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Mod's note: split from here: http://cboard.cprogramming.com/showt...872#post824872 Then you need more experience with C++, clearly. C++ isn't a "shallow" C. It ...

  1. #1
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,434

    Just another C vs C+ vs C++ debate

    Mod's note: split from here: http://cboard.cprogramming.com/showt...872#post824872

    Then you need more experience with C++, clearly. C++ isn't a "shallow" C. It supports much more high-level and less mind-boggling ways to do things.
    And don't talk about overhead in containers. Did you try them? Sometimes, they are even better than your "homebrew" solution.
    In fact, C++ will get a number of more features in the coming standard that can make it faster than C in some circumstances.

    Furthermore, your insistence of "C" makes you a bad modern programmer, since the point of C++ is to use pre-defined, existing solutions to quickly achieve your goal with less time spent debugging and thinking. And it's also safer.
    Furthermore, since the book is supposed to teach C++, it's a bad book, because it does not teach C++, it teaches "C+".
    Last edited by CornedBee; 01-11-2009 at 11:17 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #2
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,627
    Eh, let's leave the defences to people who can substantiate their claims.

    Quote Originally Posted by Elysia View Post
    Then you need more experience with C++, clearly. C++ isn't a "shallow" C. It supports much more high-level and less mind-boggling ways to do things.
    C is only mind boggling if you do not understand simple things like functional decomposition, which is key to procedural programming. Unless your claim is that procedural programming itself is mind boggling. In which case I agree, since it is natural and we humans take this method for granted it takes time to understand in the same way it took time to learn that solving algebra equations in a series of steps. But that doesn't make C++'s learning curve any flatter.

    Quote Originally Posted by Elysia
    And don't talk about overhead in containers. Did you try them?
    But you must talk about overhead in the containers at least some of the time. I have you on record saying that functors means overhead, and functors are important in regular use of the STL. Unless you think that using containers make the stuff in <algorithm> faster....

    Quote Originally Posted by Elysia
    In fact, C++ will get a number of more features in the coming standard that can make it faster than C in some circumstances.
    I'd like to see you support this claim.

    Quote Originally Posted by Elysia
    Furthermore, your insistence of "C" makes you a bad modern programmer, since the point of C++ is to use pre-defined, existing solutions to quickly achieve your goal with less time spent debugging and thinking. And it's also safer.
    Furthermore, since the book is supposed to teach C++, it's a bad book, because it does not teach C++, it teaches "C+".
    But there are pre-defined, existing C libraries that can help one quickly achieve their goals with minimal debugging. If C++ makes programming easier because you can spend less time thinking, than that's probably a benefit by detraction. C++ in no way mitigates the time you must spend to get familiar with it, and the time you must spend to design programs in whole or in part. C++ only can make the implementation faster and only marginally so, depending on the specific problem and the bugs you have to fix.

    C++ is lucky that it has a standard library, but that was not always the case and many authors focus on teaching core concepts rather than the nooks and crannies of the STL. Many author's view this as a separate topic, and a companion text on the STL is often the best resource. A common gripe is when a C++ book does an outright faulty job of teaching OOP (or ignores the subject completely) when they talk about classes. It makes it impossible to use the STL, because pupils will not understand how data can be componentized with operations.

    I don't mean to defend the author's work, but I don't see how these claims are any argument against the book. The author doing a poor job does not mean that you need to argue C v. C++ at all.

    Like I said, leave the defenses to those who can substantiate their claims.

  3. #3
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,434
    Quote Originally Posted by whiteflags View Post
    C is only mind boggling if you do not understand simple things like functional decomposition, which is key to procedural programming. Unless your claim is that procedural programming itself is mind boggling. In which case I agree, since it is natural and we humans take this method for granted it takes time to understand in the same way it took time to learn that solving algebra equations in a series of steps. But that doesn't make C++'s learning curve any flatter.
    As much as may hate to admit it, but remembering formatting options, flags, etc is harder than remembering functions, or nothing at all.
    To print an integer in C:
    Code:
    printf("%i", myint);
    In C++:
    Code:
    std::cout << myint;
    The passings of many levels of pointers in many cases is another example that C++ somewhat avoids through containers and references.

    But you must talk about overhead in the containers at least some of the time. I have you on record saying that functors means overhead, and functors are important in regular use of the STL. Unless you think that using containers make the stuff in <algorithm> faster....
    Absolutely, but as you say, don't dismiss the containers before you've actually tried them! Usually speed is faster or negligible even with the overhead, so sometimes the overhead is justified, as well.
    As well as debating the easiness of using a container vs doing it manually.

    I'd like to see you support this claim.
    Oh, I see I also slightly misworded the reply there. I meant
    In fact, C++ will get a number of more features in the coming standard that might make it faster than C in some circumstances.
    And I am, of course, referring to move constructors and enhancements in template programming, as well as more usage of compile-time code.

    But there are pre-defined, existing C libraries that can help one quickly achieve their goals with minimal debugging. If C++ makes programming easier because you can spend less time thinking, than that's probably a benefit by detraction. C++ in no way mitigates the time you must spend to get familiar with it, and the time you must spend to design programs in whole or in part. C++ only can make the implementation faster and only marginally so, depending on the specific problem and the bugs you have to fix.
    I was thinking of vector, smart pointers, certain algorithms, etc.
    Instead of doing it manually which is more dangerous and more time consuming, it saves time.

    I don't mean to defend the author's work, but I don't see how these claims are any argument against the book. The author doing a poor job does not mean that you need to argue C v. C++ at all.

    Like I said, leave the defenses to those who can substantiate their claims.
    Oh no, you misunderstand. This is not a C vs C++ debate, this is a "C+" vs C++ debate.
    The poster I replied to is typically stuck in C thinking when using C++, which is not a good thing™.
    If you are going to learn and/or use C++, then you should by all means do it properly.
    No using strcpy, malloc, fopen, fread, etc, but using C++ facilities.
    This was my message, and that C++ is like the sun is to the moon compared to C.
    Different languages, and one must adapt. And once one does, that one will find it much easier to do trivial tasks, simply because C++ is a more modern language.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,627

    Thumbs down

    Quote Originally Posted by Elysia View Post
    As much as may hate to admit it, but remembering formatting options, flags, etc.
    I don't think your foibles have any pertinence to the subject.

    Absolutely, but as you say, don't dismiss the containers before you've actually tried them! Usually speed is faster or negligible even with the overhead, so sometimes the overhead is justified, as well.
    As well as debating the easiness of using a container vs doing it manually.
    I'm not debating this but you seem to have a mental block where I discussed C libraries. I don't think performance concerns are one reason why a pupil studies one language over another.

    Quote Originally Posted by Elysia
    Oh, I see I also slightly misworded the reply there. I meant
    Whatever you meant does not deter my interest in your defense of the claim, but I'm seeking empirical evidence regarding which new features improve the performance of C++ over C. PM me about it when you come up with something substantial.

    I was thinking of vector, smart pointers, certain algorithms, etc.
    Instead of doing it manually which is more dangerous and more time consuming, it saves time.
    Using a C library is in no way "doing it manually" and you seem to not understand how this falls under my earlier comment about implementation details. You mentioned that with C++ "the programmer spends less time debugging and thinking". About what is left unstated. In the same way that a C++ library helps the programmer spend less time thinking and debugging so can a C library. The design phase of a program, which also applies to the context of your argument, is no way hurried by either language.

    Quote Originally Posted by Elysia
    Oh no, you misunderstand. This is not a C vs C++ debate, this is a "C+" vs C++ debate.
    I did not understand how some of your arguments were applicable, is that ok with you?

  5. #5
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,434
    Quote Originally Posted by whiteflags View Post
    I don't think your foibles have any pertinence to the subject.
    And I don't think what works for you works just as well for any other. There is a reason why some languages are more popular than others.
    But w/e.

    I'm not debating this but you seem to have a mental block where I discussed C libraries. I don't think performance concerns are one reason why a pupil studies one language over another.
    I quote the original poster:
    Quote Originally Posted by coletek View Post
    Ok, well I see you points. But as a C coder, I only use C++ when I really need a O-O arch. When I use C++ I still use C style coding methods. I personally don't see the point in the overhead of using some C++ stuff (eg. string wstring) when it can be done in C (eg. char). Another example is iostream (what is wrong with printf, scanf).

    From my point of view, C++ is only good for its ability to handle O-O for your large task at hand. In any other case it should be just C.

    So based on my above comments I see the book as good. I just read the ACCU comments and while I agree with he's comments I still see it as a good book. Probably more so, because of the great layout and method to ref things so easy - something I've found hard to find in any books.
    This poster seems to like doing things manually, which I originally objected against. C, by default, does not have facilities for these kinds of things. And many C coders do things manually, from what I have witnessed from comments on the board.

    Whatever you meant does not deter my interest in your defense of the claim, but I'm seeking empirical evidence regarding which new features improve the performance of C++ over C. PM me about it when you come up with something substantial.
    I am not "in" these kinds of things, but if you would just not be so stubborn and look at the features presented before you, maybe you would understand that YES, maybe if done right, it might provide improvements over equivalent C code. And I say MIGHT and MAYBE, not that it WILL.
    Believe me or not, I seriously do not care. Take it as you will.
    I am, however, mentioning it to the original poster that C++ has some powerful facilities that rivals C or can even be more efficient, negating the "always use C within C++" claim or approach the OP has.

    Using a C library is in no way "doing it manually" and you seem to not understand how this falls under my earlier comment about implementation details. You mentioned that with C++ "the programmer spends less time debugging and thinking". About what is left unstated. In the same way that a C++ library helps the programmer spend less time thinking and debugging so can a C library. The design phase of a program, which also applies to the context of your argument, is no way hurried by either language.
    The design time for the library is irrelevant. I do not know if there facilities for these things in C (as external libraries, not associated with the standard), but from what I would see, most C programmers do these things manually.
    The OP is probably included. And I wanted to also express why this is usually a bad idea.

    I did not understand how some of your arguments were applicable, is that ok with you?
    If these comments still make you fail to understand, then leave it at that. I will not be trying to explain further to such a negative member who has a grudge towards me.

    And btw, would it not make sense for the original post to be included? Otherwise the context for the reply disappears.
    I was trying to explain to a coder who uses C++ with C-style approach why it is not good or bad, and I get slammed for it. Very fair.
    And lastly, I have a request. If these posts are not to be associated with the post it was originally meant to reply to, to reach out its purpose, then there is no point at all in keeping them. I do not NOT want this to be seen as another debate "C vs C+ vs C++". If that is it viewed as, and / or will be viewed as, then I request that the topic be deleted along with its contents. It would have failed to serve its purpose.
    Last edited by Elysia; 01-11-2009 at 11:56 AM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #6
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,627
    We're just not communicating, so I don't see a point in continuing either.

    I do have something to talk to you about though, so expect a PM from me shortly.

  7. #7
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by Elysia View Post
    Furthermore, your insistence of "C" makes you a bad modern programmer, since the point of C++ is to use pre-defined, existing solutions to quickly achieve your goal with less time spent debugging and thinking. And it's also safer.
    Furthermore, since the book is supposed to teach C++, it's a bad book, because it does not teach C++, it teaches "C+".
    You're being subjective... again. You just have to cope with that - different people approach programming differently - object-oriented programming and all those extra features are not better than normal procedural C style, they're just different. It's a matter of taste.

    And the safety you mention, it's more like fool-proof than safe, and I'm not a fool, so I don't see an advantage there.
    Last edited by maxorator; 01-11-2009 at 02:47 PM.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  8. #8
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,434
    But is it good to use C++ programming using C-style techniques?
    And is it good to read or recommend a book that uses C-style techniques, but teaches C++ programming?
    I know I'm being subjective. I can't help it. I try not to be, but it's like it's buried in my DNA or something.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by Elysia View Post
    But is it good to use C++ programming using C-style techniques?
    And is it good to read or recommend a book that uses C-style techniques, but teaches C++ programming?
    I know I'm being subjective. I can't help it. I try not to be, but it's like it's buried in my DNA or something.
    A good book teaches both. And yes, it doesn't matter which style you use (as long as your employer is fine with it). I find some C++ features handy, but not all of them - so I don't use all of them, but that doesn't make me a "C+" programmer, since a C feature is also a C++ feature and should not be treated as it is not. It's not like the objective of C++ programming is to use as much C++-only features as possible.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  10. #10
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,434
    Ah, so it IS a subjective matter, then.
    I know some have been called a "C+" programmer for mostly sticking to C, mixing them with C++.
    And no, I don't believe a book that teaches this is a good book, and neither did those in the Book thread.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by Elysia View Post
    Ah, so it IS a subjective matter, then.
    I know some have been called a "C+" programmer for mostly sticking to C, mixing them with C++.
    And no, I don't believe a book that teaches this is a good book, and neither did those in the Book thread.
    Like I said, if a book teaches only this, it is not a good C++ book, because a book should introduce all major features. Also I don't consider a book that teaches only the so-called C++ style to be good. Like I already said, a C++ book should teach both styles.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  12. #12
    Ugly C Lover audinue's Avatar
    Join Date
    Jun 2008
    Location
    Indonesia
    Posts
    489
    Just want to remind you guys,...

    Whenever you use those C++-style programming, cout and cin stuff, your executable file size will be larger.

    And in my opinion, that's very inefficient.

    That's why I'm still using what you called C+ style programming.
    Just GET it OFF out my mind!!

  13. #13
    Reverse Engineer maxorator's Avatar
    Join Date
    Aug 2005
    Location
    Estonia
    Posts
    2,318
    Quote Originally Posted by audinue View Post
    Just want to remind you guys,...

    Whenever you use those C++-style programming, cout and cin stuff, your executeable file size will be larger.

    And in my opinion, that's very inefficient.

    That's why I'm still using what you called C+ style programming.
    Ugh. That's not a good argument...

    And it doesn't make a difference on larger projects anyway.
    "The Internet treats censorship as damage and routes around it." - John Gilmore

  14. #14
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,423
    Quote Originally Posted by maxorator
    Like I said, if a book teaches only this, it is not a good C++ book, because a book should introduce all major features.
    As Dewhurst quoted Mark Twain in the preface of C++ Common Knowledge, "a successful book is not made of what is in it, but what is left out of it". Remember, just as you rightly pointed out that "it's not like the objective of C++ programming is to use as much C++-only features as possible", an introductory book's author might not have "be the be all and end all tome of C++ programming" as the goal. (It would be tough to fight with Stroustrup's TC++PL anyway )

    My objection to Overland's book on this point is that Overland chooses to leave out the wrong features by ignoring many of the commonly used components of the C++ standard library.

    Quote Originally Posted by maxorator
    Also I don't consider a book that teaches only the so-called C++ style to be good.
    The modern "C++ style", if we could call it one, is multiparadigm programming. Consequently, it is a superset of the "C style" of procedural programming.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #15
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,434
    Quote Originally Posted by audinue View Post
    Just want to remind you guys,...

    Whenever you use those C++-style programming, cout and cin stuff, your executable file size will be larger.

    And in my opinion, that's very inefficient.

    That's why I'm still using what you called C+ style programming.
    Proof, please.
    It is known that templates can cause bloat, but may not necessarily do so, and it's still a very, very poor argument.
    People's hard drives today are so big anyway that size hardly matters, mostly.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Who Won The Debate, and Why?
    By B0bDole in forum A Brief History of Cprogramming.com
    Replies: 19
    Last Post: 10-10-2004, 04:26 AM
  2. Oil debate continued
    By axon in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 07-24-2004, 02:22 AM
  3. Moderatorship Debate: Civix and Fordy.
    By civix in forum A Brief History of Cprogramming.com
    Replies: 9
    Last Post: 09-06-2002, 11:55 PM
  4. Ethics & Programming Debate
    By cozman in forum A Brief History of Cprogramming.com
    Replies: 19
    Last Post: 10-09-2001, 04:59 PM
  5. compiler/editor/ide debate
    By cozman in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 08-12-2001, 06:01 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21