Like Tree32Likes

C++ vs C

This is a discussion on C++ vs C within the General Discussions forums, part of the Community Boards category; Does that mean that C++ is better as a language than Python? O_o 1): My own ability to develop programs ...

  1. #61
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,167
    Does that mean that C++ is better as a language than Python?
    O_o

    1): My own ability to develop programs in a given language is exactly as irrelevant to the query as your ability to develop programs in a given language.
    2): A languages "level", and especially relative "level", is unrelated to its expressiveness, power, or suitability for a particular purpose.

    Do you really think I'm saying "C++ is a better language than C because I develop faster with C++."?

    I develop faster with PEG. (Nope. That is not a typo. I use the same "markup" to express ordered rules of behavior. It is actually a pretty small change.) That doesn't make it better than any other language. (I think it is pretty much unsuitable for anything other than its intended purpose and maybe how I use it.) Granted, it isn't even a programing language, but conceptually all you'd need is an interpreter. That wouldn't make it better than C++, but boy would it be fast to use for new development.

    Soma

  2. #62
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,167
    /me goes to get another box of popcorn from the concession.
    Do you IRC or are you just being silly?

    [Edit]
    Well, I guess it is just as likely you don't spend any time at ##C++ or use a different name.
    [/Edit]

    Soma

  3. #63
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,437
    Sure, silly post in silly thread.
    Just like every other x vs. y thread has been, and any future x vs. y thread is going to be.
    stevesmithx likes this.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #64
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    4,167
    Sure, silly post in silly thread.
    Oki Doki Loki.

    I was a little upset that for all the times I drop in and out that you never, ever said "Hi". ;_;

    Soma

  5. #65
    TEIAM - problem solved
    Join Date
    Apr 2012
    Location
    Melbourne Australia
    Posts
    1,323
    Salem you need your 30000th post to be here.
    Fact - Beethoven wrote his first symphony in C

  6. #66
    Registered User
    Join Date
    Jun 2005
    Posts
    6,200
    Quote Originally Posted by Click_here View Post
    Salem you need your 30000th post to be here.
    I'm personally more interested in what will happen to the site when Salem posts his 32767th and 32768th posts
    Right 98% of the time, and don't care about the other 3%.

  7. #67
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,789
    Quote Originally Posted by grumpy View Post
    I'm personally more interested in what will happen to the site when Salem posts his 32767th and 32768th posts
    I think he will roll over and become a newb again!

  8. #68
    Registered User
    Join Date
    Oct 2006
    Posts
    2,292
    Quote Originally Posted by Neo1 View Post
    I would however like to see if there is a noticeable difference in compile time between some advanced piece of software written in C, and the same piece of software implemented using C++ with all the new C++0x extensions. But i guess they wouldn't be the same piece of software at all under those conditions, so the comparison wouldn't be very accurate anyways.
    they would certainly be different programs at that point. the relevant question is not how long the compiler takes to build the program. it's much more important how long it takes to write the code. I'd say that, given a task, and two programmers - one fluent in C, and the other in C++, with both programmers required to write their own code for anything not covered by the standard library, the C++ programmer will likely finish long before the C programmer. any extra time required to compile the code is irrelevant at this point, because even after building, the C++ programmer is still likely to have finished first.

  9. #69
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by Elkvis View Post
    they would certainly be different programs at that point. the relevant question is not how long the compiler takes to build the program. it's much more important how long it takes to write the code. I'd say that, given a task, and two programmers - one fluent in C, and the other in C++, with both programmers required to write their own code for anything not covered by the standard library, the C++ programmer will likely finish long before the C programmer. any extra time required to compile the code is irrelevant at this point, because even after building, the C++ programmer is still likely to have finished first.
    In my experience the compile time is mostly affected by the inclusion of lots of library headers (particularly STL headers), not because the C++ language is inherently slower to compile. This can happen in C as well -- just try including Windows.h in every single .c file in your project and see how long it takes to compile.

    A real comparison would be to take a medium sized C program (say, 10000 lines), tweak it so that it can be compiled as C++, then compare between the two.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  10. #70
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Build time is most certainly not irrelevant. There is the whole module effort going on right now, which is somewhat about avoiding the pitfalls of the preprocessor, but mostly about reducing compile time. There are companies that hire consultants for the specific purpose of reducing the build time of their product. The language Go was designed from the start to be extremely fast to compile.

    A program isn't built once. Even under the assumption that you write perfect code the first time, you will have multiple releases with additional features, and each of those needs to be compiled, possibly for multiple platforms. Of course, in the real world, you have far more compiling going on. You build several times to fix compile errors, or simply to check that there aren't any before you continue working. You fix bugs and recompile. You try something out. You add a test case.
    Then there's the nightly build that your company has (or should have). If your system allows it, there may be a continuous integration system that kicks off a build every time something is committed to the central repository.
    And don't forget the hidden builds. While you're typing in your IDE, it is struggling to keep up with you by parsing and reparsing your code so that it can mark compile errors and provide auto-completion information. How happy are you with the response time these features in Visual Studio compared to C#?

    There's a whole development method, test-driven development, that is really hard to do in C++ because it relies on a rapid edit-recompile-test cycle that breaks down once even an incremental build takes more than a few seconds.

    When Microsoft recently did a survey of what users want from their C++ compiler, improved compilation speed ranked at the top together with standards conformance.

    So yes, build time is important.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  11. #71
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by CornedBee View Post
    There's a whole development method, test-driven development, that is really hard to do in C++ because it relies on a rapid edit-recompile-test cycle that breaks down once even an incremental build takes more than a few seconds.
    If your TDD workflow involves recompiling the entire product at every step I think you're doing something wrong. If we're talking unit tests, then you only need to compile enough code to test that single unit, and a unit should not be large. (And if you have to compile more that just the unit you are testing in order to test it, maybe something is wrong with your architecture). For integration tests, in my experience a good integration test takes long enough to write (multiple hours) that even a one-hour build time might be acceptable (though of course you'd rather it take less time).

    One of the aspects of TDD is that it can drive your architecture indirectly, in exactly such ways.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  12. #72
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    If your TDD workflow involves recompiling the entire product at every step I think you're doing something wrong.
    As I said, I've often enough seen incremental builds (i.e. recompiling only what changed) take too long. And if you change your unit test system to make the compiles even more minimal (say, by putting every single unit test into its own project, and split the headers even finer) the architectural overhead may just become too great. (Also, the process startup overhead when you do a full test run.)
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #73
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by CornedBee View Post
    As I said, I've often enough seen incremental builds (i.e. recompiling only what changed) take too long. And if you change your unit test system to make the compiles even more minimal (say, by putting every single unit test into its own project, and split the headers even finer) the architectural overhead may just become too great. (Also, the process startup overhead when you do a full test run.)
    A few observations: Changes to widely-used header files suck for incremental builds. That hurts C just as much as it does C++, but perhaps C++ architectures are more prone to it (I'm not sure if anyone has tried to measure it). Also, the compiler may be doing significant code generation at link time due to whole-program optimization which means it's actually recompiling many many files on each link, not just what has changed (and for development it's usually better to turn that off for just this reason).

    But yeah, build time can be a factor. However, that has more to do with architecture than any inherent difference between C and C++, I think.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  14. #74
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    C++ headers tend to be heavier due to templates. Check out Doug Gregor's talk on Modules at the LLVM Developer's Conference for some numbers.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #75
    Registered User
    Join Date
    Jun 2005
    Posts
    6,200
    Quote Originally Posted by brewbuck View Post
    That hurts C just as much as it does C++, but perhaps C++ architectures are more prone to it (I'm not sure if anyone has tried to measure it).
    It's not so much C++ architectures, as it is particular architectures that are easy to overuse in C++ and difficult in C (or vice versa). An example would be excessive use of inheritance, which always causes a compile-time dependency.

    I'm not sure how much work has gone into measuring such things though, except in particular use cases.

    Template instantiation (which is a C++ feature, not C) can increase compile times. But it is debatable what the difference in compile times would be between "instantiate a template for a hundred types" and the rough C equivalent of "compile a set of one hundred inline functions that do the same things on one hundred different types". The differences, if something like that is being done, come down to quality of implementation issues between compilers, rather than being specific to C or C++.

    Quote Originally Posted by brewbuck View Post
    Also, the compiler may be doing significant code generation at link time due to whole-program optimization which means it's actually recompiling many many files on each link, not just what has changed (and for development it's usually better to turn that off for just this reason).
    Compilers don't typically do significant code generation at link time. There are a few "smart linkers" that do, but not compilers. I've come across a couple of really neat smart linkers associated with (proprietary) C++ compilers, but have yet to come across such a smart linker associated with a pure C compiler.

    Quote Originally Posted by brewbuck View Post
    But yeah, build time can be a factor. However, that has more to do with architecture than any inherent difference between C and C++, I think.
    I certainly agree with you that architecture of the program or system being developed is more critical than the choice of language. However, some particular architectural techniques are better supported by one language or the other.

    Another factor is quality of implementation of individual compilers, and the vintage of those compilers. A lot of the laments about C++ overheads in comparison with C (eg exceptions) originated over a decade ago, when compiler technologies were less mature than they are now. Modern compilers are much less afflicted with such things, but the laments persist even when the justification for them is less than it was.

    There is a tendency of people stacking the odds when doing "case studies" when they compare programming languages. I've seen a number of "case studies" that used professionally-written C code with a rather dodgy C++ code to argue about the virtues of C, and others that used professionally written C++ code and a dodgy C code to argue about virtues of C++. (The same sort of thing is more common in debates between C++ and Java, but it also happens in debates between C and C++).
    Last edited by grumpy; 12-07-2012 at 01:57 PM.
    Right 98% of the time, and don't care about the other 3%.

Page 5 of 6 FirstFirst 123456 LastLast
Popular pages Recent additions subscribe to a feed

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