Thread: C or C++

<This is not the language, it's the programmer. If the programmer write efficient code, then the program runs fast. If he doesn't, well then it won't run fast or how you want it to. This has nothing to do with the language.>

yeah, that' s pretty much what i was trying to say. Maybe i was unclear. Those who still hold on to C-style code often say that C++ is bloated and slow. That C holds the real "muscle". I was simply saying that this was not correct. As you correctly point out, the programmer impacts the speed and size of the code far more than the choice between C and C++. C++'s obvious benefits outweigh the insignificant performance issues.

obvious benefits?

c can do most of the things c++ does just as well creating an executable that will at least match the speed of the c++ equivalent

a lot of the stuff you use in c++ you don't really need...

<a lot of the stuff you use in c++ you don't really need...>

I need all the stuff I use in C++. Your response pretty much proves my point. Those who defend C by saying the added tools in C++ are pointless don't really understand Object Orientation. They simply see as a useless obsticle--something else to learn.
I don't know what they're doing in Canada, but in the US (form what i'm told in school anyway) a majority of Software Engineering utilizes OOD&P which is the "useless" stuff C++ adds to C.

I've learned a bit about oop. Certainly useful for data containers. Inheritence of all types looks complex and useful when seen in source files.

Given that it can sometimes be nice to drop in, for example, an HTTP_PI object into your code to give instant http protocol interpretation, and it will look good, but really it's a choice of using functions as arguments to data and using data as functions of arguments, if you see what I'm saying...

http_pi inst;
inst.interpret(request);

vs.

http_pi inst;
http_pi_init(&inst);
http_interpret(&inst, request);

the top is shorter and the code sort of directly translates to how things would work in the ideal world (dropping objects into bins to make programs :/), I prefer the bottom in a lot of cases because then I see *everything* that happens, I know how every bit works and everything is coming together.

And how do you replicate the kind of neat stuff that dup2 and fork() have to offer with streams, eh?

a lot of the stuff you use in c++ you don't really need...

You don't have to use it, but with C++ you've got the option.

I prefer the bottom in a lot of cases because then I see *everything* that happens, I know how every bit works and everything is coming together.

If you wrote the http_pi class then you would, but if it was part of a third party library then you've no need to know exactly how it works. If you were using a third party c library you probably wouldn't know what was happening in the functions.

I'm thinking more like in terms of specifying every action.. every allocation, every free. Sorta prefering to keep track of my own pointers rather than let the garbage collector do it, that's the sense I'm talking about.

You do specify every action, but within a class (if you want to use classes). C++ doesn't have an in-built garbage collector.

ggs,

check out the following link on the encapsulation of fork and dup2:

http://www.csse.monash.edu.au/~damia...html/text.html

Hmm...In my opinion, they're almost alike, except C++ has classes...No offense to C users...But I like C++ better.

<I knew about pointers to functions, I think it is slopy, to point to your function.>

i agree, it's much nicer to let the technology (compiler) do the nasty work for you. I was simply saying that functions can be "grouped" within structures using C, and there's more to C++ than member functions...