Re: Top level associative arrays
On Tuesday, 2 May 2017 at 16:34:15 UTC, H. S. Teoh wrote: On Tue, May 02, 2017 at 02:37:20PM +, ANtlord via Digitalmars-d-learn wrote: On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote: > > Note that when declared as "enum", all places it's > referenced, a new associative array will be allocated. If it is allocated at all places I can move initialization to module ctor as says evilrat but how can I make an immutable associative array? Just declare it immutable. The module ctor can still initialize it, because ctors are allowed to initialize immutables: -- immutable string[string] dict; static this() { dict = [ "abc": "def", "ghi": "lmn" ]; } void main() { import std.stdio; writeln(dict["abc"]); } -- T Thanks a lot!
Re: Porting Java code to D that uses << and >>> operators
On 2017-05-02 18:55, TheGag96 wrote: On Tuesday, 2 May 2017 at 07:42:45 UTC, Jacob Carlborg wrote: From that link: "Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression". This is something I've never understood. Why doesn't DMD implement the behavior their own language reference specifies? It seems like a very nice guarantee to have... https://github.com/dlang/dmd/pull/4035
Re: Porting Java code to D that uses << and >>> operators
On 2017-05-02 09:42, Jacob Carlborg wrote: On 2017-05-02 01:27, Faux Amis wrote: To me, this [2] suggests otherwise ;) Or am I missing something? [2] https://dlang.org/spec/expression.html#order-of-evaluation From that link: "Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression". Yeah, I am blind. Do all the compilers have this problem?
Re: problem with std.variant rounding
On 05/02/2017 04:02 AM, Suliman wrote: I need co concatenate string with variant type (I am doing SQL query). What is the best way to put it? It's seems that if I am doing simple `replace` string sql = "..." sql.replace(`37.72308`, to!string(cargpspoint.lon)).replace(`55.47957`, to!string(cargpspoint.lat)) I am loosing accuracy. Is there any better way? Building SQL strings manually isn't really good practice these days, for both that and other reasons. It's better to use prepared statements, which will fix that issue for you and will also ensure your code is not susceptible to SQL-injection attacks: // Raw SQL strings (old, ugly, unsafe way): auto name = "Fred"; auto num = 1.23; auto sql = text( "INSERT INTO `myTable` (`field1`, `field2`) VALUES ('", mysqlEscape(name), "', ", num, ")" ); exec(conn, sql); // Prepared statement (good, modern, safe way): auto name = "Fred"; auto num = 1.23; Prepared insertSomeFields = prepare(conn, "INSERT INTO `myTable` (`field1`, `field2`) VALUES (?, ?)" ); insertSomeFields.setArgs(name, num); insertSomeFields.exec();
Re: Member delegate/fp to another member in same object?
On Tuesday, 2 May 2017 at 17:08:11 UTC, Juanjo Alvarez wrote: struct S { int someState; void some_foo() { return this. someState;} void delegate() foo; void enable() { foo = _foo; } } That's actually illegal in D. It will compile, but has undefined behavior because the compiler is free to move the struct around without giving you a chance to update the delegate. You are liable for random crashes doing that. You'd be better off using a function pointer instead of a delegate and making the user pass `this` to it explicitly, or making it a class rather than a struct, which the compiler will not move. (or a struct only ever used by pointer, a diy class basically)
Re: Member delegate/fp to another member in same object?
On Tuesday, 2 May 2017 at 17:08:11 UTC, Juanjo Alvarez wrote: Example: struct S { int someState; void some_foo() { return this. someState;} void delegate() foo; void enable() { foo = _foo; } } unittest { S s; s.someState = 1; enable(); s.someState = 2; assert(foo == 2); // fails because the delegate keeps // the state of the object at the // assignment point } Forget it. I just noticed the simplified example that I just posted works (once the typo of the return value is corrected) but my more complex real code won't, will try to get a simple snippet where I can reproduce the problem.
Member delegate/fp to another member in same object?
Hi! I would like to have a "proxy" delegate, let's call it "foo" that could point to a method or another, let's call them "fast_foo" or "slow_foo" on the same object. This way depending on some conditions I could switch at runtime from one set of methods to others with a "switchFoo(" fast") method while the rest of the code inside the object would continue happily calling "foo". The problem I have is that since the delegate keep the state of the object at the moment of the assignment I can't use it for this is pretty since the "fast/slow" methods need the value of the members of the enclosing object members at the point of usage, I guess that I could pass the "this" pointer in the rebinding method but since the targets are also methods of the same object I wouldn't be surprised to find that there is an obvious/elegant way to get access to "this" on the delegate-pointed method implementing. Example: struct S { int someState; void some_foo() { return this. someState;} void delegate() foo; void enable() { foo = _foo; } } unittest { S s; s.someState = 1; enable(); s.someState = 2; assert(foo == 2); // fails because the delegate keeps // the state of the object at the // assignment point }
Re: Porting Java code to D that uses << and >>> operators
On Tuesday, 2 May 2017 at 07:42:45 UTC, Jacob Carlborg wrote: From that link: "Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression". This is something I've never understood. Why doesn't DMD implement the behavior their own language reference specifies? It seems like a very nice guarantee to have...
Re: Top level associative arrays
On Tue, May 02, 2017 at 02:37:20PM +, ANtlord via Digitalmars-d-learn wrote: > On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote: > > > > Note that when declared as "enum", all places it's referenced, a new > > associative array will be allocated. > > If it is allocated at all places I can move initialization to module > ctor as says evilrat but how can I make an immutable associative > array? Just declare it immutable. The module ctor can still initialize it, because ctors are allowed to initialize immutables: -- immutable string[string] dict; static this() { dict = [ "abc": "def", "ghi": "lmn" ]; } void main() { import std.stdio; writeln(dict["abc"]); } -- T -- Just because you survived after you did it, doesn't mean it wasn't stupid!
Re: Top level associative arrays
On Tuesday, 2 May 2017 at 14:37:20 UTC, ANtlord wrote: On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote: Note that when declared as "enum", all places it's referenced, a new associative array will be allocated. If it is allocated at all places I can move initialization to module ctor as says evilrat but how can I make an immutable associative array? I think it will be more suitable to create singleton of structure.
Re: Top level associative arrays
On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote: Note that when declared as "enum", all places it's referenced, a new associative array will be allocated. If it is allocated at all places I can move initialization to module ctor as says evilrat but how can I make an immutable associative array?
Re: Top level associative arrays
On 2017-05-02 09:48, ANtlord wrote: Hello! Is it possible to define associative array on top level of module? I try to compile this code and I get message `Error: non-constant expression ["s":"q", "ss":"qq"]` import std.stdio; auto dict = [ "s": "q", "ss": "qq" ]; void main() { writeln(val); } I solved it by replacement of word `auto` by `enum`. It is acceptable for me. But I notice some inconsistency of logic. When I define simple array I don't get same compile error and it doesn't lead to define this array using enum. What is key difference between them in this case? Thanks. Sorry if my English is not clear. Note that when declared as "enum", all places it's referenced, a new associative array will be allocated. -- /Jacob Carlborg
Re: Top level associative arrays
On Tuesday, 2 May 2017 at 09:50:50 UTC, ANtlord wrote: On Tuesday, 2 May 2017 at 08:24:09 UTC, evilrat wrote: Making enum means that value should be available at compile time and AA's are fully dynamic. But if my memory serves me well, you can declare empty AA and delay initialization. So the closest solution is to move initialization of AA to shared module ctor(note that there is difference between shared and non-shared, refer to documentation) such as in this example: static shared this() // <-- module ctors run before main() { dict = [ "s": "q", "ss": "qq" ]; } string[string] dict; void main() { ... dict is already initialized ... } I know about D's enums and I know about module ctors but my question is about difference between array and associative array in case of definition in top level of module. Why DMD allows to define array and doesn't allow to define associative array. Because it is perfectly fine. They are live in the module scope, which has its own life time, and from runtime or lifetime perspective there is no difference here. And since array can be fixed-sized it is valid to use as enum value. But there is one catch, in case of enum array it is best to avoid it in favor of immutable array* because every time you reference it it will allocate. But thats the difference between enum and not enum, not the array and map. This is what I remember from the past, and it is possibly that no longer relevant anymore. * not sure if it prevents allocation though, but in theory it should since it *should* go in to program data section when compiling
Re: Top level associative arrays
On Tuesday, 2 May 2017 at 08:24:09 UTC, evilrat wrote: Making enum means that value should be available at compile time and AA's are fully dynamic. But if my memory serves me well, you can declare empty AA and delay initialization. So the closest solution is to move initialization of AA to shared module ctor(note that there is difference between shared and non-shared, refer to documentation) such as in this example: static shared this() // <-- module ctors run before main() { dict = [ "s": "q", "ss": "qq" ]; } string[string] dict; void main() { ... dict is already initialized ... } I know about D's enums and I know about module ctors but my question is about difference between array and associative array in case of definition in top level of module. Why DMD allows to define array and doesn't allow to define associative array.
Re: problem with std.variant rounding
On Tuesday, 2 May 2017 at 08:02:23 UTC, Suliman wrote: On Saturday, 29 April 2017 at 08:57:09 UTC, Petar Kirov [ZombineDev] wrote: On Friday, 28 April 2017 at 18:08:38 UTC, H. S. Teoh wrote: On Fri, Apr 28, 2017 at 04:42:28PM +, via Digitalmars-d-learn wrote: [...] writefln(text("%.", i, "f"), x); [...] There's no need to use text() here: writefln("%.*f", i, x); does what you want. T Thanks, I missed the fact that * could be used for specifying the precision, in addition to the width. I need co concatenate string with variant type (I am doing SQL query). What is the best way to put it? It's seems that if I am doing simple `replace` string sql = "..." sql.replace(`37.72308`, to!string(cargpspoint.lon)).replace(`55.47957`, to!string(cargpspoint.lat)) I am loosing accuracy. Is there any better way? I did: sql_distance.replace(`37.72308`, format("%f",cargpspoint.lon)) It's seems that it's work ok. But is there any better way, or it's ok?
Re: Top level associative arrays
On Tuesday, 2 May 2017 at 07:48:35 UTC, ANtlord wrote: Hello! Is it possible to define associative array on top level of module? I try to compile this code and I get message `Error: non-constant expression ["s":"q", "ss":"qq"]` import std.stdio; auto dict = [ "s": "q", "ss": "qq" ]; void main() { writeln(val); } I solved it by replacement of word `auto` by `enum`. It is acceptable for me. But I notice some inconsistency of logic. When I define simple array I don't get same compile error and it doesn't lead to define this array using enum. What is key difference between them in this case? Thanks. Sorry if my English is not clear. Making enum means that value should be available at compile time and AA's are fully dynamic. But if my memory serves me well, you can declare empty AA and delay initialization. So the closest solution is to move initialization of AA to shared module ctor(note that there is difference between shared and non-shared, refer to documentation) such as in this example: static shared this() // <-- module ctors run before main() { dict = [ "s": "q", "ss": "qq" ]; } string[string] dict; void main() { ... dict is already initialized ... }
Re: problem with std.variant rounding
On Saturday, 29 April 2017 at 08:57:09 UTC, Petar Kirov [ZombineDev] wrote: On Friday, 28 April 2017 at 18:08:38 UTC, H. S. Teoh wrote: On Fri, Apr 28, 2017 at 04:42:28PM +, via Digitalmars-d-learn wrote: [...] writefln(text("%.", i, "f"), x); [...] There's no need to use text() here: writefln("%.*f", i, x); does what you want. T Thanks, I missed the fact that * could be used for specifying the precision, in addition to the width. I need co concatenate string with variant type (I am doing SQL query). What is the best way to put it? It's seems that if I am doing simple `replace` string sql = "..." sql.replace(`37.72308`, to!string(cargpspoint.lon)).replace(`55.47957`, to!string(cargpspoint.lat)) I am loosing accuracy. Is there any better way?
Re: Top level associative arrays
On Tuesday, 2 May 2017 at 07:48:35 UTC, ANtlord wrote: Hello! Is it possible to define associative array on top level of module? I try to compile this code and I get message `Error: non-constant expression ["s":"q", "ss":"qq"]` import std.stdio; auto dict = [ "s": "q", "ss": "qq" ]; void main() { writeln(val); } I solved it by replacement of word `auto` by `enum`. It is acceptable for me. But I notice some inconsistency of logic. When I define simple array I don't get same compile error and it doesn't lead to define this array using enum. What is key difference between them in this case? Thanks. Sorry if my English is not clear. By the way I notice some strange compile error when I try to change associatove array defined using enum. import std.stdio; enum dict = [ "s": "q", "ss": "qq" ]; void main() { dict["sss"] = "qqq"; } Compilation of this code returns the error & el:0x3237ab4 cnt=0 cs=0 & TY* 0x3235794 el:0x3235794 cnt=0 cs=0 call TY* 0x3235744 0x32356f4 el:0x3235744 cnt=0 cs=0 var TYC func _d_assocarrayliteralTX el:0x32356f4 cnt=0 cs=0 param TYvoid 0x32356a4 0x3235654 el:0x32356a4 cnt=0 cs=0 param TYvoid 0x3234c44 0x3234d34 el:0x3234c44 cnt=0 cs=0 rpair TYucent 0x3234ba4 0x3234bf4 el:0x3234ba4 cnt=0 cs=0 relconst TY* 0+& _TMP8 el:0x3234bf4 cnt=0 cs=0 const TYuns long long 2LL el:0x3234d34 cnt=0 cs=0 rpair TYucent 0x3234c94 0x3234ce4 el:0x3234c94 cnt=0 cs=0 relconst TY* 0+& _TMP5 el:0x3234ce4 cnt=0 cs=0 const TYuns long long 2LL el:0x3235654 cnt=0 cs=0 var TY* _D16TypeInfo_HAyaAya6__initZ Internal error: backend/cgcs.c 352 But when I try to change simple array defined using enum import std.stdio; enum arr = [1, 2, 3]; void main() { arr ~= 4; } I get the clear error `Error: [1, 2, 3] is not an lvalue`
Re: Top level associative arrays
On Tuesday, 2 May 2017 at 07:48:35 UTC, ANtlord wrote: Hello! Is it possible to define associative array on top level of module? I try to compile this code and I get message `Error: non-constant expression ["s":"q", "ss":"qq"]` import std.stdio; auto dict = [ "s": "q", "ss": "qq" ]; void main() { writeln(val); } I solved it by replacement of word `auto` by `enum`. It is acceptable for me. But I notice some inconsistency of logic. When I define simple array I don't get same compile error and it doesn't lead to define this array using enum. What is key difference between them in this case? Thanks. Sorry if my English is not clear. Sorry. There is should be `writeln(dict["s"]);` instead `writeln(val);`
Top level associative arrays
Hello! Is it possible to define associative array on top level of module? I try to compile this code and I get message `Error: non-constant expression ["s":"q", "ss":"qq"]` import std.stdio; auto dict = [ "s": "q", "ss": "qq" ]; void main() { writeln(val); } I solved it by replacement of word `auto` by `enum`. It is acceptable for me. But I notice some inconsistency of logic. When I define simple array I don't get same compile error and it doesn't lead to define this array using enum. What is key difference between them in this case? Thanks. Sorry if my English is not clear.
Re: Porting Java code to D that uses << and >>> operators
On 2017-05-02 01:27, Faux Amis wrote: To me, this [2] suggests otherwise ;) Or am I missing something? [2] https://dlang.org/spec/expression.html#order-of-evaluation From that link: "Note that dmd currently does not comply with left to right evaluation of function arguments and AssignExpression". -- /Jacob Carlborg