Type doas not exist, yet it does?

[bigsofty]

Im getting this error if I compile my program...

Code (glbasic) Select Expand

In file included from C:\DOCUME~1\DAD\LOCALS~1\Temp\glbasic\gpc_temp.h:6,
                 from C:\DOCUME~1\DAD\LOCALS~1\Temp\glbasic\gpc_tempg.cpp:2:
C:\DOCUME~1\DAD\LOCALS~1\Temp\glbasic\gpc_temp_class.h:84: error: `TSpritePage' does not name a type
C:\DOCUME~1\DAD\LOCALS~1\Temp\glbasic\gpc_temp_class.h: In member function `__GLBASIC__::TGUI& __GLBASIC__::TGUI::operator=(const __GLBASIC__::TGUI&)':
C:\DOCUME~1\DAD\LOCALS~1\Temp\glbasic\gpc_temp_class.h:93: error: 'class __GLBASIC__::TGUI' has no member named 'SpritePage'
C:\DOCUME~1\DAD\LOCALS~1\Temp\glbasic\gpc_temp_class.h:93: error: 'const class __GLBASIC__::TGUI' has no member named 'SpritePage'It has 3 program files, 1 main,2 libs.

The 2nd file has a type that refers to a type definition from the 3rd file.

The 2nd file does not seem to register the type from the 3rd unless I actually copy it from the 3rd to the 2nd, then it works, this destroys the portability of the 3rd though?

[Kitty Hello]

Strange. Are you sure the TYPE "TSpritePage" exists? Maybe some upper/lowercase problems?

[bigsofty]

If I cut it from the 3rd file to the 2nd, it compiles fine, but put it back in the 3rd then I get the error... weirdness.

[Schranz0r]

OHOH..

[AndyH]

Hi BigSofty

I can't replicate that in my game.  I have TYPE's declared at the top of different source files (before any functions) and I'm able to refer to any of them in any of the other source files so far without problems.  I've also types inside of types several layers deep.  The only times I have had problems is when I've spelled them incorrectly or got the case wrong, eg: tSprite v TSprite.

[bigsofty]

If I cut it from the 3rd file to the 2nd, it compiles fine, but put it back in the 3rd then I get the error... weirdness.

Andy, copying it elsewhere would retain the typo and it still would not work...?

Also a typo would show up as a simple error, getting caught by the pre-parser not by the compiler?

[AndyH]

yea, very true.  Tis an odd one, that was the only issues I've come up against so far (user error) with my use of TYPES.  Are you declaring them at the top of each source code file?  Any commands or functions in between/before? Any duplication of type names/member names with other types/members/variables/reserved words?  Sorry I'm not being much help, like I say I've not had this problem.

Can you replicate the problem in a small clean project?

[Kitty Hello]

Can you email me the code? It's really weird.

[bigsofty]

Can you email me the code? It's really weird.

I'll send you the code Gernot... Im beginning to think it has something to do with sending sub-types to functions....

Thanks for your help Andy, I'll see what Gernot has to say, he'll probably spot the problem in a minute...

[Kitty Hello]

Oh dear. Oh.Oh. Dear.

Code (glbasic) Select Expand

TYPE Ta
    b AS Tb
ENDTYPE

TYPE Tb
x
ENDTYPEThis is the minimalistic example reproducing this error. The background:
GPC (The GLBasic-to-C++ compiler) reads the type declaration top to bottom, first to last file.
When it encounters such a type, it puts it out in a seperate header file, so you have all types at any point in the source code at hands.
Problem: You type "Ta" has a member "Tb", which will be defined later. Thus, the C++ compiler complains about not knowing Tb. I can't forward declare them, because I need true instances for them. I could if I were using "new" allocation for each member, but that would slow things a bit down in the runtime.
Thus, if you could declare the things in other order (both types in the 3rd file?), things would be easier for me.
If you insist on it, I'll fix it with the problem of slower creation of nested types then.

[AndyH]

Ah, this is one of those things I expect so personally I would not suggest changing it.  I don't know what anyone else's view on this is, but it makes sense to me that if you are placing types within types you need to explicitly declare them in order.

I have not created libraries that have dependencies on other libraries in other source files so this problem does not happen for me.  However, should that happen and a dependency like this is unavoidable I think I'd approach it by declaring the types either in another file or the main file so I could ensure the order was as I expect.

The other way around this might be (if it is possible to do) to specify the order in which include files are compiled so types declared in includes run in the order you expect them to.

In the OOP world, my TYPES would be self contained.  Where I need to transfer data between types I would create a DS type (Data Structure type) to store that data to pass around.  I think you could still do this in a procedural style language so it would all come down to how you aproach the way you design your data structures and TYPES.

What's everyone else's view?

[bigsofty]

Hmmm, this is actually easily done when a lib passes in or out a type. I assumed the compiler was at least 2 pass, to cover this kinda thing.

How about the ability to order the files in a project, that way I could assure what types get processed 1st? As it stand now, I cant move file up-n-down in the file tree. Obviously your main file would stay in the same place.

(Oops just read, Andy suggested this too)

Another option "Include mylib.glbas" at the top of the main program.

If OO then a pointer to the typed var within the class would most likely be passed?

Hmmm, If, I delete the project file and add files in a certain order, would this fix it or would the IDE re-arrange the files internally before compile?

I don't feel like this is a big problem... solvable with any of the above methods... worst case I could make a giant "types.glbas" file, this would kinda mess with the idea of seperate libs though.

Thanks for looking into this guys,


Ian

[Kitty Hello]

You can order them by selection one with right MB, then click "set as main program", afterwards select your main.gbas and set it as main again.
Can't you have the types that are nested in one file?

[Kitty Hello]

You can order them by selection one with right MB, then click "set as main program", afterwards select your main.gbas and set it as main again.
Can't you have the types that are nested in one file?

[AndyH]

Yes, that's probably what I'd do (one file for declaration of types).  This would be a good compromise.  You can manage that more easily between different projects.