Jump to content

  • Log In with Google      Sign In   
  • Create Account

Aardvajk

Member Since 02 Mar 2006
Offline Last Active Today, 11:52 AM

Posts I've Made

In Topic: c++ should nested switch statements be avoided?

24 April 2016 - 01:43 AM

Here's one from the innards of my virtual machine for handling math operations (+, -, * and /) on an exploding number of combinations of different types. I don't think there is anything wrong with this personally, others might disagree.
 
template<class T> bool operation(State &state, const TypedValue &a, const TypedValue &b, TypedValue &c, Om::Value &res)
{
    switch(a.userType())
    {
        case Om::Type::Int:
        {
            switch(b.userType())
            {
                case Om::Type::Int: return op<T, int>(state, Om::Type::Int, a, b, c, res);
                case Om::Type::Float: return op<T, float>(state, Om::Type::Float, a, b, c, res);

                default: break;
            }

            break;
        }

        case Om::Type::Float:
        {
            switch(b.userType())
            {
                case Om::Type::Int: return op<T, float>(state, Om::Type::Float, a, b, c, res);
                case Om::Type::Float: return op<T, float>(state, Om::Type::Float, a, b, c, res);

                default: break;
            }

            break;
        }

        case Om::Type::String:
        {
            if(T::type == Addition && b.realType() == Om::Type::String)
            {
                c = TypedValue(Om::Type::String, state.allocate<StringEntity>(state.entity<StringEntity>(a.toUint()).text + state.entity<StringEntity>(b.toUint()).text));
                return true;
            }

            break;
        }

        default: break;
    }

    res = Om::ValueProxy::makeError(state, error(a.userType(), b.userType()));
    return false;
}
It is templated on structures like Add, Sub etc, so the same method can be used for all math operations via compile-time polymorphism.

In Topic: How beneficial can personal projects be?

15 April 2016 - 01:24 PM

My 2D platform game and level editor got me a job developing business software.

I wouldn't personally hire a programmer who didn't have personal projects. If all you showed me was coursework, I'd assume you lacked the passion we all share here.

In Topic: Is inheritance evil?

15 April 2016 - 01:21 PM

Of course it isn't. It's s tool that can be used or abused.

Even deep inheritance trees can be appropriate in certain domains. Look at something like Qt for example.

There is, though, a huge amount of very bad OOP out there and a great deal of confusion about the is-a and has-a relationships.

But inheritance itself is not the cause of this. Personally I blame Java :).

In Topic: How to handle a collision in a physics library and OOP?

13 April 2016 - 02:12 PM

It's pretty common for a third party physics library to use some kind of void user data pointer to allow you to link back a physics object to your game object and while this is generally a bit icky, it's not really solvable in any other general purpose way without introducing unnecessary overhead.

I tend to wrap the physics library (Bullet in my case) in my own thin wrapper that hides such activity away in a central place and makes it generally more compatible with the rest of my code. I dislike using a third party API directly in the parts of the code that just use the physics.

With the void pointer, I only ever assign one type of pointer to it, so in a way I (the programmer) do "know" the class type, even if the compiler doesn't. Rules like this are hard to treat as set in stone in the real world.

Rather than dynamic_casting to lots of different classes, can't you abstractify the things the physics needs to know about into the base class and just treat all your objects as this base inside the physics code? Seems unnecessary for the physics to need to know the exact class details for every object to me.

In Topic: I need a book (or somebody's project source code) which properly explains...

13 April 2016 - 01:54 PM

Looking at the source code for a game always seems to a beginner like it should be a great way to learn, but experience tells a different story.

Understanding is far harder to gain from a dense bunch of code than from reading a well written article or chapter on the subject.

Decide on a realistic target then just start programming. As you encounter each specific problem, break it down into the smallest sub-problems you can then research how to solve each specific sub-problem, one by one. Compare multiple solutions and decide which suits you best. There is rarely one correct answer.

OOP is a tool to solve problems. You need to be fully aware of the problems before there is any chance the solution will help you or make sense.

For that, you need to make lots of mistakes, follow lots of wrong paths and abandon lots of bad code. But when you understand the problems you have created for yourself with bad design, next time you can do better.

Good luck.

PARTNERS