> This is one of those questions that I should have asked years ago, but never got
> around to it: Does inserting duplicate #include files into a scene cause any
> hidden problems? Or extra memory usage? Not that I've noticed anything so far,
> I'm just curious (especially regarding macros, and/or defined functions that may
> need to be undefined first before being re-#included.)
>
> This would be a 'typical' example...
>
> #include "math.inc"
> #include "transforms.inc"
> #include "shapes.inc"  // this also has math.inc and transforms.inc
>
> Over the years, I've seen a few newsgroup posts that essentially say: Don't do
> this. But aside from 'bad coding practice', is is harmful? I would assume that
> using all #locals in the #included files (vs. #declares) would eliminate any
> problems(?)
>
> It would be nice to have a definitive answer, though. (I've never seen an
> explanation or caveat in the documentation, regarding this.)
>
>
>

All standard includes have a construct similar to the following:

At the beggining of the include:
#ifndef(Include_Flag)
#declare Include_flag=version;

Optionaly, version is set to 3.5 or 3.6.
...
All the code to be included
...

Need to restore the version number if it have been changed.
#version Include_Flag;
Close the #ifndef statement.
#end

The variable <Include_Flag> is based on the name of the include file and 
MUST be absolutely unique.

This insure that you don't reparse the file if it have been oncluded before.


For your own includes, I suggest that you do the same.

There are some cases where an include file actualy set an object WITHOUT 
assining it any identifier. In this case, including the file will place 
the object in your scene. If you want to move or rotate it, you need to use:
object{ #include "Object File.inc" scale Your_Scale rotate Your_Rotate 
translate Your_Transte}

For those, it can be normal to include the file several times. It would 
be beter to have this:

#declare Included_Object= object{#include "Object File.inc"}
and, then use that defined object.




Alain

Post a reply to this message