Re: struct: default construction or lazy initialization.
On Wednesday, 1 February 2017 at 23:32:12 UTC, bitwise wrote: On Wednesday, 1 February 2017 at 23:24:27 UTC, kinke wrote: It's not that bad. D just doesn't support a default ctor for structs at all and simply initializes each instance with T.init. Your `s2` initialization is most likely seen as explicit default initialization (again with T.init). Destructing both instances is exactly what should happen. I was going to add a point about this. 1| S s1; 2| S s2 = S(); The effect of line 1 and 2 are exactly the same - which is that the lhs ends up with S.init. S.this() should either be called at line 2, or the syntax of line 2 should be forbidden on the grounds that default struct ctors cannot be declared. Yep, they are the same. Initialization with S.init is a trivial blit from a compile-time constant, so there's no call to a default ctor. This in turn makes construction of static arrays and structs containing a field of type S trivial, as no default ctor has to be generated if a field has one, there are no potential exceptions etc. Ideally, S.this() would be called in both cases (just like C++). The explicit syntax in line 2 is useful for stuff like `const s = S();`.
Re: struct: default construction or lazy initialization.
On Wednesday, 1 February 2017 at 23:24:27 UTC, kinke wrote: It's not that bad. D just doesn't support a default ctor for structs at all and simply initializes each instance with T.init. Your `s2` initialization is most likely seen as explicit default initialization (again with T.init). Destructing both instances is exactly what should happen. I was going to add a point about this. 1| S s1; 2| S s2 = S(); The effect of line 1 and 2 are exactly the same - which is that the lhs ends up with S.init. S.this() should either be called at line 2, or the syntax of line 2 should be forbidden on the grounds that default struct ctors cannot be declared.
Re: struct: default construction or lazy initialization.
On Wednesday, 1 February 2017 at 23:02:11 UTC, bitwise wrote: On Wednesday, 1 February 2017 at 01:52:40 UTC, Adam D. Ruppe wrote: On Wednesday, 1 February 2017 at 00:43:39 UTC, bitwise wrote: Container!int c; // = Container!int() -> can't do this. Can you live with Container!int c = Container!int.create(); because D supports that and can force the issue with `@disable this();` which causes compilation to fail any place where it isn't explicitly initialized. I suppose this works, but to be honest, I wouldn't use it. I rather wouldn't have to live with this limitation as well. The problem is that if my struct T can only be correctly initialized via static factory, all aggregates containing a field of type T (directly or indirectly!) will then have to have a static factory as well => no real RAII. The current behavior doesn't even really make sense. Example: struct S { // this(){} this(Args...)(auto ref Args args) { writeln("ctor"); } ~this() { writeln("dtor"); } } void foo(Args...)(auto ref Args args) { writeln("foo"); } int main(string[] argv) { S s; S s2 = S(); foo(); return 0; } outputs: foo dtor dtor I would expect that I could at least have this() invoked for 's2', but I can't even declare it at all. So while 'S()' looks like a constructor call, it doesn't call one. Instead, the current behavior forces explicit initialization of objects, pointless boilerplate, or unorthodox/unreliable workarounds. Even more confusingly, the above example prints "foo" but not "ctor", because calling variadic functions with no arguments is fine - except for constructors. Finally, destructors are currently called on objects which were never constructed. You can't even call what's going on with structs RAII at this point. It's not that bad. D just doesn't support a default ctor for structs at all and simply initializes each instance with T.init. Your `s2` initialization is most likely seen as explicit default initialization (again with T.init). Destructing both instances is exactly what should happen. Can anyone point to the rationale for not supporting default constructors for structs? It prevents true RAII and hinders C++ interop.
Re: struct: default construction or lazy initialization.
On Wednesday, 1 February 2017 at 01:52:40 UTC, Adam D. Ruppe wrote: On Wednesday, 1 February 2017 at 00:43:39 UTC, bitwise wrote: Container!int c; // = Container!int() -> can't do this. Can you live with Container!int c = Container!int.create(); because D supports that and can force the issue with `@disable this();` which causes compilation to fail any place where it isn't explicitly initialized. I suppose this works, but to be honest, I wouldn't use it. I really don't feel like I'm asking to "have my cake and eat it too" by expecting a proper solution for this. The current behavior doesn't even really make sense. Example: struct S { // this(){} this(Args...)(auto ref Args args) { writeln("ctor"); } ~this() { writeln("dtor"); } } void foo(Args...)(auto ref Args args) { writeln("foo"); } int main(string[] argv) { S s; S s2 = S(); foo(); return 0; } outputs: foo dtor dtor I would expect that I could at least have this() invoked for 's2', but I can't even declare it at all. So while 'S()' looks like a constructor call, it doesn't call one. Instead, the current behavior forces explicit initialization of objects, pointless boilerplate, or unorthodox/unreliable workarounds. Even more confusingly, the above example prints "foo" but not "ctor", because calling variadic functions with no arguments is fine - except for constructors. Finally, destructors are currently called on objects which were never constructed. You can't even call what's going on with structs RAII at this point.
dep files
Hi, I'm using package.d file for the project, where is each file imported. In each file is imported only that one package file (like `import Foo;`). Problem is with .dep files. dep file for each source file contains all source files of the project just because it imports that package. This made dep files quite useless because every time when I change something just in one file, whole project is always rebuild.
Re: std.system reports win32 when running OS X
On 02/01/2017 01:34 PM, Dave Chapman wrote: I am running an iMac with OS X 10.11.5 (El Capitan) and dmd version 2.072.2 The following program prints out OS = win32. Is this the intended behavior? #!/usr/local/bin/rdmd import std.stdio; import std.system; void main (string[] args) { immutable OS os; That's a local variable that you've defined. Since OS.init happens to be OS.win32, that's what you get. writefln("OS = %s",os); } What you need is the already defined std.system.os: import std.stdio; import std.system; void main (string[] args) { writefln("OS = %s",os); } Ali
std.system reports win32 when running OS X
I am running an iMac with OS X 10.11.5 (El Capitan) and dmd version 2.072.2 The following program prints out OS = win32. Is this the intended behavior? #!/usr/local/bin/rdmd import std.stdio; import std.system; void main (string[] args) { immutable OS os; writefln("OS = %s",os); }
How to Exec Store Procedure For MySql in D? Thanks
Hi,everyone: Now,I find that I can't exec Store Procedure For MySql in D. use mySql-d,mySql-native,or ddbc. I want to get a SqlResult. I think that it's the time to fix the bug! Who can help me? Thank you! Frank
Re: Does vibe.d support setting cookies?
On Wednesday, 1 February 2017 at 14:09:41 UTC, aberba wrote: I can't find it. Like set_cookie() in php. Yes, it does. http://vibed.org/api/vibe.http.common/HTTPResponse.cookies
Re: Does vibe.d support setting cookies?
V Wed, 01 Feb 2017 14:09:41 + aberba via Digitalmars-d-learnnapsáno: > I can't find it. Like set_cookie() in php. maybe this http://vibed.org/api/vibe.http.server/HTTPServerResponse.setCookie
Re: Does vibe.d support setting cookies?
V Wed, 01 Feb 2017 14:09:41 + aberba via Digitalmars-d-learnnapsáno: > I can't find it. Like set_cookie() in php. I am not sure but I use this in one of my projects import vibe.http.client; auto clientOCX = new RestInterfaceClient!I(host ~ path); string sessionId = clientOCX.initialize(); clientOCX.requestFilter = (HTTPClientRequest req) { req.headers.addField("Cookie", "vibe.session_id=" ~ sessionId ~ "; Path=/; HttpOnly"); }; return clientOCX;
Re: capture stdout or stderr
On Wednesday, 1 February 2017 at 01:08:19 UTC, Emil wrote: is it possible to intercept the STDOUT or STDERR and capture the output into a variable ? some pseudocode to explain what I mean string[] output_buffer; stdout.capture_to(output_buffer); writeln("test 1"); # not printed writeln("test 2"); # not printed stdout.release(output_buffer); writeln("test 3"); # printed writeln(output_buffer); # prints '["test 1","test 2"]' No. Please keep in mind, that in Linux, for example, stdout is a file ... writeln() interacts with OS API, which, of course, has nothing to do with internal data structures of your application. What you could probably do is replace writeln() with a custom logger. In your logger implementation you can add such functionality.
Re: Can't find the reason of issue: "std.file.FileException@std\file.d(360): path/to/file.conf:"
On Wednesday, 1 February 2017 at 11:39:46 UTC, Suliman wrote: Full error log: 0x00580A4D in @trusted bool std.file.cenforce!(bool).cenforce(bool, const(char)[], const(wchar)*, immutable(char)[], uint) 0x00412AB6 in @safe void[] std.file.read!(immutable(char)[]).read(immutable(char)[], uint) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(229) 0x00412060 in @safe immutable(char)[] std.file.readText!(immutable(char)[], [...] Can it be issue in external lib? No stacktraces that involve in external libs are not so detailed since they are usually build without debug info.
Re: Can't find the reason of issue: "std.file.FileException@std\file.d(360): path/to/file.conf:"
On Wednesday, 1 February 2017 at 11:55:20 UTC, Suliman wrote: On Wednesday, 1 February 2017 at 11:39:46 UTC, Suliman wrote: [...] Yeah, it was issue in dini 2. dini 1 work fine. Is std.file not blocking (when used in vibe.d)?
Does vibe.d support setting cookies?
I can't find it. Like set_cookie() in php.
Re: Convert struct to set of fields and pass it's to constructor
On Wednesday, 1 February 2017 at 13:51:28 UTC, Minty Fresh wrote: On Wednesday, 1 February 2017 at 13:37:27 UTC, Suliman wrote: Class constructor accept only set if fields like this(string login, string pass) Can I create structure, fill it, and than pass to constructor? Like this: ``` import std.stdio; struct ConnectSettings { string login; string pass; }; ConnectSettings cs; void main() { cs.login = "admin"; cs.pass = "mypass"; } ``` and than pass to constructor it's like: `... new SomeClass(cs)` I tried, but get error, that ctor accept only fields list. Can I unroll struct to it? tupleof is probably what you're looking for. ie. new SomeClass(cs.tupleof); That said, why not have the constructor accept the struct as a parameter? Because it's implemented not by me, and I do not want to touch its realization.
Re: Convert struct to set of fields and pass it's to constructor
On Wednesday, 1 February 2017 at 13:37:27 UTC, Suliman wrote: Class constructor accept only set if fields like this(string login, string pass) Can I create structure, fill it, and than pass to constructor? Like this: ``` import std.stdio; struct ConnectSettings { string login; string pass; }; ConnectSettings cs; void main() { cs.login = "admin"; cs.pass = "mypass"; } ``` and than pass to constructor it's like: `... new SomeClass(cs)` I tried, but get error, that ctor accept only fields list. Can I unroll struct to it? tupleof is probably what you're looking for. ie. new SomeClass(cs.tupleof); That said, why not have the constructor accept the struct as a parameter?
Convert struct to set of fields and pass it's to constructor
Class constructor accept only set if fields like this(string login, string pass) Can I create structure, fill it, and than pass to constructor? Like this: ``` import std.stdio; struct ConnectSettings { string login; string pass; }; ConnectSettings cs; void main() { cs.login = "admin"; cs.pass = "mypass"; } ``` and than pass to constructor it's like: `... new SomeClass(cs)` I tried, but get error, that ctor accept only fields list. Can I unroll struct to it?
Re: Can't find the reason of issue: "std.file.FileException@std\file.d(360): path/to/file.conf:"
Not even issue, but unhandled exception when access to nonexistent file.
Re: Can't find the reason of issue: "std.file.FileException@std\file.d(360): path/to/file.conf:"
On Wednesday, 1 February 2017 at 11:39:46 UTC, Suliman wrote: Full error log: 0x00580A4D in @trusted bool std.file.cenforce!(bool).cenforce(bool, const(char)[], const(wchar)*, immutable(char)[], uint) 0x00412AB6 in @safe void[] std.file.read!(immutable(char)[]).read(immutable(char)[], uint) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(229) 0x00412060 in @safe immutable(char)[] std.file.readText!(immutable(char)[], immutable(char)[]).readText(immutable(char)[]) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(417) 0x004116F2 in void dini.parser.IniSection.parse(immutable(char)[], bool) at C:\Users\Dima\AppData\Roaming\dub\packages\dini-2.0.0\dini\source\dini\parser.d(318) 0x00411EB7 in dini.parser.IniSection dini.parser.IniSection.Parse(immutable(char)[], bool) at C:\Users\Dima\AppData\Roaming\dub\packages\dini-2.0.0\dini\source\dini\parser.d(497) 0x004106AF in config.MyConfig config.MyConfig.__ctor() at D:\code\CoreCMS\source\config.d(30) 0x004033EA in _Dmain at D:\code\CoreCMS\source\app.d(7) 0x0055EBFB in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv 0x0055EBBF in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() 0x0055EAC0 in _d_run_main 0x0041064C in main at D:\code\CoreCMS\source\APIInterface.d(7) 0x005BA001 in mainCRTStartup 0x73FC62C4 in BaseThreadInitThunk 0x77440FD9 in RtlSubscribeWnfStateChangeNotification 0x77440FA4 in RtlSubscribeWnfStateChangeNotification Program exited with code 1 Can it be issue in external lib? Yeah, it was issue in dini 2. dini 1 work fine.
Re: Can't find the reason of issue: "std.file.FileException@std\file.d(360): path/to/file.conf:"
Full error log: 0x00580A4D in @trusted bool std.file.cenforce!(bool).cenforce(bool, const(char)[], const(wchar)*, immutable(char)[], uint) 0x00412AB6 in @safe void[] std.file.read!(immutable(char)[]).read(immutable(char)[], uint) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(229) 0x00412060 in @safe immutable(char)[] std.file.readText!(immutable(char)[], immutable(char)[]).readText(immutable(char)[]) at C:\D\dmd2\windows\bin\..\..\src\phobos\std\file.d(417) 0x004116F2 in void dini.parser.IniSection.parse(immutable(char)[], bool) at C:\Users\Dima\AppData\Roaming\dub\packages\dini-2.0.0\dini\source\dini\parser.d(318) 0x00411EB7 in dini.parser.IniSection dini.parser.IniSection.Parse(immutable(char)[], bool) at C:\Users\Dima\AppData\Roaming\dub\packages\dini-2.0.0\dini\source\dini\parser.d(497) 0x004106AF in config.MyConfig config.MyConfig.__ctor() at D:\code\CoreCMS\source\config.d(30) 0x004033EA in _Dmain at D:\code\CoreCMS\source\app.d(7) 0x0055EBFB in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv 0x0055EBBF in void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() 0x0055EAC0 in _d_run_main 0x0041064C in main at D:\code\CoreCMS\source\APIInterface.d(7) 0x005BA001 in mainCRTStartup 0x73FC62C4 in BaseThreadInitThunk 0x77440FD9 in RtlSubscribeWnfStateChangeNotification 0x77440FA4 in RtlSubscribeWnfStateChangeNotification Program exited with code 1 Can it be issue in external lib?
Can't find the reason of issue: "std.file.FileException@std\file.d(360): path/to/file.conf:"
After building vibed project and running it I am getting error: "std.file.FileException@std\file.d(360): path/to/file.conf: Системе не удается найти указанный путь." (System can't find selected path) I even do not understand where is the error... It's do not seems that it's vibed issue.
Re: GC question
On Wednesday, 1 February 2017 at 09:50:42 UTC, osa1 wrote: Thanks for the answer. Could you elaborate on the lacklustre part? It's fine if I have to do manual memory management, but I don't want any leaks. Ideally I'd have a precise GC + RAII style resource management when needed. Rust, Go, Java, Swift etc have a single memory management scheme which is used by libraries and mostly enforced by the compiler. In C++ you tend to go with unique ownership and occasional shared ownership with the ability to have weak pointers and swap out objects without updating pointer, and there is an easy transition form old ad-hoc ownership to shared (the reference counter is in a separate object). It is not enforced by the compiler, but C++ is moving towards having dedicated tools for checking correctness. In D the goal is to have safety enforced by the compiler, but it isn't quite there yet and what is on the map for leak free resource management seems a simple reference counting mechanism (simpler than swift?) with refcount embedded in objects (like intrusive_ptr in Boost except the compiler is intended to be better at optimizing unnecessary updates of the reference count).
Re: GC question
On Wednesday, 1 February 2017 at 09:40:17 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote: I'm wondering what are the implications of the fact that current GC is a Boehm-style conservative GC rather than a precise one, I've never worked with a conservative GC before. The GC isn't competitive with the ones you find in GC languages (Java, Go etc). E.g. Go is now aiming for GC pauses in the microseconds range. Resource management in D is rather lacklustre, even C++ does better imho. D seems to move towards using thread local ref-counting and making GC optional. I guess that would be ok on cpus with few cores, but not really adequate on many core CPUs. Thanks for the answer. Could you elaborate on the lacklustre part? It's fine if I have to do manual memory management, but I don't want any leaks. Ideally I'd have a precise GC + RAII style resource management when needed.
Re: GC question
On Wednesday, 1 February 2017 at 06:58:43 UTC, osa1 wrote: I'm wondering what are the implications of the fact that current GC is a Boehm-style conservative GC rather than a precise one, I've never worked with a conservative GC before. The GC isn't competitive with the ones you find in GC languages (Java, Go etc). E.g. Go is now aiming for GC pauses in the microseconds range. Resource management in D is rather lacklustre, even C++ does better imho. D seems to move towards using thread local ref-counting and making GC optional. I guess that would be ok on cpus with few cores, but not really adequate on many core CPUs.