Is c++ a better c?

This is a discussion on Is c++ a better c? within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Originally posted by ammar BTW: I think if you are asking to determine what language you are going to learn, ...

  1. #16
    Registered User
    Join Date
    Feb 2003
    Posts
    3

    Smile

    Originally posted by ammar
    BTW: I think if you are asking to determine what language you are going to learn, you can simply learn both of them, because it's not difficult to learn one when you already know the other.
    I have nearly finished learning C. I wanted to know whether I needed to learn C++ as well.
    looks like i do so i am going to.


    Can you suggest any good book for C++. It dosen't have to be easy to understand but should be to the point.

  2. #17
    Just a Member ammar's Avatar
    Join Date
    Jun 2002
    Posts
    953
    Since you have a good backgroung in C, you can try a book called: C++ the programming language, by stroustrup( the one who designed and implemented the C++ programming language ), I think it's a good book for you.
    none...

  3. #18
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,786
    Originally posted by Polymorphic OOP
    I'd have to disagree with that to some extent. You can use the "C features" of C++ and get the same or better performance than of C (depending on the compiler). And when it comes to using member functions, it's potentially just as fast as passing the address of a structure in C. When it comes to virtual functions, you have to take into account the fact that in order to get similar functionality you'd have to either make your OWN vtable (which would give you most-likely the same, or less speed), or you'd have to set up enumerated values, etc.

    In actuality, c++'s "C features" are potentially just as fast and there's no reason they can't be faster. It's impossible to compare the higher level features of C++ to C because there is no direct correspondence between functionality, however, if you tried to simulate the functionality in C manually, your results would most-likely be slower than that of a C++ compiler.
    I would have to say that I aggree with Magos......there are certain inclusive features of C++ that can impose a slight overhead. RTTI for one....exceptions for the other ( - this is more due to compiler vendors not focussing optomisation on this subject - and why should it? - optomisation on error handling is hardly a must!)...and as operator new should throw bad_alloc on a failure, you should be prepared to take the hit (even though it is tiny IMO).

    Some compilers allow you to turn off these features...but they are still parts of the language and covered by the standard...

    I must say though that I have never found any of C++ to be a burdon and I use it all the time..its a matter of perspective and its usually only newbies or the narrow minded that use this as an argument to promote C over C++......I never bother with straight C - I prefer C++

  4. #19
    Programming Sex-God Polymorphic OOP's Avatar
    Join Date
    Nov 2002
    Posts
    1,078
    Originally posted by Fordy
    there are certain inclusive features of C++ that can impose a slight overhead. RTTI for one
    That only comes into play when you are using polymorphism, which isn't even supported in C. You can't really say it's slower because there is nothing to compare it to in C. This was what I was refering to in my previous reply when I said it's not really valid to compare it to C in this particular respect because in order to get similar functionality in C, you'd have to create your own vtable or something similar, which would most-likely end up being slower at runtime than using polymorphism directly in C++.

    Originally posted by Fordy
    ....exceptions for the other ( - this is more due to compiler vendors not focussing optomisation on this subject - and why should it? - optomisation on error handling is hardly a must!)...
    True, though I do agree with you that the "hit" is so tiny and only comes into play in certain circumstances that it's not something one would argue much about.

    Originally posted by Fordy
    and as operator new should throw bad_alloc on a failure, you should be prepared to take the hit (even though it is tiny IMO).
    Yeah, but if you really were concerned you could always just use malloc in C++.

Page 2 of 2 FirstFirst 12
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