www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Dlang equivalent of #define/#ifdef : not... version

reply ichneumwn <idonotenjoyemail idonotenjoyemail.org> writes:
Hi,

Trying to convert a C header to D. The underlying package exists 
in different versions and may or may not expose certain 
functionality (modules/extensions). One should check at compile 
time that the header provides the relevant definitions, through 
#ifdef, and do a further run-time check to confirm the 
functionality is really present. It is the compile time check 
that I am finding tricky to do/emulate.

     .h : #define i_am_a_feature 1

The C-code uses this define as a guard:

     .c : #ifdef i_am_a_feature

What would the the D equivalent? This is my attempt so far:

features.d:

     import std.traits;

     private enum capabilities {
         i_am_a_feature
     }

     template supported(string member)
     {
         enum bool supported = hasMember!(capabilities, member);
     }

     version = vs_i_am_a_feature;

     enum can_i_test_for_this;

and use.d:

     import features;
     import std.stdio;

     void main() {
         static if (supported!("i_am_a_feature")) {
             writeln("Feature 1!");
         }
         static if (supported!("i_am_not_a_feature")) {
             writeln("Feature 2!");
         }
         version(vs_i_am_a_feature) {
             writeln("If only I worked");
         }
     }

This produces "Feature 1!", so the supported() path works, but is 
a bit of a round-about way and all "capability flags" need to put 
in that single enum capabilities instead of being allowed to be 
scattered across the features.d module.

As is documented, "version" does not cross the module boundary.

So my questions:
- is there a module-crossing equivalent of "version"?
- if not, is there some way I could test for the existence of the 
enum can_i_test_for_this? A SymbolExists!() or ModuleHasSymbol!() 
or ModuleHasMember!() ?

Cheers
Apr 20
next sibling parent mw <mingwu gmail.com> writes:
On Tuesday, 20 April 2021 at 18:57:46 UTC, ichneumwn wrote:

 So my questions:
 - is there a module-crossing equivalent of "version"?
https://dub.pm/package-format-json.html Configurations / versions { ... "name": "somepackage", "configurations": [ { "name": "metro-app", "targetType": "executable", "platforms": ["windows"], "versions": ["MetroApp"], "libs": ["d3d11"] }, { "name": "desktop-app", "targetType": "executable", "platforms": ["windows"], "versions": ["DesktopApp"], "libs": ["d3d9"] }, { "name": "glut-app", "targetType": "executable", "versions": ["GlutApp"] } ] }
Apr 20
prev sibling next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Tuesday, 20 April 2021 at 18:57:46 UTC, ichneumwn wrote:
 So my questions:
 - is there a module-crossing equivalent of "version"?
mw covered this. There's more documentation here: https://dlang.org/spec/version.html#version https://dlang.org/dmd-windows.html#switch-version
 - if not, is there some way I could test for the existence of 
 the enum can_i_test_for_this? A SymbolExists!() or 
 ModuleHasSymbol!() or ModuleHasMember!() ?
__traits(hasMember, features, "i_am_not_a_feature") This is actually what std.traits.hasMember does, but for some reason it can't take a module as its first argument. -- Simen
Apr 20
parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 4/20/21 3:03 PM, Simen Kj=C3=A6r=C3=A5s wrote:
 On Tuesday, 20 April 2021 at 18:57:46 UTC, ichneumwn wrote:
 So my questions:
 - is there a module-crossing equivalent of "version"?
=20 mw covered this. There's more documentation here:=20 https://dlang.org/spec/version.html#version https://dlang.org/dmd-windows.html#switch-version =20 =20
 - if not, is there some way I could test for the existence of the enum=
=20
 can_i_test_for_this? A SymbolExists!() or ModuleHasSymbol!() or=20
 ModuleHasMember!() ?
=20 __traits(hasMember, features, "i_am_not_a_feature") =20 This is actually what std.traits.hasMember does, but for some reason it=
=20
 can't take a module as its first argument.
=20
 --=20
  =C2=A0 Simen
Could it be because __MODULE__ is string, requiring mixin? The following = prints 'true': enum i_am_not_a_feature =3D 42; pragma(msg, __traits(hasMember, mixin(__MODULE__), "i_am_not_a_feature"))= ; Ali
Apr 20
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/20/21 2:57 PM, ichneumwn wrote:
 Hi,
 
 Trying to convert a C header to D. The underlying package exists in 
 different versions and may or may not expose certain functionality 
 (modules/extensions). One should check at compile time that the header 
 provides the relevant definitions, through #ifdef, and do a further 
 run-time check to confirm the functionality is really present. It is the 
 compile time check that I am finding tricky to do/emulate.
 
     .h : #define i_am_a_feature 1
enum i_am_a_feature = true;
 
 The C-code uses this define as a guard:
 
     .c : #ifdef i_am_a_feature
static if(i_am_a_feature) { ... }
 So my questions:
 - is there a module-crossing equivalent of "version"?
enum isn't exactly "module crossing", but it's defined within the module, which means you can look at it from elsewhere.
 - if not, is there some way I could test for the existence of the enum 
 can_i_test_for_this? A SymbolExists!() or ModuleHasSymbol!() or 
 ModuleHasMember!() ?
This is surprisingly tricky. A template will not accept a symbol by alias that doesn't exist, and if you pass in a string and test, it will test if that template can see the symbol, not your code. You can probably do it inline: static if(__traits(compiles, {alias x = doesThisExist;})); -Steve
Apr 20
parent reply Dukc <ajieskola gmail.com> writes:
On Tuesday, 20 April 2021 at 23:58:46 UTC, Steven Schveighoffer 
wrote:
 static if(i_am_a_feature) {
    ...
 }
This would be correct if `i_am_a_feature` would be always defined, just set to `false` if not existent. But I think the idea was to not define the symbol at all if feature does not exists. In that case, the condition should be `static if(is(typeof(i_am_a_feature)))`.
Apr 20
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 4/21/21 2:38 AM, Dukc wrote:
 On Tuesday, 20 April 2021 at 23:58:46 UTC, Steven Schveighoffer wrote:
 static if(i_am_a_feature) {
    ...
 }
This would be correct if `i_am_a_feature` would be always defined, just set to `false` if not existent. But I think the idea was to not define the symbol at all if feature does not exists. In that case, the condition should be `static if(is(typeof(i_am_a_feature)))`.
Yeah, you're right. It's different than ifdef. I think version is the closest thing. Note that you can convert versions into enums via: version(define_the_thing) { enum the_thing_is_defined = 1; } else { enum the_thing_is_defined = 0; } -Steve
Apr 21
prev sibling parent ichneumwn <idonotenjoyemail idonotenjoyemail.org> writes:
On Tuesday, 20 April 2021 at 18:57:46 UTC, ichneumwn wrote:
 Hi,

 Trying to convert a C header to D. The underlying package 
 exists in different versions and may or may not expose certain 
 functionality (modules/extensions). One should check at compile 
 time that the header provides the relevant definitions, through 
 #ifdef, and do a further run-time check to confirm the 
 functionality is really present. It is the compile time check 
 that I am finding tricky to do/emulate.

     .h : #define i_am_a_feature 1

 The C-code uses this define as a guard:

     .c : #ifdef i_am_a_feature

 What would the the D equivalent? This is my attempt so far:

 features.d:

     import std.traits;

     private enum capabilities {
         i_am_a_feature
     }

     template supported(string member)
     {
         enum bool supported = hasMember!(capabilities, member);
     }

     version = vs_i_am_a_feature;

     enum can_i_test_for_this;

 and use.d:

     import features;
     import std.stdio;

     void main() {
         static if (supported!("i_am_a_feature")) {
             writeln("Feature 1!");
         }
         static if (supported!("i_am_not_a_feature")) {
             writeln("Feature 2!");
         }
         version(vs_i_am_a_feature) {
             writeln("If only I worked");
         }
     }

 This produces "Feature 1!", so the supported() path works, but 
 is a bit of a round-about way and all "capability flags" need 
 to put in that single enum capabilities instead of being 
 allowed to be scattered across the features.d module.

 As is documented, "version" does not cross the module boundary.

 So my questions:
 - is there a module-crossing equivalent of "version"?
 - if not, is there some way I could test for the existence of 
 the enum can_i_test_for_this? A SymbolExists!() or 
 ModuleHasSymbol!() or ModuleHasMember!() ?

 Cheers
Between them, Simen and Ali have cracked the case. Ali's demonstration that "true" was returned made me look at it further and tried the module's name directly and that worked too. It seems that Simen's expansion of hasMember() into the __traits version does the trick -- the __traits version *does* accept the module as a parameter. It seems the template expansion does not like module arguments, not __traits itself. Here is the demo: features.d: import std.traits; enum can_sing = 1; enum can_dance = 1; template supported(string member) { enum bool supported = __traits(hasMember, features, member); // features can be replaced by: mixin(__MODULE__) // to make this module robust against renaming } /* * Note that using std.traits.hasMember *does not* work. Yields error: * template instance hasMember!(features, "can_sing") does not match template * declaration hasMember(T, string name) */ use.d: import features; import std.stdio; import std.traits; void main() { static if (supported!"can_sing") { writeln("can_sing"); } static if (supported!("can_dance")) { writeln("can_dance"); } static if (supported!("can_jump")) { writeln("can_jump"); } } Result: can_sing can_dance I think the version with the mixin is neater, but I have put it in the direct "features" in the example to show it is not actually necessary. Oh, I found a bonus option: passing the module as an argument. I do not really get templates beyond the very basic ones, but I remember seeing "alias" somewhere and that gets the module through my own template: // accept module as argument template supported(alias modname, string member) { enum bool supported = __traits(hasMember, modname, member); } // accept module name (string) as argument: template supported(string modname, string member) { enum bool supported = __traits(hasMember, mixin(modname), member); } As I write this, I realise that the alias can also be used to get a version of hasMember that accepts modules: enum hasMember(alias T, string name) = __traits(hasMember, T, name); Although that might have unintended side effects? And, indeed, shorten my own use case to: enum supported(string member) = __traits(hasMember, mixin(__MODULE__), member); Many thanks to everyone with suggestions!
Apr 21