Where to put custom ldc2.conf (Windows)

2019-08-03 Thread NonNull via Digitalmars-d-learn

Perhaps I posted this to the wrong forum.
Help needed.
https://forum.dlang.org/post/pdqfquklkhambfccg...@forum.dlang.org



Re: Use std.string.lineSplitter with std.array.Appender!string

2019-08-28 Thread NonNull via Digitalmars-d-learn

On Wednesday, 28 August 2019 at 15:56:55 UTC, Anonymouse wrote:

On Wednesday, 28 August 2019 at 15:52:18 UTC, NonNull wrote:


Disambiguate how ?

```
import std.string, std.array;
auto s = appender!string;
// ...
auto a = s.lineSplitter;
```


auto a = s.data.lineSplitter;

On mobile, can't test.


Yes!


Use std.string.lineSplitter with std.array.Appender!string

2019-08-28 Thread NonNull via Digitalmars-d-learn



Disambiguate how ?

```
import std.string, std.array;
auto s = appender!string;
// ...
auto a = s.lineSplitter;
```

Error: template std.string.lineSplitter cannot deduce function 
from argument types !()(Appender!string), candidates are:


std.string.lineSplitter(Flag keepTerm = No.keepTerminator, 
Range)(Range r) if (hasSlicing!Range && hasLength!Range && 
isSomeChar!(ElementType!Range) && !isSomeString!Range)


std.string.lineSplitter(Flag keepTerm = No.keepTerminator, C)(C[] 
r) if (isSomeChar!C)




opEquals when your type occurs on the right hand side of an equality test

2019-07-31 Thread NonNull via Digitalmars-d-learn
I am creating a specialized bit pattern (secretly represented as 
a uint) as a struct S, but want to avoid `alias this` to maintain 
encapsulation excepting where I overtly say. Specifically, I want 
to avoid making arithmetic and inequalities available for S.


I have written opEquals to compare an S to a uint.

How do I write code to compare a uint to an S?



Translating Java into D

2019-11-14 Thread NonNull via Digitalmars-d-learn
Greetings, Java seems to be almost a subset of D in various ways. 
Has there been any work done to automatically translate Java 
source into D?




Functional Programming in D

2019-10-09 Thread NonNull via Digitalmars-d-learn

Hello,
I want to become fluent in the use of functional programming 
techniques in D (as well as the use of ranges) using 
std.functional (and std.algorithm and whatever else is relevant). 
Is there anything out there that isn't just module documentation 
that covers the full scope of this?




large Windows mingw64 project in C99 --- need ABI compatible D compiler

2020-05-20 Thread NonNull via Digitalmars-d-learn

Hello,

I have a large project written in C99 handed to me that 32-bit 
builds in Windows with the mingw32 compiler that comes with 
msys2. I'm working on 64-bit Windows 10.


Need to solve some nasty problems and move the build to 64 bits 
using the mingw64 compiler that comes with msys2.


Want to use D to improve some parts of this monster. But am 
confused about ABI issues.


Which D compiler should be used to be ABI compatible with 
mingw32? And which to be ABI compatible with mingw64?


The most important is the D compiler that is ABI compatible with 
the 64-bit mingw compiler because that is where this project is 
going.


How can I use D in this situation, where I need it to work 
directly with C data? building DLLs is not going to work here for 
that reason.





Re: large Windows mingw64 project in C99 --- need ABI compatible D compiler

2020-05-20 Thread NonNull via Digitalmars-d-learn

On Wednesday, 20 May 2020 at 23:10:12 UTC, IGotD- wrote:

On Wednesday, 20 May 2020 at 23:08:53 UTC, IGotD- wrote:

On Wednesday, 20 May 2020 at 21:37:23 UTC, kinke wrote:


You're welcome. If you do come across an ABI issue, make sure 
to file an LDC issue. While I have no interest in MinGW, I 
want at least a working ABI.


When you mention the ABI, is there something particular you 
have in mind or just in general?


That's a question to TS, NonNull.


General.


Re: large Windows mingw64 project in C99 --- need ABI compatible D compiler

2020-05-20 Thread NonNull via Digitalmars-d-learn

On Wednesday, 20 May 2020 at 19:25:27 UTC, kinke wrote:

On Wednesday, 20 May 2020 at 18:53:01 UTC, NonNull wrote:
Which D compiler should be used to be ABI compatible with 
mingw32? And which to be ABI compatible with mingw64?


The natural choice for coupling mingw[64]-gcc would be GDC. 
Especially wrt. ABI, gdc apparently doesn't have to do much by 
itself, in sharp contrast to LDC. No idea where gdc's 
MinGW[-w64] support is at though and whether you need more 
recent D features not available in gdc.

[...]


Thanks for the detailed information!

I see your point about gdc's ABI, but it seems gdc is not 
distributed for Windows at this juncture and I am looking for a 
simple way forward, so I will likely go with ldc2 with the option 
you suggested and see how it goes.


Thanks again!




Re: Best way to confine project to 64 bit builds only?

2020-10-17 Thread NonNull via Digitalmars-d-learn

On Saturday, 17 October 2020 at 14:56:33 UTC, Basile B. wrote:

On Saturday, 17 October 2020 at 14:50:47 UTC, NonNull wrote:
I have inherited an open source C project that assumes that 
the size of a long and the size of a pointer are the same, and 
I have translated it into very similar D just like 
https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/


D has the size of long fixed at 64 bits, so a pointer now has 
to be 64 bits.


No it's wrong. A pointer always has the size of a general 
purpose register.


You misunderstand. The original C only works if the size of a 
pointer is the same as the size of a long. So when translated 
into D in a simple way where the size of a long is always 64 bits 
the D will only work if the size of a pointer is 64 bits.


Re: Forward referencing functions in D

2020-10-17 Thread NonNull via Digitalmars-d-learn
On Friday, 16 October 2020 at 21:28:18 UTC, Steven Schveighoffer 
wrote:

Inner functions have benefits:

1. They are only accessible inside the function. Which means 
you only have to worry about correctness while INSIDE that 
function.
2. inner functions have access to the outer function's stack 
frame.


Often, I use inner functions to factor out a common piece of 
code that I don't want to have to write multiple times in the 
same function.


-Steve


How can you write two inner functions that call each other? 
(Recursively)


Re: Best way to confine project to 64 bit builds only?

2020-10-17 Thread NonNull via Digitalmars-d-learn

On Saturday, 17 October 2020 at 15:03:29 UTC, Dennis wrote:
If you want to exactly match the original C code's semantics, I 
suggest translating (unsigned) long with c_long or c_ulong. You 
can import them here:

```
import core.stdc.config: c_long, c_ulong;
```

Then you could add this:
```
static assert(c_long.sizeof == size_t.sizeof);
```

This will fail on Windows 64 bit, where C longs are 32-bit and 
pointers 64-bit.


That is useful information in general, I did not know about 
core.stdc.config and it is useful in future projects!


But for my project the C works at 64 bits except on Windows for 
the reason you gave. So by translating long in C to long in D it 
loses 32 bits but gains 64 bits on Windows. This is what I want.


Best way to confine project to 64 bit builds only?

2020-10-17 Thread NonNull via Digitalmars-d-learn
I have inherited an open source C project that assumes that the 
size of a long and the size of a pointer are the same, and I have 
translated it into very similar D just like 
https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/


D has the size of long fixed at 64 bits, so a pointer now has to 
be 64 bits. So I want to put something into the source to ensure 
an attempt to make a 32 bit build fails. What is the best way to 
do this?


Re: Best way to confine project to 64 bit builds only?

2020-10-17 Thread NonNull via Digitalmars-d-learn

On Saturday, 17 October 2020 at 14:56:35 UTC, Adam D. Ruppe wrote:

On Saturday, 17 October 2020 at 14:50:47 UTC, NonNull wrote:
I have inherited an open source C project that assumes that 
the size of a long and the size of a pointer are the same


static assert(long.sizeof == void*.sizeof);


That's a nice clean answer!


Re: reference variables don't exist, but can simulate them

2020-06-28 Thread NonNull via Digitalmars-d-learn

On Sunday, 28 June 2020 at 20:59:59 UTC, NonNull wrote:

Using gdc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Please criticize:

struct refer(T) {
  T* ptr;
  this(ref T x) { ptr =  }
  ref T _() { return *ptr; }
  alias _ this;
  string toString() { import std.conv; return to!string(*ptr);  
}

}

This will make a reference variable (simulation). [ toString() 
is just for writeln. ]


void main() {
int i = 100;
refer!int j = i;
j = 3;
writeln(i);
i = 100;
writeln(j);
j += 3;
writeln(i);
refer!int k = j;
writeln(k);
}

And a refer!int can be returned as it is just a value. 
Returning one that contains a pointer to a local variable leads 
to a compilation error.


* does not lead to a compilation error



reference variables don't exist, but can simulate them

2020-06-28 Thread NonNull via Digitalmars-d-learn

Using gdc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Please criticize:

struct refer(T) {
  T* ptr;
  this(ref T x) { ptr =  }
  ref T _() { return *ptr; }
  alias _ this;
  string toString() { import std.conv; return to!string(*ptr);  }
}

This will make a reference variable (simulation). [ toString() is 
just for writeln. ]


void main() {
int i = 100;
refer!int j = i;
j = 3;
writeln(i);
i = 100;
writeln(j);
j += 3;
writeln(i);
refer!int k = j;
writeln(k);
}

And a refer!int can be returned as it is just a value. Returning 
one that contains a pointer to a local variable leads to a 
compilation error.







Re: reference variables don't exist, but can simulate them

2020-06-28 Thread NonNull via Digitalmars-d-learn

On Sunday, 28 June 2020 at 21:01:36 UTC, NonNull wrote:

On Sunday, 28 June 2020 at 20:59:59 UTC, NonNull wrote:

Using gdc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Please criticize:

struct refer(T) {
  T* ptr;
  this(ref T x) { ptr =  }
  ref T _() { return *ptr; }
  alias _ this;
  string toString() { import std.conv; return to!string(*ptr);
 }
}

This will make a reference variable (simulation). [ toString() 
is just for writeln. ]


void main() {
int i = 100;
refer!int j = i;
j = 3;
writeln(i);
i = 100;
writeln(j);
j += 3;
writeln(i);
refer!int k = j;
writeln(k);
}

And a refer!int can be returned as it is just a value. 
Returning one that contains a pointer to a local variable 
leads to a compilation error.


* does not lead to a compilation error


Now with a different compiler I this:

Deprecation: Cannot use alias this to partially initialize 
variable j of type refer. Use j._()


This is for the line j=3

What is this about? Where does this hidden rule come from?



mixin template compile-time compute declared name

2020-06-27 Thread NonNull via Digitalmars-d-learn



Want

mixin mytemplate!("foo", .);

to be able to declare names dependent upon the text foo in the 
context it is used.


For example declaring

enum x_foo = ;
blah foo_value = ;
.
.
.
.

Is it possible to use a template to declare something whose name 
is computed at compile time?






Re: mixin template compile-time compute declared name

2020-06-27 Thread NonNull via Digitalmars-d-learn

On Saturday, 27 June 2020 at 21:23:10 UTC, Adam D. Ruppe wrote:

On Saturday, 27 June 2020 at 21:10:59 UTC, NonNull wrote:
Is it possible to use a template to declare something whose 
name is computed at compile time?


You'd have to string mixin the contents inside the mixin 
template.


Worked! Thank you!!


Simulating computed goto

2020-11-25 Thread NonNull via Digitalmars-d-learn
For automatically generated code of some low level kinds it is 
convenient to have "computed goto" like this:


https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

and D does not have this.

A switch could be used to simulate it. But this would lead to 
what could have been a single jump being chained jumps.


How good is optimization in ldc2, gdc, dmd at compiling chained 
jumps into one jump each time?


Is there a good way to simulate computed goto in D?



Re: Simulating computed goto

2020-11-25 Thread NonNull via Digitalmars-d-learn

On Wednesday, 25 November 2020 at 19:04:45 UTC, H. S. Teoh wrote:
FWIW, D's switch statement is flexible enough to directly write 
Duff's device.



How good is optimization in ldc2, gdc, dmd at compiling 
chained jumps into one jump each time?


I'm pretty sure ldc2 and gdc will optimize away any such 
chained jumps. But if performance is important to you, I 
recommend *not* bothering with dmd.


Yes this is about efficiency.


Is there a good way to simulate computed goto in D?


With a switch statement. ;)


OK, so I took a look at switch documentation and tried out 
something. It looked like switch can have computed goto using 
case labels.


case 5:
  //...
  goto case ; //doesn't compile when  is 
not a constant


So to simulate computed goto have to
1. wrap switch(x) in a loop [ while(0) ]
2. inside each case recompute x (instead of jump to computed y)
3. jump back to execute switch again [ continue ]

It does look as if a nested switch can contain case labels from 
an outer switch which is very good. Did not try this out.


Any more ideas, advice?





Re: Simulating computed goto

2020-11-26 Thread NonNull via Digitalmars-d-learn

On Thursday, 26 November 2020 at 04:42:08 UTC, Dukc wrote:

On Wednesday, 25 November 2020 at 18:44:52 UTC, NonNull wrote:

Is there a good way to simulate computed goto in D?


I haven't used assembly myself, but it's possible that you can 
define a mixin that does this, using inline assembly.


Interesting idea!


Re: Simulating computed goto

2020-11-26 Thread NonNull via Digitalmars-d-learn

On Wednesday, 25 November 2020 at 18:57:35 UTC, Paul Backus wrote:

On Wednesday, 25 November 2020 at 18:44:52 UTC, NonNull wrote:
How good is optimization in ldc2, gdc, dmd at compiling 
chained jumps into one jump each time?


The easiest way to find the answer to a question like this is 
to use the compiler explorer:


https://d.godbolt.org/


Very good tool! Thanks.