Re: Runtime heterogeneous collections?
I'd like to thank everyone for their help! I was finally able to do what I'd like. I didn't end up using a variant, but maybe there's a better way to do what I want using it, and I just couldn't figure it out. Here's the solution I finally came up with: https://run.dlang.io/is/GdDDBp If anyone has any better solutions I'm all ears!
Re: Am I misusing with?
On Saturday, 19 January 2019 at 20:38:00 UTC, faissaloo wrote: On Saturday, 19 January 2019 at 20:07:34 UTC, Rubn wrote: On Saturday, 19 January 2019 at 17:49:31 UTC, faissaloo wrote: [...] If you look at the implementation, "lines" is a struct. https://github.com/dlang/phobos/blob/v2.084.0/std/stdio.d#L4330 [...] Ah that makes some sense, thanks for the explanation. If you import symbols explicitly, you'd have known. Probably in your code: import std.file; What should be there: import std.file : File, lines; If lines is a member of the File struct, the import fails. If lines is not a member of File, not importing it fails. You get more detailed information. Using import bind lists [1] usually is a good idea. [1] https://dlang.org/spec/module.html#import-declaration
Re: Am I misusing with?
On Saturday, 19 January 2019 at 20:07:34 UTC, Rubn wrote: On Saturday, 19 January 2019 at 17:49:31 UTC, faissaloo wrote: [...] If you look at the implementation, "lines" is a struct. https://github.com/dlang/phobos/blob/v2.084.0/std/stdio.d#L4330 [...] Ah that makes some sense, thanks for the explanation.
Re: Am I misusing with?
On Saturday, 19 January 2019 at 17:49:31 UTC, faissaloo wrote:
This seems to work fine
file = File("test.txt", "r");
with (file)
{
scope(exit) close();
foreach (string line; file.lines())
{
line_array ~= line;
}
}
however:
file = File("test.txt", "r");
with (file)
{
scope(exit) close();
foreach (string line; lines())
{
line_array ~= line;
}
}
Tells me I'm attempting to read from an unopened file, what's
going on here? It seems like I'm able to use lines() like this
within with statements unless they're in my foreach iterator.
Is this a bug or intended behaviour?
If you look at the implementation, "lines" is a struct.
https://github.com/dlang/phobos/blob/v2.084.0/std/stdio.d#L4330
I didn't know you could use structs with UFCS, which is why you
are probably confused as well. It's a function defined in "file".
If you use lines() by itself, you are constructing a new "lines"
struct where the default File is an unopened file.
I tend to avoid "with" altogether because of things like this. It
becomes hard to tell what is actually part of the struct and what
is just UFCS. If you do want to use the object with UFCS you have
to explicitly use the object anyways so the point is kind of mute.
UFCS if you don't know just means you can use global functions
(and apparently structs) with the same syntax as if it were a
member function:
struct testStruct {
this( int value ) {
import std.stdio : writeln;
writeln("testStruct - ", value);
}
}
void test(int value) {
import std.stdio : writeln;
writeln( value );
}
void main() {
10.test(); // prints 10
20.testStruct();
}
https://run.dlang.io/is/0Xpnmt
Re: Compiling to 68K processor (Maybe GDC?)
On Saturday, 19 January 2019 at 12:54:28 UTC, rikki cattermole wrote: I have no idea about GDC, but the -betterC flag is pretty recent so its support may not be what you would consider first class there yet. so specifically -betterC has been around for years, but it has only recently become somewhat usable in dmd. The pre-built gdc won't work well with -betterC but a custom built one... might. Probably not though.
Am I misusing with?
This seems to work fine
file = File("test.txt", "r");
with (file)
{
scope(exit) close();
foreach (string line; file.lines())
{
line_array ~= line;
}
}
however:
file = File("test.txt", "r");
with (file)
{
scope(exit) close();
foreach (string line; lines())
{
line_array ~= line;
}
}
Tells me I'm attempting to read from an unopened file, what's
going on here? It seems like I'm able to use lines() like this
within with statements unless they're in my foreach iterator. Is
this a bug or intended behaviour?
Re: Compiling to 68K processor (Maybe GDC?)
On Saturday, 19 January 2019 at 12:54:28 UTC, rikki cattermole wrote: On 20/01/2019 1:38 AM, Edgar Vivar wrote: Hi, I have a project aiming to old 68K processor. While I don't think DMD would be able for this on the other hand I think GDC can, am I right? If yes would be any restriction of features to be used? Or the compiler would be smart enough to handle this properly? Edgar V. Potentially. D is designed to only work on 32bit+ architectures. The 68k series did have 32bit versions of them. After a quick check it does look like LDC is out as LLVM has not yet got support for M68k target. Which is unfortunate because with the -betterC flag it could have pretty much out of the box worked. Even if you don't have most of D at your disposal e.g. classes and GC (but hey old cpu! can't expect that). I have no idea about GDC, but the -betterC flag is pretty recent so its support may not be what you would consider first class there yet. At least 68030 (or 68020+68851) would be necessary for proper segfault managing (MMU) and an OS that uses it. Afaict NULL pointer derefernecing must fault for D to be "usable". At least all code is written with that assumption.
Re: Is there a nice syntax to achieve optional named parameters?
On Tuesday, 15 January 2019 at 11:14:54 UTC, John Burton wrote:
As an example let's say I have a type 'Window' that represents
a win32 window. I'd like to be able to construct an instance of
the type with some optional parameters that default to some
reasonable settings and create the underlying win32 window.
[...]
how about this
auto With(string code,T)(T value)
{
with(value)
{
mixin(code ~";");
}
return value;
}
auto window = Window().With!q{title = "My window",width =
800,fullscreen = true};
Re: Compiling to 68K processor (Maybe GDC?)
On 20/01/2019 1:38 AM, Edgar Vivar wrote: Hi, I have a project aiming to old 68K processor. While I don't think DMD would be able for this on the other hand I think GDC can, am I right? If yes would be any restriction of features to be used? Or the compiler would be smart enough to handle this properly? Edgar V. Potentially. D is designed to only work on 32bit+ architectures. The 68k series did have 32bit versions of them. After a quick check it does look like LDC is out as LLVM has not yet got support for M68k target. Which is unfortunate because with the -betterC flag it could have pretty much out of the box worked. Even if you don't have most of D at your disposal e.g. classes and GC (but hey old cpu! can't expect that). I have no idea about GDC, but the -betterC flag is pretty recent so its support may not be what you would consider first class there yet.
Compiling to 68K processor (Maybe GDC?)
Hi, I have a project aiming to old 68K processor. While I don't think DMD would be able for this on the other hand I think GDC can, am I right? If yes would be any restriction of features to be used? Or the compiler would be smart enough to handle this properly? Edgar V.
Re: Alternative to Interfaces
On Friday, 18 January 2019 at 18:48:46 UTC, Jonathan M Davis
wrote:
Yes, but some D features will use the GC
They would like to allocate, but they don't know nor care where
it's allocated from, if the developer uses custom memory
management, he will know how it's allocated and will be able to
manage it.
The list of such features is short, but delegates are on it.
Closures are, but not delegates. Delegate is just a pair of
pointers, you don't need to allocate at all to keep them around,
similar to slices. They even work in betterC.
get around the allocations in some cases, but in general, if
you use delegates, you're going to allocate with the GC.
Custom memory management is obviously not the general case.
but the allocations that happen for delegates and lambdas is
one of the biggest reasons that some folks avoid std.algorithm
and complain that it allocates. That's what happens when you
pass stuff that the compiler decides has to have closures
allocated for it.
Is it really blocked? I got this to work with dip1000:
@safe @nogc:
alias int delegate(int) @safe @nogc dg;
struct Map(T)
{
private T a;
}
Map!dg map(return dg b)
{
Map!dg m;
m.a=b;
return m;
}
void f()
{
int a;
auto b=map(i=>a);
a=b.a(0);
}
Templated function can't infer closure type for some reason.
