LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   Applications seem favor C over C++, why? (https://www.linuxquestions.org/questions/programming-9/applications-seem-favor-c-over-c-why-132919/)

h/w 01-09-2004 05:31 PM

megamanx, that link i posted mentions the same issue as said by stroustrup.
neither have i actually needed an OO approach to what i did in C++/Java. but then, im still in school, and im guessing the reall problems will appear when i start work.
even then, im told that a lot of OO code written does not really need such an approach.

Mega Man X 01-09-2004 06:31 PM

I will check the link h/w, thanks mate. I've just got my C++ grades, it was not good at all.. since I really don't understand the hole concept of h/w. Arghhh, looks like I'll have to remake that course :S

Tesl 01-10-2004 01:22 PM

at first i never saw the need for OO, i understood how it worked but never ever saw the need for it.

For a lot of projects i think thats the same, however in all the larger apps iv built OO has been vital for me, and has made things a lot lot easier. Its all about the design, and iv found a lot of problems easily solved using OO.

That and being able to write my own classes for little bits and pieces really can be extremely helpful. There are times when you write a little program and think "hang on, that might be useful in other places" so you can just save it into a class, write its accessor methods (or whatever it needs) then forget about it :)

wgself 01-10-2004 01:56 PM

I think the reason most large projects are in c is that they are at established companies with large libraries of code that handle most of the functionality of c++. It is far quicker to write a function in c and add it to a library than to write the same function in c++ and cover all ot the OO overhead and documentation. I've been using c for about twenty years anc c++ for ten. I use both as needed by the project at hand. Both are great compared to Java or VB. (My opinion - don't want to start a war either ;-)

MadCactus 01-12-2004 02:15 PM

jtshaw:

Quote:

Object Orientation and Abstraction, while logically very efficient, doesn't lend itself to code that is as fast or as memory friendly as function code with only simple data types.
I've often seen this view expressed, but have yet to see any reasoning or evidence that supports it. I can understand why compile might be generally slower than for a similar C program, but why would a C++ prog use more memory or perform worse than a C program?

h/w 01-12-2004 05:28 PM

and i found the "real" reason coming from the developers at the lkml. apparently, the assembly code generated from the compilers is not as clean/efficient when in C++.

jtshaw 01-12-2004 07:12 PM

h/w, I believe that is exactly what I said earlier... gcc is better at compiling C code, thanks for verifying:)

Mad Cactus:
The more layers of abstraction the more variables you tend to have, the more function calls you have (which tend to translate to jumps in assembly), the more total lines of code, ect. ect. ect. More variables and more code tends to mean more memory usage. The more jumps you have the more processor time you use (since it takes a step longer to get to the next productive line of code). Unless you have ridiculously good optimization at compile time this will cause your code to be slightly slower. Now of course this doesn't make a bit of different on something like a 1Ghz. processor. But when you run it on a i386 or some slow embedded processor it sure does.

kev82 01-12-2004 07:30 PM

by jtshaw
The more jumps you have the more processor time you use (since it takes a step longer to get to the next productive line of code).

its a bit worse than you make out because jumps also require the pipeline to be re-filled and possibly a cache refill if the destination isnt in the cache, this is the reason why compilers offer the option to unroll loops

by Mad Cactus
but why would a C++ prog use more memory or perform worse than a C program?

C++ has to implement rtti, you also need to store tables for virtual function addresses, and there are loads of temporary objects created and destroyed which results in a lot of constructor/destructor calls

leonscape 01-12-2004 07:34 PM

The type of programming I did in school also didn't need OO, but they taught it because in the world you programs aren't going to be that simple. The abstraction and layering is very useful for nearly everthing I've done since.

Currently I'm programming a lot of 3D stuff, and I don't know how I'd cope without my Vector, Matrix, and Camera classes. I wrote those about 4 years ago, they've been in continual use ever since.

As for applications written in C++ download KDE source, have a poke around. The best examples I ever saw of well written OO code.

MadCactus 01-13-2004 07:16 AM

jtshaw:

Quote:

The more layers of abstraction the more variables you tend to have, the more function calls you have ...
I don't agree with that at all - the only difference between an object and functionally identical modular code is the notation used, the same variables and functions are used. So each object is a "variable" - so what? The memory needed is still only the sum of its members.

kev82 01-13-2004 07:56 AM

by MadCactus
the only difference between an object and functionally identical modular code is the notation used, the same variables and functions are used. So each object is a "variable" - so what? The memory needed is still only the sum of its members.

that is not true as i said in my above post(23) the memory needed is not the same as you also need to store information about its type, virtual function addresses, etc. you also get a lot of extra function calls for constructors/destructors when creating temporary objects

look at the following c++ code
Code:

#include <iostream>

using namespace std;

class A
{
private:
        int a;
public:
        A() {
                a=0;
                cerr << "Constructing a default A" << endl;
        }
        ~A() {
                cerr << "Destructing an A" << endl;
        }
        A(A& b) {
                cerr << "Copying an A" << endl;
                a=b.a;
        }
       
        void set(int i) {
                a=i;
        }

        friend ostream& operator<<(ostream& os, A a);
};

ostream& operator<<(ostream& os, A b) {
        os << b.a;
        return os;
}

int main()
{
        A array[100];

        for(int i=0;i<100;i++) {
                array[i].set(i);
        }

        for(int i=0;i<100;i++) {
                cout << array[i] << endl;
        }

        return 0;
}

compiling it and running ./a.out 2>&1 1>/dev/null | wc -l gives me an output of 400, if i did operator<< by const reference(which you should always do) rather than value then it would cut me down to 200 but i wanted to show the copy constructor because there are times when const reference isnt possible. now just imagine i was passing a vector of these things around in a recursive function, can you see just how many function calls your gonna get.

now if you do it in C with structs then you dont get any of those function calls but nor do you get the safety of having constructors/destructors.

mr_segfault 01-23-2004 01:34 AM

Your examples might be true for trivial samples, but given a more complex (real life system) I think you might find there is little to no performance benefit using C over C++..

C++ compilers are getting better and faster (generated code) with time.

The number of instructions in a object file is not a direct representation of the execution speed or memory use.

I believe in using my experience more than other's bold statements regarding these types of matters.

I have been programming for many years (15+) and have used c++ for nearly all development for the past 5 years. Not once have I experienced a performance issue due to code execution speed. In practice the design of the software is far more important than the language it is implemented in.

C++ gives speed close to C (close enough) but provides type safty, references (safe pointers), exceptions and all the other OO features we've been enjoying ever since its creation.

Some argure that C++ has RTTI (Run Time Type Information) virtual tables which cause additonal overhead. True but not quite. RTTI and virtual tables to add additional overhead but it is not that expensive, nor required. A C++ program man turn off RTTI and exceptions (exception handling requires RTTI) if it is deemed to expensive. Also virtual tables are only created/used when needed. If you never have virtual function or inheritence then you will not pay the penalty.

I believe that OO aids in decomposing a problem down to to implementable units which encapslate their functionality and infact make it easier (in general) to optimise performance critical code.

Its a matter of taste. C has its place, as does C++. They are both great languages, but both require good programmers to make use of their features rather than abuse.

kev82 01-23-2004 07:02 AM

i generally agree with you mr_segfault, in a program thats actually doing real work then the extra time and memory taken by C++ is insignificant compared to what the algorithm itsself requires, on the fast machines of today you cant really see a noticeable difference, the aim of my post was to point out to MadCactus that higher level languages do use more memory and do make more function calls than there lower level equivelent even though its not noticable because of the speed/memory capacity of machines today.

jtshaw 01-23-2004 07:32 AM

I also tend to agree with you mr_segfault. Today, right now, the C++ compilers like g++ are pretty much as good as the c compilers. However, if you think back to the early days of linux the same statement was not true. There were probably C++ compilers out that performed perfectly well, but the ones packaged with GCC did not. Many many open source projects have roots back to those days when pretty much everything Linux/Unix was in C.


All times are GMT -5. The time now is 04:44 AM.