Re: struct: default construction or lazy initialization.

2017-02-01 Thread kinke via Digitalmars-d-learn

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.

2017-02-01 Thread bitwise via Digitalmars-d-learn

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.

2017-02-01 Thread kinke via Digitalmars-d-learn

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.

2017-02-01 Thread bitwise via Digitalmars-d-learn
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

2017-02-01 Thread Satoshi via Digitalmars-d-learn

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

2017-02-01 Thread Ali Çehreli via Digitalmars-d-learn

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

2017-02-01 Thread Dave Chapman via Digitalmars-d-learn
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

2017-02-01 Thread FrankLike via Digitalmars-d-learn

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?

2017-02-01 Thread Jack Applegame via Digitalmars-d-learn

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?

2017-02-01 Thread Daniel Kozák via Digitalmars-d-learn
V Wed, 01 Feb 2017 14:09:41 +
aberba via Digitalmars-d-learn 
napsá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?

2017-02-01 Thread Daniel Kozák via Digitalmars-d-learn
V Wed, 01 Feb 2017 14:09:41 +
aberba via Digitalmars-d-learn 
napsá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

2017-02-01 Thread angel via Digitalmars-d-learn

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:"

2017-02-01 Thread Basile B. via Digitalmars-d-learn

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:"

2017-02-01 Thread aberba via Digitalmars-d-learn

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?

2017-02-01 Thread aberba via Digitalmars-d-learn

I can't find it. Like set_cookie() in php.


Re: Convert struct to set of fields and pass it's to constructor

2017-02-01 Thread Suliman via Digitalmars-d-learn

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

2017-02-01 Thread Minty Fresh via Digitalmars-d-learn

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

2017-02-01 Thread Suliman via Digitalmars-d-learn

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:"

2017-02-01 Thread Suliman via Digitalmars-d-learn
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:"

2017-02-01 Thread Suliman via Digitalmars-d-learn

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:"

2017-02-01 Thread Suliman via Digitalmars-d-learn

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:"

2017-02-01 Thread Suliman via Digitalmars-d-learn

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

2017-02-01 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

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

2017-02-01 Thread osa1 via Digitalmars-d-learn
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

2017-02-01 Thread Ola Fosheim Grøstad via Digitalmars-d-learn

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.