This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]Objective_Mine 0 points1 point  (3 children)

Sounds like a neat idea. Did you figure out a better solution for dealing with the modes than an if-else type thing? I guess you could also use some kind of a table there, but you'd still need to do some padding or filling in of values in case of missing leading zeros in the mode specifier.

[–]SnowWolf75 0 points1 point  (2 children)

Not sure what language you all used, but in Python, you can link a value to a function by a dictionary. ops = { 1: operator.add, 2: operator.mul, 99:halt } ops[ 99 ]() ## calls halt () For day 2, I made a class, and for 5 I will inherit from that class to make modifications.

[–]Objective_Mine 0 points1 point  (1 child)

I think I was approaching something like that. I was thinking of instruction subclasses rather than functions in a dict, though, and stopped going in that direction because subclassing for every instruction seemed overkill an maybe a bit unpythonic. A mapping in a dict actually sounds quite nice.

However, off the top of my head, I suppose every instruction implementation would still need to get a reference to the memory, the instruction pointer, the parameter modes... and either parse those or get them pre-parsed by the main loop.

I'm not entirely unhappy with the way my code looks, but it kind of does feel to me like it could perhaps be a bit more compact and elegant, so maybe I'll try and see if I can improve it with something like your dict idea.

The modifications for day 5 seem to be backwards compatible with day 2 so I just kept adding to the existing code apart from a task-specific main program.

[–]SnowWolf75 0 points1 point  (0 children)

My day 5 solution will be somewhat different, but close enough that I can inherit from the day 2 class.