On Saturday, 2 December 2023 at 15:48:02 UTC, Nick Treleaven
wrote:
On Saturday, 2 December 2023 at 15:03:25 UTC, ryuukk_ wrote:
I wish we could use ``version`` as expression, to void the
repetition:
```D
import std.stdio;
enum HasTest = version (Test) ? true : false;
Tomek Sowiński wrote t
On Saturday, 2 December 2023 at 15:03:25 UTC, ryuukk_ wrote:
I wish we could use ``version`` as expression, to void the
repetition:
```D
import std.stdio;
enum HasTest = version (Test) ? true : false;
Tomek Sowiński wrote this template:
```d
enum bool isVersion(string ver) = !is(typeof({
On Saturday, 2 December 2023 at 13:16:26 UTC, Johannes
Miesenhardt wrote:
Hello,
I am trying to learn D and I have stumbled upon an issue
Consider this code:
```d
import std.stdio;
//version = Test;
int main() {
version (Test) {
writeln("Hello, world!");
}
On Saturday, 2 December 2023 at 13:16:26 UTC, Johannes
Miesenhardt wrote:
Hello,
[...]
I see the way why it doesn't work, but I think it should.
Considering that
`version (Test) {} else {`
works without any issue but looks very ugly.
Can somebody explain if this is an intended decision or wh
Hello,
I am trying to learn D and I have stumbled upon an issue
Consider this code:
```d
import std.stdio;
//version = Test;
int main() {
version (Test) {
writeln("Hello, world!");
}
return 0;
}
```
This compiles, however what if we want to turn the versi
On Thursday, 5 August 2021 at 11:54:38 UTC, Mike Parker wrote:
On Thursday, 5 August 2021 at 10:43:01 UTC, wjoe wrote:
Could you elaborate on ```version(assert)``` a bit more,
please ? Like I compiled with ```-release, -g``` and without
the 2 options but the ```assert``` branch was always t
On Thursday, 5 August 2021 at 11:01:56 UTC, Adam D Ruppe wrote:
On Thursday, 5 August 2021 at 09:18:08 UTC, wjoe wrote:
If it's to be determined whether or not the code is being
compiled in debug or release mode, i.e. e.g. the dmd
```-release```
You should never use the -release flag. It shou
On Thursday, 5 August 2021 at 10:43:01 UTC, wjoe wrote:
Could you elaborate on ```version(assert)``` a bit more, please
? Like I compiled with ```-release, -g``` and without the 2
options but the ```assert``` branch was always taken. Could it
be that ```-unittest``` has something to do with
On Thursday, 5 August 2021 at 09:18:08 UTC, wjoe wrote:
If it's to be determined whether or not the code is being
compiled in debug or release mode, i.e. e.g. the dmd
```-release```
You should never use the -release flag. It should be renamed to
"-enable-security-holes" since that's what it a
On Thursday, 5 August 2021 at 10:08:12 UTC, Mike Parker wrote:
On Thursday, 5 August 2021 at 09:18:08 UTC, wjoe wrote:
Given that we have `version(assert)` and
`version(D_NoBoundsChecks)`, it probably makes sense to also
have equivalents to test if contracts are enabled, or if bounds
checking
On Thursday, 5 August 2021 at 09:18:08 UTC, wjoe wrote:
If it's to be determined whether or not the code is being
compiled in debug or release mode, i.e. e.g. the dmd
```-release``` or ```-g``` options, which version identifier is
supposed to be used ?
There's no ```release``` identifier and
If it's to be determined whether or not the code is being
compiled in debug or release mode, i.e. e.g. the dmd
```-release``` or ```-g``` options, which version identifier is
supposed to be used ?
There's no ```release``` identifier and ```-debug``` switch and
```debug()``` condition are some
On Friday, 5 June 2020 at 22:36:23 UTC, data pulverizer wrote:
Hi,
I was switching from dmd to ldc2 and would like to know the
equivalent command line for conditional compilation
-version=Flag I was using in dmd. I checked the ldc2 --help but
didn't see anything relevant. Version
On Friday, 5 June 2020 at 22:39:23 UTC, Steven Schveighoffer
wrote:
It's in there, I had to do grep to find it:
--d-version= - Compile in version
code >= or identified by
-Steve
Thanks, I tried that but didn't realise I still had the old
version flag in the command line and
On 6/5/20 6:36 PM, data pulverizer wrote:
Hi,
I was switching from dmd to ldc2 and would like to know the equivalent
command line for conditional compilation -version=Flag I was using in
dmd. I checked the ldc2 --help but didn't see anything relevant. Version
there refers to compiler ve
Hi,
I was switching from dmd to ldc2 and would like to know the
equivalent command line for conditional compilation -version=Flag
I was using in dmd. I checked the ldc2 --help but didn't see
anything relevant. Version there refers to compiler version or
some other unrelated things.
Thanks
On Saturday, 21 March 2020 at 00:12:20 UTC, Jonathan M Davis
wrote:
On Friday, March 20, 2020 4:33:58 PM MDT jxel via
Digitalmars-d-learn wrote:
On Friday, 20 March 2020 at 21:03:55 UTC, Jonathan M Davis
wrote:
> On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via
>
> Digitalmars-d-learn wr
On Friday, March 20, 2020 4:33:58 PM MDT jxel via Digitalmars-d-learn wrote:
> On Friday, 20 March 2020 at 21:03:55 UTC, Jonathan M Davis wrote:
> > On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via
> >
> > Digitalmars-d-learn wrote:
> >> I have not seen any example where version has several
On Friday, 20 March 2020 at 21:03:55 UTC, Jonathan M Davis wrote:
On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via
Digitalmars-d-learn wrote:
I have not seen any example where version has several OR
matches.
Example idiom:
version(X86_64 || X86)
{
}
else version(ARM || Thumb)
{
}...
On Wednesday, March 18, 2020 10:23:26 AM MDT IGotD- via Digitalmars-d-learn
wrote:
> I have not seen any example where version has several OR matches.
>
> Example idiom:
>
> version(X86_64 || X86)
> {
>
> }
> else version(ARM || Thumb)
> {
>
> }...
>
> you get the idea. So is this possible at all
https://issues.dlang.org/show_bug.cgi?id=19495#c1
On Wednesday, 18 March 2020 at 16:23:26 UTC, IGotD- wrote:
you get the idea. So is this possible at all or do you have to
duplicate the code for each version identifier despite they are
equal for many version identifiers?
The usual workaround is to define a common version, e.g.
version(X86)
On 3/18/20 12:23 PM, IGotD- wrote:
I have not seen any example where version has several OR matches.
Example idiom:
version(X86_64 || X86)
{
}
else version(ARM || Thumb)
{
}...
you get the idea. So is this possible at all or do you have to duplicate
the code for each version identifier desp
I have not seen any example where version has several OR matches.
Example idiom:
version(X86_64 || X86)
{
}
else version(ARM || Thumb)
{
}...
you get the idea. So is this possible at all or do you have to
duplicate the code for each version identifier despite they are
equal for many version
Thanks Mike!
On Friday, 10 November 2017 at 06:22:51 UTC, Tony wrote:
Doing a port of some C code that has an #ifdef in the middle of
an initialization for an array of structs. I am getting a
compile error trying to get equivalent behavior with "static
if" or "version". Is there a way to achieve this other
Doing a port of some C code that has an #ifdef in the middle of
an initialization for an array of structs. I am getting a compile
error trying to get equivalent behavior with "static if" or
"version". Is there a way to achieve this other than making two
separate array initialization sections?
Druntime uses this for its translation of POSIX header files:
https://github.com/dlang/druntime/blob/master/src/core/sys/posix/config.d
An example:
https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/resource.d#L96
Ok, I see. Thanks!
(I've gotta try reggae someday) :)
On Friday, 6 January 2017 at 13:44:37 UTC, Claude wrote:
Yes, it works quite well for most use cases and should
generally be preferred. I disagree that it scales, though. At
some point (a point that is highly project-dependent), it
breaks down, requiring either very large modules or duplicated
On Friday, 6 January 2017 at 13:27:06 UTC, Mike Parker wrote:
version(Windows)
enum bool WindowsSupported = true;
else
enum bool WindowsSupported = false;
Well, yes, that was a bad example. I thought to change it before
sending my post but I could find any other meaningful alternative.
Glad hear it's working for you!
On Friday, 6 January 2017 at 10:25:26 UTC, Claude wrote:
So I had a stream of:
version (Win32)
enum bool WindowsSupported = true;
else
enum bool WindowsSupported = false;
version (Win64)
enum bool WindowsSupported = true; //Ooops
else
enum bool Windows
On Thursday, 20 October 2016 at 09:58:07 UTC, Claude wrote:
I'm digging up that thread, as I want to do some multiple
conditional compilation a well.
Well I'm digging up that thread again, but to post some positive
experience feedback this time as I've found an answer to my
sion(One) || version(Two){ }
version(One) && version(Two){ }
Bit
nope. Walter is against that, so we'll not have it, despite the
triviality of the patch.
I'm digging up that thread, as I want to do some multiple
conditional compilation a well.
I have a couple of question
On 01/18/2016 04:38 PM, Adam D. Ruppe wrote:
On Tuesday, 19 January 2016 at 00:33:21 UTC, Johan Engelen wrote:
Is it possible to do conditional compilation inside an array initializer?
No, but you might break it up:
enum inttable_1 = [1,4];
version(smth)
enum inttable_middle = [5,6
On Tuesday, 19 January 2016 at 00:33:21 UTC, Johan Engelen wrote:
Is it possible to do conditional compilation inside an array
initializer?
No, but you might break it up:
enum inttable_1 = [1,4];
version(smth)
enum inttable_middle = [5,6];
else
enum inttable_middle = [];
enum
Is it possible to do conditional compilation inside an array
initializer? Something like this:
int[] inttable =
[
1,
4,
version(smth) { // <--- does not compile
5,
6,
}
8,
1345
];
(real world case:
https://github.com/ldc-developers/ldc/blob/merge-2.069/ddmd/idgen.d#L
On Sat, 13 Jun 2015 12:20:40 -0400, ketmar wrote:
On Sat, 13 Jun 2015 13:49:49 +, anonymous wrote:
Taking it one step further:
template Version(string name)
{
mixin("
version("~name~") enum Version = true;
else enum Version = false;
");
}
static if(Version!"O
On Sat, 13 Jun 2015 13:49:49 +, anonymous wrote:
> Taking it one step further:
>
> template Version(string name)
> {
> mixin("
> version("~name~") enum Version = true;
> else enum Version = false;
> ");
> }
>
> static if(Version!"One" || Version!"Two")
> {
>
On Sat, 13 Jun 2015 12:01:29 -0400, bitwise wrote:
>> nope. Walter is against that, so we'll not have it, despite the
>> triviality of the patch.
>
> Any idea what the rationale was for not allowing it?
i don't remember. that murmuring about "it makes the code harder to read"
goes beyond me, so
On Sat, 13 Jun 2015 08:21:50 -0400, ketmar wrote:
On Fri, 12 Jun 2015 20:41:59 -0400, bitwise wrote:
Is there a way to compile for multiple conditions?
Tried all these:
version(One | Two){ }
version(One || Two){ }
version(One && Two){ }
version(One) | version(Two){ }
version(One) || versio
On Saturday, 13 June 2015 at 00:47:37 UTC, Mike Parker wrote:
// config.d
version(One) enum One = true;
else enum One = false;
version(Two) enum Two = true;
else enum Two = false;
// other.d
import config;
static if(One || Two) {
...
}
Taking it one step further:
template Version(string
On Fri, 12 Jun 2015 20:41:59 -0400, bitwise wrote:
> Is there a way to compile for multiple conditions?
>
> Tried all these:
>
> version(One | Two){ }
> version(One || Two){ }
> version(One && Two){ }
> version(One) | version(Two){ }
> version(One) || version(Two){ }
> version(One) && version(T
On Fri, 12 Jun 2015 20:55:51 -0400, Márcio Martins
wrote:
I know... I too hate that one can't use simple logic ops...
Indeed...
Thanks.
Bit
On Saturday, 13 June 2015 at 00:42:00 UTC, bitwise wrote:
Is there a way to compile for multiple conditions?
version(One) version = OneOrTwo;
else version(Two) version = OneOrTwo;
version(OneOrTwo) {
writeln("moo");
}
---
version(One) version(Two) version = OneAndTwo;
version(OneAndTwo)
On 6/13/2015 9:41 AM, bitwise wrote:
Is there a way to compile for multiple conditions?
Tried all these:
version(One | Two){ }
version(One || Two){ }
version(One && Two){ }
version(One) | version(Two){ }
version(One) || version(Two){ }
version(One) && version(Two){ }
Bit
// config.d
vers
Is there a way to compile for multiple conditions?
Tried all these:
version(One | Two){ }
version(One || Two){ }
version(One && Two){ }
version(One) | version(Two){ }
version(One) || version(Two){ }
version(One) && version(Two){ }
Bit
On Monday, 6 April 2015 at 15:24:53 UTC, Namespace wrote:
On Monday, 6 April 2015 at 15:15:48 UTC, Johan Engelen wrote:
On Monday, 6 April 2015 at 14:55:58 UTC, Namespace wrote:
debug {
pragma(lib, "libcmtd.lib");
} else {
pragma(lib, "libcmt.lib");
}
Thanks for the quick reply!
Worth a
On Monday, 6 April 2015 at 15:15:48 UTC, Johan Engelen wrote:
On Monday, 6 April 2015 at 14:55:58 UTC, Namespace wrote:
debug {
pragma(lib, "libcmtd.lib");
} else {
pragma(lib, "libcmt.lib");
}
Thanks for the quick reply!
Worth adding an example like that to
http://dlang.org/version.h
On Monday, 6 April 2015 at 14:55:58 UTC, Namespace wrote:
debug {
pragma(lib, "libcmtd.lib");
} else {
pragma(lib, "libcmt.lib");
}
Thanks for the quick reply!
Worth adding an example like that to
http://dlang.org/version.html ?
On Monday, 6 April 2015 at 14:50:29 UTC, Johan Engelen wrote:
How do conditionally compile code for either release
("-release") or debug ("-debug")?
Something like this:
version(Debug) {
pragma(lib, "libcmtd.lib");
} else {
pragma(lib, "libcmt.lib");
}
In the documentation [1], I don't
How do conditionally compile code for either release ("-release")
or debug ("-debug")?
Something like this:
version(Debug) {
pragma(lib, "libcmtd.lib");
} else {
pragma(lib, "libcmt.lib");
}
In the documentation [1], I don't see any predefined version
identifiers for this purpose.
Th
On 2015-01-07 20:48, Jonathan Marler wrote:
I've looked up the windows version helper functions
(http://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx).
The problem is that these functions are not defined in DMD's
user32.lib. I could use the operating system's user32.
On Wednesday, 7 January 2015 at 19:48:16 UTC, Jonathan Marler
wrote:
On Wednesday, 7 January 2015 at 18:50:40 UTC, Jacob Carlborg
wrote:
On 2015-01-07 19:27, Jonathan Marler wrote:
I'm looking at the Windows multicast API. It has different
socket
options depending on if you are on Windows XP o
On Wednesday, 7 January 2015 at 18:50:40 UTC, Jacob Carlborg
wrote:
On 2015-01-07 19:27, Jonathan Marler wrote:
I'm looking at the Windows multicast API. It has different
socket
options depending on if you are on Windows XP or Windows Vista
(and
later). Is there a way to tell at runtime which
On Wednesday, 7 January 2015 at 18:50:40 UTC, Jacob Carlborg
wrote:
On 2015-01-07 19:27, Jonathan Marler wrote:
I'm looking at the Windows multicast API. It has different
socket
options depending on if you are on Windows XP or Windows Vista
(and
later). Is there a way to tell at runtime which
On Wednesday, 7 January 2015 at 18:50:40 UTC, Jacob Carlborg
wrote:
On 2015-01-07 19:27, Jonathan Marler wrote:
I'm looking at the Windows multicast API. It has different
socket
options depending on if you are on Windows XP or Windows Vista
(and
later). Is there a way to tell at runtime which
On 2015-01-07 19:27, Jonathan Marler wrote:
I'm looking at the Windows multicast API. It has different socket
options depending on if you are on Windows XP or Windows Vista (and
later). Is there a way to tell at runtime which version of windows you
are on? Note: I'm specifically talking about r
I'm looking at the Windows multicast API. It has different
socket options depending on if you are on Windows XP or Windows
Vista (and later). Is there a way to tell at runtime which
version of windows you are on? Note: I'm specifically talking
about runtime because I want the same binary to r
Thx
On Monday, 9 June 2014 at 17:36:10 UTC, Nordlöw wrote:
Can I use the version keyword or static if to perform
conditional compilation that depends on the version of DMD?
The __VERSION__ magic token should do the job.
David
Can I use the version keyword or static if to perform conditional
compilation that depends on the version of DMD?
I typicall something like
version(>= DMD_2.0.66)
{
// use new byChar, byWchar, byDchar, byCodepoint
}
else
{
// use old style slower version
}
If so how?
There is the aforementioned extern(system), which is probably
your best bet. But I'm wondering if your design could seperate
the connection to IUnknown for non-Windows builds? Something
like this:
version(Windows) interface _Inter_ : IUnknown {}
else interface _Inter_ {}
// later
interface
On Friday, 7 June 2013 at 12:20:23 UTC, finalpatch wrote:
string mixins and template mixins don't work either.
On Friday, 7 June 2013 at 12:14:45 UTC, finalpatch wrote:
Hi folks,
I need to apply different calling conventions to the same
interfaces when compiling for different platform. It's
On Friday, 7 June 2013 at 12:14:45 UTC, finalpatch wrote:
Hi folks,
I need to apply different calling conventions to the same
interfaces when compiling for different platform.
extern(System)
On Windows, it will be seen by the compiler as extern(Windows),
elsewhere as extern(C).
string mixins and template mixins don't work either.
On Friday, 7 June 2013 at 12:14:45 UTC, finalpatch wrote:
Hi folks,
I need to apply different calling conventions to the same
interfaces when compiling for different platform. It's
something like this:
OSX:
interface InterfaceA : IUnknow
Hi folks,
I need to apply different calling conventions to the same
interfaces when compiling for different platform. It's something
like this:
OSX:
interface InterfaceA : IUnknown
{
extern(C):
...
}
Windows:
interface InterfaceA : IUnknown
{
...
}
I have to add extern(C) on OSX b
On 28/04/12 15:03, F i L wrote:
Or you could use debug statements:
Yes, that was what I wanted to avoid -- I wanted the tests to be there by
default, not only when debugging ... :-)
AFAICS the foreach loop probably does get optimized out by the compiler (I'm
using GDC); if anything is left,
asserts aren't compiled into release builds (except
assert(false)). So, if the loop only contains asserts, the
compiler *should* be able to strip out the loop altogether. I
don't know if DMD actually does that, though.
Or you could use debug statements:
debug foreach (x; largeArray) {
On 04/28/2012 02:05 PM, Joseph Rushton Wakeling wrote:
Hello all,
I've just been reading through this page: http://dlang.org/version.html
Is there a way to put in place a conditional segment of code that is
included if the code is _not_ compiled with the -release flag?
Of course I can put in a
Joseph Rushton Wakeling:
Is there a way to put in place a conditional segment of code
that is included if the code is _not_ compiled with the
-release flag?
Contract programming? D is designed to make it hard on purpose to
do what you want to do.
The reason I'm asking is because the checks
Hello all,
I've just been reading through this page: http://dlang.org/version.html
Is there a way to put in place a conditional segment of code that is included if
the code is _not_ compiled with the -release flag?
Of course I can put in a debug statement, but that would require me to compile
O... So I if it is in my main function (which I think it is) I should move
it
out? That makes sense... Thank you Timon!!
On 09/22/2011 04:17 AM, alex wrote:
Hi Y'all!! Just as a note, I am new to the news group, but slightly less
new to D =)
Back on topic:
I am unable to get multiple version specifications to work (from the
website)
sometihng like:
version (foo) {
version = bar;
version = baz;
}
version (bar) {
Hi Y'all!! Just as a note, I am new to the news group, but slightly less
new to D =)
Back on topic:
I am unable to get multiple version specifications to work (from the
website)
sometihng like:
version (foo) {
version = bar;
version = baz;
}
version (bar) {
... codes 'n' stuff
}
ve
Mostly babbling... Please comment here and there... :)
What are the semantics of the three? What are your guidelines when
choosing among them? Is my understanding below correct? Have I missed
other related D features?
- specialization means "there is a general definition somewhere; but
this
75 matches
Mail list logo
