Messages

166

General / Re: C2248 NonCopyable error in Mutex.hpp, even though I'm not using mutexes

« on: April 29, 2012, 08:39:31 pm »

For types that are movable, there are two cases where objects can be moved implicitly: RValue expressions (e.g. arguments for a function) and function return values. In other cases (concerning LValues), std::move() is required to transfer ownership.

Hence why I said generally =) I actually had a whole paragraph explaining when it does move implicitly but got bored of writing it half-way through xD Probably should of gone into the full detail...

167

General / Re: C2248 NonCopyable error in Mutex.hpp, even though I'm not using mutexes

« on: April 29, 2012, 03:02:51 am »

Note: this may not be true anymore in C++11 with move semantics, I don't know.

They provide both copy and move functions, so if it's movable you can store a non-copyable object in a standard structure such as a vector or a map.

Buuuut unless you explicitly defined those move constructors, and deltaphc is explicitly moving it onto the map (via std::move) it'll try and copy it. C++11 generally will not move without being told to.

168

General / Re: Clock and openGL

« on: April 29, 2012, 02:57:15 am »

Also to pop my head back in: http://gafferongames.com/game-physics/fix-your-timestep/
I need to bookmark that page I pass it around so often.

169

General / Re: Clock and openGL

« on: April 26, 2012, 12:03:06 am »

With your code, x will increase exponentially and your animation will be jumping ahead by multiple frames every update. GetElapsedTime gets the time since the program started, which is constantly increasing. You want the change in time between the last call and this one.

170

SFML projects / Re: Thor 2.0

« on: April 16, 2012, 09:53:00 pm »

Don't most IDEs have an option to treat n spaces as a tab when editing but stored as n spaces when saving?

171

SFML projects / Re: Thor 2.0

« on: April 11, 2012, 09:49:19 pm »

Well it's not 1-byte per class, it's one byte per class which has the get_info function used on it. Still not ideal.

Ah, my bad about the std::size_t. In the actual implementation I use I specifically define a set of integrals such as int32, int64, and I have one defined which is guaranteed to be at least the same size as a void*.

Basically I did a bunch of template specialisations for each possible size and it's all checked by static_asserts at compile-time so if you did try and use it on a system that has issue with it, it'll just not compile. But then that can be overriden by a define and providing the correct specialisations and...I'll never win one of those "small program" challenges since I do way too much template metaprogramming xD

My point about HANDLE was it does hide the fact that it's a void pointer from the user. How many times do you think people even notice it's void*? I could of done typedef void* typekey. I mostly went with std::size_t to demonstrate the concept and because here it works fine and gets across the "not a void*, not to be treated as a void*" concept.

I used reinterpret_cast because it's a copy bit-for-bit into an integer. That's when you use reinterpret_cast.

My actual implementation does some things to hide this inside a class, and has macros and functions to let you completely ignore whether you're using the built in RTTI or this system...again, never gonna win a smallest program contest.

As for string comparisons, I'm of the opinion that if you can avoid string comparisons, avoid them as a matter of design. Especially since a map is going to be a common place to store a typeinfo which means a lot of string comparisons. Heck, my wrapper for standard C++ works by hashing the name first, and comparing that to reduce the number of string comparisons greatly.

Anyhoo, getting waaaaaaaaaay off-topic xD

172

General / Re: Time-based movement: recommended?

« on: April 10, 2012, 05:14:16 pm »

A very good article on timesteps and fixing them can be found here:
http://gafferongames.com/game-physics/fix-your-timestep/

173

SFML projects / Re: Thor 2.0

« on: April 10, 2012, 04:27:22 pm »

I was under the impression that with Windows DLLs it's still an issue, in that the comparisons can only reliably be done on the name and not the address of what is returned by typeid(X). I'd consider this a problem, especially if you're using it somewhere that performance matters. If I'm wrong that's great, now they just need to find a way to propagate exceptions across DLLs...

Either way, the purpose of avoiding RTTI tends to be how RTTI still adds ~40bytes of overhead per virtual destructor. As opposed to this, which only adds 1byte of overhead to the static memory per class actually checked. Especially on an embedded system that could really make a difference. And then some programmers just switch it off and refuse to work with it, so whilst you could just say "well screw them then", ideally would want to be able to do something in that situation if you're making a library.

Sure, you could use void*. You could use char*. It's just that makes it clear you're dealing with a pointer, not some magic number. Usually if you return a pointer, then in my opinion it should be expected to do some pointer things to that pointer. Here you aren't and never would need to, unless you were stretching for single bytes to use in the worst possible way in which case the drawing board is over there, go back to it.

The Windows API hides this via a typedef (such as HANDLE), I hide it inside an integer. It's not a problem on any compiler I know of, as one of the requirements of std::size_t is that it is large enough to hold the value of a pointer and casting a pointer to an integer is one of the main uses of reinterpret_cast.

174

SFML projects / Re: Thor 2.0

« on: April 10, 2012, 01:14:48 am »

For GCC 4.6, well 4.7 now, you can download it with Mingw for windows at http://nuwen.net/mingw.html

@MorleyDev: How can you get a unique ID for a class without RTTI? You need to register the types manually or require a special interface, don't you?

You can essentially "hash" a type/class like this:

Code: [Select]

template<typename T> std::size_t get_id()
{
static char id;
return reinterpret_cast<std::size_t>(&id);
}

The address of id will be the same for the same values of T, but different for different values of T. It has some problems with dll boundaries, but so does the built in C++ RTTI.

If you wanna cross DLL boundaries, use a functor and provide specialisations with unique ids for each specialisation.

175

SFML projects / Re: Thor 2.0

« on: April 09, 2012, 08:10:43 pm »

It doesn't use RTTI. It creates a deleter at initialization, where the dynamic type is known. Using type erasure, it can call it later. I've also implemented this technique in Aurora's CopiedPtr.

Sorry I meant my Resource Manager uses RTTI or fake RTTI internally, not shared_ptr does xD Shoulda been more clear about that, my bad. I always try and provide a way around using built-in C++ RTTI simply because I know people don't like it due to the overhead.

A simplistic fake rtti can reduce the overhead from 40-bytes per class to 1-byte per class that is checked. Don't use it, no overhead. Though it doesn't have the benefits of being able to tell the super class of a reference...You may even be able to take that overhead out if with some template specialisation tricks.

176

SFML projects / Re: Thor 2.0

« on: April 09, 2012, 04:02:04 am »

So each Resource has it's own manager? Huh, different to my approach where I centralised it so a single resource manager can load any resource, even user defined.

Basically stores
-map of loaders for each type
-map of type/object pair for each name.

Internally it stores things as std::shared_ptr<void>. The awesome thing about std::shared_ptr<void> is it still calls the correct destructor.

Internally it then uses some form of templated Type-to-Identifier to determine which loader to use and make sure it's casting things back to the right type. This defaults to either RTTI or a really simple fake RTTI.

Externally a function like template<typename Type> std::shared_ptr<Type> getResource<Type>("filename") is exposed to the user.

Ideally this lets me store all resources in a central location, whilst keeping the end result type safe.

177

SFML projects / Re: Aurora

« on: April 06, 2012, 05:20:04 pm »

I especially like the dispatcher. But how's the smart pointer any different from the generic solutions in C++11 and Boost?

As I understand it, it copies the value into a new heap allocated object. shared_ptr copies the reference and increments a counter, unique_ptr can't copy but can move the reference.

178

Feature requests / Re: Request: Exceptionhandling?

« on: March 30, 2012, 08:10:28 pm »

The C++ 2011 standard provides std::exception_ptr, see this MSDN page for example.

That's it! I was trying to think of the thing they added. I'm correct in that the join point is specifically when std::thread rethrows, yes? As I understand it still has to be done explicitly (as std::thread does), but it does at least make it easier...

179

Feature requests / Re: Request: Exceptionhandling?

« on: March 30, 2012, 07:37:10 pm »

By the way, I don't know how well exceptions work across threads.

std and boost thread both catch any exceptions thrown in the thread, and then rethrow them when a join() is called. That's how they pass them to different threads. If it's not done by the code explicitly like that, I think it's undefined. It could just vanish into the abyss and the thread ends, or it could die and take the whole program with it. I'd hope it does the latter, but fear it'd do the former.

I don't know if SFML does something similar with sf::Thread. I try to use std::thread or boost::thread if that's not available (like on windows) with wrappers around boosts differences to bring them in line with the standard.

Personally I've always felt exceptions were for exceptional circumstances in C++, places where you very much want the whole program to be potentially aware of a critical error and all pre-tense of encapsulation to be broken. Places where the best thing for your program is probably to just kill itself as quickly and messily as possible. So for me they've always been for if things go wrong at a fundamental level, like running out of heap memory. Otherwise, avoid.

This has the downside of not being able to identify specific problems when multiple things can go wrong, but the afore-mentioned override method could work for that if you care (of course in an ideal world, each function would only have one possible error xD). Or maybe instead of a reference, take a pointer that defaults to null. If it's null, just fail. If not, store specifics in that which it points to. Perhaps uglier, but less writing at least xD

Just my 2 pence.

180

SFML projects / Re: TGUI: a c++ GUI for SFML

« on: March 27, 2012, 07:50:57 pm »

I guess you could set it up for gcc so all they have to do is CD to the folder in the command prompt and run make? The most complex part of that is ensuring that make is in your path.