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.

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

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

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

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

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: ```

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);

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

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

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

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

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()

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!

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

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

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.

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

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?

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;

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

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

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