Re: Type inference and overloaded functions
Am Tue, 10 Dec 2013 08:29:02 +0100 schrieb "Kenji Hara" : > This is an intended behavior. An array literal has dynamic array > type *by default*. > But all of literals in D behave as polymorphic. > > char c = 'A'; // character literal has char type by default > dchar d = 'A'; // but it may be implicitly typed as wchar/dchar > > string str = "hello"; > dstring dstr = "hello"; // string literal is implicitly typed as > dstring > > int[] darr = [1,2,3]; > int[3] darr = [1,2,3]; // implicitly typed as int[3] > > So, an array literal [1,2,3] is implicitly convertible both to > int[] and int[3]. > And, int[3] is more specialized than int[], so overload > resolution will choose the first 'bar'. > > Kenji Hara So this is how it works. I honestly wouldn't have come up with this. Your example for char makes it clear why this implicit type changing is in place. The OP still has a point though. If they are so polymorphic and "try to specialize" as necessary, then D's typeof(…) must always be in a Schrödinger cat-like state and only decide on an actual result when it is clear from static code analysis that every use of it's argument in the program leads to the same concrete type. Taking the following example as a failing case for this analysis: int[] arr1 = [1,2,3]; int[3] arr2 = [1,2,3]; writeln(typeof([1,2,3]).stringof); It must lead to a compiler error informing the user that [1,2,3] is simultaneously int[] and int[3]. -- Marco
Re: Type inference and overloaded functions
On Tuesday, December 10, 2013 08:29:02 Kenji Hara wrote:
> On Tuesday, 10 December 2013 at 07:15:43 UTC, Jonathan M Davis
>
> wrote:
> > On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
> >> On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
> >> > On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
> >> >> I just found weird D behavior about inference of array
> >> >> types.
> >> >>
> >> >> Let's suppose we have these overloaded functions:
> >> >>
> >> >> import std.stdio;
> >> >>
> >> >> void bar(const(int[3]) arr)
> >> >> {
> >> >>
> >> >> writeln("static array");
> >> >>
> >> >> }
> >> >>
> >> >> void bar(const(int[]) arr)
> >> >> {
> >> >>
> >> >> writeln("array slice");
> >> >>
> >> >> }
> >> >>
> >> >> // In main we have something like that:
> >> >> int main(string[] args)
> >> >> {
> >> >>
> >> >> bar([1,2,3]);
> >> >> writeln(typeof([1,2,3]).stringof);
> >> >> return 0;
> >> >>
> >> >> }
> >> >>
> >> >> Weird thing is that the static array version of bar is
> >> >> called,
> >> >> but typeof().stringof is int[], not int[3].
> >> >
> >> > Array literals are always dynamic arrays. int[3] is a static
> >> > array.
> >> >
> >> > - Jonathan M Davis
> >>
> >> The original question is valid then: [1,2,3] goes to the
> >> static array
> >> overload.
> >
> > Then AFAIK, that's a bug. The type of array literals is always
> > a dynamic
> > array, so they should match dynamic array overloads rather than
> > static array
> > overloads, or if they match both due to an implicit conversion,
> > there should
> > be an ambiguity error. Choosing the static array overload over
> > the dynamic one
> > is just plain wrong.
>
> This is an intended behavior. An array literal has dynamic array
> type *by default*.
> But all of literals in D behave as polymorphic.
>
> char c = 'A'; // character literal has char type by default
> dchar d = 'A'; // but it may be implicitly typed as wchar/dchar
>
> string str = "hello";
> dstring dstr = "hello"; // string literal is implicitly typed as
> dstring
>
> int[] darr = [1,2,3];
> int[3] darr = [1,2,3]; // implicitly typed as int[3]
>
> So, an array literal [1,2,3] is implicitly convertible both to
> int[] and int[3].
> And, int[3] is more specialized than int[], so overload
> resolution will choose the first 'bar'.
I'd argue that it would be far better to give an ambiguity error rather than
silently pick one over the other. In general, having a literal of any kind
pick a particular overload when it can match multiple is just begging for
trouble.
- Jonathan M Davis
Re: Only const or immutable class thread local variables are allowed
On Tuesday, December 10, 2013 08:41:25 Joseph Rushton Wakeling wrote: > On 10/12/13 06:33, Jonathan M Davis wrote: > > It's still essentially a singleton - it's just that it's a single instance > > per thread in that case instead of per program. And you avoid all of the > > threading-related initialization issues with singletons if it's > > thread-local. Just check whether it's null, initialize it if it is (leave > > it alone if it isn't), and then do whatever you're going to do with it. > > So for example the below code as an rndGen where Random is a class, not a > struct? Yeah. Something like that. > I think I was misled by the "Only const or immutable ..." part of the error > message: I'd assumed that any class that actually modified its internal > state would be disallowed as a static instance. It's a matter of what you can directly initialize a non-local variable with. Module-level variables, static variables, and member variables all have to be known at compile time, and you can't have a mutable class instance being constructed at compile time and then kept around until runtime. - Jonathan M Davis
Re: Only const or immutable class thread local variables are allowed
On 10/12/13 06:33, Jonathan M Davis wrote:
It's still essentially a singleton - it's just that it's a single instance per
thread in that case instead of per program. And you avoid all of the
threading-related initialization issues with singletons if it's thread-local.
Just check whether it's null, initialize it if it is (leave it alone if it
isn't), and then do whatever you're going to do with it.
So for example the below code as an rndGen where Random is a class, not a
struct?
I think I was misled by the "Only const or immutable ..." part of the error
message: I'd assumed that any class that actually modified its internal state
would be disallowed as a static instance.
///
ref Random rndGen() @property
{
static Random result = null;
if (result is null)
{
result = new Random;
static if (isSeedable!(Random, typeof(repeat(0).map!((a) =>
unpredictableSeed
{
result.seed(repeat(0).map!((a) => unpredictableSeed));
}
else
{
result.seed(unpredictableSeed);
}
}
return result;
}
///
Re: Type inference and overloaded functions
Am Mon, 09 Dec 2013 23:15:27 -0800
schrieb Jonathan M Davis :
> On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
> > On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
> > > On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
> > >> I just found weird D behavior about inference of array types.
> > >>
> > >> Let's suppose we have these overloaded functions:
> > >>
> > >> import std.stdio;
> > >>
> > >> void bar(const(int[3]) arr)
> > >> {
> > >>
> > >> writeln("static array");
> > >>
> > >> }
> > >>
> > >> void bar(const(int[]) arr)
> > >> {
> > >>
> > >> writeln("array slice");
> > >>
> > >> }
> > >>
> > >> // In main we have something like that:
> > >> int main(string[] args)
> > >> {
> > >>
> > >> bar([1,2,3]);
> > >> writeln(typeof([1,2,3]).stringof);
> > >> return 0;
> > >>
> > >> }
> > >>
> > >> Weird thing is that the static array version of bar is called,
> > >> but typeof().stringof is int[], not int[3].
> > >
> > > Array literals are always dynamic arrays. int[3] is a static array.
> > >
> > > - Jonathan M Davis
> >
> > The original question is valid then: [1,2,3] goes to the static array
> > overload.
>
> Then AFAIK, that's a bug. The type of array literals is always a dynamic
> array, so they should match dynamic array overloads rather than static array
> overloads, or if they match both due to an implicit conversion, there should
> be an ambiguity error. Choosing the static array overload over the dynamic
> one
> is just plain wrong.
>
> - Jonathan M Davis
>
[1,2,3] looks like a static array to me. And if overload
resolution picked the most specialized function it seems
natural to call the int[3] version.
My reasoning being that static arrays can be implicitly
converted to dynamic array, but the reverse is not true. So I
think it would be better to have [1,2,3] be a static array and
keep the current behavoir, no?)
--
Marco
Re: Type inference and overloaded functions
On Tuesday, 10 December 2013 at 07:15:43 UTC, Jonathan M Davis
wrote:
On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
> On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
>> I just found weird D behavior about inference of array
>> types.
>>
>> Let's suppose we have these overloaded functions:
>>
>> import std.stdio;
>>
>> void bar(const(int[3]) arr)
>> {
>>
>> writeln("static array");
>>
>> }
>>
>> void bar(const(int[]) arr)
>> {
>>
>> writeln("array slice");
>>
>> }
>>
>> // In main we have something like that:
>> int main(string[] args)
>> {
>>
>> bar([1,2,3]);
>> writeln(typeof([1,2,3]).stringof);
>> return 0;
>>
>> }
>>
>> Weird thing is that the static array version of bar is
>> called,
>> but typeof().stringof is int[], not int[3].
>
> Array literals are always dynamic arrays. int[3] is a static
> array.
>
> - Jonathan M Davis
The original question is valid then: [1,2,3] goes to the
static array
overload.
Then AFAIK, that's a bug. The type of array literals is always
a dynamic
array, so they should match dynamic array overloads rather than
static array
overloads, or if they match both due to an implicit conversion,
there should
be an ambiguity error. Choosing the static array overload over
the dynamic one
is just plain wrong.
This is an intended behavior. An array literal has dynamic array
type *by default*.
But all of literals in D behave as polymorphic.
char c = 'A'; // character literal has char type by default
dchar d = 'A'; // but it may be implicitly typed as wchar/dchar
string str = "hello";
dstring dstr = "hello"; // string literal is implicitly typed as
dstring
int[] darr = [1,2,3];
int[3] darr = [1,2,3]; // implicitly typed as int[3]
So, an array literal [1,2,3] is implicitly convertible both to
int[] and int[3].
And, int[3] is more specialized than int[], so overload
resolution will choose the first 'bar'.
Kenji Hara
Re: Type inference and overloaded functions
On Monday, December 09, 2013 22:59:49 Ali Çehreli wrote:
> On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
> > On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
> >> I just found weird D behavior about inference of array types.
> >>
> >> Let's suppose we have these overloaded functions:
> >>
> >> import std.stdio;
> >>
> >> void bar(const(int[3]) arr)
> >> {
> >>
> >> writeln("static array");
> >>
> >> }
> >>
> >> void bar(const(int[]) arr)
> >> {
> >>
> >> writeln("array slice");
> >>
> >> }
> >>
> >> // In main we have something like that:
> >> int main(string[] args)
> >> {
> >>
> >> bar([1,2,3]);
> >> writeln(typeof([1,2,3]).stringof);
> >> return 0;
> >>
> >> }
> >>
> >> Weird thing is that the static array version of bar is called,
> >> but typeof().stringof is int[], not int[3].
> >
> > Array literals are always dynamic arrays. int[3] is a static array.
> >
> > - Jonathan M Davis
>
> The original question is valid then: [1,2,3] goes to the static array
> overload.
Then AFAIK, that's a bug. The type of array literals is always a dynamic
array, so they should match dynamic array overloads rather than static array
overloads, or if they match both due to an implicit conversion, there should
be an ambiguity error. Choosing the static array overload over the dynamic one
is just plain wrong.
- Jonathan M Davis
Re: Type inference and overloaded functions
On 12/09/2013 10:52 PM, Jonathan M Davis wrote:
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
I just found weird D behavior about inference of array types.
Let's suppose we have these overloaded functions:
import std.stdio;
void bar(const(int[3]) arr)
{
writeln("static array");
}
void bar(const(int[]) arr)
{
writeln("array slice");
}
// In main we have something like that:
int main(string[] args)
{
bar([1,2,3]);
writeln(typeof([1,2,3]).stringof);
return 0;
}
Weird thing is that the static array version of bar is called,
but typeof().stringof is int[], not int[3].
Array literals are always dynamic arrays. int[3] is a static array.
- Jonathan M Davis
The original question is valid then: [1,2,3] goes to the static array
overload.
Ali
Re: Type inference and overloaded functions
On Tuesday, December 10, 2013 07:47:38 FreeSlave wrote:
> I just found weird D behavior about inference of array types.
>
> Let's suppose we have these overloaded functions:
>
> import std.stdio;
>
> void bar(const(int[3]) arr)
> {
> writeln("static array");
> }
>
> void bar(const(int[]) arr)
> {
> writeln("array slice");
> }
>
> // In main we have something like that:
> int main(string[] args)
> {
> bar([1,2,3]);
> writeln(typeof([1,2,3]).stringof);
> return 0;
> }
>
> Weird thing is that the static array version of bar is called,
> but typeof().stringof is int[], not int[3].
Array literals are always dynamic arrays. int[3] is a static array.
- Jonathan M Davis
Type inference and overloaded functions
I just found weird D behavior about inference of array types.
Let's suppose we have these overloaded functions:
import std.stdio;
void bar(const(int[3]) arr)
{
writeln("static array");
}
void bar(const(int[]) arr)
{
writeln("array slice");
}
// In main we have something like that:
int main(string[] args)
{
bar([1,2,3]);
writeln(typeof([1,2,3]).stringof);
return 0;
}
Weird thing is that the static array version of bar is called,
but typeof().stringof is int[], not int[3].
Re: Using std.algorithm.map: Error: cannot implicitly convert expression of type MapResult!
On Tue, Dec 10, 2013 at 6:54 AM, Dfr wrote:
> Hello, here is example code, which doesn't work:
>
> Variant[] vtypes = [ Variant("hello"), Variant("bye") ];
> string[] filetypes = map!(to!string)(vtypes);
>
> Gives me error:
>
> Error: cannot implicitly convert expression (map(vtypes)) of type
> MapResult!(to, VariantN!(24u)[]) to string[]
> What is wrong here and how to fix it ?
map, and with it most other algorithm and ranges in std.algorithm and
std.range, returns lazy ranges: structs that will produce the data you
want when you iterate on them (with foreach, for example).
What map!(to!string)(someArray) does is constructing a 'view' on
someArray that will get you someArray elements, concerted into string.
If you want to convert it into an array, use std.array.array:
import std.stdio;
import std.algorithm;
import std.range;
import std.array;
import std.conv;
import std.variant;
void main()
{
Variant[] vtypes = [ Variant("hello"), Variant("bye"), Variant(3.1415) ];
string[] filetypes = map!(to!string)(vtypes).array();
writeln(filetypes);
}
Using std.algorithm.map: Error: cannot implicitly convert expression of type MapResult!
Hello, here is example code, which doesn't work:
Variant[] vtypes = [ Variant("hello"), Variant("bye") ];
string[] filetypes = map!(to!string)(vtypes);
Gives me error:
Error: cannot implicitly convert expression (map(vtypes)) of type
MapResult!(to, VariantN!(24u)[]) to string[]
And alternative version:
Variant[] vtypes = [ Variant("hello"), Variant("bye") ];
string[] ftypes = map!(t => t.get!(string))(vtypes);
Error: cannot implicitly convert expression (map(vtypes)) of type
MapResult!(__lambda2, VariantN!(24u)[]) to string[]
What is wrong here and how to fix it ?
Re: Only const or immutable class thread local variables are allowed
On Monday, December 09, 2013 06:19:19 Joseph Rushton Wakeling wrote: > On Monday, 9 December 2013 at 00:24:44 UTC, Ali Çehreli wrote: > > David Simcha presented it as a D-specific pattern and explained > > how D avoids at least one of the bugs of double-checked locking: > > > > > > http://www.youtube.com/watch?feature=player_detailpage&v=yMNMV9JlkcQ#t=167 > > 6 > > I will look at this in detail but instinctively based on what I > understand a singleton to be for, I'm not sure it's what I want: > I'm not looking for something truly global, only thread-global. It's still essentially a singleton - it's just that it's a single instance per thread in that case instead of per program. And you avoid all of the threading-related initialization issues with singletons if it's thread-local. Just check whether it's null, initialize it if it is (leave it alone if it isn't), and then do whatever you're going to do with it. - Jonathan M Davis
Re: File Picker
On Tuesday, 10 December 2013 at 02:05:12 UTC, Jeremy DeHaan wrote: On Monday, 9 December 2013 at 16:49:04 UTC, Malkierian wrote: On Monday, 9 December 2013 at 08:57:16 UTC, Jeremy DeHaan wrote: On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian wrote: *sigh* No dice. And I can't get GtkD to work either, because of entry point errors... I've gotten GtkD to work for me, though it has been a while. If I am able to find some time soon I will see if I can do some kind of example for you. Well, in the mean time, have you ever heard of this error before? "The procedure entry point gdk_frame_clock_begin_updating could not be located in the dynamic link library libgdk-3-0.dll. I've also gotten a similar error with some other entry point in libgdk_pixbuf-2.0-0.dll, but then I copied that file from the Gtk 3.6.4 release into my bin folder and it went away. Copying the the libgdk-3-0.dll from the same release did nothing to fix this error. This is getting ridiculous. I don't know if this is your problem exactly, but the Gtk+ installer on the GtkD website(http://gtkd.org/download.html) is for 3.8.1, so maybe something has been updated since then? You could also open an issue on GtkD's github repo(https://github.com/gtkd-developers/GtkD) if you continue to experience problems with it. LOL, that was the version I was replacing with the 3.6.4 stuff XD. And I already made a post on their forum about it.
Re: File Picker
On Monday, 9 December 2013 at 16:49:04 UTC, Malkierian wrote: On Monday, 9 December 2013 at 08:57:16 UTC, Jeremy DeHaan wrote: On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian wrote: *sigh* No dice. And I can't get GtkD to work either, because of entry point errors... I've gotten GtkD to work for me, though it has been a while. If I am able to find some time soon I will see if I can do some kind of example for you. Well, in the mean time, have you ever heard of this error before? "The procedure entry point gdk_frame_clock_begin_updating could not be located in the dynamic link library libgdk-3-0.dll. I've also gotten a similar error with some other entry point in libgdk_pixbuf-2.0-0.dll, but then I copied that file from the Gtk 3.6.4 release into my bin folder and it went away. Copying the the libgdk-3-0.dll from the same release did nothing to fix this error. This is getting ridiculous. I don't know if this is your problem exactly, but the Gtk+ installer on the GtkD website(http://gtkd.org/download.html) is for 3.8.1, so maybe something has been updated since then? You could also open an issue on GtkD's github repo(https://github.com/gtkd-developers/GtkD) if you continue to experience problems with it.
Re: Symbol Undefined _D2rt12__ModuleInfoZ
My fault! and the reason is worth understanding in a slightly wider context. I'm importing into the new memory management related D source files a D interface file obtained via htod and some tweaking from the C header files associated with the C source I am modifying. And that interface file, while perfectly correct and containing nothing that shouldn't be in a C header file (specifically, no function definitions) nevertheless needed to be compiled into an object and added to the eventual link. Doing so eliminated the problem entirely. "Symbol Undefined _D2rt12__ModuleInfoZ" which I couldn't unmangle, meant that there was a missing module called rt. Presumably dmd put that symbol in the import section of the object that was made with 'import rt' in its source to bring in my interface file. Obvious from the symbol after the fact. I was able to demangle the symbol in the following part of the error message, "Symbol Undefined _D2rt6b_real11__xopEqualsUKxS2rt6b_realKxS2rt6b_realZb". It's the mangled version of the following. extern (C) bool rt.b_real.__xopEquals(ref const(rt.b_real), ref const(rt.b_real)) This lead me to understand that the message "Symbol Undefined _D2rt6b_real6__initZ" appears to be about an initializer for the struct b_real that doesn't exist either. Why optlink chose these particular missing symbols is somewhat puzzling, as there are perhaps 50 or so structs in rt. And I do not use an equality test with b_real in any way. I'd be curious to know, as it would be nice to have a better handle on decrypting the implications of error messages produced when linking a 32 bit windows program built with dmd fails.
Re: array question
On 09.12.2013 23:03, seany wrote:
yet another array question :
I have defined :
alias string[] surrealNum_segments;
alias string[string] surrealNum_segments_withID;
surrealNum_segments_withID BAR;
Is there a built in function FOO, such that i could also write:
FOO(surrealNum_segments) BAR;
instead of
surrealNum_segments_withID BAR;
i.e. that will return an Associative Array type with string keys , with an array
as argument?
import std.range;
alias string[] surrealNum_segments;
alias ElementType!surrealNum_segments[string] surrealNum_segments_withID;
Or, if you don't like writing all that (say, you have 1e8 array types you want
ID versions of):
template FOO(T : U[], U) {
alias U[string] FOO;
}
alias FOO!surrealNum_segments surrealNum_segments_withID;
But no, there is no built-in function of this kind.
--
Simen
Re: array question
yet another array question : I have defined : alias string[] surrealNum_segments; alias string[string] surrealNum_segments_withID; surrealNum_segments_withID BAR; Is there a built in function FOO, such that i could also write: FOO(surrealNum_segments) BAR; instead of surrealNum_segments_withID BAR; i.e. that will return an Associative Array type with string keys , with an array as argument?
Re: "null this"
On Monday, 9 December 2013 at 19:53:09 UTC, Adam D. Ruppe wrote: When you used the class, did you remember to new it? Unlike C++, "Io io;" in D would be null. You have to create it with "io = new Io();" You got me thinking in the right direction, turns out I was putting in a bad parameter at the places like Io session ... session = new IO(...) Thank you very much. :)
Re: "null this"
When you used the class, did you remember to new it? Unlike C++, "Io io;" in D would be null. You have to create it with "io = new Io();"
"null this"
So, I was doing some coding to my IO.d, and came across the strangest error, I looked it up and tried some different asserts, which is why it shows up as something different from "null this" now, anyway here, I seriously can't figure this out, the code is here: http://pastebin.com/bGiKMM4Y core.exception.AssertError@src/breaker/utility/io.d(167): (io.d:add) this is null bin/Breaker 3D Game Engine(_d_assert_msg+0x45) [0x5130e9] bin/Breaker 3D Game Engine(void breaker.utility.io.IO.add!(immutable(char)[], immutable(char)[], immutable(char)[]).add(immutable(bool), immutable(char)[], immutable(char)[], immutable(char)[])+0x66) [0x4c355e] bin/Breaker 3D Game Engine(immutable(char)[] breaker.utility.io.getDir(immutable(char[]))+0x1c2) [0x4c17ea] bin/Breaker 3D Game Engine(breaker.utility.io.IO breaker.utility.io.IO.__ctor(immutable(char[]), immutable(char[]), immutable(char[]))+0x1cf) [0x4c1e37] bin/Breaker 3D Game Engine(_Dmain+0x8b) [0x4c75bb] bin/Breaker 3D Game Engine(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().void __lambda1()+0x18) [0x514a20] bin/Breaker 3D Game Engine(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x51497a] bin/Breaker 3D Game Engine(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x30) [0x5149e0] bin/Breaker 3D Game Engine(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x51497a] bin/Breaker 3D Game Engine(_d_run_main+0x1a3) [0x5148fb] bin/Breaker 3D Game Engine(main+0x25) [0x4c7d85] /usr/lib/libc.so.6(__libc_start_main+0xf5) [0x7ff428219bc5] Exited: 256 Thank you for your time and help.
Re: Modify const reference data
Wow, i didn't know i could cast out constness from an lvalue. This is what i needed. I'll try it in my code as soon as i can. Thanks. Yep, it compiles and works! By the way, i forgot to call b.foo() in my example. Thanks for your help guys.
Passing ref T[n] to C
Given the following declarations in C: typedef int foo_t[3]; void take_foo( foo_t ); How would you handle this in D? It's obvious to me that the type should be declared the same way, so that it may be used the same way in D as in C: alias foo_t = int[3]; Given that on the C side, foo_t[3] parameters will degrade to pointers, it's just as obvious to me to declare the function on the D side like so: extern( C ) void take_foo( foo_t* ); That means that one need pass foo.ptr when calling the function, but it doesn't really bother me. However, it was recently brought to my attention that the following actually works: extern( C ) void take_foo( ref foo_t ); foo_t foo = [1, 2, 3]; void take_foo( foo ); I tested it with DMC and DMD and it actually worked fine. I was expecting the length field to get in the way, but it didn't seem to. I was able to print the values of the array just fine on the C side. My question is, can I rely on this? Is there a guarantee that a ref static array parameter will be compatible with a C array pointer on every platform and architecture? A voice in my head is screaming NO at me in all caps and with multiple exclamation points. But, if true, it would certainly simplify user code by not having to remember to pass foo.ptr all the time. So I thought I'd ask. I can't find anything regarding the implementation details of ref parameters.
Symbol Undefined _D2rt12__ModuleInfoZ
I'm building a 32-bit windows executable using dmd 2.064.2, dmc (857 according to the file in its root directory, but when run it says 8.42n), and implicitly optlink. The executable is the a vm for an interpreted language. The source is mainly C that I didn't write, but I successfully bolted a D front end on, making it a genuine windows program (not a console program) and got a working build that could achieve my main purpose: dynamically loading a DLL written in D and sync'ing the runtimes so there's only one GC (the one in the EXE). Everything builds and works perfectly at this point. Now I've rewritten the memory management and allocation modules in D, and excluded the C ones from the build. And I get mysterious linker errors for the first time. The command I'm using for the last step of the build and the reply from optlink are as follows. === dmd -d -oficonx.exe dmain.d dmemmgt.d dalc.d @diconx.link iconx.def -L/map/noi OPTLINK (R) for Win32 Release 8.00.13 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html iconx.obj(iconx) Error 42: Symbol Undefined _D2rt12__ModuleInfoZ iconx.obj(iconx) Error 42: Symbol Undefined _D2rt6b_real6__initZ iconx.obj(iconx) Error 42: Symbol Undefined _D2rt6b_real11__xopEqualsUKxS2rt6b_realKxS2rt6b_realZb === diconx.link is just a list of the objects compiled earlier from the C source plus shell32.lib . It seems that dmain.d , dmemmgt.d and dalc.d are being compiled by dmd into a single object iconx.obj . Running the Digital Mars librarian `lib -l iconx.obj` on that object produces iconx.lst which does not contain the symbols complained about above. And these three files contain the only D source. The rest is C. Any advice about what's going on or what to do?
Re: std.string inPattern() and UTF symbols
On Monday, 9 December 2013 at 16:10:34 UTC, qznc wrote:
That is probably not the root of Fras problem, though.
You are right, that was not the root, even if the mistake is
extremely simple: foreach(c, s) is used to seek the string.
I just realized that foreach can mess things up when used on
strings. I can't scroll the feeling this is a pitfall of the
language:
the code
foreach (immutable dchar c; s)
writeln("token: ", c);
produces deeply different results than
foreach (c; s)
writeln("token: ", c);
see http://dpaste.dzfl.pl/302291fd
I understand why foreach would produce such a result, but I guess
newcomers will get burnt by this.
I will open a bug report for the munch function in the mean time.
Re: Passing ref T[n] to C
On Monday, 9 December 2013 at 16:11:39 UTC, Jakob Ovrum wrote: Upon consulting the specification[1], it looks like it's officially recommended to use `ref T[n]` for C's `T[n]`, and `T*` for C's `T[]`, in parameter lists. [1] http://dlang.org/interfaceToC.html, "Passing D Array Arguments to C Functions" Thanks. I completely missed that.
Re: std.string inPattern() and UTF symbols
On Monday, 9 December 2013 at 16:10:34 UTC, qznc wrote:
On Monday, 9 December 2013 at 15:58:53 UTC, qznc wrote:
I also smell a unicode bug, due to the combination of foreach
and length.
Bug reported. :)
https://d.puremagic.com/issues/show_bug.cgi?id=11712
That is probably not the root of Fras problem, though.
Your ticket:
"The following assert fails, but should not.
assert(!inPattern('a', "äöüa-z"));"
Actually, 'a' IS in the given pattern, so the inPattern should
return true, then you negate it and therefore it fails. Long
story short, it should fail, and it does. So your bug report is
actually incorrect.
Re: std.string inPattern() and UTF symbols
On Monday, 9 December 2013 at 15:58:53 UTC, qznc wrote: I also smell a unicode bug, due to the combination of foreach and length. Bug reported. :) https://d.puremagic.com/issues/show_bug.cgi?id=11712 That is probably not the root of Fras problem, though.
Re: Modify const reference data
Apparently the OP intended to set it in foo(). If the data is
actually mutable and there really is no way other than going
against the type system, foo() must be called at least once and
can be implemented like this:
public void foo()
{
abc = [1,2,3,4];
cast(ubyte*)data = abc.ptr;
}
// ...
B b = new B();
b.foo();
b.print(); // now OK
Ali
Wow, i didn't know i could cast out constness from an lvalue.
This is what i needed. I'll try it in my code as soon as i can.
Thanks.
Re: File Picker
On Monday, 9 December 2013 at 08:57:16 UTC, Jeremy DeHaan wrote: On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian wrote: *sigh* No dice. And I can't get GtkD to work either, because of entry point errors... I've gotten GtkD to work for me, though it has been a while. If I am able to find some time soon I will see if I can do some kind of example for you. Well, in the mean time, have you ever heard of this error before? "The procedure entry point gdk_frame_clock_begin_updating could not be located in the dynamic link library libgdk-3-0.dll. I've also gotten a similar error with some other entry point in libgdk_pixbuf-2.0-0.dll, but then I copied that file from the Gtk 3.6.4 release into my bin folder and it went away. Copying the the libgdk-3-0.dll from the same release did nothing to fix this error. This is getting ridiculous.
Re: Passing ref T[n] to C
On Monday, 9 December 2013 at 16:11:39 UTC, Jakob Ovrum wrote: On Monday, 9 December 2013 at 15:46:40 UTC, Mike Parker wrote: Given that on the C side, foo_t[3] parameters will degrade to pointers, it's just as obvious to me to declare the function on the D side like so: extern( C ) void take_foo( foo_t* ); That means that one need pass foo.ptr when calling the function, but it doesn't really bother me. Do you mean `&foo`? Actually, I meant to declare the parameter as int*.
Re: Passing ref T[n] to C
On Monday, 9 December 2013 at 15:46:40 UTC, Mike Parker wrote: Given that on the C side, foo_t[3] parameters will degrade to pointers, it's just as obvious to me to declare the function on the D side like so: extern( C ) void take_foo( foo_t* ); That means that one need pass foo.ptr when calling the function, but it doesn't really bother me. Do you mean `&foo`? While they both yield the same memory address, the type of the pointer is different. `foo.ptr` is typed as a pointer to the element type, while `&foo` is (completely regularly) typed as a pointer to the fixed-length array. i.e. `T*` vs `T[n]*` where T is the element type of the array. However, it was recently brought to my attention that the following actually works: extern( C ) void take_foo( ref foo_t ); foo_t foo = [1, 2, 3]; void take_foo( foo ); I tested it with DMC and DMD and it actually worked fine. I was expecting the length field to get in the way, but it didn't seem to. I was able to print the values of the array just fine on the C side. Fixed-length arrays in D have no data-field for the length, because the length is always known at compile-time. ABI-wise, `int[3]` is always just 3 contiguous `int`s in memory. They are very unlike slices. My question is, can I rely on this? Is there a guarantee that a ref static array parameter will be compatible with a C array pointer on every platform and architecture? A voice in my head is screaming NO at me in all caps and with multiple exclamation points. But, if true, it would certainly simplify user code by not having to remember to pass foo.ptr all the time. So I thought I'd ask. I can't find anything regarding the implementation details of ref parameters. Upon consulting the specification[1], it looks like it's officially recommended to use `ref T[n]` for C's `T[n]`, and `T*` for C's `T[]`, in parameter lists. [1] http://dlang.org/interfaceToC.html, "Passing D Array Arguments to C Functions"
Re: Passing ref T[n] to C
Mike Parker: I was expecting the length field to get in the way, but it didn't seem to. If you pass a fixed-sized array by ref it only passes the pointer. The length is not passed, it's a compile-time known value. My question is, can I rely on this? Is there a guarantee that a ref static array parameter will be compatible with a C array pointer on every platform and architecture? While the semantics of "ref" if fixed, I don't remember if the standard D ABI specifies how "fixed-sized array by ref" is implemented. Bye, bearophile
Re: std.string inPattern() and UTF symbols
On Monday, 9 December 2013 at 14:44:23 UTC, Fra wrote: various (UTF) symbols seems to be ignored by inPattern, see http://dpaste.dzfl.pl/e8ff9002 for a quick example (munch() uses inPattern() internally) Is it me doing something in an improper way, or is the documentation lacking more specific limitation of the function? All I can read is "In the future, the pattern syntax may be improved to be more like regular expression character classes". This doesn't sound like "non-ascii symbols are not supported" Looking at the implementation of inPattern [0], I'd say it is restricted to ASCII. The unittests only cover ASCII, for example. I also smell a unicode bug, due to the combination of foreach and length. [0] https://github.com/D-Programming-Language/phobos/blob/master/std/string.d#L2595
std.string inPattern() and UTF symbols
various (UTF) symbols seems to be ignored by inPattern, see http://dpaste.dzfl.pl/e8ff9002 for a quick example (munch() uses inPattern() internally) Is it me doing something in an improper way, or is the documentation lacking more specific limitation of the function? All I can read is "In the future, the pattern syntax may be improved to be more like regular expression character classes". This doesn't sound like "non-ascii symbols are not supported"
Re: Simultaneous Assignment
On Monday, 9 December 2013 at 09:32:26 UTC, Dfr wrote:
What i trying to achieve in my current example is more succinct
code.
A coming from Perl and instead of writing:
if(some_complex_statement.here > 0) {
writefln("x is %s", some_long_expression.here);
}
I got used not to repeat complex statement, but use 'x' as
quick alias:
if((int x = some_complex_statement.here) > 0) {
writefln("x is %s", x);
}
Afaik, D has no StatementExpression, which means no declarations
inside expressions. However, there is an AssignExpression, so
assignment works, but requires the declaration before.
int x;
if((x = some_long_expression.here) > 0) {
writefln("x is %s", x);
}
The bad news is that this means type inference cannot be used
here (no "auto") and the variables is declared in a wider scope
than just the if-body.
Re: Equality == comparisons with floating point numbers
On 09/12/13 12:43, Abdulhaq wrote: I was tidying up my emails at work and by coincidence I found the original paper that I was referring to, it's very pertinent to this discussion and interesting too, The pitfalls of verifying floating-point computations David Monniaux (LIENS, Verimag - Imag) http://arxiv.org/abs/cs/0701192 Thank you very much! That's very useful. I managed to find a way to not trigger equality or isIdentical failures, just by calling std.math.feqrel on the quantities first (and comparing its result to double.mant_dig). I guess this is also a case of taking the variables off the FPU; I'm not experienced enough with assembly to be confident taking the program apart and analysing it that way.
Re: Equality == comparisons with floating point numbers
On 07/12/13 11:52, John Colvin wrote: I'm pretty sure D is free to do this, it goes with the whole more-precision-is-better-precision philosophy. I'm not complaining about better precision, I just want my equality comparisons to be predictable -- arguably a losing cause :-)
Re: Equality == comparisons with floating point numbers
I was tidying up my emails at work and by coincidence I found the original paper that I was referring to, it's very pertinent to this discussion and interesting too, The pitfalls of verifying floating-point computations David Monniaux (LIENS, Verimag - Imag) http://arxiv.org/abs/cs/0701192
Re: iterate over enum name:value pairs
Jay Norwood:
I notice that if Suit and SuitShort have an enum with the same
name, then you still have to fully qualify the enum names when
using the with statement. So, for example, if spd in SuitShort
was renamed spades, the first entry in the array initialization
would have to be {Suit.spades, 1, 6, SuitShort.spades}.
Yes, that's named anti-shadowing, the D type system tried to
avoid such bugs in your code.
Bye,
bearophile
Re: Simultaneous Assignment
Sorry, it was misnomer in topic title. But simultaneous
assignment also useful topic to learn.
What i trying to achieve in my current example is more succinct
code.
A coming from Perl and instead of writing:
if(some_complex_statement.here > 0) {
writefln("x is %s", some_long_expression.here);
}
I got used not to repeat complex statement, but use 'x' as quick
alias:
if((int x = some_complex_statement.here) > 0) {
writefln("x is %s", x);
}
On Monday, 9 December 2013 at 08:28:48 UTC, qznc wrote:
Could you give more context for your specific example? What are
you trying to do?
Re: Equality == comparisons with floating point numbers
To give context, you're talking about a comparison of (a ^^ 2.0) * 1.0 + 0.0 == a ^^ 2.0 (or, alternatively, the same but using isIdentical). I'm curious to confirm why placing writefln statements before the isIdentical check should change its behaviour (I assume flushing the FPU cache?) and whether this can be reliably done without writing output to screen. It's an interesting question. If I was attacking this problem I think I'd look at the assembly generated by the compiler, write a little self contained assembly program, and see if I could replicate it. I don't think it's a compiler problem - but what do I know!.
Re: File Picker
On Monday, 9 December 2013 at 06:32:06 UTC, Malkierian wrote: *sigh* No dice. And I can't get GtkD to work either, because of entry point errors... I've gotten GtkD to work for me, though it has been a while. If I am able to find some time soon I will see if I can do some kind of example for you.
Re: Only const or immutable class thread local variables are allowed
On Monday, 9 December 2013 at 06:43:05 UTC, Joseph Rushton
Wakeling wrote:
On 09/12/13 01:24, Ali Çehreli wrote:
On 12/08/2013 02:40 PM, qznc wrote:
I understand you are talking about the "Singleton" design
pattern.
You might want to look how std.parallelism does it with the
default
global thread pool.
https://github.com/D-Programming-Language/phobos/blob/master/std/parallelism.d#L3261
(ii) I still think it's not what I want. The "static" class
instance doesn't need to be globally global, I want the default
thread-local storage as per the existing std.random.rndGen.
Hence the solution I arrived at, but which I'm sure could be
improved.
class Foo {
private static Foo singleton = null;
@property public static Foo global() {
if (singleton is null)
singleton = new Foo();
return singleton;
}
}
Running example: http://www.dpaste.dzfl.pl/f65513fa
Re: Simultaneous Assignment
On Monday, 9 December 2013 at 07:38:04 UTC, Dfr wrote:
Does D has somtething similar ?
http://code.google.com/p/go-wiki/wiki/SimultaneousAssignment
No, not in general. There are a few special cases, though.
The foreach loop can assign value and index simultaneously.
foreach (int i, char c; a) {
writefln("a[%d] = '%c'", i, c);
}
Many things can be done in the library. For example, the variable
swap from your link:
swap(i,j); // more: http://www.dpaste.dzfl.pl/582f7ae2
For returning multiple values from a function in D, you use
std.typecons.tuple.
I tried this way, but it not worked out.
if((int x = 10) > 0) {
writefln("x is %s", x);
}
Could you give more context for your specific example? What are
you trying to do?
Re: Searching for a string in a text buffer with a regular expression
I mean a code fragment like this:
foreach(i; 1..2085)
{
// Bugbug: when we read in the buffer, we can't know anything
about its encoding...
// But REGEX could fail if it contained unknown chars!
Latin1String buf;
string s;
try
{
buf = cast(Latin1String)
read(format("psi\\psi%04d.htm", i));
transcode(buf, s);
}
catch (Exception e)
{
writeln("Last record (", i, ") reached.");
exit(1);
}
// Exception "Invalid UTF-8 sequence @index 1" in file 55
enum rx = ctRegex!(`.+?`,
"gs");
auto m = match(s, rx);
if (! m.empty())
{
if (indexOf(m.captures[0], "", 0) > -1 &&
indexOf(m.captures[0], "1983", 0) > -1)
writeln(m.captures[0]);
}
}
The question is: what kind of cast should I use to safely
(=without conversion exceptions got raised) scan all possible
kind of textual (or binary) buffer, lile in Python 2.7.x?
Thanks!
