Re: Fixed size array initialization
On Sunday, 11 February 2018 at 01:26:59 UTC, psychoticRabbit
wrote:
On Sunday, 11 February 2018 at 01:13:00 UTC, psychoticRabbit
wrote:
Well, in C.. I can do:
int arr[2] = { [0]=10, [1]=20 };
I cannot work out how to do that in D yet (anyone know??)
Oh. just worked it out after reading this thread ;-)
int[2] arr = [ 0:10, 1:20 ];
This is indeed the most simple and elegant solution. Thanks.
How can I get the new stdout which changes periodically from a process?
I do call a program from my application which changes its stdout perdiodically (with ncurses library, I guess), where I'd to get somehow "notified" when some change happen (I need to new data from that changes and change my application accordingly). Currently, I do use spawnProcess() which runs the app in paralel but I have no idea how to capture periodically changes in its stdout. It doesn't need to be exact; like a notification for every single change. If it checks for changes and report if there's any, every say, x seconds is enough.
Re: Linking multiple libraries
On Sunday, 26 November 2017 at 11:15:58 UTC, Jacob Carlborg wrote: On 2017-11-25 23:31, Mike Parker wrote: For "ld" on macOS the order does not matter. For "ld" on Linux the order does matter, but, if necessary, the following flags can be used to link libraries in any order: "--start-group" and "--end-group". Those flag will cause the linker to search the libraries repeatedly to resolve undefined symbols. These flags should be passed to ld by DMD i think
Re: typedef behavior
On Saturday, 10 February 2018 at 02:55:26 UTC, Alex wrote: bug filed https://issues.dlang.org/show_bug.cgi?id=18416
Re: Fixed size array initialization
On Sunday, 11 February 2018 at 01:13:00 UTC, psychoticRabbit
wrote:
Well, in C.. I can do:
int arr[2] = { [0]=10, [1]=20 };
I cannot work out how to do that in D yet (anyone know??)
Oh. just worked it out after reading this thread ;-)
int[2] arr = [ 0:10, 1:20 ];
Re: typedef behavior with @disable this()
On Sunday, 11 February 2018 at 00:54:07 UTC, Simen Kjærås wrote: Typedef explicitly initializes the wrapped value to T.init, thus circumventing the disabled default constructor. Filed a bug: https://issues.dlang.org/show_bug.cgi?id=18415 -- Simen Thanks!
Re: Fixed size array initialization
On Saturday, 10 February 2018 at 10:55:30 UTC, rumbu wrote:
I have a large static initialized array, let's say int[155],
and I forgot to declare the last element:
int[155] myarray = [
a,
b,
c,
...
//forgot to declare the 155th element
];
Well, in C.. I can do:
int arr[2] = { [0]=10, [1]=20 };
I cannot work out how to do that in D yet (anyone know??)
In the meantime, I'd suggest doing it this way, as you're more
likely to see that whether you forgot an element:
int[2] arr;
{
arr[0] = 10;
arr[1] = 20;
}
Re: typedef behavior with @disable this()
On Saturday, 10 February 2018 at 13:18:28 UTC, Alex wrote:
Do I overlook something?
/// --- code --- ///
import std.typecons;
void main(){}
static assert(!__traits( compiles, E()));
static assert(!__traits( compiles, MyE())); // line 6
struct E
{
size_t dummy;
@disable this();
this(size_t val) { dummy = val; }
}
alias MyE = Typedef!E;
/// --- code ends --- ///
While line 5 does not compile as expected, due to disabled
default constructor, the Typedef'd type does. Why?
Typedef explicitly initializes the wrapped value to T.init, thus
circumventing the disabled default constructor. Filed a bug:
https://issues.dlang.org/show_bug.cgi?id=18415
--
Simen
Re: Getting a reference to an immutable string
On Saturday, 10 February 2018 at 22:59:18 UTC, ag0aep6g wrote: But there is a recent regression on Windows that might be related. Do you also have a static constructor (`static this`) that uses `wndclassName`? If so, you might be hitting issue 18412. https://issues.dlang.org/show_bug.cgi?id=18412 If you don't have a static constructor, it might be a different bug. In that case, please provide complete code so that we can get to the bottom of it. I have a static constructor that uses wndclassName to register the window class... at the top of the file. I think that's the bug.
Re: Getting a reference to an immutable string
On 02/10/2018 11:46 PM, David Zhang wrote:
This is what I'm talking about:
void createWindow( ... ) {
assert( wndclassName.ptr ); //This fails
HWND hwnd = CreateWindowW(
wndclassName.ptr, //This too
null,
0,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
null,
null,
null,
null
);
}
wstring wndclassName = "wndclass_name"w;
That's not enough code to reproduce the issue. This works as far as I see:
import core.sys.windows.windef: HWND;
import core.sys.windows.winuser: CreateWindowW, CW_USEDEFAULT;
void main()
{
assert( wndclassName.ptr );
HWND hwnd = CreateWindowW(
wndclassName.ptr,
null,
0,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
null,
null,
null,
null
);
}
wstring wndclassName = "wndclass_name"w;
But there is a recent regression on Windows that might be related. Do
you also have a static constructor (`static this`) that uses
`wndclassName`? If so, you might be hitting issue 18412.
https://issues.dlang.org/show_bug.cgi?id=18412
If you don't have a static constructor, it might be a different bug. In
that case, please provide complete code so that we can get to the bottom
of it.
Re: Getting a reference to an immutable string
Building with Visual Studio seems to be fine. This isn't an OptLink issue, is it?
Re: Getting a reference to an immutable string
On Saturday, 10 February 2018 at 22:36:41 UTC, ag0aep6g wrote:
On 02/10/2018 11:26 PM, David Zhang wrote:
I've got an immutable string declared in module scope, and I
attempted to get a pointer to its characters through both
&str[0] and str.ptr. However, it appears to me that the string
is behaving like a manifest constant, in that the pointer is
null.
The language reference indicates that it has a location in
memory and thus has a pointer.
So, my question is thus: Is this a bug in DMD, or is this just
something I missed?
The pointer should not be null, even when `str` is a manifest
constant. But without code it's impossible to say if you're
hitting a compiler bug or if you're doing something wrong.
Ah, yeah.
It appears to occur only when compiled in x86 mode.
This is what I'm talking about:
void createWindow( ... ) {
assert( wndclassName.ptr ); //This fails
HWND hwnd = CreateWindowW(
wndclassName.ptr, //This too
null,
0,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
null,
null,
null,
null
);
}
wstring wndclassName = "wndclass_name"w;
Re: Getting a reference to an immutable string
On 02/10/2018 11:26 PM, David Zhang wrote: I've got an immutable string declared in module scope, and I attempted to get a pointer to its characters through both &str[0] and str.ptr. However, it appears to me that the string is behaving like a manifest constant, in that the pointer is null. The language reference indicates that it has a location in memory and thus has a pointer. So, my question is thus: Is this a bug in DMD, or is this just something I missed? The pointer should not be null, even when `str` is a manifest constant. But without code it's impossible to say if you're hitting a compiler bug or if you're doing something wrong.
Getting a reference to an immutable string
Hi, I've got an immutable string declared in module scope, and I attempted to get a pointer to its characters through both &str[0] and str.ptr. However, it appears to me that the string is behaving like a manifest constant, in that the pointer is null. The language reference indicates that it has a location in memory and thus has a pointer. So, my question is thus: Is this a bug in DMD, or is this just something I missed? Thanks David
Re: Fixed size array initialization
On Saturday, 10 February 2018 at 15:54:03 UTC, rumbu wrote: On Saturday, 10 February 2018 at 14:55:49 UTC, b2.temp wrote: On Saturday, 10 February 2018 at 14:35:52 UTC, rumbu wrote: In this case, it there any way to be sure that I declared all the elements I intended? Obviously, without counting them by hand. At the level of the library use a template. Sorry, but I don't get it. Can you elaborate, please? https://github.com/dlang/phobos/pull/4936
Re: Fixed size array initialization
On Saturday, 10 February 2018 at 14:55:49 UTC, b2.temp wrote: On Saturday, 10 February 2018 at 14:35:52 UTC, rumbu wrote: In this case, it there any way to be sure that I declared all the elements I intended? Obviously, without counting them by hand. At the level of the library use a template. Sorry, but I don't get it. Can you elaborate, please? This is the array in question: https://github.com/rumbu13/decimal/blob/master/src/decimal/integrals.d#L2072 First time, I tried to use mixins to generate the array, in order to avoid writing the same thing again and again. The mixin solution was nice until the compiler served me a nice Out of Memory error, that's why I finally used a hand-written array. At the level of the compiler: no. Not only not all elements are required but they also don't need to be declared in order (static array initialization, like in the example beyond). It would be possible to put a compiler warning but warnings are not in the D philosophy (one consequence is that many people, like me use -de all the time, making a possible warning not compatible with the legit uses of the "partial array initialization"). By the way i said i did change the compiler. Actually i even captured the session to promote my IDE: http://sendvid.com/c00x7nps.
Re: Fixed size array initialization
On Saturday, 10 February 2018 at 14:35:52 UTC, rumbu wrote: On Saturday, 10 February 2018 at 12:28:16 UTC, b2.temp wrote: On Saturday, 10 February 2018 at 10:55:30 UTC, rumbu wrote: I know that according to language spec (https://dlang.org/spec/arrays.html#static-init-static) you can skip declaring all your elements in a fixed size array. I'm just recovering from a bug which took me one day to discover because of this. I have a large static initialized array, let's say int[155], and I forgot to declare the last element: int[155] myarray = [ a, b, c, ... //forgot to declare the 155th element ]; I took for granted that the compiler will warn me about the fact that my number of elements doesn't match the array declaration but I was wrong. Does it worth to fill an enhancement on this, or this is intended behavior? I used to agree (https://issues.dlang.org/show_bug.cgi?id=17341) and even patched the compiler to emit a deprecation in this case. Then i discovered that druntime for example relies on this. The classic use case is to init a LUT where only a few elements need a non-default value, for example: ``` bool[char.max] lut = [10:true, 13:true, 9: true]; assert(!lut[46]); assert(lut[9]); ``` which can be useful. In this case, it there any way to be sure that I declared all the elements I intended? Obviously, without counting them by hand. At the level of the library use a template. At the level of the compiler: no. Not only not all elements are required but they also don't need to be declared in order (static array initialization, like in the example beyond). It would be possible to put a compiler warning but warnings are not in the D philosophy (one consequence is that many people, like me use -de all the time, making a possible warning not compatible with the legit uses of the "partial array initialization"). By the way i said i did change the compiler. Actually i even captured the session to promote my IDE: http://sendvid.com/c00x7nps.
Re: Fixed size array initialization
On Saturday, 10 February 2018 at 12:28:16 UTC, b2.temp wrote: On Saturday, 10 February 2018 at 10:55:30 UTC, rumbu wrote: I know that according to language spec (https://dlang.org/spec/arrays.html#static-init-static) you can skip declaring all your elements in a fixed size array. I'm just recovering from a bug which took me one day to discover because of this. I have a large static initialized array, let's say int[155], and I forgot to declare the last element: int[155] myarray = [ a, b, c, ... //forgot to declare the 155th element ]; I took for granted that the compiler will warn me about the fact that my number of elements doesn't match the array declaration but I was wrong. Does it worth to fill an enhancement on this, or this is intended behavior? I used to agree (https://issues.dlang.org/show_bug.cgi?id=17341) and even patched the compiler to emit a deprecation in this case. Then i discovered that druntime for example relies on this. The classic use case is to init a LUT where only a few elements need a non-default value, for example: ``` bool[char.max] lut = [10:true, 13:true, 9: true]; assert(!lut[46]); assert(lut[9]); ``` which can be useful. In this case, it there any way to be sure that I declared all the elements I intended? Obviously, without counting them by hand.
typedef behavior with @disable this()
Do I overlook something?
/// --- code --- ///
import std.typecons;
void main(){}
static assert(!__traits( compiles, E()));
static assert(!__traits( compiles, MyE())); // line 6
struct E
{
size_t dummy;
@disable this();
this(size_t val) { dummy = val; }
}
alias MyE = Typedef!E;
/// --- code ends --- ///
While line 5 does not compile as expected, due to disabled
default constructor, the Typedef'd type does. Why?
Re: Fixed size array initialization
https://issues.dlang.org/show_bug.cgi?id=481#c40
Re: Fixed size array initialization
On Saturday, 10 February 2018 at 10:55:30 UTC, rumbu wrote: I know that according to language spec (https://dlang.org/spec/arrays.html#static-init-static) you can skip declaring all your elements in a fixed size array. I'm just recovering from a bug which took me one day to discover because of this. I have a large static initialized array, let's say int[155], and I forgot to declare the last element: int[155] myarray = [ a, b, c, ... //forgot to declare the 155th element ]; I took for granted that the compiler will warn me about the fact that my number of elements doesn't match the array declaration but I was wrong. Does it worth to fill an enhancement on this, or this is intended behavior? I used to agree (https://issues.dlang.org/show_bug.cgi?id=17341) and even patched the compiler to emit a deprecation in this case. Then i discovered that druntime for example relies on this. The classic use case is to init a LUT where only a few elements need a non-default value, for example: ``` bool[char.max] lut = [10:true, 13:true, 9: true]; assert(!lut[46]); assert(lut[9]); ``` which can be useful.
Fixed size array initialization
I know that according to language spec (https://dlang.org/spec/arrays.html#static-init-static) you can skip declaring all your elements in a fixed size array. I'm just recovering from a bug which took me one day to discover because of this. I have a large static initialized array, let's say int[155], and I forgot to declare the last element: int[155] myarray = [ a, b, c, ... //forgot to declare the 155th element ]; I took for granted that the compiler will warn me about the fact that my number of elements doesn't match the array declaration but I was wrong. Does it worth to fill an enhancement on this, or this is intended behavior?
Re: opDispatch with string mixin does not work as I would expect.
On Saturday, 10 February 2018 at 07:47:58 UTC, Nicholas Wilson
wrote:
On Saturday, 10 February 2018 at 06:32:43 UTC, German Diago
Alternatively you could do something like
auto opDispatch(string name)()
if(hasMember!(HeaderData,name){
readHeader();
return mixin("headerData." ~ name);
}
Do not ask me why but now seems to work with my initial solution.
:)
