108 replies to this topic

[Sirisian]

Oh and one of my big gripes is malloc and free are annoying as hell to use with all their casting clutter.

If you need to cast, then you're trying to compile a C program as C++. My favorite idiom is:

touche. That's what I get for coding in C++ so much. I'm curious why my professor never questioned that.

[Luckless]

I use C a fair bit to write libraries that get called from python code. (At times it can drift into the dreaded c/c++ bastardization mess, but I try to keep things to C for most parts. Some of the C++ standard library stuff is just too tempting. I really don't want to know just how badly a few of these libraries break if I try to port them.)

Right now, the current project I'm finishing up is about 60% C by Lines of Code, which seems to translate to something around 20-30% functionality as I look back at some of my documentation.

[Eelco]

Lets add some fuel to the flames:

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

The list of plain indisputable pareto improvements over either is nearly endless. The list of drawbacks? The only significant one I can think of is foregoing an existing C++ codebase; but you can compile it into a DLL if you need to (or rewrite it in a fraction of the number of lines).

C code compiles virtually without modifications, but if you want you can for instance seemlessly integrate as much functional jazz in there as you want, in clean syntax, and all of it compiling to the same machine code as hand-rolled C loops. Or do full blown metaprogramming with the same power as C++, plus extras, minus the agonizing pain.

Im not saying boost::bind or boost::range are impossible to use; its just that you have to learn the whole template jungle by yourself anyway if you want to have any clue whatsoever how to debug your programs, or gain any insight as to why abstractions that are supposed to inline without overhead cripple your performance anyway. It makes a mockery of the encapsulation libraries are supposed to provide. That is, if you didnt give up in dismay right when your 100 line program took more than a minute to compile.

So there you have it: use D

[i_luv_cplusplus]

Lets add some fuel to the flames:

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

The list of plain indisputable pareto improvements over either is nearly endless. The list of drawbacks? The only significant one I can think of is foregoing an existing C++ codebase; but you can compile it into a DLL if you need to (or rewrite it in a fraction of the number of lines).

C code compiles virtually without modifications, but if you want you can for instance seemlessly integrate as much functional jazz in there as you want, in clean syntax, and all of it compiling to the same machine code as hand-rolled C loops. Or do full blown metaprogramming with the same power as C++, plus extras, minus the agonizing pain.

Im not saying boost::bind or boost::range are impossible to use; its just that you have to learn the whole template jungle by yourself anyway if you want to have any clue whatsoever how to debug your programs, or gain any insight as to why abstractions that are supposed to inline without overhead cripple your performance anyway. It makes a mockery of the encapsulation libraries are supposed to provide. That is, if you didnt give up in dismay right when your 100 line program took more than a minute to compile.

So there you have it: use D

Decent toolchain? Maybe on *nix, but on Windows, AFAIK there are no really working IDEs with full debugging support, neither there are any user-friendly debuggers. Also, there are like five different build tools, because rather than trying to find a compromise, the already scattered opensource community is making a lot of forks. Just look how many dead projects are there on dsource.org.


I like D, but without a decent, open IDE, it won't gain any momentum.

[Antheus]

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

Not enough.

In order for a major shift to occur, there needs to be a killer feature.

Tapes won over vinyl because they were robust.
DVD won over tape because they didn't need to be rewinded.
USB won over DVD because it's not mechanical.

Java won over C++ because of garbage collection.
Dynamic languages won over the web because they removed the need for compilation step.

Note that in all of the above cases there are plenty of examples of incremental improvement. Zip drive did not win since it merely improved on size of disk. Blu-ray or AudioDVD did not win because they do similar.

To improve, one must change some fundamental aspect, not just iterate on existing parameters.

The killer feature of C++ over C? Namespaces, either real ones or struct/class encapsulation. And little else.

But merely fixing what is broken or improving on individual parameters simply isn't enough.

C code compiles virtually without modifications,

Virtually without? Or completely without?

What about C-with-classes, which represents huge portion of production code. And if that code compiles already, why would I now start with a new language that might or might not work?

A C++ which compiles virtually all code is fine. It takes no effort, one just switches the compiler parameter in build.
D code first needs to be rewritten, build needs to be rewritten, application must then be tested and finally, in addition to all the usual bugs, a whole new class of bugs appears from "almost compatible" code.

None of this adds anything at all to final product, it takes *years* away from time that could be spent on that. Even if that problem were solved, there is still the lack of the killer feature.

without a decent, open IDE

There is no IDE for PHP. Well, there are many, but most one can hope is some trivial syntax highlighting. It certainly hasn't hindered the adoption, in many ways it made language accessible since all one needed was notepad.

[Eelco]

Decent toolchain? Maybe on *nix, but on Windows, AFAIK there are no really working IDEs with full debugging support, neither there are any user-friendly debuggers. Also, there are like five different build tools, because rather than trying to find a compromise, the already scattered opensource community is making a lot of forks. Just look how many dead projects are there on dsource.org.


I like D, but without a decent, open IDE, it won't gain any momentum.

Visual Studio integration works pretty damned smooth for me. Autocomplete could be better, but id rather get an imperfect cue instantly than a better one after waiting for ten seconds.

No complainst about the debugger. Its not perfect, but it beats trying to parse a boost template error any day of the week.

Not to say there is no room for improvement here, but its improved a lot recently.

[Eelco]

Hell no; why would you, if you could use D?

It links with all C libraries, and has a solid compiler and decent toolchain of its own nowadays.

All of that, but more importantly, its C/C++ done right, plus a few extra decades of accumulated wisdom in language design.

Not enough.

In order for a major shift to occur, there needs to be a killer feature.

Tapes won over vinyl because they were robust.
DVD won over tape because they didn't need to be rewinded.
USB won over DVD because it's not mechanical.

Java won over C++ because of garbage collection.
Dynamic languages won over the web because they removed the need for compilation step.

Note that in all of the above cases there are plenty of examples of incremental improvement. Zip drive did not win since it merely improved on size of disk. Blu-ray or AudioDVD did not win because they do similar.

To improve, one must change some fundamental aspect, not just iterate on existing parameters.

The killer feature of C++ over C? Namespaces, either real ones or struct/class encapsulation. And little else.

But merely fixing what is broken or improving on individual parameters simply isn't enough.

Considering the vast expanses of incremental improvement C++ leaves for the taking, id say it adds up.

That said, there are a few fundamental things D offers; such as a memory model geared towards mullticore processing, and somewhat related: support for immutable data and transitive const. Its going to win out against C++ in that regard bigtime as parralelism continues to increase in importance.

Most importantly, in my opinion, is that it manages to combine a wide spectrum of features, not yet found within the same box. That matters; a lot. Want to do to the metal programming? Stuck with C++ and friends. Want to do functional programming or otherwise not be driven insane by syntax that makes ASM look easy on the eyes in comparison? Crap, got to give up on the latter or split my project over several programming languages. Want to write safe managed code and be productive? Shit; yet another programming language in the mix.

That, or you use D, which allows you to take the best form these paradigms as it suits you, without trying to force some religion on you.

There is one feature I think it should envy, which is the fluid static/dynamic interfacing the .NET platform offers. Other than that, im really happy with it.

[dublindan]

Java won over C++ because of garbage collection.

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.

[1] Ok, admitedly, we were doing some pretty specialized stuff, so most developers won't need to.

Java won over C++ because of garbage collection.

In in the areas where Java did win over C++, whether or not it was because of garbage collection is debatable at best.

[C-Lesh]

Nice to see different opinions on C and C++. Thanks for all of the feedback!

[BeerNutts]

I typically program in C, but mostly because I'm much more comfortable using it than C++ (I program in C at work, and I have a complete understanding of it). I have written some programs in C++, but it is usually slower since I'm trying to learn some new ways of doing things.

There are certainly advantages to using C++ when used right, but I don't always use it right, and often it will take me longer to do something in C++ I could've done much quicker in C.

[rethan]

I use C for almost all of my programming because I like the simplicity of C over C++. I also agree with previous posters that some C++isms make the code harder to read/follow but that's probably because I don't code in C++ much. I have yet to come across a problem that just cannot be coded in C, and any extra bit you may need to get something working in C that is "easier" in C++ seems to me is gained back in the clarity of the language.

[ChaosEngine]

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.

Anything you can do in C, you can do in assembler with a bit more effort. Always use the highest level/most productive tool you can*. Time wasted doing stuff in C that "requires a bit more effort" is time that could better be spent adding features, polishing the design, etc.


*i.e. the one that satisfies your requirements for portability, performance, etc.

[Aardvajk]

Almost everything you can do in C++, you can do in C, but just requires a bit more effort.

True, but then pretty much everything that you can do in C can be done in C++. All the features of C++ that C lacks are optional and if you are preferring to write procedural code, C++ can still be a better choice due to stricter type-safety.

I understand the arguments for C in terms of compilation speed, maybe easier optimisation by compilers and availability of good compilers on some platforms, but not because C++ has features that impart no overhead if you choose not to use them.

[Dave]

I basically use reduced C++. I don't try and use its features for the hell of it, like i've seen a number of times in the industry, i use what is useful. For example,

- I only use templates in a few core places (lists etc)
- I don't use STL anywhere.
- I don't use inheritance anywhere, i am favouring composition.
- I don't use function overloading.
- I don't use constructors for anything other than initialising members. I have Init() and Close() phases.
- I use global pointers to the main 'managers' in my project.
- I use public members if i would otherwise be writing transparent getter/setter methods.

Essentially, there are some good things about C++ and some bad things about it. You have to learn for yourself and experiment for yourself in order to learn these things. I have gone full circle, i was once a C++ purist, but i found writing pure C++ largely counter-productive. I just want to be productive and so should you.

Have fun!

[valderman]

Java won over C++ because of garbage collection.

I disagree. Java is a mid-level language (for lack of a better word since it's neither really high nor low level) whereas C++ is a low level language with pretend OOP. Mid-level languages with Java leading the way kicked C++ out of a lot places, but there are a few niches where C++ is still useful.

[typedef struct]

Anything you can do in C, you can do in assembler with a bit more effort. Always use the highest level/most productive tool you can*. Time wasted doing stuff in C that "requires a bit more effort" is time that could better be spent adding features, polishing the design, etc. .

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

[rip-off]

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

Many people would find C++ to be some bit more productive than C. I certainly do, maybe between 2x and 5x depending on what I'm doing (e.g. string manipulation). I find Ruby to be hugely more productive than C++, but I can't always use Ruby. Still others might be more productive in assembler. It depends on the individual, provided they remain aware of the "Blub paradox".

[SiCrane]

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?

[Fiddler]

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

Many people would find C++ to be some bit more productive than C. I certainly do, maybe between 2x and 5x depending on what I'm doing (e.g. string manipulation). I find Ruby to be hugely more productive than C++, but I can't always use Ruby. Still others might be more productive in assembler. It depends on the individual, provided they remain aware of the "Blub paradox".

One could argue that your 2x-5x increased productivity evaporates while waiting for the code to build.

[farcodev]

Since i'm a Pascal/Object Pascal man i don't use C/C++/C#.

I use VS only for compile some project of other people and dev in .Net w/ Pascal.