Hi all,

For those of you who have experienced C or C++, I was wondering which you think is the best language for you, and what features made you sway to that language.

Iv'e been searching Google looking for info, but couldn't find anything useful. For example, everyone who uses C says that C++ is slower, however the C++ programmers suggest that it's as fast as C, if not faster.

Is there any drawbacks from C due to it's old age? Any drawbacks from C++ due to it's relative newness?

What where some of our favourite daemons programmed in? (Such as Apache, Exim, Postfix, MySQL, PureFTPd, etc).

I know i'm likely to get alot of conflicting opinions here, but let's see what happens. I would like to try and make my own (confused) mind up. :)

I say that it is a matter of preference. C++ adds to the C language but under the covers is still basically C. For example, a template is just a glorified compiler trick. But that doesn't mean you shouldn't use C++. I think that for large projects C++ can be extreamly useful as it assists greatly in a good design. C++, like just about any programming language, provides plenty of rope to hang yourself too.

For me it really boils down to design. A well designed C++ program will likely run faster than a poorly designed C. Equally well designed programs might give a slight edge to C but the question then becomes which is more easily maintained over the years. That is where I think C++ gives you a bit better design patterns to help you keep the code cleaner.

At least that is my <very small amount of your localized currency> worth.

As far as I know, all the daemons you list are written in pure C. The general mentality is that C++ isn't necessary for this sort of task, so why use it? There's a well-established method of programming daemons on a *nix system, and besides, there's a long history of C programming as well, so most of the libraries are tailored to use in that fashion.

C++ should be just as fast as C, given an equally good compiler, but object-oriented code is much harder to optimize, for one. Second, if you're using virtual functions (required for polymorphism), there is additional overhead attached to each method call for a virtual function table lookup. Also, the standard library is a lot more complicated and comprehensive, so C++ programs tend to be larger in memory. With gcc, C++ also takes significantly longer to compile than pure C, I don't know if this is true of other compilers.

C's biggest drawbacks are the lack of a comprehensive library (even something as simple as string handling requires maniuplation of fixed-size overflowable buffers), and a very large chance of introducing bugs due to the lack of bounds checking, the need to use pointers etc.

C++ mitigates some of these issues by discouraging the use of pointers in favour of the safer reference, including safe string manipulation and resizing containers and such. Its biggest disadvantage is that these things come with overhead attached (C++ can do almost everything C can). It used to be a somewhat unstable standard, and it was hard to write cross-compiler code, but this has been remedied in the past few years. Complex templating is still somewhat of a problem though, but even there, projects like Boost which use it extensively manage to work in all modern compilers.

There's no reason to code in C, C++ gives added functionality and is more widely supported, it's safe to say that use of C in the professional world is deprecated.

If you want pure speed of execution, code in assembler.....

Languages are a balance of ease of use, and speed.

C++ is "easier" for some for larger projects.
C is easier for those who are used to it, and will be faster than C++ in the hands of a guru.

But C++ is probably faster in the hands of many people, as they use the pre-done libraries and classes. In C a guru would probably write their own and tweak it fully.

Then again, a good VB programmer could write a program in vb3 (old age showing here) that blew the socks off, and totally outperforms a C or C++ program by a not so good programmer- if they used their brains and the right algo's.

How you code is more important that what you code in, at least in most cases.

C is still used, as are languages like cobol, quite a lot - just you dont tend to hear about it.....

Unless it is some stupid simple console app I will always go C++ becuase you write less code which means less bugs. I am more than willing to take a slight performance hit (it will still be faster than any other non-c language) to use things like the string, map, and fstream libs. standard c functions like strtok() still confuse the hell out of me.

go to www.codeproject.com for C/C++ questions.

i learnt C first, and its still the primary language i code in. although i did OO at uni, i always prefered procedural as i could 'just code' in it, whereas with oo i always had to plan first..

I've since started on a project written in c++, and i found myself reverting to C - i find string handling funny and prefer pointers to string objects! Slowly learning hte C++ way of doing things but i find C a lot quicker to code in properly, than proper C++

it's safe to say that use of C in the professional world is deprecated.

This is a very false statement. C is still in very wide use in the 'professional world' as you put it.

Most of your device drivers, your game code, and your rendering engines are written in C.

Iv'e been looking further into this, and I think it would be safe to say that C suits my programming habits more than C++ does.

Although I only started programming about 4-5 years ago, I find myself taking an "oldbie" outlook on things. For example, some of the first languages I tried where VisualBasic and DarkBASIC. I could never get the hang of VB and it's "GUI Maker" way of doing things. I'd much rather actually write something (e.g. button=createbutton(0,0,60,20,“OK”,0,0)).

From what Iv'e seen sofar, I think it would be correct to say that C isn't a world away from PHP (or the other way around I guess, since PHP is based upon C's syntax ;)). PHP is one of my strongest programming languages (or scripting language) as I've been using it for years.
If you want pure speed of execution, code in assembler.....
I like assembly, it just makes so much sense, however my ASM skills are no-more than "hobbyish", and I think it would take too long to develop them as far as being able to make useful programs. I have made a simple OS, and many other projects in ASM, but these have been personal projects (e.g. for fun, or for a course assignment) - as such neither I nor anyone else would have a reliable, secure, useful program as the result of me programming something in ASM ;)
i learnt C first, and its still the primary language i code in. although i did OO at uni, i always prefered procedural as i could 'just code' in it, whereas with oo i always had to plan first..
I agree, Iv'e always understood and enjoyed programming structured code much more than object-orientated.
Most of your device drivers, your game code, and your rendering engines are written in C.
This is true. Also, I checked up on all the daemons that I listed above, and they where all programmed in C.

Overall I think that C is the language which suits me, there is just no advantage I can see for me to use C++.

i learnt C first, and its still the primary language i code in. although i did OO at uni, i always prefered procedural as i could 'just code' in it, whereas with oo i always had to plan first..
I agree, Iv'e always understood and enjoyed programming structured code much more than object-orientated.


This is really just a matter of preference. There is some irony in your post in that PHP is actually trying to move towards an OO model and you're moving away.

But either way, the design is the key. The first time you work for a company that didn't plan first and you inherit 100,000 lines of spaghetti code you'll long for the days at school where you didn't have to plan and could throw the code away a month later.

:peace:

This is really just a matter of preference. There is some irony in your post in that PHP is actually trying to move towards an OO model and you're moving away.

But either way, the design is the key. The first time you work for a company that didn't plan first and you inherit 100,000 lines of spaghetti code you'll long for the days at school where you didn't have to plan and could throw the code away a month later.

:peace:

dont get me wrong - i'd advocate always designing a program before you actually write the code, but when im coding for me, which is where the program is generally less than 10k lines of code, i 'just code'..

I can do that in C, i cant do it in C++ :)

If C suits your programming habits, it's in your best interest to getting new habits... My opinion.

I use C for pointer arithmetic. It's fast and lightweight. I would disagree that C++ can be just as fast as C. If your C++ code can keep pace with your C code you obviously suck at coding C. :P

There's no reason to code in C, C++ gives added functionality and is more widely supported, it's safe to say that use of C in the professional world is deprecated.

I'm going to have to disagree with this statement too. C is alive and well in software where performance matters.

I use C for pointer arithmetic. It's fast and lightweight.
Pointer arithmetic has been retained in C++.

I would disagree that C++ can be just as fast as C. If your C++ code can keep pace with your C code you obviously suck at coding C.
If you are trying to argue that "an algorithm implemented in C++ can never be just as fast as the same program implemented in C", then one can refute your claim by 'cheating', i.e. writing C code that is valid C++.

I think what error404 said has to be viewed in the light that a significant difference in speed usually has more to do with the algorithms than with whether a C or C++ implementation is used, so long as both are well written and optimised.

Pointer arithmetic has been retained in C++.
If you are trying to argue that "an algorithm implemented in C++ can never be just as fast as the same program implemented in C", then one can refute your claim by 'cheating', i.e. writing C code that is valid C++.


By your own implication you would be writing C code in C++. You haven't refuted my claim that C++ can be as fast as C. If it was as fast you wouldn't have to "cheat" as you say.


I think what error404 said has to be viewed in the light that a significant difference in speed usually has more to do with the algorithms than with whether a C or C++ implementation is used, so long as both are well written and optimised.
[/quote]

What is an algorithm? Is it a function that opens a file and mallocs() a buffer and reads that file into it? Is it a function that draws graphics on the screen? Is it a function that compares the data in an array? Almost everything in a program is an algorithm on some level. Therefore, it refutes your idea that C++ can compete when what you're talking about is writing a majority of the internals of a program in C.

Let's pretend we're having this argument 30 yrs ago. Adam, I've replaced all occurences of "C" with "assembly", and all occurences of "C++" with "C".

By your own implication you would be writing assembly code in C. You haven't refuted my claim that C can be as fast as assembly. If it was as fast you wouldn't have to "cheat" as you say.

What is an algorithm? Is it a function that opens a file and mallocs() a buffer and reads that file into it? Is it a function that draws graphics on the screen? Is it a function that compares the data in an array? Almost everything in a program is an algorithm on some level. Therefore, it refutes your idea that C can compete when what you're talking about is writing a majority of the internals of a program in assembly.

Is it just me or is it scary that fits so well?

Whatever answers you give to the C vs assembly argument above are the same answers to the C vs C++ argument. It's not about language, it's about software engineering practices.

And really, this argument is really academic... C++ compiler technology has improved an enormously in the past decade. Like error404 mentioned, with a few compiler optimizations, most C++ programs will perform indistinguishably from their C counterparts. For every exception, that is, a C program faster than a C++ one, I can provide an assembly program faster than that C one--and really none of us would be proving anything.

Let's pretend we're having this argument 30 yrs ago. Adam, I've replaced all occurences of "C" with "assembly", and all occurences of "C++" with "C".

Is it just me or is it scary that fits so well?


Your comparison means nothing. Learning languages means you identify advantages and pitfalls of each language.


Whatever answers you give to the C vs assembly argument above are the same answers to the C vs C++ argument. It's not about language, it's about software engineering practices.


Wrong. Assembly will always be faster than C. The application size will also be much smaller. Perhaps if you compared a C program written by a novice to a C++ program written by an expert you might see a difference. However, that example only highlights the fact that it's important to not be an expert when you are writing performance software in C.


And really, this argument is really academic... C++ compiler technology has improved an enormously in the past decade. Like error404 mentioned, with a few compiler optimizations, most C++ programs will perform indistinguishably from their C counterparts. For every exception, that is, a C program faster than a C++ one, I can provide an assembly program faster than that C one--and really none of us would be proving anything.

You would be proving that assembly is faster than C and that C is faster than C++. And that is what I set out to prove so thank you for admitting that I was correct. If this was at all inconsequential you wouldn't have told me that C++ could match C in performance. This is a cop out.

Also, your example is poor. An assembly program should be faster than a C program. That is what we are comparing. I've benchmarked C applications that are 10 times faster than C++ applications. Clearly this isn't apples and oranges.

Your comparison means nothing. Learning languages means you identify advantages and pitfalls of each language.

Wrong. Assembly will always be faster than C. The application size will also be much smaller. Perhaps if you compared a C program written by a novice to a C++ program written by an expert you might see a difference. However, that example only highlights the fact that it's important to not be an expert when you are writing performance software in C.

It's very easy for assembly to be slower than C. Look at a beginner/intermediate assembly programmer. Especially on complex architectures like x86, compilers for have been producing faster code than probably 90% of x86 assembly programmers out there.


You would be proving that assembly is faster than C and that C is faster than C++. And that is what I set out to prove so thank you for admitting that I was correct. If this was at all inconsequential you wouldn't have told me that C++ could match C in performance. This is a cop out.

You missed my point completely... so I will spell it out: why aren't we all writing our programs in assembly?

Because it'd be too difficult. It'd take too long. It'd be completely unmaintainable, and does not facilitate code reuse. Because of advances in compiler technology, the performance increases aren't justifiable on the time spent writing programs language that yields faster programs.

You can say all these for the assembly vs C debate, and you can say them for the C vs C++ debate. The Java vs everything else debate for that matter as well. Why use newer languages? Trade-offs becomes worth it.

Performance is not everything.

You missed my point completely... so I will spell it out: why aren't we all writing our programs in assembly?

Because it'd be too difficult. It'd take too long. It'd be completely unmaintainable, and does not facilitate code reuse. Because of advances in compiler technology, the performance increases aren't justifiable on the time spent writing programs language that yields faster programs.

You can say all these for the assembly vs C debate, and you can say them for the C vs C++ debate. The Java vs everything else debate for that matter as well. Why use newer languages? Trade-offs becomes worth it.

Performance is not everything.

I'll get to your first point later. However, where the hell did I say that you shouldn't use C++ because of its code reuse, etc? Every post I have made is about performance only so your point is moot.

Yet, if the performance increases aren't justifiable then you must know more than post gres, apache, mysql, zend, renderman, and all the other performance-ware out there that uses C. I think it's obvious to everyone here that you are blatantly wrong on this one.

I'll get to your first point later. However, where the hell did I say that you shouldn't use C++ because of its code reuse, etc? Every post I have made is about performance only so your point is moot.

My point as is as moot as yours about performance: the original poster did not ask for a C/C++ performance comparison.

Yet, if the performance increases aren't justifiable then you must know more than post gres, apache, mysql, zend, renderman, and all the other performance-ware out there that uses C. I think it's obvious to everyone here that you are blatantly wrong on this one.
Maybe they used C because that's what they knew? Maybe because that's what they want to use (which is very likely)? Maybe they had to be binary-compatible with something else? Do you have proof that all of these projects chose C for performance over preference?

Unless you are a developer on any of these projects (you don't appear to follow development, else you'd know large portions of MySQL are written in C++), don't make absolute statements based on your own opinion.

Wow. Such passion....

I've been arguing with computers (programming) for more than three decades. Fortunately, I am in a position to make the decision. And the decision was C.

There is a mindset needed when programming in C.... The compiler isn't going to 'take care' of any of the details. You really need to know what you're doing. Sadly, based on what I've seen coming out of a lot of the colleges and universities, our youngsters are being crippled by bad teaching and bad languages. Collect your own garbage. Watch your own bounds. Pay attention. Understand what the heck you're doing. Do they even talk about registers any more? I mean actual hardware registers. And FPUs. And ALUs. Hardware.

In the real world, performance matters. You can kid yourself about it 'til the cows come home, but when you get down to brass tacks, when the choice is fast versus faster, I think anyone in their right mind will go for faster when the dollars are the same for either choice.

Just my $0.02....

Maybe we can try to get more story on game doveloper (not flash ver). Take a look. They are fighting which languange are better. :) What I have understand from reading some articles, C is more faster than C++ (good programmers) but C++ is better on very large projects. Nowdays, 1 game can reach millions of codes. So, they will mix all of them for example create a framework using C or assembly and others using C++ :)

Wow. Such passion....

I've been arguing with computers (programming) for more than three decades. Fortunately, I am in a position to make the decision. And the decision was C.

There is a mindset needed when programming in C.... The compiler isn't going to 'take care' of any of the details. You really need to know what you're doing. Sadly, based on what I've seen coming out of a lot of the colleges and universities, our youngsters are being crippled by bad teaching and bad languages. Collect your own garbage. Watch your own bounds. Pay attention. Understand what the heck you're doing. Do they even talk about registers any more? I mean actual hardware registers. And FPUs. And ALUs. Hardware.

In the real world, performance matters. You can kid yourself about it 'til the cows come home, but when you get down to brass tacks, when the choice is fast versus faster, I think anyone in their right mind will go for faster when the dollars are the same for either choice.

Just my $0.02....

Sure they do, it just depends on what courses you want to take. I believe that in the read world speed is not simply execution time of an application, but also developement time.

We can have XYZ Application created in 12 months, or 6 months. If we go the 6 month route the application will load up around 10 miliseconds slower through. Which would you go with? Every language is going to have it's strengths and weaknesses, that's simply the way it is. There's a lot more that goes into choosing an application language than the speed execution ;)

By your own implication you would be writing C code in C++. You haven't refuted my claim that C++ can be as fast as C.
What I point out is specially contrived to prove your absolute statement wrong. You can argue that it is C code, but if it is valid C++, it is C++ code.

Of course, what you have in mind is not such a contrived example, but things like iostreams. C style i/o is definitely faster than C++ style i/o. On the other hand, std::sort() has been cited as faster than qsort() despite the overhead, simply because the use of a function object is more tenable to inlining by a compiler. Does this mean that C++ is faster than C? No, because one could implement the sorting directly, and if done well, beat std::sort(). But then, if qsort(), std::sort or the custom implementation are all fast enough, it may not even matter at all to begin with.

That is what I am trying to get at, that the choice between C and C++ usually doesnt matter when we are talking about speed, since speed is usually not the issue when either is used well. There are other factors to consider, there may be times when we should actually prefer C to C++ due to speed issues, or even because only a C compiler is available. In the context of shockuk's question, it means that what is best for any of us may not be the best for him - the answer may be to learn both, in the end.

I believe that in the read world speed is not simply execution time of an application, but also developement time.

I'll grant you that development time is a definite factor in the real world....

We can have XYZ Application created in 12 months, or 6 months. If we go the 6 month route the application will load up around 10 miliseconds slower through. Which would you go with? Every language is going to have it's strengths and weaknesses, that's simply the way it is. There's a lot more that goes into choosing an application language than the speed execution ;)

...but development time line deltas of 100%? That's not real.

My philosophy has always been, "If it's worth doing at all, it's worth doing well." If that means we spend an extra week or two or three on a project, then so be it. Because all of your imaginary 10mS load times are going to add up.

Perhaps part of it, though, is application. We're writing server and other system-level code, not user apps. I think that when people are writing for users the bar is fairly low, generally speaking.

anyone else glad to see a heated argument about something other than java vs. php?

what java vs. php argument? php won, right? ;-)

what java vs. php argument? php won, right? ;-)
No, a python came and strangled them both. However, it missed the ruby, then some schemer came round with a lisp.

I'll grant you that development time is a definite factor in the real world....
...but development time line deltas of 100%? That's not real.

My philosophy has always been, "If it's worth doing at all, it's worth doing well." If that means we spend an extra week or two or three on a project, then so be it. Because all of your imaginary 10mS load times are going to add up.

Perhaps part of it, though, is application. We're writing server and other system-level code, not user apps. I think that when people are writing for users the bar is fairly low, generally speaking.

Which all goes back to the very first thing I said, this is taught if you take the right classes. The "average" programmer at my college is not looking for a position writing system level applications; rather, they are looking to explore the world of video game programming, web systems programming, and the very big buzz word out there is RAD. I'm sure you know, but I will mention for those that don't RAD = Rapid Applicaiton Developement. It's not to say that the "old" methods are out of date or not needed anymore, but rather that the types of applications that come from them are ones that the newer level of coders are not looking to program for the most part. At my college there is a COBOL class offered every semester, and every semester it fails to start. It is not because COBOL is a dead language, in fact the reason they are offering said language is because business is actually putting pressure on them to pump out a few more COBOL programmers.

Likewise in the second section of Java I took there was a COBOL programmer who was a very brilliant man. He was around late 40's or so, and he ended up having to drop out of the class because understanding the concept of OOP was something he simply could not do. Sadly we are going off topic and this thread is ending the same way almost every language thread does, that is: Program in the language that is right for you and your application.

Programming in the language that is right for a given person/organization and given their context is absolutely dead on. So the key then becomes proper analysis and characterization of the context, eh?

Back in the early days of my career (if we can call it that ;)) the projects on which we worked (this is back when minicomputers and mainframes ruled) received a fair amount of consideration before a single line of code was written. The police/fire dispatching systems I worked on were all coded in assembler. The banking systems were mostly COBOL. We wrote specialized compilers in DG/L (an ALGOL dialect), PL/N (a PL/1 dialect), C, and similar languages. (In fact, I wrote a compiler in COBOL in '78 just to demonstrate that it could be done; I was working at a think tank at the time.)

But it really does boil down to making appropriate choices.

Maybe we can try to get more story on game doveloper (not flash ver). Take a look. They are fighting which languange are better. :) What I have understand from reading some articles, C is more faster than C++ (good programmers) but C++ is better on very large projects. Nowdays, 1 game can reach millions of codes. So, they will mix all of them for example create a framework using C or assembly and others using C++ :)
Unreal Tournament is in C++. Quake is in C. Though, if you follow John Carmack's rantings, you'd also notice how much he talks about Java and game development...

C++ because you can also do C with it

From what Iv'e seen sofar, I think it would be correct to say that C isn't a world away from PHP (or the other way around I guess, since PHP is based upon C's syntax ;)). PHP is one of my strongest programming languages (or scripting language) as I've been using it for years.

I started with a C-like language for PalmOS and then drifted to C++. Upon realizing that learning C has definate benefits to understand the root of C++ you may find yourself drifting back and forth. Especially if, as others have mentioned, you are more procederal with your coding.

One thing that I have found as I explore PHP however, is how much of C programming knowlege that can be applied directly to PHP (4.3.x not 5 in my case). It is considerably easier (in my opinion) to work back and forth between the two. I have also had better success with moving C code to an extension that PHP can use.

As with anything, it all depends on the task at hand. Just because a two pound sledgehammer can be used to pound in a finishing nail, that 12 oz trim hammer may be better for the job.

BTW, I personally prefer C++ if I'm not concerned about any cross development with PHP. Mostly because I can't stand that printf() syntax. I always have to look up the formats. :)

Mark

What I point out is specially contrived to prove your absolute statement wrong. You can argue that it is C code, but if it is valid C++, it is C++ code.


You told me that code you were referring to was C code. Either you were being disingenious then or you are being disingenious now. Take your pick:


If you are trying to argue that "an algorithm implemented in C++ can never be just as fast as the same program implemented in C", then one can refute your claim by 'cheating', i.e. writing C code that is valid C++.

You told me that code you were referring to was C code. Either you were being disingenious then or you are being disingenious now. Take your pick:
He doesn't have to pick. Most valid C code is also valid C++ code. That's what he meant by cheating. If a C++ compiler compiles it, it's C++ code, even if it will also compile in a C compiler.

The fact of the matter is that C++ leverages the best of both worlds. If the performance penalties of virtual method lookup or whatnot actually hurt a portion of your application, you can always refactor that code as a C-style library and use that from within the more easily managed C++ framework of your application.

And another argument for C++ being overall better: templates. With ingenious use of templating, you can actually gain *better* performance over equivalent C code. Exercising equivalent functionality in C requires type checking and branching at runtime, while in C++ it's handled by the compiler. As evidenced by the blitz++ library, there are a great deal of things you can do with templates to achieve compile-time optimizations that aren't really possible with other languages. These *real* performance gains are a lot more relevant than the tiny overhead introduced by method table lookup and the additional passing of the 'this' pointer, which are really the only (CPU time) performance hits inherent to C++ worth mentioning.