StormC4 C++ Library Base Weirdness!

[Karlos]

Hi,

I'm having to work some C++ code over in StormC 4, and have happened upon a most irritating and bizzare problem using some amigaos shared libraries.

Specifically, its an issue with libraries that use the same base pointer name as the library structure (I dont care who it was who thought of that, but they should be blindfolded, shot, buried, dug up again, shot some more and reburied)

For instance:

#include
(other relevent headers follow)

struct GfxBase* GfxBase = 0;

(later, inside init code)
GfxBase = (struct GfxBase*)OpenLibrary("graphics.library", 39);


The above refuses to work, the compiler seems to believe GfxBase here is a malformed declaration. This is inspite of using the redundant (in C++ mode) 'struct' keyword to be absolutely explicit in the global declaration!

Ok, I could accept there may be a name clash problem and SC4 simply hates the fact that GfxBase is simultaneously a structure name and a pointer name.

Yet, completely contrary to the above, the following works fine:

#include
(other relevent headers follow)

struct IntuitionBase* IntuitionBase = 0;

(inside init code)
IntuitionBase = (struct IntuitionBase*)OpenLibrary("intuition.library", 39);

Both appear to be fundamentally identical to me, yet one works and the other doesn't. Am I going mad or what?

[Sidewinder]

Does changing the pointer name cause the problem to go away?

struct GfxBase *GraphicsBase = 0;

GraphicsBase = (struct GfxBase *)OpenLibrary("graphics.library", 39);

I tried out the code on my StormC 4 setup and could not duplicate the error.  Also, which line is the error reported on?

[Karlos]

Sidewinder wrote:
Does changing the pointer name cause the problem to go away?

struct GfxBase *GraphicsBase = 0;

GraphicsBase = (struct GfxBase *)OpenLibrary("graphics.library", 39);

I tried out the code on my StormC 4 setup and could not duplicate the error.  Also, which line is the error reported on?

Hi Sidewinder,

Well, some things I should point out. Firstly, the compiler wasn't operating in gcc mode - it was still in stormc3 mode. The reason for this is that I'm updating some older code (in stages) that was storm3 dependent up through stormgcc and ultimately to gcc.

Now, the error is reported on the line where I OpenLibrary() the graphics.library, not on the line where I declare the library base pointer.

Changing the pointer name does indeed eliminate the problem, but I didn't want to do this lest it causes problems later - especially when the library base names are used in some of the linker libraries...

Now, having looked closer at the proto/ headers, I think I may have found why the IntuitionBase one works and not GfxBase.

Where I use IntuitionBase, the only thing the compiler has seen up to that point is

in proto/intuition.h

extern struct IntuitionBase* IntuitionBase;

in my code

struct IntuitionBase* IntuitionBase = 0;

It hasn't yet seen the definition of struct IntuitionBase, but is happy that we are just "assigning a pointer to struct" type stuff.


Now, in the code that uses GfxBase, I think before my code is reached, at some instance, the actual struct GfxBase definition is exposed. Hence, when it sees the OpenLibrary(), it sees

GfxBase = (struct GfxBase*)OpenLibrary...;

and as soon as it sees GfxBase, it is expecting the declaration of an object of that type.

Hmm, I should try

::GfxBase = ....

I wonder...


-edit-

Incidentally, have you noticed any lockups with StormED 4 + magic menu?

[Steady]

Hi Karlos,

I came across the same problem. It is unbelievably annoying and should never have been allowed to happen, but there it is. I worked around it by declaring GfxBase as 'struct Library *' and not including graphics/gfxbase.h in the source file that opens/closes the library base. When the library was opened the GfxBase variable was copied to another variable with a different name.

All functions that needed access to a variable stored in GfxBase were placed in a different source file that did have graphics/gfxbase.h included.

In the second source file, I declared 'struct GfxBase *gfx' variable and copied the GfxBase pointer from the variable with a different name like so:

gfx = (struct GfxBase *)(sim.gfxLibPtr);

Then I could use gfx as GfxBase in that source file.

It might have been a round-about way to get past this and it might be done slightly easier, but it was just driving me insane at the time so when it worked I left it.

[Karlos]

Hi,

Actually, in stormc 3, I had this problem. I got around it by modifiying some OS headers with a bit of conditional compilation that renamed the strutures and created typedefs for them. So, if I #defined KARL_FIXES, I could use GFXBASE*, etc.

The thing is, it looked like this wasn't needed in storm4 since the intuitionbase one worked. Furthermore I'm loathe to do it again because I feel it shouldn't be required to modify the headers that come with your NDK, since that is essentially a hack!

Im now sure that the above was a fluke because the definition of the structure itself hadn't yet been seen by the compiler.

I *must* find a non structure/pointer renaming solution to this. It's making me  :pissed:

[Karlos]

Right, some news for fellow sufferers (Steady ;-) )

If you explicitly refer to the global library base pointer by prefixing with the double colon, it works - even if the structure definition has been seen by the compiler!

So

::GfxBase = (struct GfxBase*)OpenLibrary("graphics.library", 39);

compiles just fine :-D

So, no need for renaming structures, pointers or other hacky ways around the problem.

[Steady]

Thanks for that Karlos. I hated my hacky work-around anyway. It's just that it was driving me :crazy: at the time.

I'll try it out.

[Karlos]

@Steady

Did it work?