Re: How can I make DMD stop on the first fatal error? (-Wfatal-errors)
On Wednesday, 8 July 2020 at 00:54:40 UTC, Marcone wrote: How can I make DMD stop on the first fatal error like -Wfatal-errors on C++? With the `-verrors=1` flag. You can specify exactly how many errors the compiler should emit before halting the compilation. Specify `0` for unlimited. -- /Jacob Carlborg
Re: Construct an used-defined hash table container type from an AA-literal expression
On Tuesday, 7 July 2020 at 12:41:23 UTC, Per Nordlöw wrote: What about construction and assignment from a static array of `Pair`'s? Wouldn't that be easier on the compiler? I you refer to it wouldn't be using templates, then yes, I guess so. -- /Jacob Carlborg
Re: constructing labels for static foreach inside switch inside foreach
On Wednesday, 8 July 2020 at 02:06:01 UTC, Steven Schveighoffer
wrote:
OK, so I have a situation where I'm foreaching over a
compile-time list of types. Inside the loop, I'm using a second
loop over a set of input.
Inside that loop, I'm using a switch on the input, and inside
the switch, I'm foreaching over the type's members, to
construct a switch that can handle member names (this is for
serialization).
If I encounter a certain name, then I want to break out of the
inner loop (it's a while loop)
So naturally, I have to use break statements with labels like:
innerloop:
while(haveMoreData)
switchstmt:
switch(nextDataElement) {
static foreach(name; __traits(allMembers, T)) {
case name:
... // handle it
break switchstmt;
}
case "STOP":
break innerloop;
}
Seems simple enough, except that this inner portion is
unrolled, and if I have more than one type to run this on, I
already have an "innerloop" label defined.
Is there a way to define a label using a mixin or something? or
do I have to wrap this in a function?
Is there another way to approach this?
-Steve
Unfortunately mixin does not support labels so I don't think you
can do what you want to do.
Kind of surprised me tbh
constructing labels for static foreach inside switch inside foreach
OK, so I have a situation where I'm foreaching over a compile-time list
of types. Inside the loop, I'm using a second loop over a set of input.
Inside that loop, I'm using a switch on the input, and inside the
switch, I'm foreaching over the type's members, to construct a switch
that can handle member names (this is for serialization).
If I encounter a certain name, then I want to break out of the inner
loop (it's a while loop)
So naturally, I have to use break statements with labels like:
innerloop:
while(haveMoreData)
switchstmt:
switch(nextDataElement) {
static foreach(name; __traits(allMembers, T)) {
case name:
... // handle it
break switchstmt;
}
case "STOP":
break innerloop;
}
Seems simple enough, except that this inner portion is unrolled, and if
I have more than one type to run this on, I already have an "innerloop"
label defined.
Is there a way to define a label using a mixin or something? or do I
have to wrap this in a function?
Is there another way to approach this?
-Steve
How can I make DMD stop on the first fatal error? (-Wfatal-errors)
How can I make DMD stop on the first fatal error like -Wfatal-errors on C++?
Re: Template function specialization doesn't work
On 7/7/20 12:53 PM, IGotD- wrote:
ubyte[3] ar = [ 1, 2, 3 ];
ubyte[] arSlice = ar;
overloadedFunction(arSlice);
The first function will be used. Shouldn't the template argument (T :
T[]) make the compiler pick the second one?
There is also template constraints which may be useful:
import std.traits;
void overloadedFunction(T)(ref T val)
if (!isArray!T) {
writeln("general");
}
void overloadedFunction(T)(ref T s)
if (isArray!T) {
writeln("T[]");
}
Ali
Re: Template function specialization doesn't work
On 7/7/20 4:21 PM, IGotD- wrote: On Tuesday, 7 July 2020 at 20:14:19 UTC, IGotD- wrote: Thank you, that worked and now it picked the correct overloaded function. I don't understand why and it is a bit counter intuitive. Why two template arguments as I'm not even us using U? If you look at the article https://dlang.org/articles/templates-revisited.html#specialization Then it mentioned that (T : T*) would work. Intuitively, then you would think (T : T[]) would work. Here (T : T[]) is even the example with the correct double[] type as a correct example as well. https://dlang.org/spec/template.html#parameters_specialization I'm confused. That's not IFTI, that's template instantiation. I bet if you did: overloadedFunction!(ubyte[])(arSlice) it would pick the second one. there is some extra magic going on for IFTI, and I'm not sure how it figures out what to do. I would agree with you that if explicit templates use that rule, so should IFTI. But perhaps there's a good reason why it can't be done. So possibly: overloadedFunction(arSlice) => Pattern match `ref T[]` to `ubyte[]` => T is ubyte => Check ubyte for T : T[], no match. -Steve
Re: opApply and attributes
On 7/6/20 5:20 PM, solidstate1991 wrote:> See implementation of data
structure here:
>
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/treemap.d#L565
>
>
> If I try to compile this code, it'll fail, limiting it's usecase:
>
> @safe pure unittest {
> alias IntMap = TreeMap!(int, int, false);
> IntMap test;
> test[5] = 5;
> test[7] = 7;
> test[3] = 3;
> foreach(elem, key; test) {
> assert(elem == key);
> }
> }
I am not sure whether I understand it correctly but there has been a
request for opApply() to gain the attributes of the delegate (or the
range?). In other words, "transfer the attributes to opApply". This is
needed because I want opApply() to work with any foreach body,
attributes of which opApply() cannot know.
I am sure I created an issue on Dlang bug tracker for Weka on this topic
but I can't find it now. (Aside: The search boxes on the bug tracker are
inferior to the automatic search feature that works when creating a
bug.) Anyway, this one seems related:
https://issues.dlang.org/show_bug.cgi?id=7543
Ali
Re: opApply and attributes
On Tuesday, 7 July 2020 at 13:33:41 UTC, Paul Backus wrote:
You can make opApply a template:
int opApply(Dg)(Dg dg)
if (is(Dg : scope int delegate(ref E)))
{
// etc.
}
Because `scope int delegate(ref E) @safe` implicitly converts
to `scope int delegate(ref E)`, this version will accept both
@safe and non-@safe delegates. (And likewise for the other
function attributes.)
Unfortunately this doesn't really work, even with explicitly
defined foreach arguments.
Re: Template function specialization doesn't work
On Tuesday, 7 July 2020 at 20:14:19 UTC, IGotD- wrote: Thank you, that worked and now it picked the correct overloaded function. I don't understand why and it is a bit counter intuitive. Why two template arguments as I'm not even us using U? If you look at the article https://dlang.org/articles/templates-revisited.html#specialization Then it mentioned that (T : T*) would work. Intuitively, then you would think (T : T[]) would work. Here (T : T[]) is even the example with the correct double[] type as a correct example as well. https://dlang.org/spec/template.html#parameters_specialization I'm confused.
Re: Template function specialization doesn't work
On Tuesday, 7 July 2020 at 20:05:37 UTC, Steven Schveighoffer wrote: On 7/7/20 4:04 PM, Steven Schveighoffer wrote: Have you tried (T: U[], U)(ref T[] s) ? Ugh... (T: U[], U)(ref T s) -Steve Thank you, that worked and now it picked the correct overloaded function. I don't understand why and it is a bit counter intuitive. Why two template arguments as I'm not even us using U? If you look at the article https://dlang.org/articles/templates-revisited.html#specialization Then it mentioned that (T : T*) would work. Intuitively, then you would think (T : T[]) would work.
Re: Template function specialization doesn't work
On 7/7/20 4:04 PM, Steven Schveighoffer wrote: Have you tried (T: U[], U)(ref T[] s) ? Ugh... (T: U[], U)(ref T s) -Steve
Re: Template function specialization doesn't work
On Tuesday, 7 July 2020 at 19:53:30 UTC, IGotD- wrote:
...
I also forgot to mention that the overloadedFunction is used in a
variadic template function.
void processAll(T...)(ref T t)
{
foreach(ref v; t)
{
overloadedFunction(v);
}
}
Re: Template function specialization doesn't work
On 7/7/20 3:53 PM, IGotD- wrote:
I have two template functions
void overloadedFunction(T)(ref T val)
{
}
void overloadedFunction(T : T[])(ref T[] s)
{
}
Obviously the second should be used when the parameter is a slice of any
type, and the first should be used in other cases. However this doesn't
happen, the compiler always picks the first function regardless if the
parameter is a slice or not.
So
ubyte[3] ar = [ 1, 2, 3 ];
ubyte[] arSlice = ar;
overloadedFunction(arSlice);
The first function will be used. Shouldn't the template argument (T :
T[]) make the compiler pick the second one?
That specialization is... odd. It's basically saying, is T an array of T.
I know I've seen this before, so I think it's valid. But maybe not?
Have you tried (T: U[], U)(ref T[] s) ?
-Steve
Template function specialization doesn't work
I have two template functions
void overloadedFunction(T)(ref T val)
{
...
}
void overloadedFunction(T : T[])(ref T[] s)
{
...
}
Obviously the second should be used when the parameter is a slice
of any type, and the first should be used in other cases. However
this doesn't happen, the compiler always picks the first function
regardless if the parameter is a slice or not.
So
ubyte[3] ar = [ 1, 2, 3 ];
ubyte[] arSlice = ar;
overloadedFunction(arSlice);
The first function will be used. Shouldn't the template argument
(T : T[]) make the compiler pick the second one?
Re: How to specify a version from dub build command
On Tuesday, 7 July 2020 at 06:34:15 UTC, adnan338 wrote:
I have a separate version for flatpak builds in my app. Let's
say I have a large project that builds with dub that goes like
this:
import std.stdio;
void main()
{
version (flatpak) {
writeln(`Flatpak build`);
} else {
writeln("Edit source/app.d to start your project.");
}
}
Now if I try `dub build --version=flatpak` it's not recognized
by the compiler. How can I set the version __from command
line__ before building my project? I cannot depend on dflags
inside dub.json because dub.json has no idea whether if it's
being parsed in a flatpak version build or a regular build.
try dub Configurations?
https://dub.pm/package-format-json.html#configurations
Re: opApply and attributes
On Tuesday, 7 July 2020 at 13:33:41 UTC, Paul Backus wrote:
You can make opApply a template:
int opApply(Dg)(Dg dg)
if (is(Dg : scope int delegate(ref E)))
{
// etc.
}
Because `scope int delegate(ref E) @safe` implicitly converts
to `scope int delegate(ref E)`, this version will accept both
@safe and non-@safe delegates. (And likewise for the other
function attributes.)
Yeah, but unfortunately then this won't work:
foreach(elem; test) {
assert(elem == key);
}
you'd have to spell out the types for `elem`.
Re: Catching OS Exceptions in Windows using LDC
On Saturday, 4 July 2020 at 14:44:06 UTC, Kagamin wrote: try https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-setunhandledexceptionfilter Thank You, this was the winner for me. Not just I can catch the OS Exceptions, I can check and alter the CPU state and decide to continue execution from an optionally modified cpu state, or just stop and show the error. It needed some work, but this seems the best way for LDC2 Win64.
Re: opApply and attributes
On Tuesday, 7 July 2020 at 00:20:40 UTC, solidstate1991 wrote:
See implementation of data structure here:
https://github.com/ZILtoid1991/collections-d/blob/master/source/collections/treemap.d#L565
If I try to compile this code, it'll fail, limiting it's
usecase:
@safe pure unittest {
alias IntMap = TreeMap!(int, int, false);
IntMap test;
test[5] = 5;
test[7] = 7;
test[3] = 3;
foreach(elem, key; test) {
assert(elem == key);
}
}
You can make opApply a template:
int opApply(Dg)(Dg dg)
if (is(Dg : scope int delegate(ref E)))
{
// etc.
}
Because `scope int delegate(ref E) @safe` implicitly converts to
`scope int delegate(ref E)`, this version will accept both @safe
and non-@safe delegates. (And likewise for the other function
attributes.)
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
On 7/7/20 8:26 AM, Steven Schveighoffer wrote: On 7/6/20 5:09 PM, kinke wrote: On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote: Though, admittedly I'm kind of used to seeing this error message since it appears any time you try and do something that relies on type info in betterC, intentionally or not. A notable example is forgetting to supply an arrange length when declaring a stack array, or it'll try to create a runtime-allocated array. Similar case here; the 'varargs' end up in a GC-allocated array. I've recently changed `scope` slice params, so that array literal arguments are allocated on the caller's stack instead; so adding `scope` for these variadics *should* probably do the same: void tester(Test test, scope Test[] tests...); Note that without the initial parameter, or without the destructor, they do NOT end up on the heap. I think this is a bug, and not a "feature". I can't see any reason why in those two cases it can construct it on the stack, and in this case it cannot. I should clarify: 1. Removing the destructor, but leaving the initial parameter => stack allocated 2. Removing the initial parameter, but leaving the destructor => stack allocated This is why I think it's at least inconsistent. A bug might be too far, since the spec clearly gives leeway to implementations to allocate on the heap. But I would love to see the spec changed to require stack allocation. -Steve
Re: Construct an used-defined hash table container type from an AA-literal expression
On Monday, 6 July 2020 at 12:04:11 UTC, Jacob Carlborg wrote:
void main() @nogc
{
auto a = tuple(Pair("foo", 1), Pair("bar", 2));
}
--
/Jacob Carlborg
Thanks.
What about construction and assignment from a static array of
`Pair`'s? Wouldn't that be easier on the compiler?
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
On 7/6/20 5:09 PM, kinke wrote: On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote: Though, admittedly I'm kind of used to seeing this error message since it appears any time you try and do something that relies on type info in betterC, intentionally or not. A notable example is forgetting to supply an arrange length when declaring a stack array, or it'll try to create a runtime-allocated array. Similar case here; the 'varargs' end up in a GC-allocated array. I've recently changed `scope` slice params, so that array literal arguments are allocated on the caller's stack instead; so adding `scope` for these variadics *should* probably do the same: void tester(Test test, scope Test[] tests...); Note that without the initial parameter, or without the destructor, they do NOT end up on the heap. I think this is a bug, and not a "feature". I can't see any reason why in those two cases it can construct it on the stack, and in this case it cannot. Note that I was under the impression that a Typesafe Variadic would always be on the stack. Reading the spec, it says it "may" put it on the stack, which makes me like those types of functions a lot less. Is there any reason a Typesafe Variadic function called with individual values cannot be required to put the values on the stack? -Steve
Re: Associative array on the heap
On 7/7/20 3:08 AM, mw wrote:
On Tuesday, 19 May 2015 at 12:21:48 UTC, Steven Schveighoffer wrote:
On 5/18/15 7:55 PM, Freddy wrote:
How do you allocate an associative array on the heap?
void main(){
alias A=int[string];
auto b=new A;
}
$ rdmd test
test.d(4): Error: new can only create structs, dynamic arrays or class
objects, not int[string]'s
Failed: ["dmd", "-v", "-o-", "test.d", "-I."]
As others have said, I don't know why you would want to do this, since
AA is already simply a wrapper for a pointer to a
AA is a wrapper for a pointer (e.g a struct with some extra info beyond
the plain pointer), or AA is just the plain pointer (nothing extra)?
AA is a pImpl type wrapper. Yes, it's just a pointer inside.
But it's not simply a pointer because things like indexing can change
the pointer (i.e. if the pointer is null, it will allocate a new AA impl).
If it were just a pointer, then using it without initializing would be a
segfault.
-Steve
Re: dub build=ddox, where the are the docs?
On 7/6/20 5:04 PM, claptrap wrote: Ok yeah it starts up a server and opens a webpage, great, but where are the docs? Cant find any info on command line switches for dub or ddox on how to get it to just dump the docs in a folder. dub --build=ddox makes a server and runs it so you can serve live documentation. dub build --build=ddox builds a docs folder that has all the generated HTML and associated files. I admit, that's a poor interface... -Steve
Re: I need an Easy example to understand Alias This
On Tuesday, 7 July 2020 at 00:35:38 UTC, Marcone wrote: Hi, I study Dlang for one year, and I can't understand alias this. I need an Easy example to understand Alias This. I used it for widget inheritance in my experimental code here, https://github.com/aferust/noobgui/blob/master/source/widget.d
Re: I need an Easy example to understand Alias This
On Tuesday, 7 July 2020 at 00:44:32 UTC, Marcone wrote:
On Tuesday, 7 July 2020 at 00:42:40 UTC, Ali Çehreli wrote:
On 7/6/20 5:35 PM, Marcone wrote:
Hi, I study Dlang for one year, and I can't understand alias
this. I need an Easy example to understand Alias This.
Is the following example useful?
http://ddili.org/ders/d.en/alias_this.html
Ali
I can't undestand it. I need a simple example.
This only scrapes the surface, but it should give an idea of the
core mechanics and why it's regarded as an important concept.
import std.stdio;
struct Fruit {
string name;
}
struct ColoredFruit {
Fruit _fruit;
alias _fruit this;
string color;
}
void printColoredFruit(ColoredFruit f) {
writeln(f.color, " ", f.name);
}
void printGeneralFruit(Fruit f) {
writeln(f.name);
}
void main(string[] args) {
ColoredFruit banana;
banana.color = "yellow"; // It's a normal struct for its
non-alias members
banana.name = "banana"; // We can interact with internal
fields directly
// This function accepts a ColoredFruit so the whole banana
is passed.
printColoredFruit(banana);
// > yellow banana
// This function only doesn't accept a ColoredFruit, but it
does accept a
// Fruit and we have a Fruit alias this so the internal
_fruit is passed.
printGeneralFruit(banana);
// > banana
}
Re: Associative array on the heap
On Tuesday, 19 May 2015 at 12:21:48 UTC, Steven Schveighoffer
wrote:
On 5/18/15 7:55 PM, Freddy wrote:
How do you allocate an associative array on the heap?
void main(){
alias A=int[string];
auto b=new A;
}
$ rdmd test
test.d(4): Error: new can only create structs, dynamic arrays
or class
objects, not int[string]'s
Failed: ["dmd", "-v", "-o-", "test.d", "-I."]
As others have said, I don't know why you would want to do
this, since AA is already simply a wrapper for a pointer to a
AA is a wrapper for a pointer (e.g a struct with some extra info
beyond the plain pointer), or AA is just the plain pointer
(nothing extra)?
I tried this:
class Foo {}
Foo[string] foos;
writeln(foos.sizeof); // print 8
looks like it's just a plain pointer?
The usage pattern to have AA on the heap is, e.g:
class Class {
StudentInfo[string] students; // dict-by-name
// many other fields
}
suppose in a multi-threaded app, the Class object is shared, and
one thread will perform a lengthy updates on all the students. To
ensure data consistency among all the students object, instead of
updating each student's info of the original AA in a loop (with
lengthy locking period), it can be achieved by heap-alloc a new
AA, update the new AA, and atomic-set:
new_students = new StudentInfo[string]; // heap-alloc a new AA
// length update on each of new_students
atomicStore(theClass.students, new_students);
