Re: Setting a hard limit on slice size, is this possible?
On Sunday, 8 August 2021 at 02:00:26 UTC, Tejas wrote: On Saturday, 7 August 2021 at 19:07:04 UTC, Paul Backus wrote: On Saturday, 7 August 2021 at 15:41:24 UTC, Tejas wrote: On Saturday, 7 August 2021 at 15:21:01 UTC, Paul Backus wrote: [...] Oh wow, and here I thought I was being smart :( So, how can we work around this without assembly language magic? I'm illiterate at assembly. For stack allocations, you can use the workaround in [Vladimir Panteleev's comment][1] (ignoring the ASM part, which is unrelated to alignment). For heap allocations, I guess the easiest way would be to use [`AlignedMallocator`][2] from `std.experimental.allocator`. [1]: https://issues.dlang.org/show_bug.cgi?id=16098#c3 [2]: https://phobos.dpldocs.info/std.experimental.allocator.mallocator.AlignedMallocator.html Cool... thanks Thanks to everyone for all of the great discussion and hints on this topic! I have learned quite much, and have a gained an understanding on how to use D effectively. Fantastic forum here on a great language. Best Regards, James
Re: seeking advice: possible new @attribute to mark class' default property to avoid alias this ?
On Sunday, 8 August 2021 at 05:07:17 UTC, jfondren wrote:
On Sunday, 8 August 2021 at 04:51:48 UTC, someone wrote:
On Sunday, 8 August 2021 at 04:30:12 UTC, rikki cattermole
wrote:
So a field that will automatically be resolved to as part of
the behavior of generated toString methods.
No. A default property can be another object altogether. The
best use case I can think of is a default collection for a
class such as lobjComputers.computers in my example.
That really isn't what alias this is used for commonly. I.e.
I didn't know alias this even existed a month ago so I cannot
comment for what's oftenly used; I just stated that I was
pointed to alias this when I asked for default properties,
It might be that you were misunderstood. You're using "default
property" as a term of art with a specific meaning, and the
term itself looks generic enough that people can interpret it
with their familiar meanings for 'default' and 'property'.
Probably.
This is from Visual Basic, yeah?
Actually Visual FoxPro which had a full OOP implementation, for a
lot of reasons hated VB back then, but yes, Microsoft family of
developer tools have them and they were practical which is not to
say they should be good, maybe they are a terrible idea, and
*thats* why I was asking for advice beforehand.
https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/procedures/how-to-declare-and-call-a-default-property
I've never run into like that before. And it doesn't seem
well-loved in VB: "Because of these disadvantages, you should
consider not defining default properties. For code readability,
you should also consider always referring to all properties
explicitly, even default properties."
This looks similar to that example:
```d
struct MsgBox {
string[] contents;
void opIndexAssign(string s, size_t i) {
if (contents.length <= i)
contents.length = i + 1;
contents[i] = s;
}
}
void main() {
import std.stdio : writeln;
MsgBox x;
x[0] = "Hello";
x[1] = " ";
x[2] = "World";
writeln(x.contents);
}
```
```
That I don't remember. But, if they were controversial back in
the day ... I think it is all said and done ... ain't it ?
Re: seeking advice: possible new @attribute to mark class' default property to avoid alias this ?
On Sunday, 8 August 2021 at 04:51:48 UTC, someone wrote:
On Sunday, 8 August 2021 at 04:30:12 UTC, rikki cattermole
wrote:
So a field that will automatically be resolved to as part of
the behavior of generated toString methods.
No. A default property can be another object altogether. The
best use case I can think of is a default collection for a
class such as lobjComputers.computers in my example.
That really isn't what alias this is used for commonly. I.e.
I didn't know alias this even existed a month ago so I cannot
comment for what's oftenly used; I just stated that I was
pointed to alias this when I asked for default properties,
It might be that you were misunderstood. You're using "default
property" as a term of art with a specific meaning, and the term
itself looks generic enough that people can interpret it with
their familiar meanings for 'default' and 'property'.
This is from Visual Basic, yeah?
https://docs.microsoft.com/en-us/dotnet/visual-basic/programming-guide/language-features/procedures/how-to-declare-and-call-a-default-property
I've never run into like that before. And it doesn't seem
well-loved in VB: "Because of these disadvantages, you should
consider not defining default properties. For code readability,
you should also consider always referring to all properties
explicitly, even default properties."
This looks similar to that example:
```d
struct MsgBox {
string[] contents;
void opIndexAssign(string s, size_t i) {
if (contents.length <= i)
contents.length = i + 1;
contents[i] = s;
}
}
void main() {
import std.stdio : writeln;
MsgBox x;
x[0] = "Hello";
x[1] = " ";
x[2] = "World";
writeln(x.contents);
}
```
```
Re: seeking advice: possible new @attribute to mark class' default property to avoid alias this ?
On Sunday, 8 August 2021 at 04:30:12 UTC, rikki cattermole wrote:
So a field that will automatically be resolved to as part of
the behavior of generated toString methods.
No. A default property can be another object altogether. The best
use case I can think of is a default collection for a class such
as lobjComputers.computers in my example.
That really isn't what alias this is used for commonly. I.e.
I didn't know alias this even existed a month ago so I cannot
comment for what's oftenly used; I just stated that I was pointed
to alias this when I asked for default properties, it worked, but
later on when reading manuals/posts/etc it was obvious alias this
was something wholly different -that's why I got rid of all alias
this on my code, not the least when I learned of Walter's stance
on this one.
struct ValueReference {
private {
SomethingElse* impl;
}
bool isNull() { return impl is null; }
scope ref ValueType _get() { return impl.thingy; }
alias _get this;
}
Only the problem is, this also works for classes and whole pile
of extra cases.
Re: seeking advice: possible new @attribute to mark class' default property to avoid alias this ?
So a field that will automatically be resolved to as part of the
behavior of generated toString methods.
That really isn't what alias this is used for commonly. I.e.
struct ValueReference {
private {
SomethingElse* impl;
}
bool isNull() { return impl is null; }
scope ref ValueType _get() { return impl.thingy; }
alias _get this;
}
Only the problem is, this also works for classes and whole pile of extra
cases.
Re: seeking advice: possible new @attribute to mark class' default property to avoid alias this ?
On Sunday, 8 August 2021 at 00:57:47 UTC, Paul Backus wrote:
On Sunday, 8 August 2021 at 00:52:43 UTC, someone wrote:
Now that I am aware of Walter's stance on alias this:
"alias this has turned out to be a mistake" @
https://news.ycombinator.com/item?id=28029184
... would you, I mean the community, think is it a good idea
to file a DIP to eventually get a new attribute to
unambiguously label a class' default property ?
Can you please explain what a "default property" is? I have
never encountered such a thing in any other programming
language.
```d
public class cComputer {
private string pstrID;
private string pstrName;
public string ID() { return pstrID; }
public string name() { return pstrName; }
public void ID(const string lstrID) { pstrID = lstrID; }
public void name(const string lstrName) { pstrName = lstrName;
}
this(const string lstrID, const string lstrName) {
pstrID = lstrID;
pstrName = lstrName;
}
}
public class cComputers {
private cComputer[string] pobjComputers;
public cComputer[string] computers() { return pobjComputers; }
}
void main() {
cComputer lobjComputer1 = new cComputer("one", "eins");
cComputer lobjComputer2 = new cComputer("two", "zwei");
cComputer lobjComputer3 = new cComputer("three", "drei");
cComputers lobjComputers = new cComputers();
lobjComputers.computers["один"] = lobjComputer1;
lobjComputers.computers["два"] = lobjComputer2;
lobjComputers.computers["три"] = lobjComputer3;
assert(lobjComputers.computers["один"].ID == "one");
foreach (cComputer lobjComputer; lobjComputers.computers) {
writeln(lobjComputer.name); }
/// now suppose cComputer default property is name
/// now suppose cComputers default property is computers
assert(lobjComputers["один"] == "one");
foreach (cComputer lobjComputer; lobjComputers) {
writeln(lobjComputer); }
/// same output ... these are default properties; gotcha ?
}
```
PS: the above code was typed here but not actually tested
Re: Setting a hard limit on slice size, is this possible?
On Saturday, 7 August 2021 at 19:07:04 UTC, Paul Backus wrote: On Saturday, 7 August 2021 at 15:41:24 UTC, Tejas wrote: On Saturday, 7 August 2021 at 15:21:01 UTC, Paul Backus wrote: [...] Oh wow, and here I thought I was being smart :( So, how can we work around this without assembly language magic? I'm illiterate at assembly. For stack allocations, you can use the workaround in [Vladimir Panteleev's comment][1] (ignoring the ASM part, which is unrelated to alignment). For heap allocations, I guess the easiest way would be to use [`AlignedMallocator`][2] from `std.experimental.allocator`. [1]: https://issues.dlang.org/show_bug.cgi?id=16098#c3 [2]: https://phobos.dpldocs.info/std.experimental.allocator.mallocator.AlignedMallocator.html Cool... thanks
Re: Tracy
On Saturday, 7 August 2021 at 14:36:39 UTC, Dennis wrote: I'm not aware of any documentation of the feature. Could this be fixed? Or is this intentional?
Re: How suppress (Hide) prompt command console in DMC? Like -mwindows in C++?
On Sunday, 8 August 2021 at 00:23:55 UTC, Adam D Ruppe wrote: On Sunday, 8 August 2021 at 00:02:18 UTC, Marcone wrote: I create a gui program using DMC. I want to know how suppress (Hide) prompt command console in DMC? Like -mwindows in C++. Thank you. use /subsystem:windows a few more details here http://arsd-official.dpldocs.info/arsd.simpledisplay.html#installation-instructions Thank you very much! Work fine.
Re: seeking advice: possible new @attribute to mark class' default property to avoid alias this ?
On Sunday, 8 August 2021 at 00:52:43 UTC, someone wrote: Now that I am aware of Walter's stance on alias this: "alias this has turned out to be a mistake" @ https://news.ycombinator.com/item?id=28029184 ... would you, I mean the community, think is it a good idea to file a DIP to eventually get a new attribute to unambiguously label a class' default property ? Can you please explain what a "default property" is? I have never encountered such a thing in any other programming language.
seeking advice: possible new @attribute to mark class' default property to avoid alias this ?
Now that I am aware of Walter's stance on alias this: "alias this has turned out to be a mistake" @ https://news.ycombinator.com/item?id=28029184 ... would you, I mean the community, think is it a good idea to file a DIP to eventually get a new attribute to unambiguously label a class' default property ? eg: @default string whatever(...); eg: @default @property string whatever(...); /// if @property survives; that is ... or whatever you consider it should be named ? Besides, alias this was not implemented to handle default properties albeit it seems it is common practice to (as I was previously advised to in a previous related post). Do you think it'll be worth it ? PS#1: From my unqualified point-of-view it seems it won't be much difficult to add it but—I can be quite wrong. PS#2: I am not using alias this anymore; it is a double-edged sword.
Re: How suppress (Hide) prompt command console in DMC? Like -mwindows in C++?
On Sunday, 8 August 2021 at 00:23:55 UTC, Adam D Ruppe wrote: On Sunday, 8 August 2021 at 00:02:18 UTC, Marcone wrote: I create a gui program using DMC. I want to know how suppress (Hide) prompt command console in DMC? Like -mwindows in C++. Thank you. use /subsystem:windows a few more details here http://arsd-official.dpldocs.info/arsd.simpledisplay.html#installation-instructions funny timing, I'd just noticed a few hours ago that this was one of the two answers on https://wiki.dlang.org/D_FAQ
Re: How suppress (Hide) prompt command console in DMC? Like -mwindows in C++?
On Sunday, 8 August 2021 at 00:02:18 UTC, Marcone wrote: I create a gui program using DMC. I want to know how suppress (Hide) prompt command console in DMC? Like -mwindows in C++. Thank you. use /subsystem:windows a few more details here http://arsd-official.dpldocs.info/arsd.simpledisplay.html#installation-instructions
How suppress (Hide) prompt command console in DMC? Like -mwindows in C++?
I create a gui program using DMC. I want to know how suppress (Hide) prompt command console in DMC? Like -mwindows in C++. Thank you.
Re: What is the value for D to allow assign bool to char/dchar? For me, it must be an error.
On Saturday, 7 August 2021 at 21:45:09 UTC, apz28 wrote:
void main()
{
dchar d;
d = false;
d = true;
char c;
c = false;
c = true;
}
true is 1 and false is 0. These are valid char and dchar values.
Some people and languages are on board with this (like APL,
quote: "Ken asked Wolfram why it was that in Mathematica
propositions don’t have values 0 and 1 as in APL instead of True
and False. Wolfram replied that he had no objections, but the
Mathematica implementers were against it."), and some aren't.
```d
assert(2 == true+true);
assert('a' == "ab"[3 > 5]);
assert(2 == iota(5).map!"a>2".sum);
```
What is the value for D to allow assign bool to char/dchar? For me, it must be an error.
void main()
{
dchar d;
d = false;
d = true;
char c;
c = false;
c = true;
}
DMC Error: comctl32.lib Error 43: Not a Valid Library File
Using DMC to compile .cpp using gdi32.lib as dmc compile parameter. I get this error: OPTLINK (R) for Win32 Release 8.00.16 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html comctl32.lib Error 43: Not a Valid Library File --- errorlevel 1 How can I solve it?
Re: DMC Error: comctl32.lib Error 43: Not a Valid Library File
I added gdi32.lib user32.lib kernel32.lib comctl32.lib as dmc parameters. But don't work.
Re: Tracy
On Saturday, 7 August 2021 at 14:36:39 UTC, Dennis wrote: On Friday, 6 August 2021 at 12:30:16 UTC, JG wrote: I guess this means that tracy has been integrated? If this is so is it documented anywhere how to use it? Stefan Koch's WIP tracy integration in DMD is completely separate from Johan Engelen's time tracing added to LDC in 1.25.0. Note that the latter is not specific to tracy, I just recommended using tracy to view the trace file because alternatives I tried (Google Chrome and Speedscope) are terribly slow, see: https://forum.dlang.org/post/phuwlvsjigbyfvslk...@forum.dlang.org I'm not aware of any documentation of the feature. Thanks, a lot.
Re: Setting a hard limit on slice size, is this possible?
On Saturday, 7 August 2021 at 15:41:24 UTC, Tejas wrote: On Saturday, 7 August 2021 at 15:21:01 UTC, Paul Backus wrote: The issue with `align` attributes being ignored for stack variables is apparently a known bug, first reported in 2016: https://issues.dlang.org/show_bug.cgi?id=16098 The issue with `align` attributes being ignored by `new` is also a known bug, and was also first reported in 2016: https://issues.dlang.org/show_bug.cgi?id=16508 Oh wow, and here I thought I was being smart :( So, how can we work around this without assembly language magic? I'm illiterate at assembly. For stack allocations, you can use the workaround in [Vladimir Panteleev's comment][1] (ignoring the ASM part, which is unrelated to alignment). For heap allocations, I guess the easiest way would be to use [`AlignedMallocator`][2] from `std.experimental.allocator`. [1]: https://issues.dlang.org/show_bug.cgi?id=16098#c3 [2]: https://phobos.dpldocs.info/std.experimental.allocator.mallocator.AlignedMallocator.html
Re: Setting a hard limit on slice size, is this possible?
On Saturday, 7 August 2021 at 15:21:01 UTC, Paul Backus wrote: On Saturday, 7 August 2021 at 14:34:49 UTC, Tejas wrote: [...] For the array as a whole to be aligned, not only must the spacing between the elements respect the alignment, but starting address of the array itself must be a multiple of the alignment. So it is correct to check that `x.ptr%ALIGNMENT == 0`. The issue with `align` attributes being ignored for stack variables is apparently a known bug, first reported in 2016: https://issues.dlang.org/show_bug.cgi?id=16098 The issue with `align` attributes being ignored by `new` is also a known bug, and was also first reported in 2016: https://issues.dlang.org/show_bug.cgi?id=16508 Oh wow, and here I thought I was being smart :( So, how can we work around this without assembly language magic? I'm illiterate at assembly.
Re: Setting a hard limit on slice size, is this possible?
On Saturday, 7 August 2021 at 14:34:49 UTC, Tejas wrote: Umm, the ```align array``` solution is flat out wrong, please ignore it. Most likely a bug in the compiler. Also, why will the address of the first element of the array ```modulo``` alignment be 0? The address of the array has absolutely nothing to do with the alignment. You say that the ```align array``` solution has the expected spacing, but it is default aligned, totally ignoring your 64 byte requirement. Don't use ```x.PTR%ALIGNMENT``` Use ```(&x[1]-&[2])%ALIGNMENT``` You will get ALIGNMENT*(2 -1)(since you took difference of 2nd and 1st elem) For the array as a whole to be aligned, not only must the spacing between the elements respect the alignment, but starting address of the array itself must be a multiple of the alignment. So it is correct to check that `x.ptr%ALIGNMENT == 0`. The issue with `align` attributes being ignored for stack variables is apparently a known bug, first reported in 2016: https://issues.dlang.org/show_bug.cgi?id=16098 The issue with `align` attributes being ignored by `new` is also a known bug, and was also first reported in 2016: https://issues.dlang.org/show_bug.cgi?id=16508
Re: Setting a hard limit on slice size, is this possible?
On Saturday, 7 August 2021 at 13:36:52 UTC, james.p.leblanc wrote: On Saturday, 7 August 2021 at 12:08:00 UTC, Paul Backus wrote: [...] **First, thanks all for helping with this question!** The simple desire to arbitrarily align an array is certainly looking non-trivial. Below is a simple program of both the suggested "struct" and "align array" solutions. Unfortunately, neither is guaranteed to place the array with the desired alignnment. [...] If you don't believe me just subtract the adresses yourself: x.ptr: 78D05B90 &x[0]78D05B90 &x[1]78D05BD0 &x[2]78D05C10 &x[1] 78D05BD0 -&x[0] -78D05B90 _ 0040 0X40 = 64 in base 10 Your alignment requirement was 64 bytes
Re: Tracy
On Friday, 6 August 2021 at 12:30:16 UTC, JG wrote: I guess this means that tracy has been integrated? If this is so is it documented anywhere how to use it? Stefan Koch's WIP tracy integration in DMD is completely separate from Johan Engelen's time tracing added to LDC in 1.25.0. Note that the latter is not specific to tracy, I just recommended using tracy to view the trace file because alternatives I tried (Google Chrome and Speedscope) are terribly slow, see: https://forum.dlang.org/post/phuwlvsjigbyfvslk...@forum.dlang.org I'm not aware of any documentation of the feature.
Re: Setting a hard limit on slice size, is this possible?
On Saturday, 7 August 2021 at 13:36:52 UTC, james.p.leblanc wrote: On Saturday, 7 August 2021 at 12:08:00 UTC, Paul Backus wrote: [...] **First, thanks all for helping with this question!** The simple desire to arbitrarily align an array is certainly looking non-trivial. Below is a simple program of both the suggested "struct" and "align array" solutions. Unfortunately, neither is guaranteed to place the array with the desired alignnment. [...] Umm, the ```align array``` solution is flat out wrong, please ignore it. Most likely a bug in the compiler. Also, why will the address of the first element of the array ```modulo``` alignment be 0? The address of the array has absolutely nothing to do with the alignment. You say that the ```align array``` solution has the expected spacing, but it is default aligned, totally ignoring your 64 byte requirement. Don't use ```x.PTR%ALIGNMENT``` Use ```(&x[1]-&[2])%ALIGNMENT``` You will get ALIGNMENT*(2 -1)(since you took difference of 2nd and 1st elem)
Re: Setting a hard limit on slice size, is this possible?
On Saturday, 7 August 2021 at 12:08:00 UTC, Paul Backus wrote:
On Saturday, 7 August 2021 at 07:32:04 UTC, Tejas wrote:
And if it really is correct, then it seems once again that
static arrays are the answer after all:
```d
align(your_alignment) int[your_length] array;
```
No need for structs \\('_')/
The main advantage of the struct is that you can heap-allocate
it:
```d
auto array = new Aligned!(int[4], 16);
```
**First, thanks all for helping with this question!**
The simple desire to arbitrarily align an array is certainly
looking non-trivial.
Below is a simple program of both the suggested "struct" and
"align array" solutions.
Unfortunately, neither is guaranteed to place the array with the
desired alignnment.
import std.stdio;
enum ALIGNMENT=64;
enum LENGTH=10;
struct Aligned(T, size_t alignment) if (alignment >=
T.alignof)
{
align(alignment) T payload;
alias payload this;
}
void main()
{
writeln("ALIGNMENT: ", ALIGNMENT, ",\t\tLENGTH: ",
LENGTH);
int[23] junk;
align(ALIGNMENT) int[LENGTH] z;
writeln("\nusing 'align(ALIGNMENT) int[LENGTH] z;'");
writeln("\ncast(ulong) z.ptr%ALIGNMENT: ", cast(ulong)
z.ptr%ALIGNMENT);
writeln("int.alignof: ", int.alignof, ",\tint.sizeof: ",
int.sizeof);
writeln("&z[0]", &z[0]);
writeln("&z[1]", &z[1]);
writeln("&z[2]", &z[2]);
writeln("\nusing: 'Aligned!(int, ALIGNMENT)[LENGTH] x;'");
Aligned!(int, ALIGNMENT)[LENGTH] x;
writeln("x.sizeof: ", x.sizeof, "\t\tx.alignof: ",
x.alignof);
writeln("x: ", x);
writeln("\nx.ptr: ", x.ptr);
writeln("&x[0]", &x[0]);
writeln("&x[1]", &x[1]);
writeln("&x[2]", &x[2]);
writeln("\ncast(ulong) x.ptr%ALIGNMENT: ", cast(ulong)
x.ptr%ALIGNMENT);
}
---
and here is a sample output of a run:
ALIGNMENT: 64, LENGTH: 10
using 'align(ALIGNMENT) int[LENGTH] z;'
cast(ulong) z.ptr%ALIGNMENT: ***32***
int.alignof: 4,int.sizeof: 4
&z[0]78D05B60
&z[1]78D05B64
&z[2]78D05B68
using: 'Aligned!(int, ALIGNMENT)[LENGTH] x;'
x.sizeof: 640 x.alignof: 64
x: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
x.ptr: 78D05B90
&x[0]78D05B90
&x[1]78D05BD0
&x[2]78D05C10
cast(ulong) x.ptr%ALIGNMENT: ***16***
---
Notice, that neither attempt yields an array starting address as
zero modulo the alignment value ...
Also, a bit weird is that the "align array" solution yields
expected
spacing between array elements, but the "struct" solution has
wider
separations ...
--
**Again, I am very appreciative of your replies and help with
this.**
I have learned quite a bit from this discussion. However, I
remain
a bit stumped by all of this
Any ideas out there?
Best Regards,
James
Re: Setting a hard limit on slice size, is this possible?
On Saturday, 7 August 2021 at 07:32:04 UTC, Tejas wrote:
And if it really is correct, then it seems once again that
static arrays are the answer after all:
```d
align(your_alignment) int[your_length] array;
```
No need for structs \\('_')/
The main advantage of the struct is that you can heap-allocate it:
```d
auto array = new Aligned!(int[4], 16);
```
Re: Setting a hard limit on slice size, is this possible?
On Friday, 6 August 2021 at 22:15:00 UTC, Paul Backus wrote:
On Friday, 6 August 2021 at 19:03:53 UTC, Tejas wrote:
Stealing Paul's answer now:
```d
import std;
enum your_max_length = 1000;
enum your_align = 256;
struct MySlice(T/*, size_t maxLength*/)
{
private align(your_align)T payload;
//invariant(payload.length <= maxLength);
//this(T[] slice) { payload = slice; }
//T opIndex(size_t i) { return payload[i]; }
}
void main()
{
MySlice!(int/*, 1000*/)[your_max_length] slice;
writeln(slice.sizeof);
}
```
You can actually pass the alignment as a parameter too:
```d
struct Aligned(T, size_t alignment)
if (alignment >= T.alignof)
{
align(alignment) T payload;
alias payload this;
}
void main()
{
Aligned!(int, 16)[4] x;
assert(x.alignof == 16);
assert(x.sizeof == 64);
Aligned!(int[4], 16) y;
assert(y.alignof == 16);
assert(y.sizeof == 16);
}
```
Is the second example really correct? if the alignment of
```int[4]``` really is 16, then why isn't the size of it 64 as
well? It seems that the alignment constraint is not being
satisfied _within_ the array,
And if it really is correct, then it seems once again that static
arrays are the answer after all:
```d
align(your_alignment) int[your_length] array;
```
No need for structs \\('_')/
