================================

For all those of you who find the version() statement in D too restrictive, you can use the C preprocessor instead. You have to wrap all the PP directives in a comment block like this:

/+
#include "yourHeaderFile.h"
#if defined (MyVersion) || defined (YourVersion) || defined (OtherVersion)
+/

      D code goes here ....

/+
#endif
+/

Then you setup appropriate dependencies in a make file to run the preprocessor on those specific files before the D compiler sees them (you'll have to come up with a suitable strategy for the PP files-names etc). Works like a charm. If you have an old MS compiler lying around, this is the command-line for it:

cl /C /E yourFile.d

That will keep comments intact and spit the processed file out to the console. You may have to pipe it into a file, since the MS compiler doesn't seem to have that option without it trying to compile the darned thing too ... (I'm sure Borland have an equivalent, and perhaps Walter's C compiler also)


===========================


This also provides the __LINE__ and __FILE__ information that many appear to need:

                throw new ExceptionEx ("my exception message",  __FILE__,
__LINE__);

Works like a charm too! Although it might get a tad confused with templates and mixins. Do you think Walter might add these very useful attributes to the D compiler?


==========================


Also works for Doxygen with respect to version() stuff (which Doxygen does
not like at all):

/+ #define version(x) class Version##x +/

version (linux)
{
  ....
}

which will cause Doxygen to treat all version-blocks as local classes instead. Alternatively, you might add that macro replacement to the Doxygen config file.

A different approach for Doxygen is to use #ifdef/#endif pairs around the
version() block(s) instead, using the strategy outlined above:

/+
#ifdef LINUX
+/

version (linux)
{
 D code goes here
}

/+
#endif
+/

This (ugly) hack will selectively choose which version/local-class Doxygen
sees.

===========================

Actually, you don't even need to wrap it in /+ ... +/ to use the C preprocessor on it.

True, but then the source file is no longer valid D ~ which would become a problem with IDE's and other tools. Either way, it's a pretty goofy hack :-)

The real value I see from this is regarding __FILE__ & __LINE__ ... will D support something like that also?


"Walter" <newshound@digitalmars.com> wrote in message news:cemjf8$hkd$1@digitaldaemon.com...
> Actually, you don't even need to wrap it in /+ ... +/ to use the C preprocessor on it.
>
>
"Walter" <newshound@digitalmars.com> wrote in message news:cemjf8$hkd$1@digitaldaemon.com...
> Actually, you don't even need to wrap it in /+ ... +/ to use the C preprocessor on it.
>
>

I meant to also suggest this as a (interim) means of handling the "stripped" module definitions to be used with object libraries:

class MyClass
{
      void myMethod ()
/+
#ifdef NOT_STRIPPED
+/
     {
        // do something
     }
/+
#else
+/
;
/+
#endif
+/
}

Sure is fugly, but it ought to work. Of course, this is the kind of thing
the compiler should support natively since stripped-modules are the
recommended approach to bundling libraries with D "header files" ... where
is
that native functionality? Surely it can't be so difficult to build into the
compiler? Does anyone know?


"van eeshan" <vanee@hotmail.net> wrote in message news:cemhtc$h65$1@digitaldaemon.com...
> ================================
>
> For all those of you who find the version() statement in D too
restrictive,
> you can use the C preprocessor instead. You have to wrap all the PP directives in a comment block like this:
>
> /+
> #include "yourHeaderFile.h"
> #if defined (MyVersion) || defined (YourVersion) || defined (OtherVersion)
> +/
>
>       D code goes here ....
>
> /+
> #endif
> +/
>
> Then you setup appropriate dependencies in a make file to run the preprocessor on those specific files before the D compiler sees them
(you'll
> have to come up with a suitable strategy for the PP files-names etc).
Works
> like a charm. If you have an old MS compiler lying around, this is the command-line for it:
>
> cl /C /E yourFile.d
>
> That will keep comments intact and spit the processed file out to the console. You may have to pipe it into a file, since the MS compiler
doesn't
> seem to have that option without it trying to compile the darned thing too ... (I'm sure Borland have an equivalent, and perhaps Walter's C compiler also)
>
>
> ===========================
>
>
> This also provides the __LINE__ and __FILE__ information that many appear
to
> need:
>
>                 throw new ExceptionEx ("my exception message",  __FILE__,
> __LINE__);
>
> Works like a charm too! Although it might get a tad confused with
templates
> and mixins. Do you think Walter might add these very useful attributes to the D compiler?
>
>
> ==========================
>
>
> Also works for Doxygen with respect to version() stuff (which Doxygen does
> not like at all):
>
> /+ #define version(x) class Version##x +/
>
> version (linux)
> {
>   ....
> }
>
> which will cause Doxygen to treat all version-blocks as local classes instead. Alternatively, you might add that macro replacement to the
Doxygen
> config file.
>
> A different approach for Doxygen is to use #ifdef/#endif pairs around the
> version() block(s) instead, using the strategy outlined above:
>
> /+
> #ifdef LINUX
> +/
>
> version (linux)
> {
>  D code goes here
> }
>
> /+
> #endif
> +/
>
> This (ugly) hack will selectively choose which version/local-class Doxygen
> sees.
>
> ===========================
>
>
>
>

van eeshan wrote:

>True, but then the source file is no longer valid D ~ which would become a
>problem with IDE's and other tools. Either way, it's a pretty goofy hack :-)
>
>The real value I see from this is regarding __FILE__ & __LINE__ ... will D
>support something like that also?
>
>
>  
>
Right!  Doxygen comes with its own C-preproccessor, so if your only using doxygen and dmd, you should use /++/.

>"Walter" <newshound@digitalmars.com> wrote in message
>news:cemjf8$hkd$1@digitaldaemon.com...
>  
>
>>Actually, you don't even need to wrap it in /+ ... +/ to use the C
>>preprocessor on it.
>>
>>
>>    
>>
>"Walter" <newshound@digitalmars.com> wrote in message
>news:cemjf8$hkd$1@digitaldaemon.com...
>  
>
>>Actually, you don't even need to wrap it in /+ ... +/ to use the C
>>preprocessor on it.
>>
>>
>>    
>>
>
>
>  
>


-- 
-Anderson: http://badmama.com.au/~anderson/