Did Average's suggestion about variadic templates work?

Testing on gcc 4.4, the following works:

Code:

#include <iostream>

using std::cout;
using std::endl;

template <typename FuncType, typename... Args>
inline void Call(FuncType funk, Args... args)
{
    funk(args...);
}

void Zero()
{
    cout << "zero\n";
}

void One(int x)
{
    cout << "one: " << x << endl;
}

void Two(int x, int y)
{
    cout << "two: " << x << ' ' << y << endl;
}

int main()
{
    Call(Zero);
    Call(One, 5);
    Call(Two, 3, 10);
}

Why don't you simply use std::function instead?

What you're trying to achieve have no sense, it's like if you simply were using std::function in code (be it templated or not).

std::function doesn't arrive until C++0x, right?  Or is it in TR1?

Answer: function pointer typedefs, no C++0x needed:

Code:

#include <iostream>

using namespace std;


typedef void (*pF)(void);


template<pF FUNC>
struct C
{
    void doStuff() { FUNC(); }
};

void A() { cout << "I am A!\n"; }
void B() { cout << "I am B!\n"; }

int main()
{
    C<A> ca;
    C<B> cb;

    ca.doStuff(); //I am A!
    cb.doStuff(); //I am B!

    return 0;
}

typedefs really don't solve anything, you're just introducing short-hand, typedefs are semantically null.

This is the same solution as my original example (with operator () ), you've just changed what's being wrapped.

Why do you want to pass the function as a template parameter, as opposed to a real parameter?  Is it for optimization purposes?  That's the only rationale I can come up with.

If that's the case, I'd reckon that making Call inline and passing constant function pointers at runtime would effectively get you the same performance, as the constant function address could be propagated through the inline function.

I'm pretty sure that variadic templates would handle all the parameter concerns, but since I'm not still not boned up on the syntax for those, don't take this as gospel.  I believe it would look something like this:

Code:

template <typename FuncType, typename Args...>
inline void Call(FuncType funk, Args... args)
{
    funk(args...);
}

So the question is, is there any possible way to pass a function as a template parameter without having to specify the function type by hand?  Something like:

Code:

Call<SomeFunc>();   // not valid C++ code

If I understand what you're doing, I believe the answer is no.

One solution is to use classes with overloaded () operators, and use those as "function wrappers."

Code:

class Funk_1
{
public:
    void operator () ()
    {
        // Do stuff.
    }
};

class Funk_2
{
public:
    void operator () ()
    {
        // Do other stuff.
    }
};

template <typename Type>
void Call()
{
    Type()();
}

int main()
{
    Call<Funk_1>();
    Call<Funk_2>();
}

As to the OP, if you don't plan on porting to anything other than the Mac, Objective-C is fine and will probably make your life easier. While GCC and Clang do have a cross platform Objective-C compiler, there isn't a cross platform standard library of sorts that you can use.

Yes there is.

Hello!, I would advice you against coding a real game engine in Objective-C , it can be done , but greatly reduces portability an has some impact on performance.

There nothing non-portable whatsoever about Objective-C.  GCC includes an Objective-C compiler, and you can get that for damn near everything.  The Apple sponsored Clang compiler suite also supports it, and that's cross platform as well.

FreePascal FTW!

Java and C++ here. Cross plat FTW!

Are you insinuating that FreePascal isn't cross-platform or am I reading stuff into your post that isn't intended?

Sorry, but you're just reading into it badly x_x I love all cross-plat langs. I just only learned Java for my cross-plat programming.

To quote Stroustrup, Java is not cross-platform, java is a platform.  Subtle, but important difference.

I discovered that I've been using glXWaitVideoSyncSGI the wrong way for like 6 years.

Moral of the story:  Don't ever trust sample code on the Internet, verify it with the documentation.

It works right now, and I'm happy.

Ada, with some C and Objective-C sprinkled in for libraries that don't play nice with Ada's type system.

This Java project of mine does a lot of drawing, it may be worth a look.  Source code is included.

I don't remember much about how I did it, but it involves drag-and-drop between components, and I'm pretty sure I ended up doing dirty rectangle on this one.

Saltwater is a nasty one too.  I was coming back from a sea deployment (I'm an ex-Marine) and the landing craft couldn't get us all the way to the shore, so a bunch of people had to wade in, many of them carrying laptops.

I was the unit "IT guy," didn't have any fun with that one.

In the end I wound up editing character maps and breaking a number of international standards, but I got my em dash.

Expect UN sanctions.

The thing about functional programming and games is that you're really deliberately using the wrong tool for the job. Games are by their nature imperative and interactive and all that time-dependent stuff.

Something I was thinking about today was process vs. the sampling point. In a game the update ticks are the sampling points; I'm not sure there is a real 'process' in a game that's imperatively written.

It's a similar situation when modeling natural processes. Modeling a river, say (computationally rather than with a physical scale model that is), usually you do it in the same manner as a game. But can you say that the real river acts in the same way? So the question is whether we have no choice to model it the way it's usually done.

I don't mean to get too far out here, but this where I see things going in trying to write games in a functional language.

Maybe the problem is that people are trying to write the wrong kinds of games in a functional language.

Not all games have to be of the event-loop, graphics and input driven model.  Perhaps there are new kinds of games that fit the functional mindset much more naturally that nobody is really exploring.

The Windows API lacks a splitter plane control.  What the hell?

Guess I have to make my own.

I did learn a few interesting things about templates though.  The version of GCC I'm using has issues with implicitly referencing members of a parameterized superclass.  But adding 'this->' fixes it.

All compilers are supposed to do this, because when you have a template superclass, it could be specialized and it's members can't possibly be known in the child class.

Code:

template <typename Type>
struct Parent
{
    int x;
};

// Specialization for int does not have x.
template <>
struct Parent<int>
{
};

template <typename Type>
class Child : public Parent<Type>
{
    void Member()
    {
        x = 5; // Error, x undeclared.  No way to know if the parent class has one.
        this->x = 5; // OK, x is obviously a member of this class, somehow.
    }
};

I still can't wrap my head around when 'template<>' is necessary but I learned one new instance. 

template <> is only for full specializations, I believe.

Coming up with new concepts for my programming language makes me happy.
It brings me joy to know that I have created the best programming language of all time.

Too bad there probably never will be a compiler for it.

Write a compiler for it I've done it, once (well, technically it was an interpreted language, and what got written was an interpreter), but it's a brilliantly fun and educational way to waste time. Hell, if it IS the best programming language of all time, a compiler, even if it's a crappy one, might start people using the language and writing other compilers for it. You sort of need a reference implementation for it to be a real language, though.

I guess it wouldn't hurt to try to make a compiler at least for the basic stuff to begin with, like variables and the main function and a way to write to the console.

I really have no idea where to start, though. My knowledge of Assembly, hexadecimal and binary and stuff like that is less than limited; it's not even that.

You don't need assembly at all.  Outputting a language like C, and then running that through a C compiler is a perfectly valid option, and many compilers do this.

While I wasn't looking, Objective-C got closures.

What other surprises has Apple left for me?

Someone, I think it was the guy who wrote TeX, advocated "coding the comments" rather than "commenting the code."  He would write everything out as comments first, and then fill in the code to correspond to the comments.

Interesting idea, I've never had the patience to try it.

Being UNIX based, installing a library on Mac OS X is generally exactly the same procedure as in Linux.
But... damn. I don't want to have to change bunches and bunches of little details for every function and file to turn it into a DLL for an operating system that is of my least concern; if I write portable code from the beginning, I want it to be, well, portable. Surely I don't need to make any DLL or Shared Object files?

Libraries on OS X are generally a bit more than just a binary.

They're usually distributed as frameworks, which are actually directories.  The framework contains not just the binary that you link to, but all the headers necessary to use the library.  It's an all-in-one type deal, very similar to OS X application packages.

You don't need to make binaries, in fact, you might be better off not doing so.  Just providing the source is a perfectly valid option, and hundreds of libraries do this.  If the developer wants to make a binary for their own purposes, they can do so.  My one library (the Ada OpenAL interface) is just a source distribution, this neatly avoids almost all of your problems.  When you do binaries, you run into issues with architectural differences (I know lots of people who run PowerPC Linux distros, your x86 binaries are useless there) 32/64 bit issues, and who the hell knows what else.

Another approach is to make binaries for a few systems, and make the source available for anyone that wants to make them on their own for "unsupported" systems.

Addendum:
I would also like to add that if you're using C++, binaries may not even be an option.  Differences between compilers in areas like name mangling and object layout will not just tie your binary to the compiler it was built with, but maybe even the specific version of the compiler it was built with.