How smart is a smart compiler...

Kaos Kidd

There are basically 2 methods of monitored output: vga and tv
Some use one, others use the other, ok, this is grand, but makes for programming something generically darn near a headach.
So, I thought I would include both objects in the obj section and use a constant to drive with obj to use.
Is the compilier smart enough to know when an objects code can never be reached because of the value of a CON?
I know I can include both objects, and thus include their ram foot print, and use the CON to drive the various output routines I want.
Is there a way to do something like this:

[noparse][[/noparse]<code>]
CON
·VGAFlag = True··················· 'set this to true to use vga, set to false to use tv
·OutStartPin = 12················· 'set this to the first pin for either the vga or tv object

VAR
··IF VGAFlag == true·············· 'Only if VGA is connected
··· OUTPUT = 'vga_text'· ········ 'Use the vga driver
··ELSE························· ······· 'Otherwise
··· OUTPUT = 'tv_spin'····· ······ 'Use the tv driver

PUB Start
· OUTPUT.Start(OutStartPin)· 'Init the output driver

[noparse][[/noparse]</code>]
The above code doesn't compile, so maybe I'm hoping for conditional compilation.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Paul Baker

No conditional compilation in the present incarnation. I was among several who asked about this at the seminar. After that their was some discussion with Jeff about the possibility of including a preprocessor hook (where the author would specify a path to a stream editing utility), but the hydra that would result from code written to be preprocessed by one of the multitudes of preprocessing environments availible would create a support nightmare.

If you really desire preprocessing capabilities at this point in time you can use one outside the Tool environment.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life is one giant teacup ride.

Kaos Kidd

Thanks...
I wasn't sure... thought I'd ask...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

rokicki

On the other hand, if both VGA and TV shared the same set of method names:

init()
write_string()
write_char()
write_decimal()
write_hex()

or some such, then we could just change the object definition at the top and
be able to use either.

It would also be possible to write an object adaptor that does this; i.e.

tv_genericoutput uses tv
vga_genericoutput uses vga

and then call the genericoutput routines. Indeed this could be generalized
for LCD as well.

This would help a *lot* because a lot of the objects we post and exchange have
their debugging set for one device, and ripping out all that code and changing
it for another device is a pain.

Kaos Kidd

rokicki...
Exactly my point.
At the top, you would select which output method, and it's pins, and when you compile it, the compiler wouldn't include the code from the other, unused objects.
I don't know if that works or not, but I'll be testing it soon enough. RIght now I'v like 5 apps I'm 'teasing' myself with, and I need to get at least two of them done, so I can finish that "learning" curve... [noparse]:)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·