www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - "version" private word

reply Igor Shirkalin <mathsoft inbox.ru> writes:
Hello!

We need some conditional compilation using 'version'.
Say we have some code to be compiled for X86 and X86_64.
How can we do that using predefined (or other) versions?
Examples:

    version(X86 || X86_64) // failed
    version(X86) || version(X86_64) // failed


The following works but it is too verbose:

version(X86) {
	version = X86_or_64;
}
version(X86_64) {
	version = X86_or_64;
}


  - IS
Oct 31 2017
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2017-10-31 14:46, Igor Shirkalin wrote:

 Hello!
 
 We need some conditional compilation using 'version'.
 Say we have some code to be compiled for X86 and X86_64.
 How can we do that using predefined (or other) versions?
 Examples:
 
     version(X86 || X86_64) // failed
     version(X86) || version(X86_64) // failed
 
 
 The following works but it is too verbose:
 
 version(X86) {
      version = X86_or_64;
 }
 version(X86_64) {
      version = X86_or_64;
 }


The only alternative is to do something like this:

version (X86)
     enum x86 = true;
else
     enum x86 = false;

else version (X86_64)
     enum x86_64 = true;
else
     enum x86_64 = false;

static if (x86 || x86_64) {}

-- 
/Jacob Carlborg
Oct 31 2017
next sibling parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg wrote:

 On 2017-10-31 14:46, Igor Shirkalin wrote:

 Hello!
 
 We need some conditional compilation using 'version'.
 Say we have some code to be compiled for X86 and X86_64.
 How can we do that using predefined (or other) versions?
 Examples:
 
     version(X86 || X86_64) // failed
     version(X86) || version(X86_64) // failed
 
 
 The following works but it is too verbose:
 
 version(X86) {
      version = X86_or_64;
 }
 version(X86_64) {
      version = X86_or_64;
 }


 The only alternative is to do something like this:

 version (X86)
     enum x86 = true;
 else
     enum x86 = false;

 else version (X86_64)
     enum x86_64 = true;
 else
     enum x86_64 = false;

 static if (x86 || x86_64) {}


Got it. Thank you!
Oct 31 2017
parent bauss <jj_1337 live.dk> writes:
On Tuesday, 31 October 2017 at 13:55:56 UTC, Igor Shirkalin wrote:

 On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg 
 wrote:

 On 2017-10-31 14:46, Igor Shirkalin wrote:

 Hello!
 
 We need some conditional compilation using 'version'.
 Say we have some code to be compiled for X86 and X86_64.
 How can we do that using predefined (or other) versions?
 Examples:
 
     version(X86 || X86_64) // failed
     version(X86) || version(X86_64) // failed
 
 
 The following works but it is too verbose:
 
 version(X86) {
      version = X86_or_64;
 }
 version(X86_64) {
      version = X86_or_64;
 }


 The only alternative is to do something like this:

 version (X86)
     enum x86 = true;
 else
     enum x86 = false;

 else version (X86_64)
     enum x86_64 = true;
 else
     enum x86_64 = false;

 static if (x86 || x86_64) {}


 Got it. Thank you!


Yeah, in Diamond I went with this approach to make conditional 
compilation around the project much easier.

https://github.com/DiamondMVC/Diamond/blob/master/core/apptype.d
Oct 31 2017
prev sibling parent reply Dr. Assembly <netorib94 gmail.com> writes:
On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg wrote:

 On 2017-10-31 14:46, Igor Shirkalin wrote:

 Hello!
 
 We need some conditional compilation using 'version'.
 Say we have some code to be compiled for X86 and X86_64.
 How can we do that using predefined (or other) versions?
 Examples:
 
     version(X86 || X86_64) // failed
     version(X86) || version(X86_64) // failed
 
 
 The following works but it is too verbose:
 
 version(X86) {
      version = X86_or_64;
 }
 version(X86_64) {
      version = X86_or_64;
 }


 The only alternative is to do something like this:

 version (X86)
     enum x86 = true;
 else
     enum x86 = false;

 else version (X86_64)
     enum x86_64 = true;
 else
     enum x86_64 = false;

 static if (x86 || x86_64) {}


Why is that keyword called enum? is this any related to the fact 
enumeration's field are const values? it would be called 
invariable or something?
Oct 31 2017
parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Tuesday, 31 October 2017 at 14:54:27 UTC, Dr. Assembly wrote:

 On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg 
 wrote:

 On 2017-10-31 14:46, Igor Shirkalin wrote:

 [...]


 The only alternative is to do something like this:

 version (X86)
     enum x86 = true;
 else
     enum x86 = false;

 else version (X86_64)
     enum x86_64 = true;
 else
     enum x86_64 = false;

 static if (x86 || x86_64) {}


 Why is that keyword called enum? is this any related to the 
 fact enumeration's field are const values? it would be called 
 invariable or something?


You're right. Enum defines constant or group of constants in 
compile time.
The full description of enum can be found here: 
https://dlang.org/spec/enum.html
Oct 31 2017
parent reply Dr. Assembly <netorib94 gmail.com> writes:
On Tuesday, 31 October 2017 at 15:20:31 UTC, Igor Shirkalin wrote:

 On Tuesday, 31 October 2017 at 14:54:27 UTC, Dr. Assembly wrote:

 On Tuesday, 31 October 2017 at 13:53:54 UTC, Jacob Carlborg 
 wrote:

 On 2017-10-31 14:46, Igor Shirkalin wrote:

 [...]


 The only alternative is to do something like this:

 version (X86)
     enum x86 = true;
 else
     enum x86 = false;

 else version (X86_64)
     enum x86_64 = true;
 else
     enum x86_64 = false;

 static if (x86 || x86_64) {}


 Why is that keyword called enum? is this any related to the 
 fact enumeration's field are const values? it would be called 
 invariable or something?


 You're right. Enum defines constant or group of constants in 
 compile time.
 The full description of enum can be found here: 
 https://dlang.org/spec/enum.html


thanks. I just find it werid, maybe because I came from C/C++ 
background, where it means only integer types. So enum s = "foo"; 
is really werid. But I'll get used to it.
Oct 31 2017
parent reply Jacob Carlborg <doob me.com> writes:
On 2017-10-31 16:36, Dr. Assembly wrote:


 thanks. I just find it werid, maybe because I came from C/C++ 
 background, where it means only integer types. So enum s = "foo"; is 
 really werid. But I'll get used to it.


Think of it more like #define in C/C++ than "const". The above defines a 
manifest constant that are only available at compile time, i.e. you 
cannot take the address of a manifest constant.

-- 
/Jacob Carlborg
Oct 31 2017
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, October 31, 2017 20:36:57 Jacob Carlborg via Digitalmars-d-learn 
wrote:

 On 2017-10-31 16:36, Dr. Assembly wrote:

 thanks. I just find it werid, maybe because I came from C/C++
 background, where it means only integer types. So enum s = "foo"; is
 really werid. But I'll get used to it.


 Think of it more like #define in C/C++ than "const". The above defines a
 manifest constant that are only available at compile time, i.e. you
 cannot take the address of a manifest constant.


Yeah, thinking about them as const would be bad. All enums (whether they're
manifest constants or actual enum types) effectively get copy-pasted when
they're used, and in the case of arrays, that can be really important to
understand. String literals aren't a problem, but an enum that is any other
type of dynamic array is going to end up allocating a new array every time
you use it, whereas if you had a variable at module-scope or a static
variable (regardless of whether the variable was mutable, const, or
immutable), then there's an actual memory location involved, and the
copy-pasting doesn't happen.

But enums in general in D (both manifest constants and actual enum types)
can be more than just int (though string is probably the most common aside
from int). They can be pretty much any type whose values can be known at
compile time, even including things like structs. So, while enum types _are_
int by default just like in C, D's enums are actually _way_ more powerful
than C's enums.

- Jonathan M Davis
Oct 31 2017
prev sibling next sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin wrote:

 Hello!


You goal should be to describe features.

Version x86
... Version = I can stand on my head
...
Oct 31 2017
parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Tuesday, 31 October 2017 at 14:22:37 UTC, Jesse Phillips wrote:

 On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin 
 wrote:

 Hello!


 You goal should be to describe features.

 Version x86
 ... Version = I can stand on my head
 ...


pardon?
Oct 31 2017
parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Tuesday, 31 October 2017 at 14:25:19 UTC, Igor Shirkalin wrote:

 On Tuesday, 31 October 2017 at 14:22:37 UTC, Jesse Phillips 
 wrote:

 On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin 
 wrote:

 Hello!


 You goal should be to describe features.

 Version x86
 ... Version = I can stand on my head
 ...


 pardon?


Sorry I hate writing code on mobile.

You can create an arbitrary version by assigning a symbol to it, 
use that symbol to describe a feature, assign that symbol for 
each architecture that supports it. Then write code in a version 
block of that symbol.
Oct 31 2017
parent reply Igor Shirkalin <mathsoft inbox.ru> writes:
On Tuesday, 31 October 2017 at 14:31:17 UTC, Jesse Phillips wrote:

 On Tuesday, 31 October 2017 at 14:25:19 UTC, Igor Shirkalin 
 wrote:

 On Tuesday, 31 October 2017 at 14:22:37 UTC, Jesse Phillips 
 wrote:

 On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin 
 wrote:

 Hello!


 You goal should be to describe features.

 Version x86
 ... Version = I can stand on my head
 ...


 pardon?


 Sorry I hate writing code on mobile.

 You can create an arbitrary version by assigning a symbol to 
 it, use that symbol to describe a feature, assign that symbol 
 for each architecture that supports it. Then write code in a 
 version block of that symbol.


The question was not about mobile platforms. Sometimes we need to 
mix some combinations of code in one big project with or without 
some libraries, algorithms etc.
I see what you mean and practically agree with you. But not 
everything depends on you (us).
Oct 31 2017
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/31/17 10:47 AM, Igor Shirkalin wrote:

 On Tuesday, 31 October 2017 at 14:31:17 UTC, Jesse Phillips wrote:

 On Tuesday, 31 October 2017 at 14:25:19 UTC, Igor Shirkalin wrote:

 On Tuesday, 31 October 2017 at 14:22:37 UTC, Jesse Phillips wrote:

 On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin wrote:

 Hello!


 You goal should be to describe features.

 Version x86
 ... Version = I can stand on my head
 ...


 pardon?


 Sorry I hate writing code on mobile.

 You can create an arbitrary version by assigning a symbol to it, use 
 that symbol to describe a feature, assign that symbol for each 
 architecture that supports it. Then write code in a version block of 
 that symbol.


 
 The question was not about mobile platforms.


I think he meant he didn't like writing code in a forum post on his 
mobile, so he wrote something more abstract :)


 Sometimes we need to mix 
 some combinations of code in one big project with or without some 
 libraries, algorithms etc.
 I see what you mean and practically agree with you. But not everything 
 depends on you (us).


The above response has been the standard D answer for as long as this 
question has been asked (and it has been asked a lot). Walter is 
dead-set against allowing boolean expressions in version statements.

The anointed way is to divide your code by feature support, and then 
version those features in/out based on the platform you are on.

For example, instead of "X86_or_X64", you would do "TryUsingSSE" or 
something (not sure what your specific use case is).

However, enums and static if can be far more powerful. Version 
statements do not extend across modules, so you may have to repeat the 
entire scaffolding to establish versions in multiple modules. Enums are 
accessible across modules.

-Steve
Oct 31 2017
parent Igor Shirkalin <mathsoft inbox.ru> writes:
On Tuesday, 31 October 2017 at 15:19:49 UTC, Steven Schveighoffer 
wrote:

 On 10/31/17 10:47 AM, Igor Shirkalin wrote:

 [...]


 Sorry I hate writing code on mobile.

 You can create an arbitrary version by assigning a symbol to 
 it, use that symbol to describe a feature, assign that symbol 
 for each architecture that supports it. Then write code in a 
 version block of that symbol.


 
 The question was not about mobile platforms.


 I think he meant he didn't like writing code in a forum post on 
 his mobile, so he wrote something more abstract :)


Ah. :)

 Sometimes we need to mix some combinations of code in one big 
 project with or without some libraries, algorithms etc.
 I see what you mean and practically agree with you. But not 
 everything depends on you (us).


 The above response has been the standard D answer for as long 
 as this question has been asked (and it has been asked a lot). 
 Walter is dead-set against allowing boolean expressions in 
 version statements.


Now I understand the irritation about my question. I'm sorry.


 The anointed way is to divide your code by feature support, and 
 then version those features in/out based on the platform you 
 are on.

 For example, instead of "X86_or_X64", you would do 
 "TryUsingSSE" or something (not sure what your specific use 
 case is).


This doesn't solve the case with combinations of different 
versions. Four different versions produce nine (+4) different 
variants. It's stupid to define 9 additional version constants.


 However, enums and static if can be far more powerful. Version 
 statements do not extend across modules, so you may have to 
 repeat the entire scaffolding to establish versions in multiple 
 modules. Enums are accessible across modules.


Yes, it's now clear for me what to do. Thanks!
Oct 31 2017
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Tuesday, 31 October 2017 at 13:46:40 UTC, Igor Shirkalin wrote:

 Hello!

 We need some conditional compilation using 'version'.
 Say we have some code to be compiled for X86 and X86_64.
 How can we do that using predefined (or other) versions?
 Examples:

    version(X86 || X86_64) // failed
    version(X86) || version(X86_64) // failed


 The following works but it is too verbose:

 version(X86) {
 	version = X86_or_64;
 }
 version(X86_64) {
 	version = X86_or_64;
 }


  - IS


I've implemented this in my PL:

https://github.com/BBasile/yatol/blob/master/src/yatol/semantic/versions.d
https://github.com/BBasile/yatol/blob/master/grammar/formal/peg.txt#L53


You will never see it in D for some reason, which is that Bright 
think that it's bug prone and easier to read (correct me if i'm 
wrong)
Nov 01 2017