Print

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

[Nadaka]

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?

The parameters would be members of the SpecificAction that is a subclass of the Action(ill call it GenericAction from now on). They can be anything, though references and pointers can cause concurrency issues of there is shared data. And the code for the execution of the method is in the execute method of the SpecificAction (it would be an abstract method on the GenericAction).

The receiving thread does not have to know what type of action it is, it just runs its execute method.

[MagmaMcFry]

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?

The parameters would be members of the SpecificAction that is a subclass of the Action(ill call it GenericAction from now on). They can be anything, though references and pointers can cause concurrency issues of there is shared data. And the code for the execution of the method is in the execute method of the SpecificAction (it would be an abstract method on the GenericAction).

The receiving thread does not have to know what type of action it is, it just runs its execute method.

This.

Code: [Select]

send(new AddObjectAction(object));
send(new MoveObjectWestAction(object, amount));
send(new PlaceObjectAction(object, x, y, z));
send(new ClearAllObjectsAction());


[Siquo]

... Ahaaah. Yes, thanks guys.
I had all actions as methods on the main object that is run as the thread, but actions-as-objects is way better.

See, an obvious answer right in front of me and I don't even see it.

[Nadaka]

I would also suggest that your GenericAction superclass also has an abstract method called something like getActionType(). When it is implemented in the SpecificAction, it should return a unique identifier for that SpecificAction type.

That way, if you find yourself needing to implement actions that need a different execution context  or other specific preparation in the target thread based on type, then you can implement a simple switch statement.

It may not be necessary right now, but in the long run, it can make things easier.

[Siquo]

Thanks!

[MagmaMcFry]

I would also suggest that your GenericAction superclass also has an abstract method called something like getActionType(). When it is implemented in the SpecificAction, it should return a unique identifier for that SpecificAction type.

That way, if you find yourself needing to implement actions that need a different execution context  or other specific preparation in the target thread based on type, then you can implement a simple switch statement.

It may not be necessary right now, but in the long run, it can make things easier.

Doesn't that defeat the whole point of encapsulated command objects?

[Nadaka]

I would also suggest that your GenericAction superclass also has an abstract method called something like getActionType(). When it is implemented in the SpecificAction, it should return a unique identifier for that SpecificAction type.

That way, if you find yourself needing to implement actions that need a different execution context  or other specific preparation in the target thread based on type, then you can implement a simple switch statement.

It may not be necessary right now, but in the long run, it can make things easier.

Doesn't that defeat the whole point of encapsulated command objects?

Yes... But encapsulation, like most OO concepts exist on a continuum. The thread that creates the action may not be able to set all the parameters necessary when the action is created because those other parameters are local to the target thread. Sometimes you have to compromise the idealized model for practical considerations.

[Siquo]

But that's what the context is for, right?

[Nadaka]

But that's what the context is for, right?

Yes, if the context is not a shared object. Then you can get away with putting all the information necessary in the context.

But that isn't an assumption that I made. If you can keep the context isolated to a single thread, by all means do so, it will be better in the long run.

[MagmaMcFry]

Isn't the whole point of this action passing stuff to make sure that thread interaction is handled only by action passing and that all other objects are local?

[Siquo]

Yes, it is. So: Action object is added to a queue in a "rootobject" such as "GraphicsManager". That object also has a thread running, that eventually passes over the queue to check out the contents, and does a actionQueue.pop()->execute(this);. That one GraphicsManager has all the properties and stuff that the Action could ever need, and the rest was added to the Action when it was created. Shared pointers make sure stuff won't get deleted while the Action is in transit, the queues are lockfree so adding/reading is very fast, and new Actions can be designed with whatever parameters I could ever need. Encapsulation is not entirely preserved, as an Action could carry pointers from childobjects of the sender, but that can't be helped unless I copy entire tree branches, which is slow...

Now I just need time to get stuff done. A Family is killing for your coding-time

I'm actually a bit proud of my templated getter action (that still uses a function pointer, but I guess I'll need "generic" Actions as well):

Code: [Select]

class TAction {
public:
  TAction();
  ~TAction();
  virtual void execute(TMessageProcessor*) = 0;
};

template <class R>
class TGetValue : public TAction {
public:
  TGetValue(R(*f)(void)) : returnReady(false), getFunc(f){} // init with pointer-to-getfunction
  R getValue(){ // get the returnvalue, ONLY CALL WHEN returnReady == true!
    if(!returnReady) throw NotReadyException();
    return returnVal;
  }
  void execute(){
    returnVal = getFunc();
    returnReady = true;
  }
  bool isReady(){ return returnReady; }
private:
  bool returnReady; // is the return value ready?
  R(*getFunc)(void);
  R returnVal;
};


[Valid_Dark]

I am really enjoying http://projecteuler.net
It's a site that has a bunch of problems you're supposed to solve by programming.

I'm on problem 8,
some of the problems so far that I've solved.

Spoiler (click to show/hide)

Find the largest palindrome made from the product of two 3-digit numbers.


By considering the terms in the Fibonacci sequence whose values do not exceed four million, find the sum of the even-valued terms.


Find the sum of all the multiples of 3 or 5 below 1000.

I'm doing a few a day, just thought I'd share for anyone interested, someone in one of the other threads pointed it out to me, but I felt it should be posted in here too.

I just realized I have a question for you guys though,
How come, if I do

string number ="7316";

number[0] is 7, number[1] is 3, but number[0]+number[1] is 106?
well I know WHY it's 106, its the two ascii values added together,
gahh nevermind, looks like I'll just need to make a function to convert them.

[Max White]

gahh nevermind, looks like I'll just need to make a function to convert them.

What language are you using? The vast majority of them have an ParseInt(string s) somewhere that should do what you need if you want to convert it back to an int. That is what you are looking for, right? A value of 10?
If instead you want a concat two chars into a string for a value of "73" (Note use of "" this time) then I'm sure there should be something for that. Heck you could try using a constructor.

[Valid_Dark]

C++
I ended up doing

int num (string number, int n)
{
    return number[n]-48;
}

I was able to write a program for problem 8 in like 5 minutes, compiled right first time with no syntax errors, and gave the correct answer!
I'm amazed at how easily I can program things like that, while months before I wouldn't have understood any of it,  it's like I set myself to "on" mode and I just start typing away, and functions and program structure and everything just flow out as if I were writing in English.

[Max White]

Well it is good to hear that things are coming to you more naturally. I think it is time to sew your second star onto your pointy wizard hat!
Anyway, might be useful to you to learn some standard naming conventions. For example, 'num' is a noun, where as functions should always be named after verbs. If instead of 'num', you called your function 'ConvertToInt' it would be a lot easier for you to understand what your program does a week later when you can't remember it line for line. It might not seem important now, but later on it is a great habit to be in.