gametutorials now charging

people will always try to make money. the sad thing is what people will pay money for

The age of information.

/nuff said.

Not sure if you guys know that there is an archive of the tutorials maybe go get them while you can:

http://web.archive.org/web/20040109222147/www.gametutorials.com/Tutoria…

Cheers
Sam

Just had a peek and it seems that the page is archived but the actual files you need to download are not.

I think it would've been easier to charge for membership and then have free reign over the articles rather than per article. Especially since they're not really their articles, just ones that people have contributed.

Solution: Write some articles for Sumea ;)

quote:Originally posted by redwyre

Solution: Write some articles for Sumea ;)

Now -that- sounds like a very good idea. [:D]

Now which one of you is going to do it?

Considering some of their tutorials were about for loops I am sure even someone who'd read to chapter two in a programming book could do a tut on that ;)

And USF has already done a hello world for us!

Don't know how serious you are, but I might do one on template meta-programming and compile time polymorphism if enough people are interested.

You might as well, it'd be interesting to have it as a reference if nothing else... :-)

I know what you mean, those compile errors from template meta-programming are not nice :(

What I'm working on atm is a meta-programmed memory pool based allocator- it's a container of pools, each of which is specialised for a particular size chunk of memory, and using compile time calculations to find the most appropriate pool to allocate an instance from i.e. getting rid of the run-time search.

So you get something like this

class MyType
{
public:
void* operator new(size_t size)
{
return Allocator::alloc(); //size arg not used
}
};

Of course this means that you would be in BIG trouble if you didn't overload new on every derived class. Still pondering. The pool allocator is done, it's the best way of doing the meta-programming that's taking some time.

The result should be dynamic allocation as fast as stack allocation, and I'm doing it because I'm developing a realtime scripting language where every object lives on the heap.

These accidental features are what keeps c++ interesting [:)]

Compile time polymorphism I might as well do now:

template
class Furniture
{
public:
inline void drawFurniture()
{
reinterpret_cast(this)->draw();
}
};

class Chair : public Furniture
{
public:
inline draw()
{
//actually do the stuff
}
};

How it works:
this Chair : public Furniture strangeness is called the "curiously recursive template pattern". In this case the only thing I'm using the template parameter "Chair" for is so I know in the base class that this class is actually a chair, which makes it safe to reinterpret_cast the this pointer to a Chair pointer, and call methods that are inlined in Chair.

Why would you do this sort of crazy stuff? Performance- virtual functions (and calls through function pointers) can defeat the branch prediction algorithms in CPUs, and the Prescott has around a 30 stage pipline. That means a virtual function call can be expensive. Virtual calls and function pointer calls also present problems for optimisers.

The problems with this technique are:

*Bigger code size caused by more inlining- but caches are only getting bigger
*You can't have an STL container full of Funiture pointers, because each becomes a different type due to the template parameter.

Comments please (and if someone knows how to stop sumea mangling code that would be great)

You can do lots of neat stuff with templates. A personal favorite is this,
used to allow a single base type to be used for derived templatized
types that are passed from the constructor of an object.

[code]
struct DelegateBase
{
virtual void Exec() = 0;
};

template
MethodBase : DelegateBase
{
typedef ReturnT (Object::*MethodType)();

MethodBase(ObjectT& o, MethodType ptr); // Stores method and object.

virtual void Exec() { if (m_Method) m_Object.*m_Method)(); }
};

struct Method
{
template
Method(ObjectT& o, ReturnT (ObjectT::*ptr))
: m_pBase(new MethodBase(o. ptr))
{ }

virtual void Exec() { m_pBase->Exec(); }
};
[/code]

So, this allows us to store:

[code]std::vector methods;[/code]

And still gain the benefits of having the types available when we use the
object.

These extracts from a C#-like delegate, (source available if interested)
and the interface is along the lines of:

[code]
typedef Event MessageEvent; // Takes a string.
MessageEvent OnSomething;

OnSomething += MessageEvent::Function(&PrintMessage);
OnSomething += MessageEvent::Method(Foo::GetSingleton(), &Foo::PrintMessage);

OnSomething(); // Calls Function(string), and Foo::GetSingleton().PrintMessage().
[/code]

Using the above method was required to store a list of the attached
methods and functions bound to the event, and allowing each to have
a seperate return type that is ignored. I'm sure there are many more
cases like this where the technique can be used.

Ignore kalin, he can't code.

I presseded the complile buttons and the compilers says mean things to me about the C++.

[edit]
But really, there are some errors/omissions in the above post.

Method's Exec() is should not be virtual.
'm_pBase' is of type boost::shared_ptr

Probably numerous that I didn't notice, the actual source works,
that's just a snip anyway. ;)

Well the meta-program is up and running, hopefully I should have the whole mempool thing working next week sometime. The meta programming has crazy stuff like this small sample:

[code]
//////////////////////////////////////////////////////////////////////
// Calculate (compile time) the number of pools required //
//////////////////////////////////////////////////////////////////////
template
struct PoolCount
{
enum { value = 1 + PoolCount::value }; //will hold the number of recursions
};

//This terminates the above loop at Size==MinChunkSize
template <>
struct PoolCount
{
enum { value = 1 };
};

//provides easy access to the compile time calculated number of
//pools with noOfPools::value
typedef PoolCount noOfPools;
[/code]

And the syntax used to allocate will be void* mem = Allocator::alloc() , and memory gets freed by an overloaded delete operator. I'll post the full code with detailed explanations (including the runtime pool) in a thread when done.

Anyone got any ideas why the "code" formatter isn't working for me?

Gotta use a forward slash for the closing code tag

ta

Yeah, I wouldn't use templates all over the place normally, but in some cases (where an increase in compile time means a decrease in runtime in a subsystem that's used all the time) I think it is worth it.

Another example is the scripting language I'm making- it's completely full of template code, primarily to make it really easy to extend with new types, and to automate much of the wrapping and type conversion.

Nothing to say