Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Siquo]

I think it's pretty okay, as far as car-analogies go

Question Time:
Splitting my code into "actual stuff" and "visual stuff" (No, not MVC) threads, I've thought of a kind of paging system, where for instance if a new object is added to the world, the visual thread needs to be notified. Also, if input is detected, the world needs to be notified. So each of those separate threads can send notifications to each of the others, which will periodically check for notifications and "do" them. Does anyone have experience/tutorials/examples of this? I'm doing it from scratch, and reinventing the wheel is my middle name, but it'd be nice to not bump my head into obvious stuff, or get advanced tips on how to make this resilient and fast. (C++ btw)

[MagmaMcFry]

Reinventing the wheel is probably your best bet if you want to know how your program works. It's not that big of a wheel. Also, event loops.

[Nadaka]

Reinventing the wheel is probably your best bet if you want to know how your program works. It's not that big of a wheel. Also, event loops.

Your simplest option is probably to use a thread safe queue for message passing.

[MorleyDev]

Your simplest option is probably to use a thread safe queue for message passing.

This. Look into concurrent queues. The latest versions of C# and Java provide them off the bat, and for C++ you have Intel Threading Building Blocks and Boost.Lockfree. It's best not to roll your own because trying to write them is very much "abandon hope all yee who enter here" territory xD

[Siquo]

I had started writing my own  . I'm not sure whether to go with TBB or the Boost threads (which are almost identical to the standard ones, once it's written for the windows stl), but will probably stay with the latter.

Lock-free eh? See, that's what I mean, didn't even know something like that existed. Thanks!

[MaximumZero]

I can no longer respect a language that doesn't have functions/methods as first-class objects.

What about a language that doesn't have variables?

Wait, wut? How the hell does that even work?

[fergus]

I can no longer respect a language that doesn't have functions/methods as first-class objects.

What about a language that doesn't have variables?

Wait, wut? How the hell does that even work?

I think he's referring to lisp, which does have variables, but they usually aren't changed after creation.

[eerr]

I can no longer respect a language that doesn't have functions/methods as first-class objects.

What about a language that doesn't have variables?

Wait, wut? How the hell does that even work?

I think he's referring to lisp, which does have variables, but they usually aren't changed after creation.

In haskell variables aren't changed after creation.
They don't vary, and are in fact, constant.

[MaximumZero]

So...they have variables that aren't variable? What the hell, guys. What the hell.

[MorleyDev]

It's because they aren't really "variables". They are mathematical statements.

In maths usually everything is constant, which is where := for assignment comes from. It's a way to differentiate the mathematical statement that x = 5y + 10 from the assignment that x := x * 5. As a mathematical statement x = x * 5 would mean x = 0.

[Nadaka]

The reason that functional languages like lisp and haskal don't have variables (though they kinda do) is that variables create state and one of the key concepts of functional programming is that it is stateless.

[Virex]

I can no longer respect a language that doesn't have functions/methods as first-class objects.

What about a language that doesn't have variables?

Wait, wut? How the hell does that even work?

I think he's referring to lisp, which does have variables, but they usually aren't changed after creation.

Common Lisp lets you change variables at will. Clojure and many Scheme variants don't though. What this means in practice is that you can introduce a variable, but once introduced, you cannot change it's value.
In clojure you often don't even bother with introducing variables besides the input variables of the used functions and just pipe the results through a series of calls or use recursion.

[Siquo]

Since you guys rock at giving advice and google isn't helping again...

Okay, halfway through my interprocess API I realise I have no idea what the best way is to convey information from thread to thread.
I have:
- Asynchronous messaging system sending "Action" objects, which will be processed by another thread. (lockfree yay)
- Using shared pointers I can send pointers around, and even use an Action to hold a return value if needed. (threadsafe yay)
I need/want:
- Some way of an "Action" message object to hold an actual parametrised action. How will the receiver know what to do?
- Speed, string parsing is out of the question
- Flexibility, should be easy to add new types of actions

Ideas so far:
- Send pre-filled function pointers (very dependent on the receiver's function structure), very flexible though
- Enum the actions and have a switch decide (less flexible, and have to pre-define parameters somehow)
- ? ? ?

Types of actions that will be sent:
- Add Object* X to the screen cache;
- Remove Object* X from the screen cache;
- Put Object* X in the Dynamic List;
- Move Object* X, 0.5 units to it's local west-direction.
- Place a new Object, location: (x,y,z), Object_Design: Ball, Object_Material:Rock_5


Any good ideas (even though reinventing the wheel is good for me ), or reasons why I shouldn't build an API using function pointers, if that's even possible?

Code: [Select]

shared_ptr<Action> a(new Action(GraphicsManager::addObject(), controller->getGraphics(), newObject*));
controller->getGraphics()->pushAction(a);


[MagmaMcFry]

In Thread 1:

Code: [Select]

Action * a = new SpecificAction(parameter1, parameter2);   // Parameters are specified in the sending thread
send(a);                                                   // Amount and type of parameters can be specified individually per subclass of Action

In Thread 2:

Code: [Select]

Action * a = receive();
a->Execute(context);                        // Context is supplied in the receiving thread.


[Siquo]

That's where I am now, but what's the best way to specify my "parameters"?
Enums? Function pointers? Something I haven't thought of yet?