Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Roter_Fuchs

Pages: [1]
1
General discussions / Re: SFML Game Development -- A book on SFML
« on: January 09, 2014, 11:53:17 pm »
Following your argument, assertions would be generally pointless, since every bug can eventually occur in Release mode.
If you use them as an error handling tool only, then yes. But I view assertions more of a tool designed to help the software engineer to track down bugs, rather than handling them.

The problem with using exceptions is that you can't do anything meaningful at that time. As it's not a runtime but rather a logic error, you don't know what went wrong, and as a result, everything you do to react to it can make things even worse. From that time point, the application state is corrupt.

Keep also in mind that ResourceHolder::get() is not the place to say "missing resources" (since they must have been loaded in advance, by design); this check was performed earlier in load(), and covered with an exception.
No, they must not have been loaded, they should have been loaded. Let's assume we're dealing with a large game. Let's also assume that for some reason a load call to a resource has never been made (thus an exception could never have been thrown). May it be because someone accidently deleted the load call or it was never there to begin with. It doesn't matter why. It only matters that it is missing.
Of course an assert can help in debug mode to track down that error, but only if that special part of the game is being tested. And keep in mind that it's a big game. So chances are that it might not be tested at all.

Naturally this a constructed case. But one that can actually happen. In this case the design choice can lead to a crash for the end user. And that is something you should avoid at all costs.

2
General discussions / Re: SFML Game Development -- A book on SFML
« on: January 09, 2014, 10:47:03 pm »
Yes I did and I can understand your reasoning. But you justify the design choice with an assumption: The logic error will (or should be) tracked down in debug mode. In reality though (especially with large projects) you can not and will not track down all such bugs prior to release. So in the end users might be confronted with crashing software instead of just default or missing resources.

3
General discussions / Re: SFML Game Development -- A book on SFML
« on: January 09, 2014, 10:13:51 pm »
Hey everyone,

the book really gives insight into some nice concepts. But I have a question concerning the ResourceHolder class template.

template <typename Resource, typename Identifier>
Resource& ResourceHolder<Resource, Identifier>::get(Identifier id)
{
        auto found = mResourceMap.find(id);
        assert(found != mResourceMap.end());

        return *found->second;
}

Why is the only error checking that's being done here an assert? Once we go into release and turn debug mode off, the found iterator may as well point to one-past-the-end. Shouldn't we always make sure that it is not .end() before using it?

Pages: [1]