Im getting this error if I compile my program...
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?
Strange. Are you sure the TYPE "TSpritePage" exists? Maybe some upper/lowercase problems?
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.
OHOH..
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.
Quote from: bigsoftyIf 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?
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?
Can you email me the code? It's really weird.
Quote from: GernotFrischCan 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... ;)
Oh dear. Oh.Oh. Dear.
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.
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?
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
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?
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?
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.
I could but I have a LOT of libs, this would mean declaring a lot of types even when Im just using one small lib, also its a bit less structured... but I could use it if need be.
I'll try moving the files about in the project 1st, as this would allow me to keep my libs and types together.
There's a template feature in GLB isn't there? I've not looked into how it's set up, but if the re-ordering doesn't help solve your problem maybe you could setup and maintain a game template. It would have all your libs are included and your data structure include contains all your types. Then if you use the template when creating a new game just remove the bits you don't want.
Gernot, when the GLB to C process picks up all these type declarations and puts them in the header, would the C compiler ignore those types that are not used in the code ? Meaning if you declared types for specific libraries but you remove those libraries from your game, would they add any overhead to the compiled executable files even though no variables refrence them? If this is the case, you could maintain one data structure include and not worry about taking out TYPES you don't plan to use.
No, no overhead for unused TYPEs. TYPEs are getting converted to single variables and registers later.
Read in the files, in a different order with a new project file, works fine.
It would be handy to see the project file in an asci format to check the sequence of files though... hint ;)
But like most things in life, if your aware of possible unpleasant consequences you learn to avoid ;)
The order is upside down in the files-view.