new discovery: import only if available
Adam D. Ruppe
destructionator at gmail.com
Tue Jun 18 19:37:10 PDT 2013
I watched the shared libraries in D video earlier today and one
of the things mentioned was using a library only if it is
available, and it rekindled something I wanted to do a while ago
and couldn't: expand a module if and only if some other module is
available.
Well, I could do it, but it meant using -versions. I'd prefer it
if it worked with just listing the module.
But I think I have a solution now:
template moduleIsAvailable(string name) {
enum moduleIsAvailable =
mixin("__traits(compiles, { import " ~ name ~ "; } )")
? true : false;
}
pragma(msg, moduleIsAvailable!"test");
pragma(msg, moduleIsAvailable!"not.existing");
It returned true and false, so cool. If a module is available
though, this test actually imports it and if you don't add its
object file, you'll get a linker error:
$ dmd test11
true
false
test11.o:(.data+0x50): undefined reference to
`_D4test12__ModuleInfoZ'
But that might be ok, since if it is available, you'll probably
be using it anyway - if not, why would you test? Though it would
be cool if there was some kind of technique we could use such
that it only pulls if the module is actually used elsewhere, like
a low priority linker symbol or something. But I don't know about
that.
Anyway, with this, you can wrap the usage of a module inside a
static if(moduleIsAvailable) {} and offer some magical expansion
of interoperability (though, granted, this kind of thing might be
best put into a third module anyway), or a graceful degradation
if you want a file to combine with a library and be standalone at
the same time.
The -version method might be better anyway though, since it is
more explicit.... so I'm on the fence as to if I should actually
use this. What do you all think? Bad idea or worth doing to have
one file be both standalone and interconnected at the same time?
More information about the Digitalmars-d
mailing list