Re: Why are enums with base type string not considered strings?
On Sunday, 14 March 2021 at 16:30:47 UTC, Bastiaan Veelo wrote: On Sunday, 14 March 2021 at 16:09:39 UTC, Imperatorn wrote: On Sunday, 14 March 2021 at 10:42:17 UTC, wolframw wrote: [...] May be a regression? https://issues.dlang.org/show_bug.cgi?id=16573 Indeed: https://run.dlang.io/is/liSDBZ It regressed in 2.079.1. Seems to be worth an issue report. —Bastiaan. Thanks for the advice. I've since had a deeper look into this located the PR that changed this behavior [1]. It seems this change was very much deliberate. In the PR, Jonathan also makes some points that are very hard to disagree with. So, perhaps the better solution would be to make isBoolean and isSomeChar (and perhaps other functions that I didn't think of) return false for enums? As a side note, isSomeChar returning true for enums is also what causes the behavior demonstrated in Issue 21639 [2]. [1] https://github.com/dlang/phobos/pull/5291 [2] https://issues.dlang.org/show_bug.cgi?id=21639
Why are enums with base type string not considered strings?
enum BoolEnum : bool { TestBool = false }
enum CharEnum : char { TestChar = 'A' }
enum StringEnum : string { TestString = "Hello" }
pragma(msg, isBoolean!BoolEnum); // true
pragma(msg, isSomeChar!CharEnum); // true
pragma(msg, isSomeString!StringEnum); // false
Why does isSomeString not return true for an enum with base type
string while
other isX functions return true for enums with an according base
type X?
Regarding whether enums should be considered by these functions,
I can see the
case being made one of both ways (personally, I'd say they
should), but in the
example above it seems that different rules are applied.
Re: redirect std out to a string?
On Thursday, 21 May 2020 at 15:42:50 UTC, Basile B. wrote:
On Thursday, 21 May 2020 at 04:29:30 UTC, Kaitlyn Emmons wrote:
is there a way to redirect std out to a string or a buffer
without using a temp file?
yes:
[snip]
Alternatively, setvbuf can be used:
void[1024] buf; // buffer must be valid as long as the program
is running [1]
// (buffer could also be heap-allocated; see
Basile's post)
void main()
{
import std.stdio;
import std.string : fromStringz;
stdout.reopen("/dev/null", "a"); // on Windows, "NUL" should
do the trick
stdout.setvbuf(buf);
writeln("Hello world", 12345);
stdout.writeln("Hello again");
// Lastly, fromStringz is used to get a correctly sized
char[] from the buffer
char[] mystr = fromStringz(cast(char *) buf.ptr);
stderr.writeln("Buffer contents:\n", mystr);
}
[1] https://en.cppreference.com/w/c/io/setvbuf#Notes
Re: How can I open a Binary EXE with Hexadecimal?
On Saturday, 2 May 2020 at 21:05:32 UTC, Baby Beaker wrote: save as "rb" again. This will not work. To be able to write to a binary file, you will have to use "wb".
Re: date and timestamp
On Wednesday, 29 April 2020 at 22:22:04 UTC, guai wrote: Hi, forum I have two questions: 1) Why __DATE__ and __TIMESTAMP__ have these insane formats? "mmm dd " and "www mmm dd hh:mm:ss " I think its the first time in my life I encounter something like this. start with date, then print time, then the rest of the date - what? 2) Are those locale-specific? There was a similar discussion some time ago where Walter also explained the origin of these formats: https://forum.dlang.org/post/p4c8ka$2np$1...@digitalmars.com
Default initialization of static array faster than void initialization
Hi, Chapter 12.15.2 of the spec explains that void initialization of a static array can be faster than default initialization. This seems logical because the array entries don't need to be set to NaN. However, when I ran some tests for my matrix implementation, it seemed that the default-initialized array is quite a bit faster. The code (and the disassembly) is at https://gist.github.com/wolframw/73f94f73a822c7593e0a7af411fa97ac I compiled with dmd -O -inline -release -noboundscheck -mcpu=avx2 and ran the tests with the m array being default-initialized in one run and void-initialized in another run. The results: Default-initialized: 245 ms, 495 μs, and 2 hnsecs Void-initialized: 324 ms, 697 μs, and 2 hnsecs What the heck? I've also inspected the disassembly and found an interesting difference in the benchmark loop (annotated with "start of loop" and "end of loop" in both disassemblies). It seems to me like the compiler partially unrolled the loop in both cases, but in the default-allocation case it discards every second result of the multiplication and saves each other result to the sink matrix. In the void-initialized version, it seems like each result is stored in the sink matrix. I don't see how such a difference can be caused by the different initialization strategies. Is there something I'm not considering? Also, if the compiler is smart enough to figure out that it can discard some of the results, why doesn't it just do away with the entire loop and run the multiplication only once? Since both input matrices are immutable and opBinary is pure, it is guaranteed that the result is always the same, isn't it?
