www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Can I do an or in a version block?

reply "Tyler Jameson Little" <beatgammit gmail.com> writes:
I would like to do something like this:

version (linux || BSD) {
     // do something...
} else {
     version (Windows) {
         // do something else
     } else {
         // do something else
         assert(false, "Unsupported operating system");
     }
}

The only way I've been able to do this, is by splitting up the 
two versions and repeat code.

Is there a better way to do this? A static if can do this, so is 
there a way that I can use a static if somehow?
Mar 07 2012
next sibling parent reply James Miller <james aatch.net> writes:
On 8 March 2012 18:38, Tyler Jameson Little <beatgammit gmail.com> wrote:
 I would like to do something like this:

 version (linux || BSD) {
 =C2=A0 =C2=A0// do something...
 } else {
 =C2=A0 =C2=A0version (Windows) {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0// do something else
 =C2=A0 =C2=A0} else {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0// do something else
 =C2=A0 =C2=A0 =C2=A0 =C2=A0assert(false, "Unsupported operating system");
 =C2=A0 =C2=A0}
 }

 The only way I've been able to do this, is by splitting up the two versio=

 and repeat code.

 Is there a better way to do this? A static if can do this, so is there a =

 that I can use a static if somehow?

I don't think there is an 'elseif' for versions, probably because you are normally checking mutually exclusive version descriptions. Otherwise, its probably a good idea to keep the syntax as is, since it stops people from abusing the mechanic. -- James Miller
Mar 07 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/07/2012 10:07 PM, James Miller wrote:
 On 8 March 2012 18:38, Tyler Jameson Little<beatgammit gmail.com>  wrote:
 I would like to do something like this:

 version (linux || BSD) {
     // do something...
 } else {
     version (Windows) {
         // do something else
     } else {
         // do something else
         assert(false, "Unsupported operating system");
     }
 }

 The only way I've been able to do this, is by splitting up the two versions
 and repeat code.

 Is there a better way to do this? A static if can do this, so is there a way
 that I can use a static if somehow?

I don't think there is an 'elseif' for versions, probably because you are normally checking mutually exclusive version descriptions. Otherwise, its probably a good idea to keep the syntax as is, since it stops people from abusing the mechanic. -- James Miller

I had played with this in the past. The assignment to version has an interesting meaning of "collecting" everything assigned to it: import std.stdio; version (linux) { version = linuxOrBSD; version = foo; } version (BSD) { version = linuxOrBSD; version = foo; } void main() { version (linuxOrBSD) { writeln("linux or BSD"); // do something... } else { version (Windows) { // do something else } else { // do something else assert(false, "Unsupported operating system"); } } // Later on even this works version (foo) { writeln("even foo!"); } } Ali
Mar 07 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, March 08, 2012 06:38:48 Tyler Jameson Little wrote:
 I would like to do something like this:
 
 version (linux || BSD) {
      // do something...
 } else {
      version (Windows) {
          // do something else
      } else {
          // do something else
          assert(false, "Unsupported operating system");
      }
 }
 
 The only way I've been able to do this, is by splitting up the
 two versions and repeat code.
 
 Is there a better way to do this? A static if can do this, so is
 there a way that I can use a static if somehow?

You can do version(x) {} else version(y) {} else {} but there is no logical and or logical or with versions. It's _only_ checking whether a particular version exists or not. Walter Bright is completely against having anything more complicated with versioning, since he thinks that it just engenders bad code and bugs. Now, you could do version(x) version = xOrY else version(y) version = xOrY version(xOrY) {} and then xOrY will exist for the rest of that module. But that's as close as you're going to ge to logical and or logical or for versions. Of course, if the issue is linux || FreeBSD, you might want to just consider using Posix. Unless you're doing something that is specific to linux and FreeBSD but not Posix in general (which I would expect to be unlikely), Posix will do the trick just fine. - Jonathan M Davis
Mar 07 2012
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
 Now, you could do

 version(x)
     version = xOrY
 else version(y)
     version = xOrY

 version(xOrY) {}

Huh, clever! I like it!! I hope I don't have to do that very often, though...
 Of course, if the issue is linux || FreeBSD, you might want to 
 just consider
 using Posix. Unless you're doing something that is specific to 
 linux and
 FreeBSD but not Posix in general (which I would expect to be 
 unlikely), Posix
 will do the trick just fine.

Yeah, that was just an example. Perhaps a better example would be comparing versions of something: version (LIBV1 || LIBV2) { // include some dirty hacks for old versions } else { // do some new fancy stuff for new features } I was mostly thinking that there are things that linux and BSD share that other BSDs may not. I know that Mac OS X has some subtle differences in a few things. Anyway, I think this answers my question. I can get by with using your suggestion for those (hopefully) rare cases where I need something more specific. Thanks!
Mar 07 2012
prev sibling next sibling parent "Tyler Jameson Little" <beatgammit gmail.com> writes:
 Now, you could do

 version(x)
     version = xOrY
 else version(y)
     version = xOrY

 version(xOrY) {}

Huh, clever! I like it!! I hope I don't have to do that very often, though...
 Of course, if the issue is linux || FreeBSD, you might want to 
 just consider
 using Posix. Unless you're doing something that is specific to 
 linux and
 FreeBSD but not Posix in general (which I would expect to be 
 unlikely), Posix
 will do the trick just fine.

Yeah, that was just an example. Perhaps a better example would be comparing versions of something: version (LIBV1 || LIBV2) { // include some dirty hacks for old versions } else { // do some new fancy stuff for new features } I was mostly thinking that there are things that linux and BSD share that other BSDs may not. I know that Mac OS X has some subtle differences in a few things. Anyway, I think this answers my question. I can get by with using your suggestion for those (hopefully) rare cases where I need something more specific. Thanks!
Mar 07 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-08 06:38, Tyler Jameson Little wrote:
 I would like to do something like this:

 version (linux || BSD) {
 // do something...
 } else {
 version (Windows) {
 // do something else
 } else {
 // do something else
 assert(false, "Unsupported operating system");
 }
 }

 The only way I've been able to do this, is by splitting up the two
 versions and repeat code.

 Is there a better way to do this? A static if can do this, so is there a
 way that I can use a static if somehow?

A workaround is to use static if constants, here's a start: https://github.com/jacob-carlborg/mambo/blob/master/util/Version.d -- /Jacob Carlborg
Mar 08 2012
prev sibling next sibling parent "Regan Heath" <regan netmail.co.nz> writes:
On Thu, 08 Mar 2012 06:12:44 -0000, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:
 On Thursday, March 08, 2012 06:38:48 Tyler Jameson Little wrote:
 I would like to do something like this:

 version (linux || BSD) {
      // do something...
 } else {
      version (Windows) {
          // do something else
      } else {
          // do something else
          assert(false, "Unsupported operating system");
      }
 }

 The only way I've been able to do this, is by splitting up the
 two versions and repeat code.

 Is there a better way to do this? A static if can do this, so is
 there a way that I can use a static if somehow?


 <snip>... Walter Bright is completely
 against having anything more complicated with versioning, since he  
 thinks that
 it just engenders bad code and bugs.

IIRC the argument was that we should define version identifiers for 'features' or 'behaviours' not for platforms, etc. So, given the 2nd example, instead of: version (LIBV1 || LIBV2) { // include some dirty hacks for old versions } else { // do some new fancy stuff for new features } do: version (LIBV1) version = LIB_OLD version (LIBV2) version = LIB_OLD version (LIB_OLD) { // dirty hacks } else { // new fancy stuff } Regan -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Mar 08 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 08 Mar 2012 01:07:08 -0500, James Miller <james aatch.net> wrote:

 On 8 March 2012 18:38, Tyler Jameson Little <beatgammit gmail.com> wrote:
 I would like to do something like this:

 version (linux || BSD) {
    // do something...
 } else {
    version (Windows) {
        // do something else
    } else {
        // do something else
        assert(false, "Unsupported operating system");
    }
 }

 The only way I've been able to do this, is by splitting up the two  
 versions
 and repeat code.

 Is there a better way to do this? A static if can do this, so is there  
 a way
 that I can use a static if somehow?

I don't think there is an 'elseif' for versions, probably because you are normally checking mutually exclusive version descriptions. Otherwise, its probably a good idea to keep the syntax as is, since it stops people from abusing the mechanic.

Noting that there actually isn't an elseif keyword for if either, of course there is the same construct for version: // if if(cond1) {} else if(cond2) {} // version version(version1) {} else version(version2) {} -Steve
Mar 08 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I find it interesting that having this feature would somehow "enable"
abuse, yet we can do so much abuse already with CTFE, templates, and
string mixins. One large pain in the ass is to pass an integral at
compile time. I sometimes wish to use a syntax such as "version(foo ==
5) {}". The only alternative that I know of is to use string imports
via -J switch to initialize an enum. Compare that with the simple
-Dfoo=5 in DMC/GCC/etc. We might not have globals or macros in D, but
at least 'version(foo) = 5' or something similar should work. It's
also strange that version uses its own meaning of the equals operator,
I really dislike that.

Generally it seems version is the poorest-developed feature of D. And
the counterargument for new features is always a Go-like stance ("you
just won't need it"/"people will abuse the feature").

Of course all I can do now is whine and not propose something better.
:) But there have been a few threads about version and its issues. I
think it's only a matter of time before D gets popular enough that we
get these kinds of threads every other day. Maybe then something will
change.
Mar 08 2012
prev sibling next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/8/12 2:38 AM, Tyler Jameson Little wrote:
 I would like to do something like this:

 version (linux || BSD) {
 // do something...
 } else {
 version (Windows) {
 // do something else
 } else {
 // do something else
 assert(false, "Unsupported operating system");
 }
 }

 The only way I've been able to do this, is by splitting up the two
 versions and repeat code.

 Is there a better way to do this? A static if can do this, so is there a
 way that I can use a static if somehow?

I don't think it would be hard to implement boolean logic inside version. Would it make sense if I make a pull request for it? (because every now and then somebody stumbles upon this issue, and it looks like it could be implemented really easily)
Mar 08 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/8/12 6:11 PM, H. S. Teoh wrote:
 On Thu, Mar 08, 2012 at 05:56:09PM -0300, Ary Manzana wrote:
 [...]
 I don't think it would be hard to implement boolean logic inside
 version.

It's not hard at all.
 Would it make sense if I make a pull request for it?

Walter would reject it. He has stated clearly in the past that he intended version to be simple and minimal, and that adding anything onto it will only result in abuses.

What kind of abuses? I don't understand that logic in a language that allows you to use pointers, alloc memory however you want, and get segfaults for null memory access.
Mar 08 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/09/2012 02:25 AM, Ary Manzana wrote:
 On 3/8/12 6:11 PM, H. S. Teoh wrote:
 On Thu, Mar 08, 2012 at 05:56:09PM -0300, Ary Manzana wrote:
 [...]
 I don't think it would be hard to implement boolean logic inside
 version.

It's not hard at all.
 Would it make sense if I make a pull request for it?

Walter would reject it. He has stated clearly in the past that he intended version to be simple and minimal, and that adding anything onto it will only result in abuses.

What kind of abuses?

Just have a look at reasonably portable C libraries that use the C preprocessor for versioning. IIRC Walter pointed to the Hans-Boehm GC the last time this issue was brought up.
 I don't understand that logic in a language that
 allows you to use pointers, alloc memory however you want, and get
 segfaults for null memory access.

Sorry, but this does not make any sense.
Mar 09 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/09/2012 06:20 AM, Andrej Mitrovic wrote:

 The same story goes for unittests which can't be independently
 ran to get a list of all failing unittests

D unittest blocks are for code correctness (as opposed to other meanings of the unfortunately overused term "unit testing" e.g. the functional testing of the end product). From that point of view, there should not be even a single test failing.
, and so people are coming
 up with their own custom unittest framework (e.g. the Orange library).

Yes, some unit test features are missing. From my day-to-day use I would like to have the following: - Ensure that a specific exception is thrown - Test fixtures That obviously reflects my use of unit tests but I really don't care how many tests are failing. The reason is, I start with zero failures and I finish with zero failures. Any code that breaks an existing test is either buggy or exposes an issue with the test, which must be dealt with right then. Ali
Mar 13 2012
parent reply Ary Manzana <ary esperanto.org.ar> writes:
On 3/13/12 2:21 PM, Ali Çehreli wrote:
 On 03/09/2012 06:20 AM, Andrej Mitrovic wrote:

  > The same story goes for unittests which can't be independently
  > ran to get a list of all failing unittests

 D unittest blocks are for code correctness (as opposed to other meanings
 of the unfortunately overused term "unit testing" e.g. the functional
 testing of the end product). From that point of view, there should not
 be even a single test failing.

  >, and so people are coming
  > up with their own custom unittest framework (e.g. the Orange library).

 Yes, some unit test features are missing. From my day-to-day use I would
 like to have the following:

 - Ensure that a specific exception is thrown

 - Test fixtures

 That obviously reflects my use of unit tests but I really don't care how
 many tests are failing. The reason is, I start with zero failures and I
 finish with zero failures. Any code that breaks an existing test is
 either buggy or exposes an issue with the test, which must be dealt with
 right then.

 Ali

How can you re-run just a failing test? (without having to run all the previous tests that will succeed?)
Mar 13 2012
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/13/2012 11:04 AM, Ary Manzana wrote:
 On 3/13/12 2:21 PM, Ali Çehreli wrote:
 On 03/09/2012 06:20 AM, Andrej Mitrovic wrote:

 The same story goes for unittests which can't be independently
 ran to get a list of all failing unittests

D unittest blocks are for code correctness (as opposed to other meanings of the unfortunately overused term "unit testing" e.g. the functional testing of the end product). From that point of view, there should not be even a single test failing.
, and so people are coming
 up with their own custom unittest framework (e.g. the Orange library).

Yes, some unit test features are missing. From my day-to-day use I would like to have the following: - Ensure that a specific exception is thrown - Test fixtures That obviously reflects my use of unit tests but I really don't care how many tests are failing. The reason is, I start with zero failures and I finish with zero failures. Any code that breaks an existing test is either buggy or exposes an issue with the test, which must be dealt with right then. Ali

How can you re-run just a failing test? (without having to run all the previous tests that will succeed?)

I know that there are test suites too and Unittest++, the framework that we use, supports them but we don't use suites. There has never been a need to run a subset of the tests for us. The tests almost by definition must run very fast anyway. We don't even notice that they get run automatically as a part of the build process. We are getting a little off topic here but I've been following the recent unit test thread about writing to files. Unit tests should not have external interactions like that either. For example, no test should connect to an actual server to do some interaction. Developers wouldn't want that to happen every time a .d file is compiled. :) (Solutions like mocks, fakes, stubs, etc. do exist. And yes, I know that they are sometimes non-trivial.) Ali
Mar 13 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 03/13/2012 11:49 AM, Andrej Mitrovic wrote:
 On 3/13/12, Ali Çehreli<acehreli yahoo.com>  wrote:
 Developers wouldn't
 want that to happen every time a .d file is compiled.

Well luckily unittests don't run when you compile a .d file but when you run the app! :)

Good point. :) Our C++ unit tests are a part of a test binary that has a make file dependency on the library that the .cc files contribute to. A changed .cc causes its .o to be built, the .o causes its .a to be built, the .a causes its unit test application to be built, and finally the unit test application is executed as a part of the library's post build step. Ali
Mar 13 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 05:56:09PM -0300, Ary Manzana wrote:
[...]
 I don't think it would be hard to implement boolean logic inside
 version.

It's not hard at all.
 Would it make sense if I make a pull request for it?

Walter would reject it. He has stated clearly in the past that he intended version to be simple and minimal, and that adding anything onto it will only result in abuses. T -- Why ask rhetorical questions? -- JC
Mar 08 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 08, 2012 at 10:25:53PM -0300, Ary Manzana wrote:
 On 3/8/12 6:11 PM, H. S. Teoh wrote:
On Thu, Mar 08, 2012 at 05:56:09PM -0300, Ary Manzana wrote:
[...]
I don't think it would be hard to implement boolean logic inside
version.

It's not hard at all.
Would it make sense if I make a pull request for it?

Walter would reject it. He has stated clearly in the past that he intended version to be simple and minimal, and that adding anything onto it will only result in abuses.

What kind of abuses? I don't understand that logic in a language that allows you to use pointers, alloc memory however you want, and get segfaults for null memory access.

Ask Walter. It was his opinion. T -- People walk. Computers run.
Mar 08 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I have a felling people will end up abusing string mixins to generate
version statements, and this will be the exact opposite effect Walter
wanted. The same story goes for unittests which can't be independently
ran to get a list of all failing unittests, and so people are coming
up with their own custom unittest framework (e.g. the Orange library).
Mar 09 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 3/13/12, Ali =C7ehreli <acehreli yahoo.com> wrote:
 Developers wouldn't
 want that to happen every time a .d file is compiled.

Well luckily unittests don't run when you compile a .d file but when you run the app! :)
Mar 13 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, March 13, 2012 15:04:09 Ary Manzana wrote:
 How can you re-run just a failing test? (without having to run all the
 previous tests that will succeed?)

You can't, not without essentially creating your own unit testing framework. D's unit testing framework is quite simple. If you compile with -unittest, then the unittest blocks are all run before main is run. If any unittest block in a module fails, then no further unittest blocks in that module are run (though unittest blocks in other modules are run). If any unittest block failed, then main is never run, otherwise the program continues normally. There is no way to rerun specific unit tests or have any control whatsoever which unit tests run unless you create separate programs which only compile in specific modules so that only the unit tests in those modules are run. And even then, you have no control over _which_ tests in a unittest block run unless you play with version statements or whatnot. D's unit testing framework works quite well as long as you're willing to always run all of the tests. If you want more control than that, you have to play games if not outright create your own unit testing framework. - Jonathan M Davis
Mar 13 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 13, 2012 at 11:28:24AM -0700, Ali ehreli wrote:
[...]
 We are getting a little off topic here but I've been following the
 recent unit test thread about writing to files. Unit tests should not
 have external interactions like that either. For example, no test
 should connect to an actual server to do some interaction.  Developers
 wouldn't want that to happen every time a .d file is compiled. :)
 (Solutions like mocks, fakes, stubs, etc. do exist. And yes, I know
 that they are sometimes non-trivial.)

It's not about whether unittests should write to files, but about testing a part of the code that operates on files. So you create some test data in the unittest and put it in the file, then pass the file to the function being tested. Ideally, this should be done in some kind of tmpfs, which is only accessible to the program, and which is discarded by the OS once the testing is finished. You still have the case of non-trivial test data, though. Sometimes there's a large dataset with a known result that you want to use in a unittest, to ensure that your latest changes didn't break a known non-trivial working case. I suppose you could argue that these kinds of tests belong in an external test framework, but that's the kind of thing that discourages people from actually writing test cases in the first place. I know I'll be too lazy to do this if it wasn't as simple as adding a unittest block to my code. It's just too much trouble to implement an external framework, write the test case in a separate file, update the build system to include it in the test suite, only to have to scrap a lot of this effort later when you suddenly realize that there's a better algorithm you can use which invalidates most of the original test case. Whereas if this was just an embedded unittest block, you can delete or comment out the block, replace it with a new test relevant to the new code, and keep going. Seems like a small difference, but having to edit 2-3 different files just to update a test case as opposed to continuing to work with the same source file you've been working on can make the difference between the programmer deciding to put it off till later (which usually means it doesn't get done) vs. doing it immediately without too much interruption (test cases are up-to-date and more thorough). T -- I'm still trying to find a pun for "punishment"...
Mar 13 2012