Someone is bypassing permissions on the bug tracker!

[eRe4s3r]

For me language just needs to compile properly and fail gracefully, when a bracket is open I want to be told where, the line number at least. If a language can't do that, I don't use it.

As you can guess, I don't "code" much ;p

[LintMan]

Yea, C has lots of gotchas, and its minimal sanity checking also means it is very easy to mess things up and not know about it for a long time. Also, its single, unified namespace can be a big pain in the but

It's not entirely a single unified namespace.  Using the static keyword, you can restrict a global variable's scope to the current compilation unit.  ie: if you declare
static int temp1;
in multiple .c files, all linked together, then each .c fill will have its own unique temp1 variable.  Similarly for functions.  So each .c file can essentially have its own namespace (albeit not a conveniently as more modern languages).

C++ has many of the same gotchas as C does plus like 3 times as many on top of it. C++ is very powerful though.

C++ gets a lot of bad rap these days, so let me defend it a bit...

C++ fixes a lot of the basic gotchas of C because it is much more strongly typed.  Even if you're writing a straight C program, there's almost no good reason not to compile it as C++ just for the better typing protection.

A lot of C++'s gotchas are because it leans towards "we'll give the programmers the power and flexibility to do almost everything, even if that will also allow them to shoot themselves in the foot" and is also a is a "kitchen sink" language.  It layers all sorts of newer concepts (ie: overloading, classes, single AND multiple inheritance, templates) on top of the existing C language, all while retaining 95+% C back-compatibility, keeping all these different programming methodologies viable, and being suitable for adapting to everything from the latest supercomputer down to a real-time embedded soft-core FPGA processor that has only 1 megabyte of RAM and no multithreading or virtual memory.

That last bit is a lot of the reason C++ lacks a lot of the built-in high level features that many other more-focused modern languages have.

Now, my least favorite language that I actually worked with is FORTRAN 77.   I had to port a large engineering application written partly spaghetti-style by non-programmers from F77 to C++.  GOTO's.  No data structures.  Nearly everything global.  3-way conditional branching.  Specialized math functions that don't exist outside of FORTRAN.  What a nightmare.

[Hearteater]

Not that I agree with his conclusion, but this article was always pretty interesting to me on C++.  And I've used C++ for more than 10 years.

[keith.lamothe]

Not that I agree with his conclusion, but this article was always pretty interesting to me on C++.  And I've used C++ for more than 10 years.

That is interesting.  I think he does have a point with:

Empirically, I have found it very difficult to find even experienced C++ programmers capable of correctly writing a simple C++ class containing a pointer.

I wouldn't say that's an open-and-shut case for not doing large projects in C++, but if it were me and I had to run something like that, I'd make sure they knew how to use the safer pointer wrappers (no small task) and post signs with "You Write Raw Pointer, We Delete You" in large bold type on the inside and outside of every programmer's door (delivered free of charge as a courtesy to anybody working from home)

I forget if you said; are you writing that procedural-world tactical RPG in C++?

[Hearteater]

I'm using C# and XNA.  This is actually my first C# project, although I've used enough languages that picking up a new one isn't all that big a deal anymore.  So far I've very happy with C#.

[keith.lamothe]

I'm using C# and XNA.  This is actually my first C# project, although I've used enough languages that picking up a new one isn't all that big a deal anymore.  So far I've very happy with C#.

Yea.  I happen to think C# the best language I've ever seen, but that's just me

And you could do worse than XNA for a framework, though I tend to be nervous about stepping into a situation where I'm bound to someone else's code.  We use Unity (it's absolutely awesome for deployment in terms of cross-platform and no-prerequisites), but we do our own thing so much of the time it's pretty funny.  At this point we even have our own outside-Unity build process for most build cases.

[Hearteater]

I strongly considered Unity, but the free version wouldn't work for this project and I couldn't justify the cost for the full version at this time.  It would be great to avoid the .NET dependency and associated installation issues, not to mention get (relatively) easy cross-platform builds.  But even all that aside, the alt-tab issue is a deal killer for me.  I suspect I could do some simple C++ code to detect it properly, but then I'm losing cross-platform support.  At that point I'm paying around $2000 to not have to install .NET.  If they ever get over that issue I will certainly re-investigate.

The other huge XNA advantage is if we decide we want to make an XBox version.  But that's for way down the road, and the costs look prohibitive enough I'm not certain we'd even go that route.

[LintMan]

Not that I agree with his conclusion, but this article was always pretty interesting to me on C++.  And I've used C++ for more than 10 years.

Very interesting article.  On my last big "do it the right way" C++ project, we had to address all those same concerns he discusses, and more.  But the level of concern is rather overinflated, IMHO, for a few reasons:

- STL containers or equivalents from other libraries remove a lot of these pointer concerns.  He admits this, but then doesn't follow through to the logical conclusion that pointers aren't nearly as fundamental, necessary or prevalent in C++ as in C.  The first thing I thought when I saw the first iteration of the solution was "why aren't they using string (STL) or CString (MFC) or the like?".  I suspect he steered the candidates into that minefield by disallowing that option.
- For a large a project of the type he describes, there should be coding standards that disallow the use of pointers for class members unless there are exceptional circumstances.  Also, all the class design/architecture should be group reviewed, with the most complex parts (such as the stuff that actually needs pointers) handled by the best/most experienced team members.

[Cyborg]

Not that I agree with his conclusion, but this article was always pretty interesting to me on C++.  And I've used C++ for more than 10 years.

Very interesting article.  On my last big "do it the right way" C++ project, we had to address all those same concerns he discusses, and more.  But the level of concern is rather overinflated, IMHO, for a few reasons:

- STL containers or equivalents from other libraries remove a lot of these pointer concerns.  He admits this, but then doesn't follow through to the logical conclusion that pointers aren't nearly as fundamental, necessary or prevalent in C++ as in C.  The first thing I thought when I saw the first iteration of the solution was "why aren't they using string (STL) or CString (MFC) or the like?".  I suspect he steered the candidates into that minefield by disallowing that option.
- For a large a project of the type he describes, there should be coding standards that disallow the use of pointers for class members unless there are exceptional circumstances.  Also, all the class design/architecture should be group reviewed, with the most complex parts (such as the stuff that actually needs pointers) handled by the best/most experienced team members.

This is all true. Actually, it's not that uncommon for competitive programmers to steer others into minefields in order to make themselves look better to management, increase their own value (or perceived value), and more.