Re: I need an Easy example to understand Alias This
On 7/6/20 5:44 PM, 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.
I find the example of converting two integers to double to be a simple
example of 'alias this'. (If it's not simple, then there is another
example later.)
So, allow me to change the name of the struct. :) Let's say we have a
Money class that stores dollars and cents as two separate members. This
class also has a member function that returns the amount as double:
struct Money {
long dollars;
long cents;
double value() const {
return double(cents) / 100 + dollars;
}
}
unittest {
assert(Money(10, 50).value == 10.5);
}
void main() {
}
So far so good: We can get the value by calling value().
*If* this is a type where conversion to double should be automatic, then
calling value() all over the place might be considered cumbersome and
too wordy. If that's true, we may want to get the value of this type
automatically as double. For example, we may want to be able to call the
following function with Money:
void foo(double d) {
// ...
}
void main() {
foo(Money(20, 50)); // <-- Compilation error
}
Currently the code fails to compile because Money is not 'double'.
(Note: Arguably, Money is not a type that should be converted to double
automatically, but again, I find this example simple.)
'alias this' allows a type to be converted to a specific type
automatically. For example, if we want to convert Money objects
automatically to 'double', then we use the following line inside the
struct defition:
alias value this;
What that line means is this: "Dear compiler, please automatically
convert this type to whatever the type of the 'value' member is." In
this case, "Allow using an object of Money wherever that object is used
in place of a double."
So, with that addition, now the call inside main compiles and foo() gets
called with 'Money(20, 50).value' (compiler injects an automatic call to
value()).
Here is the complete program:
struct Money {
long dollars;
long cents;
double value() const {
return double(cents) / 100 + dollars;
}
alias value this; // <-- ADDED
}
unittest {
assert(Money(10, 50).value == 10.5);
}
void foo(double d) {
// ...
}
void main() {
foo(Money(20, 50));
}
'alias this' is sometimes used where a type needs to behave like some
other type with some added functionality. For example, here is another
example where a Month type should behave like an 'int' but it cannot
have any value other than 1-12:
struct Month {
int value;
this(int value) {
this.value = value;
}
invariant() {
assert(value >= 1);
assert(value <= 12);
}
alias value this;
}
unittest {
import std.exception;
assertThrown!Error(Month(0));
assertThrown!Error(Month(13));
void foo(int) {
}
// 'alias this' allows the following call to foo()
assert(__traits(compiles, foo(Month(3;
}
void main() {
}
Ali
Re: I need an Easy example to understand Alias This
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
Re: I need an Easy example to understand Alias This
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.
I need an Easy example to understand Alias This
Hi, I study Dlang for one year, and I can't understand alias this. I need an Easy example to understand Alias This.
opApply and attributes
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 know that implementing foreach with other means do exist, and I
used them in my other data structures, but it's much more
difficult (and potentially slower) to implement that within a
binary search tree.
Should I change the `opApply` into the `popfront` - `front` -
`empty` trinity, or write a template that overrides all the
potential attribute combinations?
Maybe D needs a template for attributes somehow, or something
like that.
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
On Monday, 6 July 2020 at 22:02:37 UTC, Kayomn wrote:
On Monday, 6 July 2020 at 21:09:57 UTC, kinke wrote:
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...);
This doesn't seem to be the case as the issue persists in the
same manner.
https://run.dlang.io/is/LcaKeu
I meant 'should' as in 'should be fixed to do the same', as this
works with -betterC:
struct Test { ~this() {} }
void tester(Test test, scope Test[] tests) { }
extern(C) void main() {
tester(Test(), [Test()]);
}
Re: Calling a C function whose name is a D reserved word or keyword
https://dlang.org/spec/pragma.html#mangle pragma(mangle, "body") extern(C) void body_func();
Calling a C function whose name is a D reserved word or keyword
Is there a special mechanism in D for handling this problem, where an existing C function might be a name that is reserved in D? Of course I could write a wrapper function in C and call that.
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
On Monday, 6 July 2020 at 21:09:57 UTC, kinke wrote: 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...); This doesn't seem to be the case as the issue persists in the same manner. https://run.dlang.io/is/LcaKeu
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
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...);
dub build=ddox, where the are the docs?
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.
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote: example is forgetting to supply an arrange length when array length*
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
On Monday, 6 July 2020 at 20:20:44 UTC, Stanislav Blinov wrote: I'd say the original error should be reported on bugzilla, if it isn't already; if only for the error message which is ridiculously obscure. Yeah, you're tellin' me lol. I spent the better part of the day tracking this one down, and the error file and line numbers display it as having occured at the callsite rather than the actual problem areas. 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. I'll open a report for this shortly if it is a bug if there isn't one already. For now, that template is an adequate workaround.
Re: BetterC Bug? Intended Behavior? Asking Here As Unsure
On Monday, 6 July 2020 at 20:06:51 UTC, Kayomn wrote:
Something discovered in the D Language Code Club Discord server
with the help of Wild is that the following code:
struct Test { ~this() {} }
void tester(Test test, Test[] tests...) { }
extern(C) void main() {
tester(Test(), Test());
}
Raises the "TypeInfo cannot be used with ~betterC" error. It
seems to be due to an inclusion of both the destructor and the
non-vararg and vararg argument matching from testing.
Anyone know a way around this without resulting to the rather
hacky solution of just having 1 argument and always assuming
that at least 1 argument is present?
Here is a code demo setup for demonstrating the potential
problem:
https://run.dlang.io/is/A6oIpl
This seems to compile:
struct Test { ~this() {} }
void tester(size_t n)(Test[n] tests...)
if (n > 0)
{}
extern(C) void main() {
tester(Test(), Test());
}
No assumptions, though `tester` does become a template.
I'd say the original error should be reported on bugzilla, if it
isn't already; if only for the error message which is
ridiculously obscure.
BetterC Bug? Intended Behavior? Asking Here As Unsure
Something discovered in the D Language Code Club Discord server
with the help of Wild is that the following code:
struct Test { ~this() {} }
void tester(Test test, Test[] tests...) { }
extern(C) void main() {
tester(Test(), Test());
}
Raises the "TypeInfo cannot be used with ~betterC" error. It
seems to be due to an inclusion of both the destructor and the
non-vararg and vararg argument matching from testing.
Anyone know a way around this without resulting to the rather
hacky solution of just having 1 argument and always assuming that
at least 1 argument is present?
Here is a code demo setup for demonstrating the potential problem:
https://run.dlang.io/is/A6oIpl
Re: Construct an used-defined hash table container type from an AA-literal expression
On Sunday, 5 July 2020 at 21:06:32 UTC, Per Nordlöw wrote:
Is there a way to construct a custom written hash-table
container (struct) from an AA-literal expression?
I think your best bet is a tuple of pairs, because then you're
not limited to compile time values, but it won't look pretty:
import std;
struct Pair
{
string key;
int value;
}
void main() @nogc
{
auto a = tuple(Pair("foo", 1), Pair("bar", 2));
}
--
/Jacob Carlborg
Re: Construct an used-defined hash table container type from an AA-literal expression
On Monday, 6 July 2020 at 01:43:43 UTC, user1234 wrote:
---
import std;
struct AA
{
void opIndexAssign(int v, string k) @nogc
{}
}
void main(string[] args) @nogc
{
AA myCustom;
enum literal = ["one":1, "two":2].stringof[1..$-1];
enum pairs = literal.split(',').array;
static foreach (p; pairs)
{
myCustom[mixin(p.split(':')[0])] =
mixin(p.split(':')[1]);
}
}
---
`static foreach` actual works for AA literals in `@nogc`
functions. So there's no need complicate things with `.stringof`:
struct Foo
{
int a;
int b;
}
enum literal = ["one": Foo(1, 2), "two": Foo(3, 4)];
struct AA
{
void opIndexAssign(Foo value, string k) @nogc
{
}
}
void main() @nogc
{
AA aa;
static foreach (k, v; literal)
{
aa[k] = v;
}
}
Re: Construct an used-defined hash table container type from an AA-literal expression
On Monday, 6 July 2020 at 11:51:19 UTC, Jacob Carlborg wrote:
On Monday, 6 July 2020 at 01:43:43 UTC, user1234 wrote:
Hereh we go ;)
---
import std;
struct AA
{
void opIndexAssign(int v, string k) @nogc
{}
}
void main(string[] args) @nogc
{
AA myCustom;
enum literal = ["one":1, "two":2].stringof[1..$-1];
enum pairs = literal.split(',').array;
---
That split won't work if you have something more complicated,
like struct values:
struct Foo
{
int a;
int b;
}
enum literal = ["one":Foo(1, 2), "two":Foo(3,
4)].stringof[1..$-1];
enum pairs = literal.split(',').array;
static assert(pairs == 4);
--
/Jacob Carlborg
Wouldn't work if the keys had , in them either. So don't even
need a struct to break it.
enum literal = ["one,two": 12, "two,three": 23].stringof[1..$-1];
// Now split(",") won't work either.
Re: Construct an used-defined hash table container type from an AA-literal expression
On Monday, 6 July 2020 at 01:43:43 UTC, user1234 wrote:
Hereh we go ;)
---
import std;
struct AA
{
void opIndexAssign(int v, string k) @nogc
{}
}
void main(string[] args) @nogc
{
AA myCustom;
enum literal = ["one":1, "two":2].stringof[1..$-1];
enum pairs = literal.split(',').array;
---
That split won't work if you have something more complicated,
like struct values:
struct Foo
{
int a;
int b;
}
enum literal = ["one":Foo(1, 2), "two":Foo(3,
4)].stringof[1..$-1];
enum pairs = literal.split(',').array;
static assert(pairs == 4);
--
/Jacob Carlborg
