Moot points and semantics(?). Defining a pointer to something that has not been defined.

[olympic sleeper]

Hello,
Hi I am writing a text adventure as a way of relearning coding and am currently reworking the way I handle objects, and indeed rooms by combining them. Thus objects and rooms are now just 'things', the player is just a 'thing' in another 'thing', which just happens to be a 'room', but could just as easily be a box, a boat or whatever.

The below (deliberately) does not work as I am (stupidly) trying to create a pointer to a type that has not been declared which needs the previous type to be declared first :/.

Code: Select all

Type _thing
	name as string
	long_name as string
	description as string
	plurals as string
	additional_desc as string
	position as string
	init_player_stance as string
	init_player_position as string
	room_start_words
	as _thing ptr parent
	as _thing ptr contents
	as _thing ptr _next, _prev
	as _d_links ptr directions
end type	
	
type _d_links
	as _thing ptr n,s,e,w,up,down,in,out,ne,se,sw,nw
end type

dim objects(100) as _thing
dim directions(50) as _d_links

_d_links contains a pointer to _thing, so has to go after _thing. But _thing has a pointer to _d_links so has to go before _d_links, which of course is not possible. I can change the 'as _d_links line in _thing' to 'as any ptr directions', but can I now make _thing.directions become the type _d_links? This might seem a moot point since objects(1).directions=@directions(5) compiles, however I'm somewhat intrigued as I'd like to try and reduce the chance of stuff-ups like;

Code: Select all

dim direction as string
.
.
.
.
objects(1).directions=@direction

[paul doe]

This is one of those typical 'chicken before the egg' problem. FreeBasic allows forward typing, as long as you don't refer to any of its members before:

Code: Select all

'' Type alias to forward reference
type as _d_links _
  _d_links_fwd

Type _thing
   name as string
   long_name as string
   description as string
   plurals as string
   additional_desc as string
   position as string
   init_player_stance as string
   init_player_position as string
   'room_start_words
   as _thing ptr parent
   as _thing ptr contents
   as _thing ptr _next, _prev
   as _d_links_fwd ptr directions
end type   
   
type _d_links
   as _thing ptr n,s,e,w,up,down,in,out,ne,se,sw,nw
end type

dim objects(100) as _thing
dim directions(50) as _d_links

Remember, this works only if you don't refer to any of the other members first. What's room_start_words supposed to be?

[olympic sleeper]

Thanks Paul.

room_start_words is a hang-over from previous code. The code is in a state of flux - aka a mess - right now as I move from the original plan to a new one. I'm trying to reduce work here by setting up an array of pointers objects(x) which points to the new combined objects/rooms db type '_thing' ,which is evolving constantly as I move through the code.

However I may have hit a snag. In the old code I used a lot of withs - like with objects(count) - which was the old code's type. I thought that this would just resolve to mean the new _thing type as I have

Code: Select all

dim shared db(_max_db_size) as _thing
dim objects (_max_no_objects) as _thing ptr
...
objects(obj_count)=@db(count)
...

in the code to create an array of pointers to just the objects. But I get errors like - error 24: Invalid data types, found ''' in 'with objects(obj_id) at compile when it encounters any of the withs, suggesting you can only use with with types and not pointers to them. Ok there is no mention of using with, with pointers to types in the docs, but I was hoping to save typing.

Is there any way around this?

[fxm]

FreeBASIC does not support:

Code: Select all

With objects(obj_id)      '' WITH does not work with pointers
    Print ->name
    Print ->long_name
    Print ->description
End With

But a workround is:

Code: Select all

With *objects(obj_id)     '' but WITH works with dereferenced pointers
    Print .name
    Print .long_name
    Print .description
End With

[olympic sleeper]

Many thanks FXM, didn't know that.