> Yeah, modularity is always a hassle when you are working with something 
> that
> reads like C and lacks the objectivity of C++. Heh. The #ifndef thing has 
> been around for decades.
>
> I'm thinking that I might be able to add some sort of object abstraction 
> by resolving namespaces through nested includes. This could be a dead end, 
> of course, but I won't know until I try it or until somebody steers me 
> toward a solution or a reason why it can't be done. Thanks for the assist.

One way to handle variables is just to use global variables and use #ifndef
and #declare to set default values in your include. Private variables in
your include can just be #local.  You might end up having a few variables
to determine which components to add when the #include is called...
Then just call your #include to create each rocket instance. The drawbacks
of this method are potential name collisions, and the need to reset some
global variables if you #include multiple objects. The positive is that
you don't need to set all the values every time you want a simple rocket.

Another way to do it is to pass all the values to macros, use #local
and have a "tree" of macros. The "rocket" macro might call the "fin"
macro, etc. Then for fins only you could just call the "fin" macro
directly to create an object. The drawback of this method is that
if you have a large number of variables they will all need to be passed
to the main macro. The positive is that you only need to #include your
file once to call multiple rocket instances, with no name collisions.

Or you can use a hybrid of the two methods. Use global variables,
don't bother with #ifndef, just #include at the top, and then call
into macros to create objects instead of multiple #includes.

Post a reply to this message