Re: std.sumtype nested SumTypes
On Monday, 22 January 2024 at 21:36:47 UTC, Paul Backus wrote: SumType does not do this automatically (because sometimes you might want to keep the inner SumTypes separate), but you can do it yourself like this: alias A = SumType!(X, Y); alias B = SumType!(Z, W); alias C = SumType!(A.Types, B.Types); Very nice!
Re: std.sumtype nested SumTypes
On Monday, 22 January 2024 at 16:35:39 UTC, ryuukk_ wrote: On Monday, 22 January 2024 at 16:16:56 UTC, NonNull wrote: I am defining a new value type (small struct) from some old value types that are already `SumType`s. So I want to have some `SumType`s as some of the alternative types in another `SumType`. How how efficient this is, including space efficient? Without knowing what you are doing, this sounds like a bad idea, i suggest to revise your design I'd like SumType to combine the implicit tags so there's only one tag.
std.sumtype nested SumTypes
I am defining a new value type (small struct) from some old value types that are already `SumType`s. So I want to have some `SumType`s as some of the alternative types in another `SumType`. How how efficient this is, including space efficient?
Re: class variable initialization
On Saturday, 15 April 2023 at 15:47:40 UTC, Steven Schveighoffer
wrote:
You can construct objects at compile time.
If I understand your question properly:
```d
struct Wrapper
{
Object x = new Object();
alias x this;
}
void foo(Object o)
{
assert(o !is null);
}
void main()
{
Wrapper w;
foo(w);
}
```
-Steve
Amazing, was this always so?
Re: class variable initialization
On Saturday, 15 April 2023 at 14:17:19 UTC, Vijay Nayar wrote:
I believe if you do initialization at the class declaration
level, then every instance of the class shares the same
instance, e.g.:
```
class Var {}
class MyClass {
Var var = new Var();
}
void main() {
MyClass c1 = new MyClass();
MyClass c2 = new MyClass();
assert(c1.var is c2.var);
}
```
I should have made it clear that want a single shared default
object. Your code above solves that problem. So does
```
Var defaultObj;
static this() { defaultObj = new Var(); }
```
By wrapping the new variable and the constructor call to
initialize it in MyClass, you eliminate the need to call the
constructor, which is what I want, but now you add the need to
call another constructor. So for my purposes this is just moving
the problem of null to another place.
class variable initialization
I want a way to default initialize a class variable to a default object (e.g. by wrapping it in a struct, because initialization to null cannot be changed directly). Such a default object is of course not available at compile time which seems to make this impossible. Can this be done in some way?
Re: Windows specific: MS C++ versus D thread local variables
On Saturday, 26 November 2022 at 23:36:13 UTC, NonNull wrote: In the CLR module I have a static variable that can contain a reference to a .NET object. I need that variable to be thread local. I achieved this by prefixing its declaration with [System::ThreadStaticAttribute]. But this is thread local for .NET concurrency. How will this variable behave with a multi-threaded D program (that calls those exported library functions from more than one thread) and why? I tested this with D threads and it works for my test program. I might guess that this is so in general, because such a library has to successfully work with arbitrary MS VC++ and that "interop" is defined by MS to work.
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Sunday, 27 November 2022 at 17:26:37 UTC, NonNull wrote: I worked around this by setting a LIB environment variable containing the extra path I needed, so I didn't need the pragma. But this only worked for ldc2; dmd still complained it cannot find the necessary, ignoring the LIB environment variable. Is this a bug? I set the LIB environment variable and now ```ldc2 main.d``` works. So I know LIB is set correctly. But ```dmd main.d``` still has linking fail to find libraries at the location LIB. I did both in a new console where ```echo %LIB%``` produced the expected path. Any idea what may be going on with dmd?
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Monday, 28 November 2022 at 14:41:01 UTC, Adam D Ruppe wrote: This is the Microsoft doc page for the feature the pragma uses: https://learn.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?source=recommendations=msvc-170#linker It looks like they actually removed some options in the recent update, I know /SUBSYSTEM used to work there too but it is no longer listed and there's people on the web saying it stopped working after updating to the 2022 visual studio. So yeah I think they removed support for that. But /LIBPATH has never been supported as far as I know. Aha! Thank you: the MS doc page is very informative. So https://dlang.org/spec/pragma.html#linkerDirective is not simply a mechanism that via the object file can get any directive eventually to the linker as if on the command line. I've been completely successful using pragma(lib,_) but looking carefully I see that https://dlang.org/spec/pragma.html#lib contains highly significant clues under "implementation defined" when compared to "implementation defined" under https://dlang.org/spec/pragma.html#linkerDirective --- pragma(lib,_) in effect guarantees to get the information through to the linker. It is not restricted to MS-COFF, and is not restricted to passing the information through the object file but may use "other means" left unspecified. --- pragma(linkerDirective,_) IS restricted in these ways as you made clear. So by comparison I should have realized, taking the hint "restricted to MS-COFF" that the documentation for the MS linker about what directives can be embedded in object files was pertinent, because who knows what MS may permit?! The clues were all there. But I didn't catch on. Sorry about the kerfuffle. I have now successfully used pragma(lib,_) with a full path to link what's needed without resorting to external build stuff. I just need one pragma(lib,_) per library.
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Sunday, 27 November 2022 at 17:37:50 UTC, kinke wrote: For LDC, you shouldn't need any double quotes, the compiler quotes the linker flag if it contains spaces. In fact I cannot find any way (multiple double quotes, escaped double quotes, different combinations of these) to get any double quotes whatsoever into the linker command line via pragma(linkerDirective,_). The linker always complains and the quoted error always contains no double quotes. The behavior of ldc2 is identical to that of dmd with all attempts. pragma(linkerDirective,_) is broken apparently. Please confirm or show how to use.
Re: pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
On Sunday, 27 November 2022 at 17:37:50 UTC, kinke wrote: For LDC, you shouldn't need any double quotes, the compiler quotes the linker flag if it contains spaces. Didn't work for me with LDC: This, which works at the command line with ```-L=```: ```enum LIBPATH = `/LIBPATH:"C:\Program Files (x86)\Windows Kits\NETFXSDK\4.7.2\Lib\um\x64"`; pragma(linkerDirective, LIBPATH);``` gave this: ```warning LNK4229: invalid directive '/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.7.2\Lib\um\x64' encountered; ignored``` and without the double quotes gave this: ```fatal error LNK1276: invalid directive 'Files' found; does not start with '/'``` This, which also works at the command line with ```-L=```: ```enum LIBPATH = `"/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.7.2\Lib\um\x64"`; pragma(linkerDirective, LIBPATH);``` gave this: ```warning LNK4229: invalid directive '/LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.7.2\Lib\um\x64' encountered; ignored``` So double quotes are not arriving at the destination.
pragma(linkerDirective,_) removes double quotes, dmd ignores LIB
Hello, using dmd 2.100.2 and ldc2 1.30.0, compiling to 64-bits, Windows 10. pragma(linkerDirective,_) strips double quotation marks, so how can a linker command line like /LIBPATH:"Path/containing spaces/to/needed/libs" be passed on to the linker via this pragma? Is this a bug? Note: the libs in question are installed in locations not determined by me. I worked around this by setting a LIB environment variable containing the extra path I needed, so I didn't need the pragma. But this only worked for ldc2; dmd still complained it cannot find the necessary, ignoring the LIB environment variable. Is this a bug?
Windows specific: MS C++ versus D thread local variables
Hello, a low level question about Windows internals and D interacting with .NET at a low level. I just made an experimental native .lib (static library) with MS's C++ compiler, providing a C API for D to link to. The .lib contains one module compiled with the /CLR option which provides some functions manipulating .NET objects, and the C API is in another module compiled to native code (no /CLR option), containing the definitions of the functions to be exported to D, which in turn call those in the CLR module via a mechanism silently implemented by the MS compiler. I then have successfully used both dmd and ldc2 to build a D test program statically linked to this .lib calling the functions in its API. It works fine in this toy singly threaded example. All builds are 64-bit. I am using the versions of the compilers that came with Visual D. As well as the C++ compiler that comes with VS2022 (Community). In the CLR module I have a static variable that can contain a reference to a .NET object. I need that variable to be thread local. I achieved this by prefixing its declaration with [System::ThreadStaticAttribute]. But this is thread local for .NET concurrency. How will this variable behave with a multi-threaded D program (that calls those exported library functions from more than one thread) and why? I first had written the library code for a .dll (dynamic library) and had the D test program be linked to its import library, so I could make it work without the inevitable linkage issues. How will the static variable behave in this situation with a multi-threaded D program and why? --- the same as when statically linked? I'm looking for an actual technical explanation in both cases please.
Re: overloading main
On Sunday, 30 October 2022 at 18:24:22 UTC, Adam D Ruppe wrote:
it prolly just to keep newbs from making confusing mistakes and
getting weird behavior at startup. If there's two mains, which
one is the expected entry? Perhaps it could just be the one
that matches the permitted signature, and if there isn't one it
complains. But how does it know if there is one? Suppose
there's module A:
module a;
int main(int argc, char** argv) {}
And module B:
module b;
void main() {}
They are compiled separately:
dmd -c a.d
dmd -c b.d
dmd a.o b.o
Which one is the main you want to use? What if you just did
`dmd a.d`, should it error that the prototype is wrong, or just
give the user the linker error "could not find D main" when
they think they have it right there? (remember the linker
doesn't know what D signatures are so it can't print a helpful
message to correct the mistake).
Ah, makes sense to limit the possible low level error messages
with separate compilation because of the linker not knowing D
signatures. Thanks for the intuition.
Re: overloading main
On Sunday, 30 October 2022 at 17:41:07 UTC, Imperatorn wrote: On Sunday, 30 October 2022 at 17:29:25 UTC, NonNull wrote: On Sunday, 30 October 2022 at 16:31:45 UTC, Imperatorn wrote: You should not have multiple mains. Rename it and call it Doesn't answer my questions. I wasn't asking for practical, moral or esthetic advice. Try to phrase your question more clearly. I'm just stating a fact. Doesn't look like a fact. Looks like a judgment. A different judgment might be to allow overloads and not have them be an entry point unless they have the signatures identified as such by D. My questions "Is this restriction essential? And if not, why make it?" are asking to justify the judgment you made. Which you did not do. So you have not answered them. Not unclear at all.
Re: overloading main
On Sunday, 30 October 2022 at 16:31:45 UTC, Imperatorn wrote: You should not have multiple mains. Rename it and call it Doesn't answer my questions. I wasn't asking for practical, moral or esthetic advice.
overloading main
I am linking to a C project with some C already automatically
translated into D including the C main function `int main(int
argc, char** argv){/* ... */}` which I wanted to call from a D
main function in a new module. But then I found that the former C
main in D will not compile! ldc2 complains that main must only
have prototypes as if it is the entry point. So it seems that
main cannot be overloaded with a prototype that is not a valid
entry point in D. Is this restriction essential? And if not, why
make it?
Re: line terminators
On Wednesday, 28 September 2022 at 21:17:16 UTC, rassoc wrote: On 9/28/22 21:36, NonNull via Digitalmars-d-learn wrote: [...] If you have structured data, you can use byRecord [1] to read the important parts right into a tuple. [...] Thanks --- very helpful.
line terminators
Hello, I notice that readln from std.stdio has '\n' as the default line terminator. What about multiple line terminators in UTF-8 being used in one input file, such as '\n', NEL, LS, PS? And in Windows "\r\n" is a line terminator, and what if NEL, LS, PS exist in a Windows UTF-8 text file as well? The following explains the details when reading Unicode. https://en.wikipedia.org/wiki/Newline#Unicode If I want to read a text file line by line, treating any one of these things as a newline, there would seem to be no canned way to do that in std.stdio . 1.) What is the best way to achieve this result in D? It is convenient to read text files of unknown origin in this fashion. Additionally discarding the newlines however they are represented is convenient. 2.) What about reading UTF-16LE text files line by line (e.g. from Windows, with a BOM)?
type in extern declaration
How do I write the type of a function so as to alias it, and use
that in an extern(C) declaration?
For example, how do I write the type of an external function
int main2(int argc, char** argv) {
//
}
?
This is not
int function(int, char**)
because this is the type of a function pointer of the right type,
not the type of the function itself.
If I had that type aliased to mainfunc I could write
extern(C) mainfunc main2;
in D source to arrange to call it, and similarly any other
functions of the same type.
Re: Which operators cannot be overloaded and why not?
On Monday, 13 September 2021 at 16:12:34 UTC, H. S. Teoh wrote: On Mon, Sep 13, 2021 at 02:12:36PM +, NonNull via Digitalmars-d-learn wrote: Which operators cannot be overloaded and why not? Others have already given the list, so I won't repeat that. I didn't see unary &. Maybe others are missing. As to the "why": In general, D tries to avoid the wild wild west, every operator for himself situation in C++ that leads to unreadable, unmaintainable code. Thanks for this explanation. The consolidation you mention is great!
Re: Which operators cannot be overloaded and why not?
On Monday, 13 September 2021 at 14:42:42 UTC, jfondren wrote: On Monday, 13 September 2021 at 14:33:03 UTC, user1234 wrote: - condition al expression ` cond ? exp : exp ` And many other boolean operators, unary !, binary && and || https://dlang.org/spec/operatoroverloading.html lists all the overloadable operators, and https://dlang.org/spec/expression.html has all the operators, so "which operators" is a matter of close comparison. Is there no list of such in an article online? It would be good if that work was done for once and for all, with a short explanation in each case, possibly with discussion in some cases of how to achieve results by other means.
Which operators cannot be overloaded and why not?
Which operators cannot be overloaded and why not?
Re: Building several dynamic libraries with one shared GC
On Sunday, 12 September 2021 at 18:56:50 UTC, Ali Çehreli wrote: All initialization functions of the plugins were called automatically in my D test environment and all plugins were usable. The trouble started when the main library was being used in a foreign environment (something like Python loading Python loading C++ library loading our D library): Although the initialization function of the main library was being called, the 'shared static this' functions of the plugins were not being called. So here, your main dynamic library in turn dynamically loads plugins. Did you try simply calling a function exported by a plugin from the static constructor in the main library after it had made the call to initialize druntime to see if that stimulated running the plugin's static constructors first? The problem you linked to suggests that might do the job. I haven't run into this problem yet myself. But I'm interested.
Re: Building several dynamic libraries with one shared GC
On Sunday, 12 September 2021 at 18:56:50 UTC, Ali Çehreli wrote: All initialization functions of the plugins were called automatically in my D test environment and all plugins were usable. The trouble started when the main library was being used in a foreign environment (something like Python loading Python loading C++ library loading our D library): Although the initialization function of the main library was being called, the 'shared static this' functions of the plugins were not being called. (I tried dlopen after guessing intelligently the name of the 'shared static this' function (not obvious); it was not satisfactory and I don't remember exactly why not.) Later I learned, this could be because merely loading a plugin might not be enough, and perhaps the main library might have to use a feature of the library as well: https://forum.dlang.org/post/sdb5jb$2rk3$1...@digitalmars.com [...] > If several plugins are built by different third parties, each dynamic > library will have its own GC and copy of druntime right now. Like the user 'frame', I don't think that's the case. I hope you're right about this last. Not sure how static versus dynamic linking affects it. ldc2 seems to default to dynamic linking for phobos and have druntime in a dynamic library too. [Not clear what DMD does with druntime when it dynamically links to phobos.] In that ideal situation you seem to be right. Not sure how a plugin can be distributed as an executable only (to those without a D compiler installed) without static linking and then what? I have a mess to sort out. Any info or suggestions?
Re: Building several dynamic libraries with one shared GC
On Sunday, 12 September 2021 at 16:23:13 UTC, frame wrote: Shouldn't the runtime not already be shared on Linux? The `Runtime.loadLibrary` specs say `If the library contains a D runtime it will be integrated with the current runtime.` This should be true for the GC too. At least the memory is shared because as I remember I could access __gshared variables, whereas on Windows nothing like this works and any DLL will spawn a new thread (for each thread you use too). The plugin libraries expose a C API and are dynamically loaded by the application which is written in C, so presumably using dlopen. No D runtime there. Still your reply does suggest a way to proceed...
Building several dynamic libraries with one shared GC
I am making a plug-in development system for a high performance Linux application that already exists and is written in C and will not be modified for this purpose. It is already has an API for plugins written in C. A plug-in simply makes new functions (e.g. manipulating text and numbers) available to be used inside the application. The D GC will intentionally be available inside a plugin. I have written a D source file containing templates that do the work when a plugin is written by a third party in D. A plugin will expose a C API for the functions made available to the application, and any data in D made available to the application will be copied to the application's managed storage and vice versa, so there are no GC issues. All of this is to make it as simple as possible for a third party to write such a plugin without worrying about any of these issues, and use D in a simplistic scripting language-like way. This is for non-experts. They just use the templates and build a dynamic library and all of the above is done for them. If several plugins are built by different third parties, each dynamic library will have its own GC and copy of druntime right now. How can I organize that there is one separate dynamic library to share these among all plugins?
Re: Name Mangling & its representation of D types
On Wednesday, 4 August 2021 at 02:01:54 UTC, Mathias LANG wrote: Yes, because D is a nominal type system, using the FQN of the symbol is enough. [...] Mangling is altered by `extern(LANG)` (where LANG is one of `C`, `C++`, `Objective-C`, `System`, `D`), or `pragma(mangle)`. All useful information, thank you.
Re: Name Mangling & its representation of D types
On Tuesday, 3 August 2021 at 17:14:42 UTC, Ali Çehreli wrote: On 8/3/21 9:43 AM, NonNull wrote: I'd like to understand how any D type is represented as a string by the name mangling done by the compilers. Related article that mentions .mangleof, a property of all symbols: https://dlang.org/blog/2017/12/20/ds-newfangled-name-mangling/ Ali Thanks for that: will read.
Re: Name Mangling & its representation of D types
On Tuesday, 3 August 2021 at 17:01:38 UTC, Mike Parker wrote: On Tuesday, 3 August 2021 at 16:43:52 UTC, NonNull wrote: how does it work for recursive types like a struct containing a pointer to a struct of the same type A struct `S` with a member of type `S*` is still just a struct `S`. The pointer doesn't change anything about the type. Aha, so it just uses the name S, not an algebraic representation of the structure of S.
Name Mangling & its representation of D types
I'd like to understand how any D type is represented as a string by the name mangling done by the compilers. Does this always have the desirable property that different types have different mangled names, so that a type is faithfully represented by its mangled string incorporated into a symbol name in an object file? What is that representation of a type as a string, and how does it work for recursive types like a struct containing a pointer to a struct of the same type? Please explain.
Near-simplest route to learn D
Hello, Some documents/books seem to be out of date. If an intuitive person competent in several other programming languages and in abstract reasoning wanted to take the fastest route to learn pretty much the whole of D as it stands now, having already learned and used a core of the language, what is the best way to proceed? And how long would this likely take?
Re: Broken examples
On Friday, 5 March 2021 at 22:59:09 UTC, H. S. Teoh wrote: On Fri, Mar 05, 2021 at 10:01:37PM +, Imperatorn via Digitalmars-d-learn wrote: Basically none of the examples on here compile: https://dlang.org/library/std/conv/parse.html Any idea why? File a bug. T Sad that there's such an uninviting space for outsiders coming in.
Re: Simulating computed goto
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
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.
Re: Simulating computed goto
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?
Simulating computed goto
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: Forward referencing functions in D
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?
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.
Re: Best way to confine project to 64 bit builds only?
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: Best way to confine project to 64 bit builds only?
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.
Best way to confine project to 64 bit builds only?
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: reference variables don't exist, but can simulate them
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?
Re: reference variables don't exist, but can simulate them
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
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: mixin template compile-time compute declared name
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!!
mixin template compile-time compute declared name
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: large Windows mingw64 project in C99 --- need ABI compatible D compiler
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
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!
large Windows mingw64 project in C99 --- need ABI compatible D compiler
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.
Translating Java into D
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
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
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
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)
Where to put custom ldc2.conf (Windows)
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
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?
