Re: 'thatenums' in practice & function names as enums

fir wrote:

fir wrote:

>
>
i get back for a while to coding (though my health
is real disaster)
>
i think about maybe not even writing some 'paragraph'
game (i mean game that writes paragraph of text, then gives
options to chose A) B) C) .. then writes next paragraph and
this is a game
>
coding it is itself easy, especially if someone has
learned a library for this it mainly look like this
>
CastleScreen()
{
   clear_screan();
   text("Youre in a Castle of Baron blblabla..")
   text("a) talk with baron")
   text("b) go to kitchen")
   //...
}
>
runFrame()
{
   if(screen=='castle') CastleScreen();
   if(screen=='river') RiverScreen();
   //.... and so on tens of that
>
}
>
OnKeyDown(int key)
{
   if(screen=='castle)
   {
     if(key=='A') screen == 'baron'
     if(key=='B') screen == 'kitchen'
   }
>
   //.....
}
>
and thats it its basically all of it
(add yet few state variables like kitchen_visited
atc to make soem mechanics)
>
one question i had in mind was it that could be
yet simplified , bot in c or as extension in soem langage
>
it seem that there is some Simplification and it is to
use callback like CurrantScreen and assign pointers
to screen functions to it
>
it is bold/brave though and im not sure if i should
do that - there seem to be tremendous advantage not
having this kind of enums at all (real advantage
as if game has hundreds of screens - and probably
would need it like books has hundreds of pages) then
you damn type hundred of enums and function names
and there is a lot of (sadly not much 'scalable') code
jumping and resolving typos (which is monkeyish
work)
>
second advantage is that Fuction names can be enough long
and 'thiskind' of enums are not  (below on this)
>
this idea to getting rid of this literal enums
is somewhat bold/brave as i said and i not rethinked
what this danger may be? do you maybe know?
>
second thing is using this 'literal enums '
for signs like 'sdas' is for sure not enough
for this use case so i need at least eight or
more
>
doeas maybe someone know how to enforce it
(im using 32bit mode mingw/gcc)
>
need i write
>
unsigned long long screen;
>
and then type "screen='aasasas'" and "if(screen=='aasasas')"
or i need something more to be safe (liek adding L before
like L'aasasas'
>
im terribly sick and weary and not made initial
experimentation what work... if i use those long literals
it seem to work (compiles) but it seem some reduce
to teh same (probably last 4 being significant) and it makes errors
>
?
tnx for answer

>
i tested it a bit and it seem callbacks are far better
1 enums vanish and trupbles with them
2 there is good separation of functions
like castle_screen() {} and catsle_keys() {}
where in prevoius one screens was separate and
keys was in one giant switch
>
hovever the switching those screen/keys pairs could be
imporoved as i can have
>
screen=castle_screen;
keys=castle_keys;
>
or (better imo) using structure
>
call = {castle_screen, keys};
>
but in fact if there woudl be some of function structures
>
castle
{
   void screen() {}
   void keys(int key) {}
}
>
then one could just swich by writing call = castle
and that would further improve code
>

in those examples above
castle
{
   void screen() {}
   void keys(int key) {}
}
river
{
   void screen() {}
   void keys(int key) {}
}
ant the usesge like
current = castle;
current = river;
current.screen()
current.keys(key)
this "castle" or "river" are just part of names
and the current is a callback structure
but i could try to think how to generalise it
(though my form is specialy bad btw, and thinking
not much glues this months)
one think if this current structure shouldnt be defined
authomatically (it could but probably not necessary)
here "river*" could also be understand as a pointer
to 2 pointers - though as something like this not
exist - becouse those 2 pointers must be hold
together wich takes ram - so i think river* is
more like structure of 2 pointers
okay at least that
the question is what if there are more functions
castle
{
   void screen() {}
   void keys(int key) {}
   void foo() {}
}
river
{
   void screen() {}
   void keys(int key) {}
   void bar() {}
}
imo probably if current is defined as pair of "screen, keys"
assigning
currant = river
currant = castle
should probably copy those 2 pointers only (and binding
should be by names)