[beagle3]

> Why code this all by hand when the language can do it for you at no penalty? The only penalty I see in C++ for using classes or polymorphism is that it produces longer symbol names (w/ the type mangling)

There are other penalties which people who write C++ are oblivious to. For example, switching the class of an established object in runtime:

Suppose you have two compatible class layouts (same field order and types, different methods). When you implement dispatch yourself, switching the behavior is a simple matter of replacing the vtbl pointer from one class to the other (I'm not sure Linux VFS does this, but it's common enough in C object systems).

Whereas if you use C++, the standard solution is to break this into a dataless "strategy" object (which can be changed independently of the data) and a data object which contains the state. If you never had the luxury of doing something like "if (obj->class == Living) obj->class = Zombie", you don't miss it, but it doesn't mean you're not missing out on some flexibility.

> Of course, just because you're using classes doesn't mean you're doing any useful object-oriented programming.

Furthermore, just because you are doing object-oriented programming doesn't mean it is useful. (And a purist would say, just because you are doing programming, doesn't meant it is useful)

> Right now, you'd have to do a lot of convincing to get me to write native code in straight C again.

I've switched to C++ in 1993 and back to C in 2004 when compile times with boost started to measure on a geological time scale and single error messages spilled onto my 2nd screen -- and haven't looked back. When a write GUIs, I do use FLTK which is C++ (very effective, but not idiomatic), because I haven't seen a GUI toolkit as good that's native C -- but other than that, I don't miss anything, and I'm not less productive.

C++, the language, has a lot of useful tools, but C++, the ecosystem, guarantees that in any nontrivial project you'll be thrown into the tarpit. In my experience, the overall effect of C++ on a project is negative. YMMV.

[SomeCallMeTim]

>In my experience, the overall effect of C++ on a project is negative. YMMV.

Curious: What's your domain?

In video games where there are a lot of "objects" floating around that can really benefit from polymorphism, the type checking that C++ can do that C can't really gives you a huge development bonus.

Of course I'm saying this having moved past C++ for 99% of the development into an elegant and tiny scripting language called Lua, where you can do just about anything (including having an object system that you can change an object from one type to another trivially if that's what you want).

[beagle3]

> Curious: What's your domain?

I switch every couple of years. Most recently: Image analysis; previously: Big data analysis; Before that: financial mathematics ("quant") and trading systems. If I go back long enough to '91-95: Game programming (SNES and PC); although I've been somewhat involved in game programming and related projects as late as 2008.

> In video games where there are a lot of "objects" floating around that can really benefit from polymorphism, the type checking that C++ can do that C can't really gives you a huge development bonus.

Only if your logic is written in C++ as well. In the projects I was involved with, most of the logic was actually data driven or scripted, and C++ contributes much less in that scenario.

I don't deny C++ has its uses. But it also has a lot of drawbacks. Whether or not the net is gain or loss compared to $LANGUAGE, is subjective. For me with $LANGUAGE=C, it is negative. YMMV.

[berkut]

Hmm, a friend of mine from Criterion said that in two of the last games they did, they had to re-write the Lua parts (fairly significant) in C++ to get the framerate high enough as it's memory fragmentation was just too much.

They went from ~34 fps to ~60 fps for 4 developer weeks re-writing the Lua code.

[beagle3]

Ask them if they were using LuaJIT2; they probably didn't -- it's relatively new (only been stable enough for real work for less than a year).

It is ludicrously fast. It usually loses to optimized C / C++, but by no more than 10-20% -- and you have essentially no restrictions whatsoever on the Lua features you use; Furthermore, it's FFI makes interoperating with C / C++ a superfast breeze, dropping the FFI overhead to zero.

And even ignoring LuaJIT2 -- they probably took less time and got higher quality overall by going through Lua (assuming programmers were equally versed in Lua and C++, and the infrastructure was reasonable) -- it's easier to iterate and debug with Lua than it is with C++.

[SomeCallMeTim]

LuaJIT2 is awesome, but it still uses the Lua 5.1.4 garbage collector, so if the problem was GC related (i.e., memory fragmentation), then LuaJIT2 wouldn't help much.

OTOH, changing how you do things in Lua CAN be a big help in not generating garbage. I love the ability to ignore memory allocation in Lua, and I'm annoyed that I have to deal with thinking about it, but at least it's pretty straightforward.

Also, depending on the game, you can nuke your Lua allocation every level/section/other segment, allocating Lua memory from a memory pool. That can also help a lot with fragmentation.

But if you're doing a game that's one continuous experience, you have no choice but to be careful with managing memory. Again, it CAN be done from within Lua (think object pools), and that could be easier than porting to C++. And with LuaJIT 2, it would likely be fast enough in that case.