"Bald Eagle" <cre### [at] netscapenet> wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> > This is an ancient trick I learned decades ago ;-). The form
> > _GRANITE_FILE_INC_ (the last underscore is maybe redundant) somehow
> > covers all the possible forms of writing (capitals, dots, etc) of which
> > a file name is composed. And it works perfectly well for me.
> You're killin' me.
> I have never seen this used before, or even mentioned.
> Is this in the documentation?
> > And then...!!!! [thunderclap]
> > So I forgot to give you the proper Line 70, which should be of course,
> > after Line 69, as given:
> > #ifndef (_GRANITE_FILE_INC_) #local Granite_file =
> > "DakotaRedGranite.inc" #end
> > #include Granite_file
> So I guess I will have to play with this... is the _GRANITE_FILE_INC_
> "operating on" the #local Granite_file declaration ...? Does it need the _INC_
> part then...?
This is a lifting of a "protection" mechanism from the C language (at least
that's where I first encountered it).
The basic form is in your main .c file is:
Assume that somefile.h also includes other files, and those include others.
Further assume that someotherfile.h also includes other files. If it ends up
that some set of includes is /duplicated/ then you run into problems.
So, to avoid that, in C somefile.h will contain something like this:
/* file: somefile.h */
/* defines some stuff */
The idea is that each include file defines the variable name associated with
that file, so that if that include file is hit /again/ when resolving includes
the first ifndef line will discover that, the include file contents will be
'skipped', and nothing /more/ will happen.
I'm not aware of any 'magic' that happens in povscript WRT defining a
_filename_INC_ variable, but there could be such.
(hope this helps clear up the concept)
Post a reply to this message