Re: Strange exception, with EXTREMELY SIMPLE toString() in a struct
On Monday, 7 December 2015 at 08:17:27 UTC, Enjoys Math wrote:
Exception Message:
First-chance exception: std.format.FormatException Unterminated
format specifier: "%" at
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(828)
[CODE]
module set;
import std.conv;
struct Set(T) {
string toString() const {
auto str = "{";
return str;
}
}
unittest {
import std.stdio;
auto A = Set!int();
writeln(A);
}
[/CODE]
This is caused in fact by a correct unittest assertion in
format.d:
f = FormatSpec("a%%b%%c%");
w.clear();
assertThrown!FormatException(f.writeUpToNextSpec(w)); <-- here
assert(w.data == "a%b%c" && f.trailing == "%");
You can add std.Format.FormatException to the Exception Settings
(Debug -> Exceptions) and untick the Thrown checkbox.
Re: Do a class invariants affect -release builds?
On 12/6/15 6:01 PM, Andrew LaChance wrote: On Saturday, 5 December 2015 at 23:27:31 UTC, Steven Schveighoffer wrote: On 12/5/15 6:06 PM, Andrew LaChance wrote: I was reading a blog post here: http://3d.benjamin-thaut.de/?p=20 which mentions: "Calls to the druntime invariant handler are emitted in release build also and there is no way to turn them off. Even if the class does not have any invariants the invariant handler will always be called, walk the class hirarchy and generate multiple cache misses without actually doing anything." I was curious if this was still true today (the post was written 3 years ago in Sept 2012). Thanks! I don't remember that the invariant was ever called in release mode. But maybe I'm not understanding the statement. I think what he was saying was that even in release mode, the druntime would keep the invariant "subsystem," but just wouldn't call the invariant handlers. So even in release mode, the code to get a list of all handlers would happen, they just wouldn't be invoked. Rather than completely ripping out the invariant system. I don't think that's true. The invariant is called as part of function execution. Using obj2asm, the code emitted for an empty class function is vastly larger without -release. -Steve
Re: Comparison operator overloading
On Monday, 7 December 2015 at 11:49:51 UTC, Dominikus Dittes Scherkl wrote: On Sunday, 6 December 2015 at 15:01:08 UTC, cym13 wrote: Don't use opCmp, all binary operators should be overriden using opBinary. For more information I recommend this page http://ddili.org/ders/d.en/operator_overloading.html Why should we don't use opCmp() ? I can't see any recommendation about this in the cited book. In That chapter actually shows quite clearly in the table in the Binary Operators section that opCmp is used for <, <=, >, and >=, which is also exactly what the language reference says. There's also another section further down the page that covers opCmp explicitly. I have no idea what cym13 is looking at. On the other hand the chapter also states that opCmp() should always return "int" - which is a bad idea if you e.g. want to provide a "NaN" value in your type. For that "float" is a much better return type for opCmp(). So you should not weight in gold for the words in the cited book, I think. This is not something the author is just making up. opCmp is expected to return int because of the way the compiler rewrites comparison expressions. See the table at [1]. It wouldn't do to return NaN from opCmp. [1] http://dlang.org/spec/operatoroverloading.html#compare
Question about mysql-d Object
When I do the following:
auto mysql = new Mysql("localhost", 3306, "mt", "", "verwaltung");
auto rows = mysql.query("select field from my_table limit 50");
foreach(row;rows){
writeln(row["field"]);}
// second time same loop
foreach(row;rows){
writeln(row["field"]);}
I only get the output of the first loop (50 lines), probably this
is a feature
not a bug, but what kind of Object is rows?
A nested loop, did not worked either:
foreach(row;rows){
foreach(field;row){
writeln(field);}
}
Which other ways to access the elements of rows do I have?
Sorry, but I am very new on D, (it may be the best language
available, I don't know yet, but it is really the most
interesting!) thank you!
Re: Question about mysql-d Object
On Monday, 7 December 2015 at 14:40:12 UTC, Martin Tschierschke
wrote:
When I do the following:
auto mysql = new Mysql("localhost", 3306, "mt", "",
"verwaltung");
auto rows = mysql.query("select field from my_table limit 50");
foreach(row;rows){
writeln(row["field"]);}
// second time same loop
foreach(row;rows){
writeln(row["field"]);}
I only get the output of the first loop (50 lines), probably
this is a feature
not a bug, but what kind of Object is rows?
A nested loop, did not worked either:
foreach(row;rows){
foreach(field;row){
writeln(field);}
}
Which other ways to access the elements of rows do I have?
Sorry, but I am very new on D, (it may be the best language
available, I don't know yet, but it is really the most
interesting!) thank you!
what if you make array from it:
import std.array: array;
auto rows = mysql.query("select field from my_table limit
50").array;
Re: Comparison operator overloading
On Monday, 7 December 2015 at 13:31:52 UTC, Mike Parker wrote: On Monday, 7 December 2015 at 11:49:51 UTC, Dominikus Dittes Scherkl wrote: On the other hand the chapter also states that opCmp() should always return "int" - which is a bad idea if you e.g. want to provide a "NaN" value in your type. For that "float" is a much better return type for opCmp(). So you should not weight in gold for the words in the cited book, I think. This is not something the author is just making up. opCmp is expected to return int because of the way the compiler rewrites comparison expressions. See the table at [1]. It wouldn't do to return NaN from opCmp. [1] http://dlang.org/spec/operatoroverloading.html#compare Hmm. But it works just fine! It overloads also the special floatingpoint operators <> !<> !<= and so on. And how else could I handle a self-defined type that happens to have a NaN value (like my save-signed intergers do)?
Re: Pixelbuffer to draw on a surface
On Sunday, 6 December 2015 at 13:32:19 UTC, visitor wrote: gtkd demos for examples, might be of interest, like clock : https://github.com/gtkd-developers/GtkD/blob/master/demos/cairo/cairo_clock/clock.d Thanks! I didn't knew about that source, that helped me alot :)
Re: Question about mysql-d Object
On Monday, 7 December 2015 at 14:40:12 UTC, Martin Tschierschke
wrote:
When I do the following:
auto mysql = new Mysql("localhost", 3306, "mt", "",
"verwaltung");
auto rows = mysql.query("select field from my_table limit 50");
foreach(row;rows){
writeln(row["field"]);}
// second time same loop
foreach(row;rows){
writeln(row["field"]);}
I only get the output of the first loop (50 lines), probably
this is a feature
not a bug, but what kind of Object is rows?
A nested loop, did not worked either:
foreach(row;rows){
foreach(field;row){
writeln(field);}
}
Which other ways to access the elements of rows do I have?
Sorry, but I am very new on D, (it may be the best language
available, I don't know yet, but it is really the most
interesting!) thank you!
I suppose that's because the rows object is a mysql cursor, which
means you can only iterate it once, and only forward (Not sure
how it is implemented in mysql-d). It seems like your inner loop
is exhausting it.
If you need random access or multiple iterations, you first need
to copy your rows into another array/structure, and then you can
do whatever you want with it.
Strange exception, with EXTREMELY SIMPLE toString() in a struct
Exception Message:
First-chance exception: std.format.FormatException Unterminated
format specifier: "%" at
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(828)
[CODE]
module set;
import std.conv;
struct Set(T) {
string toString() const {
auto str = "{";
return str;
}
}
unittest {
import std.stdio;
auto A = Set!int();
writeln(A);
}
[/CODE]
Re: Strange exception, with EXTREMELY SIMPLE toString() in a struct
On Monday, 7 December 2015 at 08:17:27 UTC, Enjoys Math wrote:
Exception Message:
First-chance exception: std.format.FormatException Unterminated
format specifier: "%" at
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(828)
[CODE]
module set;
import std.conv;
struct Set(T) {
string toString() const {
auto str = "{";
return str;
}
}
unittest {
import std.stdio;
auto A = Set!int();
writeln(A);
}
[/CODE]
Works fine for me (Linux x86_64, DMD 2.069). Which version are
you using exactly? Also, are you sure you're not accidentally
running an outdated executable, or your executable doesn't
actually match the code you posted? It doesn't invoke format at
all.
Re: benchmark on binary trees
On Sunday, 6 December 2015 at 12:23:52 UTC, visitor wrote: Hello, interesting exercise for me to learn about allocators :-) Nice to know, a novice can inspire someone :) i managed to parallelize the code reaching similar performance, in terms of speed, as the non parallel version : http://dpaste.dzfl.pl/6c3e6edcff59 Cool! This is what I looked for! BUT it consumes insane memory, don't try with argument more than 17 !!! so either i'm doing something stupid (in parallel code, i guess) or the FreeList allocator is totally not the right tool ... (both ?) I assume, the allocator itself is something, that is not really needed in this case. Maybe, there is a more straight forward access to the problem. Even a simpler then in all the versions on the benchgame site, but I don't see it right now. And with the allocator attempt I had a chance to experiment with the experimental module and to write a very quick copy of a program, which I want to have... But your solution is really impressive, it reduces the factor from 5 to 3 immediately :) And I'm going to read your code carefully... some light-shedding would be really appreciated, Thanks
Re: Strange exception, with EXTREMELY SIMPLE toString() in a struct
On Monday, 7 December 2015 at 08:17:27 UTC, Enjoys Math wrote:
Exception Message:
First-chance exception: std.format.FormatException Unterminated
format specifier: "%" at
C:\D\dmd2\windows\bin\..\..\src\phobos\std\format.d(828)
[CODE]
module set;
import std.conv;
struct Set(T) {
string toString() const {
auto str = "{";
return str;
}
}
unittest {
import std.stdio;
auto A = Set!int();
writeln(A);
}
[/CODE]
Are you running this in VisualD plugin? This is the only place I
get that exception. Running it from the command line works as
expected on 2.069.1 win32
Re: benchmark on binary trees
On Sunday, 6 December 2015 at 08:45:10 UTC, Rikki Cattermole wrote: Why is TreeNode not final? This is an interesting hint! Just after adding final the program takes two seconds less... This is roughly 5%. Do you have another hints of this kind? ;) Also yours does not use threads in any way. If you cannot add multithreading on D, remove it from c++ before comparing. They are not equal. Yes... I'm aware of this discrepancy, and I tried how the time statistics differ with and without the #pragma statement. With the statement it is half a second slower then without. This seems strange to me, and I don't have a clue why it is so. But as this doesn't change very much for the D/C++ comparison and I think the correct goal is to have a parallel version in D I let the #pragma statement inside.
Re: Comparison operator overloading
On Sunday, 6 December 2015 at 15:01:08 UTC, cym13 wrote: Don't use opCmp, all binary operators should be overriden using opBinary. For more information I recommend this page http://ddili.org/ders/d.en/operator_overloading.html Why should we don't use opCmp() ? I can't see any recommendation about this in the cited book. In the chapter is only mentioned that opSliceAssign() and the like are discouraged - but without stating a reason or a replacement. On the other hand the chapter also states that opCmp() should always return "int" - which is a bad idea if you e.g. want to provide a "NaN" value in your type. For that "float" is a much better return type for opCmp(). So you should not weight in gold for the words in the cited book, I think.
Re: Comparison operator overloading
On Monday, 7 December 2015 at 00:43:50 UTC, Ali Çehreli wrote: On 12/06/2015 06:41 AM, Márcio Martins wrote: > auto m = (a > b) * a + 15; > auto c = a.choose(a > b)^^2; What do those operations do? Are you thinking of a special meaning for '>', perhaps common in numerical computations, which I'm not familiar with? If I understand correctly, 'a > b' in choose(a > b) is the condition to pick elements from a. If so, it is better to pass a lambda in such cases: a.choose!((i, j) => i > j); However, as I understand it, the whole expression is supposed to generate an array-like result. Is that right? :) Ali Yes, each expression involving these arrays will almost always also result in another array, sometimes with a different type. For example, a > b returns an array of bools whose elements are the the result of the condition applied to each individual element of a and b. This makes writing numerical code very easy, and with fewer bugs, because it's all very succinct and each operation is very simple and well defined. My initial intuition was that opBinary and opBinaryRight would be used if suitable and opCmp/opEquals would be the fallback. That didn't seem to work, so I quickly realised this is not possible in D. I'm wondering if it is an oversight in the language design or there are real reasons for this limitation?
AA struct hashing bug?
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
Foo foo;
int[ Foo ] map;
map[ foo ] = 1; // Crash! bug?
// This also crashes. I believe crash above makes a call like
this (or similar) in the rt.
//auto h = typeid( foo ).getHash( ); // Crash!
win64 & dmd 2.69.2
How to make a transparent wrapper type?
I kind of miss reference values on stack, so I attempted to make
one in a struct.
Pointers are pretty good (since d doesn't have ->), but it would
be nice to avoid dereferencing them explicitly on assignment.
Since reference is a pointer that you can't change afterwards.
I tried something like this:
struct RefVal( T )
{
this( T* val ) { ptr = val; }
ref auto opAssign( T value ){ *ptr = value; return
*ptr; }
ref auto opAssign( ref T value ){ *ptr = value; return
*ptr; }
alias ptr this;
T* ptr;
}
This works for most basic cases but breaks in:
struct Foo
{
this( int k )
{
a = k;
}
void opAssign( int k )
{
a = k;
}
int a;
}
Foo foo = Foo(2);
Foo baz = Foo(3);
RefVal!Foo bar = RefVal!Foo( );
bar = baz;
bar = 5; // Ooops! doesn't work
Is there a way to transparently pass everything to *RefVal.ptr?
Also is there a way to make "alias ptr this" to work with
"private T*"?
Ideally I wouldn't want to give access to the ptr, but for now
it's handy as a workaround.
Re: benchmark on binary trees
On Monday, 7 December 2015 at 10:55:25 UTC, Alex wrote: On Sunday, 6 December 2015 at 12:23:52 UTC, visitor wrote: Hello, interesting exercise for me to learn about allocators :-) Nice to know, a novice can inspire someone :) i managed to parallelize the code reaching similar performance, in terms of speed, as the non parallel version : http://dpaste.dzfl.pl/6c3e6edcff59 Cool! This is what I looked for! BUT it consumes insane memory, don't try with argument more than 17 !!! I assume, the allocator itself is something, that is not really needed in this case. Maybe, there is a more straight forward access to the problem. Even a simpler then in all the versions on the benchgame site, but I don't see it right now. And with the allocator attempt I had a chance to experiment with the experimental module and to write a very quick copy of a program, which I want to have... i've got more speed improvement with "taskPool.parallel(depthind, 2)" in the foreach parallel loop : second argument are workUnits (2 for me, on a quad core gave best results) Also using directly "FreeList!(Mallocator, Tree_node.sizeof)" without wrapping it in an allocatorObject gives speed improvement (with changes to makeTree method) i took inspiration from the C code, they use a memory pool management, like anonymous already pointed in c++ version, which i think could (must?) be achieved with allocators, to gain speed i think it's a key point, no GC !! FreeList allocator appears (to me) as a good candidate for this. but as i'm new to this, i'm sure to not doing it the right way ! i tried the exact same FreeList allocator but backed with the GCAllocator (not the Mallocator used in my code), then memory consumption is very good but of course it"s slow ! i tried a lot of other allocators, variations on the presented code, but memory management is awful :(
Re: How to make a transparent wrapper type?
This seems to work:
struct RefVal(T) {
private T* ptr;
this(T* val) {
ptr = val;
}
ref auto opAssign(U)(auto ref U value) {
*ptr = value;
return *ptr;
}
auto get() inout {
return ptr;
}
}
The @@@BUG@@@ the size of China - std.conv.d - Target parse(Target, Source)(ref Source s, uint radix)
So whilst attempt to convert from a hex string (without the 0x) to int I bumped into the @@@BUG@@@ the size of China https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L2270 Is there a bugzilla issue number tracking this? Searching for conv and parse in the issue tracker didn't turn it up Is this a phobos bug or a compiler bug? I followed the example in the unit test to get a workaround but I don't understand why the workaround works!
How do you create an opengl window with DerelictOrg?
I've seen these: https://github.com/DerelictOrg?page=1 BUt not sure how to use them, examples?
Re: How do you create an opengl window with DerelictOrg?
On Monday, 7 December 2015 at 21:33:57 UTC, Enjoys Math wrote: I've seen these: https://github.com/DerelictOrg?page=1 BUt not sure how to use them, examples? Derelict is just bindings for other libraries, for using C libraries with D. Pick a library that does windows management (I use GLFW, but I also see SFML and SDL), find the docs for them.
Re: How do you create an opengl window with DerelictOrg?
On Monday, 7 December 2015 at 21:33:57 UTC, Enjoys Math wrote: I've seen these: https://github.com/DerelictOrg?page=1 BUt not sure how to use them, examples? OpenGL itself can't create a window/context, so you'll need to use DerelictGLFW or DerelictSDL. GLFW is lighter-weight. Combine the setup code from here: https://github.com/DerelictOrg/DerelictGLFW3 ...with the example code from here: http://www.glfw.org/documentation.html Don't forget to load DerelictGL when you load DerelictGLFW. In addition, after you have the OpenGL context, you'll need to call DerelictGL3.reload() if you want anything more advanced than OpenGL 1.1. https://github.com/DerelictOrg/DerelictGL3
Re: AA struct hashing bug?
On Monday, 7 December 2015 at 18:48:18 UTC, Random D user wrote:
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
Foo foo;
int[ Foo ] map;
map[ foo ] = 1; // Crash! bug?
// This also crashes. I believe crash above makes a call like
this (or similar) in the rt.
//auto h = typeid( foo ).getHash( ); // Crash!
win64 & dmd 2.69.2
Also works on DMD v2.069.2 on XUbuntu Linux x64. I can try it on
Windows later.
Exact code I tested:
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
void main() {
Foo foo;
int[ Foo ] map;
map[ foo ] = 1;
}
Re: How do you create an opengl window with DerelictOrg?
On Monday, 7 December 2015 at 22:01:15 UTC, BLM768 wrote: On Monday, 7 December 2015 at 21:33:57 UTC, Enjoys Math wrote: I've seen these: https://github.com/DerelictOrg?page=1 BUt not sure how to use them, examples? OpenGL itself can't create a window/context, so you'll need to use DerelictGLFW or DerelictSDL. GLFW is lighter-weight. Combine the setup code from here: https://github.com/DerelictOrg/DerelictGLFW3 ...with the example code from here: http://www.glfw.org/documentation.html Don't forget to load DerelictGL when you load DerelictGLFW. In addition, after you have the OpenGL context, you'll need to call DerelictGL3.reload() if you want anything more advanced than OpenGL 1.1. https://github.com/DerelictOrg/DerelictGL3 Any one have a sample dub / glfw project to get me going?
Re: How do you create an opengl window with DerelictOrg?
On Monday, 7 December 2015 at 22:19:17 UTC, Enjoys Math wrote: On Monday, 7 December 2015 at 22:01:15 UTC, BLM768 wrote: On Monday, 7 December 2015 at 21:33:57 UTC, Enjoys Math wrote: I've seen these: https://github.com/DerelictOrg?page=1 BUt not sure how to use them, examples? OpenGL itself can't create a window/context, so you'll need to use DerelictGLFW or DerelictSDL. GLFW is lighter-weight. Combine the setup code from here: https://github.com/DerelictOrg/DerelictGLFW3 ...with the example code from here: http://www.glfw.org/documentation.html Don't forget to load DerelictGL when you load DerelictGLFW. In addition, after you have the OpenGL context, you'll need to call DerelictGL3.reload() if you want anything more advanced than OpenGL 1.1. https://github.com/DerelictOrg/DerelictGL3 Any one have a sample dub / glfw project to get me going? I have one that uses SDL and display things using "modern" OpenGL. https://github.com/d-gamedev-team/gfm/blob/master/examples/simpleshader/simpleshader.d
Re: The @@@BUG@@@ the size of China - std.conv.d - Target parse(Target, Source)(ref Source s, uint radix)
On 07.12.2015 21:56, John Carter wrote: So whilst attempt to convert from a hex string (without the 0x) to int I bumped into the @@@BUG@@@ the size of China https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L2270 Is there a bugzilla issue number tracking this? Searching for conv and parse in the issue tracker didn't turn it up Is this a phobos bug or a compiler bug? I followed the example in the unit test to get a workaround but I don't understand why the workaround works! I'm not sure if there's a bug. `parse` takes the string via `ref`, but string literals are not lvalues so they cannot be passed that way. This should also make it clear why the workaround works: A string literal is not an lvalue, but a variable is. Maybe whoever added that note thinks that string literals should be lvalues. That would make it a compiler bug. I think that would be a controversial viewpoint, though. Or the author thinks that `parse` should work with non-lvalues. That would make it a phobos issue. We have std.conv.to for that, though. So weakening the requirements on `parse` isn't exactly necessary. Just use `to` when you don't care about popping the input.
Re: The @@@BUG@@@ the size of China - std.conv.d - Target parse(Target, Source)(ref Source s, uint radix)
On 12/7/15 5:32 PM, anonymous wrote: On 07.12.2015 21:56, John Carter wrote: So whilst attempt to convert from a hex string (without the 0x) to int I bumped into the @@@BUG@@@ the size of China https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L2270 Is there a bugzilla issue number tracking this? Searching for conv and parse in the issue tracker didn't turn it up Is this a phobos bug or a compiler bug? I followed the example in the unit test to get a workaround but I don't understand why the workaround works! I'm not sure if there's a bug. `parse` takes the string via `ref`, but string literals are not lvalues so they cannot be passed that way. This should also make it clear why the workaround works: A string literal is not an lvalue, but a variable is. Maybe whoever added that note thinks that string literals should be lvalues. That would make it a compiler bug. I think that would be a controversial viewpoint, though. https://github.com/D-Programming-Language/phobos/commit/4069b485c01eb3afeada056ffb46924ee06b I doubt Andrei thinks string literals should be lvalues. It's an old bug, if it still exists. But in any case, the description is terrible. A real bug report should be filed. -Steve
Re: Comparison operator overloading
On Monday, 7 December 2015 at 17:18:20 UTC, Dominikus Dittes Scherkl wrote: Hmm. But it works just fine! It overloads also the special floatingpoint operators <> !<> !<= and so on. Those are deprecated: http://dlang.org/deprecate.html#Floating%20point%20NCEG%20operators And how else could I handle a self-defined type that happens to have a NaN value (like my save-signed intergers do)? Something like this: http://dlang.org/phobos/std_math.html#isNaN Or maybe this: http://dlang.org/phobos/std_typecons.html#Nullable Obviously, you'd want to do what makes sense for your type and its semantics. That probably doesn't involve using NCEG operators.
Re: AA struct hashing bug?
worksforme. git HEAD, GNU/Linux, x86.
Re: Reset all Members of a Aggregate Instance
On 4/12/2015 8:38 AM, Chris Wright wrote: An object reference is just a pointer, but we can't directly cast it. So we make a pointer to it and cast that; the type system allows it. Now we can access the data that the object reference refers to directly. Casting is fine too: cast(void*)classRef
Re: The @@@BUG@@@ the size of China - std.conv.d - Target parse(Target, Source)(ref Source s, uint radix)
On Monday, 7 December 2015 at 20:56:24 UTC, John Carter wrote:
So whilst attempt to convert from a hex string (without the 0x)
to int I bumped into the @@@BUG@@@ the size of China
https://github.com/D-Programming-Language/phobos/blob/master/std/conv.d#L2270
Is there a bugzilla issue number tracking this?
Searching for conv and parse in the issue tracker didn't turn
it up
Is this a phobos bug or a compiler bug?
I followed the example in the unit test to get a workaround
but I don't understand why the workaround works!
Despite the note in the unittest, it's actually not a bug after
all - parse is just designed for a different use case than yours.
What you want is T std.conv.to(T, S)(S value, uint radix). For
example, this works fine:
import std.conv;
foreach (i; 2..37)
{
assert(to!int("0", i) == 0);
assert(to!int("1", i) == 1);
assert(to!byte("10", i) == i);
}
Or using UFCS, if you prefer:
import std.conv;
foreach (i; 2..37)
{
assert("0".to!int(i) == 0);
assert("1".to!int(i) == 1);
assert("10".to!byte(i) == i);
}
The technical reason that the compiler won't let you use parse
that way, is that its first argument is annotated with ref and
cannot accept rvalues for memory safety reasons.
Re: The @@@BUG@@@ the size of China - std.conv.d - Target parse(Target, Source)(ref Source s, uint radix)
On Monday, 7 December 2015 at 22:38:03 UTC, Steven Schveighoffer wrote: It's an old bug, if it still exists. But in any case, the description is terrible. A real bug report should be filed. -Steve Filed (https://issues.dlang.org/show_bug.cgi?id=15419) and fixed (https://github.com/D-Programming-Language/phobos/pull/3861). Someone still needs to review the PR, though.
Re: AA struct hashing bug?
On Monday, 7 December 2015 at 22:03:42 UTC, Alex Parrill wrote:
On Monday, 7 December 2015 at 18:48:18 UTC, Random D user wrote:
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
Foo foo;
int[ Foo ] map;
map[ foo ] = 1; // Crash! bug?
// This also crashes. I believe crash above makes a call like
this (or similar) in the rt.
//auto h = typeid( foo ).getHash( ); // Crash!
win64 & dmd 2.69.2
Also works on DMD v2.069.2 on XUbuntu Linux x64. I can try it
on Windows later.
Exact code I tested:
struct Foo
{
this( int k )
{
a = k;
}
int a;
}
void main() {
Foo foo;
int[ Foo ] map;
map[ foo ] = 1;
}
Tested the same code with -m32 and -m64 on Windows. Works for
me, too.
Re: Reset all Members of a Aggregate Instance
On Tue, 08 Dec 2015 14:12:02 +1100, Daniel Murphy wrote: > On 4/12/2015 8:38 AM, Chris Wright wrote: >> An object reference is just a pointer, but we can't directly cast it. >> So we make a pointer to it and cast that; the type system allows it. >> Now we can access the data that the object reference refers to >> directly. > > Casting is fine too: cast(void*)classRef Amazing. I assumed that this wouldn't be allowed because it's not exactly nice to the type system, but apparently you can cast anything but a user- defined value type to void*. Bool, dchar, associative arrays, normal arrays, the good void* casts them all.
