Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail From: fir Newsgroups: comp.lang.c Subject: Re: 'thatenums' in practice & function names as enums Date: Mon, 19 Aug 2024 19:57:37 +0200 Organization: i2pn2 (i2pn.org) Message-ID: <2999e12cff5a1d64afc3f1dbc47797ec09a501af@i2pn2.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 19 Aug 2024 17:57:29 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="3143494"; mail-complaints-to="usenet@i2pn2.org"; posting-account="+ydHcGjgSeBt3Wz3WTfKefUptpAWaXduqfw5xdfsuS0"; User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 In-Reply-To: X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 4393 Lines: 121 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