Tracking hidden duplicate code

[AReichl]

found this on CodeProject:

http://www.codeproject.com/Articles/831 ... icate-code

[mongoose7]

Translated from Chinese?

It's a stupid criticism of Irrlicht, which has many functions which do the same thing, but with different signatures. Isn't this a feature of C++?

Stupid.

[CuteAlien]

No, doublicate code is generally bad. I spend some time in 1.9 already to remove a lot of places with nearly doublicated code for texture-loading for example. It meant all our meshes had loaded textures in similar, but slightly different ways. And nearly each one was having it's own bugs. But it's not always easy to clean that up - I haven't even managed to fix all loaders yet as some have approached the same problem so different that it's no longer easy to figure out (as I wrote none of this code I have to work my way through such stuff line-by-line trying to understand what the authors tried to do so I don't miss anything...).

But the first examples are all about burnings renderer. I simply don't dare touching that. Not sure about the stuff in the other material renderers, haven't checked yet.

There's one more place which has lot's of doublicate code and that's in the particle-system. All the emitters should need some kind of base-class I guess. But tricky design as that base-class should also be accessible from the outside if possible so custom particle emitters can use it. Might have to be done similar to the SMeshBuffer implementations maybe.

And then there is the text-breaking in the GUI. Which is done in all kind of places and again each time slightly different. Something I hope to work at for a long time already, but never find enough time (I started a few times on that already, but each time run into other bugs on the way which needed to be fixed first *sigh*).

@ AReichl: Thx for the link, I haven't heard about this tool yet.

[AReichl]

Was NOT meant as a criticism of Irrlicht (at least not by me).
More as a help to make it better.

There is another place (don't find the link anymore), where they compared big projects written in C (e.g. Linux) compared to C++.
Result: C++ has more "features", but it's harder to change something later in the process.
Irrlicht was shown as an example of how to combine the best of both worlds; it's C++, yes, but also (easily) modifiable and extensible.
Maybe that's the reason why there are so many "mods" end extensions around, something you won't find with any other engine.

I am bringing this up, because i am still searching for "the engine" for "the space game" i am dreaming of for decades now and the
world is waiting for ( in that time i actually could have DONE some programming, but that's another story ).
The point is, NO engine has what i need, so at one point in the development process i have to program something anyway. And THEN
the struggle begins - CAN i do it or do i have to fight AGAINST the engine?

[CuteAlien]

I also think about writing the perfect engine some days. But I wait for the perfect programming language to arrive first. Every language seems to be missing something ;-)

[AReichl]

No new language needed - C++ can "emulate" every other language. And you are not bound to a specific paradigm (like Java or C#, where everything IS an 'object').

I have learned or played around with several languages. ADA is the best and safest, but not very common.
Stay with C++. Learn the new things in C++11/14 and use them (gcc 4.9, Visual Studio 2013) - makes a BIG difference.
Irrlicht is fine because it also compiles with older compilers, but in the future you could rewrite parts to use newer language features (e.g. smart pointers, algorithms, move operations [speed!], ...).

And because this thread has gone off-topic somehow (my fault), i have another idea:
There are many modifications of Irrlicht out there. Some are said to be better in one ore more aspects. Would it make sense to analyze them and "backport" parts?

[CuteAlien]

Yeah, it's just one of those excuses, obviously neither the perfect language nor the perfect 3D engine are possible. Thought there is some stuff where c++ actually has weaknesses - you can work around them but it makes the code uglier. For example in the D programming you can use the whole D programming language to do metaprogramming. That's far nicer than the kind of template hacks people use to do the same in c++. And because of c++ is so hard to parse and it's crazy type system even the best IDE's still have troubles with stuff like code completion and refactoring support. Which makes also tools like CCFinderX harder to write (yay, we're back to the topic ^_^).

I'm not familiar with the Irrlicht spin-off's, so can't really say anything about those. But it's generally hard to merge other people's code unless they actively help.

[AReichl]

D! - i forgot about that one.
Now we only need a "decent" compiler for it. Maybe gcc one day will support it.
What about "Go" (from Google)?

[CuteAlien]

I don't really know enough about other modern languages, just reading through articles about them and feature-lists. On first view Go looks like a very interesting server-side language to me. Given that it doesn't allow manual memory management and has no metaprogramming support at all it's probably not such a good choice for games.

Rust might be interesting in the future, thought again a little weak on the metaprogramming side from what I read so far. Only c++ competitor which got that right seems do be D.

[Marthog]

Rust might be interesting in the future, thought again a little weak on the metaprogramming side from what I read so far. Only c++ competitor which got that right seems do be D.

Rust's generics are quite powerful and it's the best system i have ever seen in an object oriented language. It combines haskells typeclasses with javas interfaces, but the second one only if needed and explicitely asked for it.
The only downsides are missing generic integers and constant expressions, so you can't do something like boost::static_vector.

And of course rust is still work in progress so currently no stable features, no bugfree-guarantee, some optimizations are missing, no IDEs, no specialized tools for refactoring and bug searching (although still easier than in C++ because of clearer error messages).

[CuteAlien]

Generics are useful. But real metaprogramming starts when you can use the meta-language to generate code and not just fill in types. C++ accidentally got a turing complete language with templates, but it's close to unusable as it was never planned (and still some people work with it). While in D you can use D itself for meta programming.