'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.

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.

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"]