'typedef said:

This is silly. C is 10 times more productive than assembler. C++ is not 10 time more productive than C.

So you'll only use something if it's ten times better? A car isn't ten times faster than a bike, so are you saying that we shouldn't use cars? A microwave doesn't cook food ten times faster than an oven, so are you saying that we shouldn't use microwaves?

Is this a serious question? I'm saying that the advantage of C over assembler is huge compared to the disadvantage. The advantage of C++ over C is considerably less compared to the disadvantage. Using C over ASM is a no-brainer. Using C++ over C is less of an obvious decision.

As a general statement that is just plain not true. In some industries, sure, but as a blanket statement, no way. I spent two years working in a Java shop, on large server software, and event here an integral task had to be delegated to C++[1] (nevermind maintenance tasks which were generally scripted in bash). Outside of the enterprise-bloatware world, there are still a lot of people using C++. In game development, C++ is still very much winning over Java.

There are also far, far more people doing enterprise development then games (even then a large subset of games are Java based). And Java is the dominate language in enterprise development. C++ use has actually been going down and I would image it won't be to long before C# even overtakes C++ (if it hasn't already). I would imagine the only reason C++ still has any kind of serious widespread use is from library inertia. Dealing with C++ hell instead of spending the next two years rewriting the project is probably the only viable option for a lot of businesses.

In my experience, in C++ project people tend to write more "fluff". Especially beginners tend to make a mess of classes and create complex dependencies.
Especially things like "Let's encapsulate it (because I don't want to use the other persons class directly)" leads to lots of bloat and unneeded interfaces.
The same with making it futureproof (for any eventuality) - rather then just hardcode the limited # cases actually needed (and get it done) - we are adding
more "fluff which might (but probably won't due to changing requirements) be used in the future,

In some projects I saw multiple classes, interfaces, factories and stuff - which could have been hardcoded with just a few simple lines - instead everything
is delegated to another class which i turn delegates it again. Much overhead and little code actually doing something for the end-product.

So I started doing a multiplatform mini-project (osx, iphone, win32) in plain-C a few months ago - after programming for many years in C++.

I set the followig guidelines for myself:
- "If it takes much lines-of-code, rethink it because that solution is wrong ^^
- "it's done when it's impossible to remove any code (as opposed to "it's done when you couldn't possiblily add anything more - that might _potentially_ be used")
- Add on-demand (don't look too much forward) - eg: no programming an entire matrix-class with all possible functions - if you currently only really need matrix-mul).
- Don't be over-flexible/extensible (if I need 5 of something then "Something s[5]" will do fine - no factories, managers or dynamic datastructures needed).

Sure, I miss template-containers - and yeah, you darn well know what you are doing with those void*'s - but it does have it elegance and simplicity.
Anyway, don't just discard C because "it's old and C++ is better".

Just my 2 ct

I tend to use C more but I've been transitioning to C++ slowly. I can see the appeal of OOP, particularly for data structure-intensive tasks, but I think a lot of OO design principles are overblown, namely "data hiding" and "reusability". A lot of code that I write is not going to be reused or, if it is, is going to be implemented in a radically different fashion. On the current project that I'm tinkering with, an emulator, objects seemed compelling from a design standpoint but looking back now, I realize that the core functionality of the program should be done in a procedural fashion, with a few objects here and there for things that either are truly well encapsulated or interchangeable and which would benefit from concepts like inheritance. I'm discovering that when the functionality of different modules is tightly coupled, accessor functions and data hiding really do result in over-designed solutions.

Furthermore, I haven't been very impressed with STL and have been using the old standard C library for file I/O and string handling. I need to be able to gracefully handle errors and doing it with STL and a bunch of try-catch blocks is hardly elegant or foolproof.

I might get flamed for this, but oh well, I'm used to it. I think C++ promotes alot of bad programming practice and laziness, especially for beginner programmers. I don't hate C++, but I prefer straight forward C over some class/template crazy C++ code. TBH, I don't even see what makes most of those features even useful to begin with. Almost everything you can do in C++, you can do in C, but just requires a bit more effort.

I wrote my first 3rd person shooter game in C. Saw no advantage in using C++ whatsoever, and it was easier to follow/maintain.

I might get flamed for this, but oh well, I'm used to it. I think C promotes alot of bad programming practice and laziness, especially for beginner programmers. I don't hate C, but I prefer straight forward assembler over some struct/functions crazy C code. TBH, I don't even see what makes most of those features even useful to begin with. Almost everything you can do in C, you can do in assembler, but just requires a bit more effort.

I wrote my first 3rd person shooter game in assem.... oh no, I didn't

C++ offers the programmer some more tools than C. Either you make use of them or you don't. Or you ABuse them. I guess C++ actually makes you think of what you are going to program, because if you don't, you'll end up with a big pile of junk.

Amazing how big this thread got. Anyways, here are some stats from a projects I did in the past, a level editor:

C: 400 lines of code
C++: 1200 lines of code

I guess C++ actually makes you think of what you are going to program, because if you don't, you'll end up with a big pile of junk.

lol, exactly my point - I witnessed a substantial amount of programmers ignoring the "think" step, ending up with a big pile of junk ^^

I might get flamed for this, but oh well, I'm used to it. I think C promotes alot of bad programming practice and laziness, especially for beginner programmers. I don't hate C, but I prefer straight forward assembler over some struct/functions crazy C code. TBH, I don't even see what makes most of those features even useful to begin with. Almost everything you can do in C, you can do in assembler, but just requires a bit more effort.

I wrote my first 3rd person shooter game in assem.... oh no, I didn't

C++ offers the programmer some more tools than C. Either you make use of them or you don't. Or you ABuse them. I guess C++ actually makes you think of what you are going to program, because if you don't, you'll end up with a big pile of junk.

(Madhead, your post is a complete waste of time, and in no way represents practical thinking from anyone. here's another)


[size=2]I might get flamed for this, but oh well, I'm used to it. I think Assembly promotes alot of bad programming practice and laziness, especially for beginner programmers. I don't hate Assembler, but I prefer straight forward machine code over some symbolic reference/mnemonic crazy assembly code. TBH, I don't even see what makes most of those features even useful to begin with. Almost everything you can do in Assembly, you can do in machine code, but just requires a bit more effort.

I wrote my first 3rd person shooter game in machine c.... oh no, I didn't
[size="1"]

I might get flamed for this, but oh well, I'm used to it. I think Assembly promotes alot of bad programming practice and laziness, especially for beginner programmers. I don't hate Assembler, but I prefer straight forward machine code over some symbolic reference/mnemonic crazy assembly code. TBH, I don't even see what makes most of those features even useful to begin with. Almost everything you can do in Assembly, you can do in machine code, but just requires a bit more effort.

I wrote my first 3rd person shooter game in machine c.... oh no, I didn't

No, no, no... let's try another one.

I might get flamed for this, but oh well, I'm used to it. I think machine code promotes alot of bad engineering practice and laziness, especially for beginner engineers. I don't hate machine code, but I prefer straight forward soldering transistors over some opcode/byte crazy machine code. TBH, I don't even see what makes most of those features even useful to begin with. Almost everything you can do in machine code, you can do with soldering logic gates, but just requires a bit more effort.

I assembled my first 3rd person shooter game with transistors.... oh no, I didn't

Amazing how big this thread got. Anyways, here are some stats from a projects I did in the past, a level editor:

C: 400 lines of code
C++: 1200 lines of code

C++ being a superset of C (yeah... I know. Let's just pretend), 800 lines of your C++ program were superfluous, or you implemented additional features.
Even if you didn't mean to implement new features you probably did: Type safety, buffer overflow protection, ...
Let me get this straight, I'm in no way a C++ fanboy but the neverending C++ bashing gets a little on my nerves. There is no such thing as a perfect language, only different tools for different jobs.