Polka dots texture

[chuck_starchaser]

Well, not sure I know exactly, myself. I picture them as red dots on a white background, in a square grid arrangement. I think back in the 50's they were fashionable on skirts, table-cloths and stuff, but they've been deprecated since... ... I kind of like them..

[klauss]

A consistency check would be a good idea, but it would be a hard maintenance tool: think of it, since whenever any dev-decision changes the formats, or the arrangement of things, the tool would have to be adjusted accordingly.

It would be a great tool, though, since it would allow much cleaner releases.
I guess someone should take charge of it, and do propper maintenance, otherwise it would quickly become useless.

That somewone would need to be very knoledgable of VS structures. The tool could even run a check on .py modules (there must be a python checker somewhere, you don't have to write it yourself). And it would be great to check the modules for propper interface usage, like don't call undefined functions (although that would be asking too much).

[chuck_starchaser]

That's right, it would be hard maintenance. Well, my secret agenda with it is, that once I release it and devs start using it and finding it useful, they might themselves take over its upgrade and maintenance... ... It's to save them time, anyways.

Hey, maybe we should start thinking of ourselves as dev's... Nah, not yet. Code first.

[klauss]

I think that going from Bounty Hunter or ISO party member to Developer requires at least a piece of code that made it to a release version.

[hellcatv]

We'll set you as an actual developer when you commit code or if you need commit access to the tree for some reason


if you feel like you don't need real access but want to be known as people actively working on the code, I can set you to developer on just the forum if it suits you.

ISO party member is just a rank that you get as you rack up posts

[BradMick]

ooh! ooh! do i get to get dev status for model stuff?!!

heheh, or am i just 'that modeler guy'?

[hellcatv]

you can get an Artist rank, like cubofjudaslion and strangelet and Spiner should have.

Developer is for those who actually understand the internal code and work with it (so they can help each other answer code-specific questions)

[chuck_starchaser]

Well, I think I'm on the verge of earning dev rank...

IT WORKS!!!! This call propagator thing...

You can register a plain member function.
You can register a virtual member function.
You can register a member function inherited from a parent class.
You can register a static member function.
You can register functions of same name in a class, overloaded by event type.
And you can register a free (non-class-member) function.

... and you can un-register them all, too...

Very easy to use:

Code: Select all

#include "event.h"

struct explosion : public event
{
   vector3d location;
   megajoules power;
};

explosion::subscribe(&my_ship,&Ship::on_event);
explosion::subscribe(&your_ship,&CapShip::on_event);
explosion::subscribe(&GNN_tips); //free function

explosion big_explosion(vector3D(77.7,22.0,666),50);
big_explosion.send();

//now, my ship didn't make it, so in its dtor,
explosion::unsubscribe(&my_ship,&Ship::on_event);
//And if GNN had enough news for the day,
explosion::unsubscribe(&GNN_tips);

Three design choices I made for this thing, to keep it lean,
and fast:

To be able to register, functions must return void. This is only
logical, since otherwise which function's return should be
returned to the caller? This is like subscribing to an email
newsletter: You don't reply to it. Same principle applies. Now,
it's unbelievable some programmers go to the trouble to
try and support arbitrary return types for observers and
delegates...

Secondly: Registering functions must accept 1 argument, of
type event, or derived from event. To pass 17 parameters,
one derives an event type struct from event, and adds the
parameters as members. I chose to do this for three reasons:
a) It helps standardize a method and syntax for event
message delivery, b) simplifies the router class code (much
less template stuff) and c) It forces a good programming
practice: grouping parameters in function calls into structs,
--which is advocated for its benefits in terms of ease of
refactoring.

Thirdly, only one member function per class can be subscribed
to a given event type. And why would anyone want to register
more than one function in a class to the same event?


So now I'm going to turn the router class into a Singleton, and
embed it within the event struct, so that all one needs to do
is to declare an event type derived from event, have clients
subscribe to it. When a sender wants to send, it instantiates
the event type, fills out the parameters, and hits send().

The router singleton will allocate itself on demand, and
deallocate itself when the list of subscribers goes to zero.
The send() function in event calls a static send() function in
router, so allocation of the router itself won't be an issue.

Oh, and I'm also going to add boost mutexes to the subscribe,
unsubscribe and singleton allocation spots, for thread safety.

[klauss]

If you send me the code, I can add it to the VS project file I'm working on.
Use the e-mail, or post it, whatever.

It sounds nice, but, why the limitation of a single member per class? It doesn't seem necessary for what we've talked. Perhaps you think there's a limitation but it actually isn't. Remember: in any given architecture, different functions must have different addresses, hence different pointers to them. Also, different instances will have different this pointers. Unless you finally decided not to include the this pointer in the sort key, which is possible, since it would make things a little easier.

[chuck_starchaser]

If you send me the code, I can add it to the VS project file I'm working on.
Use the e-mail, or post it, whatever.

The code is still ugly, let me clean it up a bit, maybe by noon ET I'll put a download link.

It sounds nice, but, why the limitation of a single member per class? It doesn't seem necessary for what we've talked. Perhaps you think there's a limitation but it actually isn't. Remember: in any given architecture, different functions must have different addresses, hence different pointers to them.

Only a single member per class PER EVENT TYPE. You can have 50,000 members registered with as many event types.
I have the this pointer and the function pointer in a template wrapper. But, I only use the this pointer for equality comparison. That's why you can only register one function of a class with the same event type. But then again, registering two functions in the same class and with the same event would be redundant.

[klauss]

That's why you can only register one function of a class with the same event type. But then again, registering two functions in the same class and with the same event would be redundant.

Yes, I get you. But I don't like limitations, when they're totally arbitrary.
But you're right... Why would you do that?

But to make things clearer: one registration per event type, per instance. It makes a difference.

[chuck_starchaser]

Yes, of course, per instance. The address of the instance IS the identifier, so definitely per instance.
Sorry, klauss, give me until tomorrow. Right now I'm in the middle of embedding the router singleton into the abstract event class, so, at the moment it's not compiling.
Besides, you wouldn't be able to understand any of the code, because everything is named like class A, B, C, V, S, F; I know what they mean, but I have to name them properly before I can show the code without shame..

[klauss]

I know what they mean, but I have to name them properly before I can show the code without shame..

I know the feeling. Some parts of Orfeo make me feel the same.