Re: equivalent of __attribute__((constructor))
On 2013-05-24 02:02, Ellery Newcomer wrote: posix.mak makes no reference to it Then I guess it's not used. Just compile it manually and link with it. I don't think that D has anything corresponding to __attribute__((constructor)). I also see a problem with adding such feature. It will be run before the runtime is initialized (that's how it works now). Then people will start using it and complain about there code failing in mysterious ways because the runtime isn't initialized. -- /Jacob Carlborg
Re: how to have alias this with an unaccessible member?
This won't do for the same reason: now 'get' is made public so we're back
to the same problem (inverting roles of x and get).
However what about changing the behavior of alias this as follows:
when a member/method x is private, "alias x this" behaves as if x was not
declared private.
I think this makes sense:
* this allows protection (x is an implementation detail) so that 'this'
behaves exactly as 'x'
* also, without this change of behavior, "alias x this" would not make any
sense in terms of behavior outside the class (inside behavior should just
access x directly)
Then, when multiple alias this statements will become allowed in D, we
would have implemented the same concept as "embedding" in GO.
Any thoughts?
here's what we would have:
struct A(T){
private T x would prevent alias this from doing anything useful
alias x this;
}
void main(){
auto a=A!int;
a++;//should do a.x++; //semantic change: even though x is private, all
its methods are un-privated through alias this.
static assert(!__traits(compiles,a.x));
}
On Sat, May 18, 2013 at 1:33 AM, Dicebot wrote:
> Will this do?
>
>
>
>
> struct A(T)
> {
> private T x;
>
> ref T get()
>
> {
> return x;
> }
>
> alias get this;
> }
>
> -
>
Re: equivalent of __attribute__((constructor))
On 05/22/2013 11:18 PM, Jacob Carlborg wrote: On 2013-05-23 06:27, Ellery Newcomer wrote: I don't know if it's automatically linked but here you go: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.c posix.mak makes no reference to it
Re: Templated Function can't deduce function arguments
Thank you for the help. Bug report at http://d.puremagic.com/issues/ show_bug.cgi?id=10156
Re: Why is this code returning the wrong type?
you former private FILE* _file wasn't an File and your current private FILE _file is still not File because FILE and File is something differnt (case sensitive) why not write private File _file Gah! of course. Thanks. I think i better get some sleep...
Re: Why is this code returning the wrong type?
Am 23.05.2013 21:45, schrieb Gary Willoughby:
Hmmm... Following your example i'm still having problems
compiling this simple snippet:
import std.stdio;
class Example
{
private FILE _file;
public this(string file)
{
this._file = File(file, "r");
}
}
Error:
test.d(9): Error: cannot implicitly convert expression ((File
__ctmp1220 = 0;
, __ctmp1220).this(file, "r")) of type File to shared(_iobuf)
you former
private FILE* _file wasn't an File
and your current
private FILE _file is still not File
because FILE and File is something differnt (case sensitive)
why not write
private File _file
Re: Why is this code returning the wrong type?
Hmmm... Following your example i'm still having problems
compiling this simple snippet:
import std.stdio;
class Example
{
private FILE _file;
public this(string file)
{
this._file = File(file, "r");
}
}
Error:
test.d(9): Error: cannot implicitly convert expression ((File
__ctmp1220 = 0;
, __ctmp1220).this(file, "r")) of type File to shared(_iobuf)
Re: Why is this code returning the wrong type?
File is a wrapper around a FILE*, it's not the same as a FILE* No need for new, File is a struct, new is (normally) for classes. No need for "this.", although there's no harm in it. Ah yes, thanks.
Re: Is there anything in the standard library to help writing a file watcher?
Hmmm.. this is what i first thought. I think i'll implement a simple watcher based on modification times as a first iteration. Then if time allows add platform specific solutions based on the above. Thanks.
Re: Is there anything in the standard library to help writing a file watcher?
On 2013-05-23 18:19, David wrote: For Linux you can use inotify http://linux.die.net/man/7/inotify I think the corresponding for Mac OS X is fsevents: http://en.wikipedia.org/wiki/FSEvents -- /Jacob Carlborg
Re: DVM + DMD git-master
On 2013-05-23 19:35, nazriel wrote: Greetings. Does DVM [1] supports building DMD from git-master tree? If yes, how does it name resulting binary? dmd-master? It won't automatically fetch from the git repositories or install but you can build it using DVM. Do something like this: $ mkdir dlang $ cd dlang clone DMD, druntime and Phobos $ dvm compile . You'll get a couple of new folders in dlang/dmd. A bin and lib folder with the architecture appended. -- /Jacob Carlborg
Re: Templated Function can't deduce function arguments
On 05/23/2013 07:21 PM, Jonathan Crapuchettes wrote:
On Wed, 22 May 2013 23:28:21 -0400, Jonathan M Davis wrote:
On Wednesday, May 22, 2013 21:31:53 Steven Schveighoffer wrote:
On Wed, 22 May 2013 21:16:44 -0400, Jonathan Crapuchettes
wrote:
Can anyone tell me why this doesn't compile? Dmd 2.062 says that it
cannot deduce the template function from arguments types.
import std.stdio;
void main()
{
test!(dchar, int)('b', 6, 'a', 54);
}
template test(Types...)
{
void test(T...)(const Types v, const T values...)
Do you need that last elipsis? I thought you didn't, but not sure.
You don't, and I'm surprised that it compiles, since I don't think that
the elipsis is actually legal there. AFAIK, the only time that an
elipsis is legal in the function arguments is with array variadics; e.g.
auto foo(int[] bar...) {...}
- Jonathan M Davis
The last ellipsis was a remnant of testing. Thank you for pointing that
out. Removing it still doesn't help the compiler deduce the argument
types. It appears that the issue has to do with the usage of the "Types"
TypeTuple. If the
const Types v
is swapped out for
const dchar v1, const int v2
the code compiles just fine. This makes me wonder if dmd is not
interpreting the Types TypeTuple correctly in the inner-function.
Jonathan
Yes, this is indeed a compiler bug.
http://d.puremagic.com/issues/
DVM + DMD git-master
Greetings. Does DVM [1] supports building DMD from git-master tree? If yes, how does it name resulting binary? dmd-master? Best regards, Damian Ziemba [1] https://github.com/jacob-carlborg/dvm
Re: Templated Function can't deduce function arguments
On Wed, 22 May 2013 23:28:21 -0400, Jonathan M Davis wrote:
> On Wednesday, May 22, 2013 21:31:53 Steven Schveighoffer wrote:
>> On Wed, 22 May 2013 21:16:44 -0400, Jonathan Crapuchettes
>>
>> wrote:
>> > Can anyone tell me why this doesn't compile? Dmd 2.062 says that it
>> > cannot deduce the template function from arguments types.
>> >
>> > import std.stdio;
>> >
>> > void main()
>> > {
>> >
>> > test!(dchar, int)('b', 6, 'a', 54);
>> >
>> > }
>> >
>> > template test(Types...)
>> > {
>> >
>> > void test(T...)(const Types v, const T values...)
>>
>> Do you need that last elipsis? I thought you didn't, but not sure.
>
> You don't, and I'm surprised that it compiles, since I don't think that
> the elipsis is actually legal there. AFAIK, the only time that an
> elipsis is legal in the function arguments is with array variadics; e.g.
>
> auto foo(int[] bar...) {...}
>
> - Jonathan M Davis
The last ellipsis was a remnant of testing. Thank you for pointing that
out. Removing it still doesn't help the compiler deduce the argument
types. It appears that the issue has to do with the usage of the "Types"
TypeTuple. If the
const Types v
is swapped out for
const dchar v1, const int v2
the code compiles just fine. This makes me wonder if dmd is not
interpreting the Types TypeTuple correctly in the inner-function.
Jonathan
Re: Why is this code returning the wrong type?
On Thursday, 23 May 2013 at 16:27:19 UTC, Gary Willoughby wrote:
Why won't the following code compile? Here's the error:
filewatcher.d(21): Error: cannot implicitly convert expression
(new File(file, "r")) of type File* to shared(_iobuf)*
/**
* Imports.
*/
import std.stdio;
/**
* A class to watch for changes in a file.
*/
class Example
{
/**
* Member variables.
*/
private FILE* _file;
/**
* Constructor.
*/
public this(string file)
{
this._file = new File(file, "r");
}
}
/**
* Imports.
*/
import std.stdio;
/**
* A class to watch for changes in a file.
*/
class Example
{
/**
* Member variables.
*/
private File _file;
/**
* Constructor.
*/
public this(string file)
{
_file = File(file, "r");
}
}
File is a wrapper around a FILE*, it's not the same as a FILE*
No need for new, File is a struct, new is (normally) for classes.
No need for "this.", although there's no harm in it.
Re: Why is this code returning the wrong type?
Am 23.05.2013 18:27, schrieb Gary Willoughby:
> Why won't the following code compile? Here's the error:
>
> filewatcher.d(21): Error: cannot implicitly convert expression (new
> File(file, "r")) of type File* to shared(_iobuf)*
>
> /**
> * Imports.
> */
> import std.stdio;
>
> /**
> * A class to watch for changes in a file.
> */
> class Example
> {
> /**
> * Member variables.
> */
> private FILE* _file;
>
> /**
> * Constructor.
> */
> public this(string file)
> {
> this._file = new File(file, "r");
> }
> }
Because that's not the same: File != FILE
you probably want the .handle
Why is this code returning the wrong type?
Why won't the following code compile? Here's the error:
filewatcher.d(21): Error: cannot implicitly convert expression
(new File(file, "r")) of type File* to shared(_iobuf)*
/**
* Imports.
*/
import std.stdio;
/**
* A class to watch for changes in a file.
*/
class Example
{
/**
* Member variables.
*/
private FILE* _file;
/**
* Constructor.
*/
public this(string file)
{
this._file = new File(file, "r");
}
}
Re: Is there anything in the standard library to help writing a file watcher?
Am 23.05.2013 17:35, schrieb Benjamin Thaut: > Am 23.05.2013 17:26, schrieb Gary Willoughby: >> Is there anything in the standard library to help writing a file >> watcher? I want to monitor a single file for changes and if a change is >> detected call a function. Is there any existing libraries to do this in >> D as it must be cross-platform as much as possible? > > I have something like this implemented for windows. It watches a entire > directory including subdirectories (optional) and tells you which files > changed upon request: > > https://github.com/Ingrater/thBase/blob/master/src/thBase/directory.d > > I don't think its possible to imiplement this cross-plattform. You will > have to reimplement for every plattform you need it on. > > Kind Regards > Benjamin Thaut For Linux you can use inotify http://linux.die.net/man/7/inotify
Re: Is there anything in the standard library to help writing a file watcher?
Am 23.05.2013 17:26, schrieb Gary Willoughby: Is there anything in the standard library to help writing a file watcher? I want to monitor a single file for changes and if a change is detected call a function. Is there any existing libraries to do this in D as it must be cross-platform as much as possible? I have something like this implemented for windows. It watches a entire directory including subdirectories (optional) and tells you which files changed upon request: https://github.com/Ingrater/thBase/blob/master/src/thBase/directory.d I don't think its possible to imiplement this cross-plattform. You will have to reimplement for every plattform you need it on. Kind Regards Benjamin Thaut
Is there anything in the standard library to help writing a file watcher?
Is there anything in the standard library to help writing a file watcher? I want to monitor a single file for changes and if a change is detected call a function. Is there any existing libraries to do this in D as it must be cross-platform as much as possible?
Re: Copy instead of reference?
On 05/23/13 14:30, Namespace wrote: > On Thursday, 23 May 2013 at 12:29:04 UTC, Artur Skawina wrote: >> On 05/23/13 13:57, Namespace wrote: >>> I know that D has (sadly) no C++ references, but I still think that >>> >>> A a = some_existing_A; >>> >>> should call opAssign. >> >> Not opAssign, but user-defined copy-constructor. But D does not have >> them either... > > That would be a solution. They are required anyway, for several reasons. Right now, you /can/ do: A a = A(some_existing_A); but, because 'A a = some_existing_A' will bypass your cpctor and call the postblit, it's too dangerous. Unless you mark the latter as @disabled, which of course causes other problems. artur
Re: Copy instead of reference?
On Thursday, 23 May 2013 at 12:29:04 UTC, Artur Skawina wrote: On 05/23/13 13:57, Namespace wrote: I know that D has (sadly) no C++ references, but I still think that A a = some_existing_A; should call opAssign. Not opAssign, but user-defined copy-constructor. But D does not have them either... artur That would be a solution.
Re: Copy instead of reference?
On 05/23/13 13:57, Namespace wrote: > I know that D has (sadly) no C++ references, but I still think that > > A a = some_existing_A; > > should call opAssign. Not opAssign, but user-defined copy-constructor. But D does not have them either... artur
Re: Copy instead of reference?
On Thursday, 23 May 2013 at 12:07:40 UTC, Maxim Fomin wrote: On Thursday, 23 May 2013 at 11:57:04 UTC, Namespace wrote: I know that D has (sadly) no C++ references, but I still think that A a = some_existing_A; should call opAssign. Now I see what has you confused. Whether postblit or opAssign is called, depend on left, not right side of assignment. Object 'a' didn't exists prior, so postblit is called, and copy ctor is called with respect of 'a' as 'this' argument. What had confused me, was the point, that it doesn't matter if you return by value or by ref, you get the same output for this specific case. That did not feel right. But thanks to you.
Re: Copy instead of reference?
On Thursday, 23 May 2013 at 11:57:04 UTC, Namespace wrote: I know that D has (sadly) no C++ references, but I still think that A a = some_existing_A; should call opAssign. Actually, it is similar to C++ : http://codepad.org/lkPMU1Ne
Re: Copy instead of reference?
On Thursday, 23 May 2013 at 11:57:04 UTC, Namespace wrote: I know that D has (sadly) no C++ references, but I still think that A a = some_existing_A; should call opAssign. Now I see what has you confused. Whether postblit or opAssign is called, depend on left, not right side of assignment. Object 'a' didn't exists prior, so postblit is called, and copy ctor is called with respect of 'a' as 'this' argument.
Re: Copy instead of reference?
And if I do this: A a; a = b.getA(); I get what I want. What a spasm...
Re: Copy instead of reference?
I know that D has (sadly) no C++ references, but I still think that A a = some_existing_A; should call opAssign.
Re: Copy instead of reference?
On 05/23/13 13:34, Namespace wrote: > A a = b.getA(); > Postblit, no opAssign call. > You're constructing, not assigning. Try reassigning 'a' to see opAssign in action. It's a bit unintuitive and easy to miss - which I did too, hence my misleading first reply - sorry. The issue is that D has no ref vars, so you can't really keep the returned refs around, other than passing them to another func. artur
Re: Copy instead of reference?
To be more detailed:
I'd expected that the code with 'getA' without ref
[code]
A getA() {
writeln("Return A");
return this._a;
}
[/code]
would print this output:
CTor 42
opAssign R 42
DTor 42
Return A
Postblit 42
opAssign R 84
DTor 84
DTor 42
And with 'getA' with ref
[code]
ref A getA() {
writeln("Return A");
return this._a;
}
[/code]
would print this output:
CTor 42
opAssign R 42
DTor 42
Return A
opAssign L 42
DTor 42
DTor 42
Re: Copy instead of reference?
On Thursday, 23 May 2013 at 11:31:19 UTC, Simen Kjaeraas wrote:
On Thu, 23 May 2013 13:29:49 +0200, Namespace
wrote:
That was what I also expected. But opAssign is not called.
Because you have a postblit. It's called instead of opAssign.
[code]
import std.stdio;
import std.c.string : memcpy;
struct A {
public:
int id;
this(int id) {
writeln("CTor ", id);
this.id = id;
}
this(this) {
writeln("Postblit ", this.id);
this.id *= 2;
}
void opAssign(ref const A a) {
writeln("opAssign L: ", a.id);
this.id = a.id;
}
void opAssign(const A a) {
writeln("opAssign R ", a.id);
memcpy(&this, &a, A.sizeof);
}
~this() {
writeln("DTor ", this.id);
}
}
class B {
private:
A _a;
public:
this() {
this._a = A(42);
}
ref A getA() {
writeln("Return A");
return this._a;
}
}
void main() {
B b = new B();
A a = b.getA();
}
[/code]
Output:
CTor 42
opAssign R 42
DTor 42
Return A
Postblit 42
DTor 84
DTor 42
Postblit, no opAssign call.
Re: Copy instead of reference?
On Thu, 23 May 2013 13:29:49 +0200, Namespace wrote: That was what I also expected. But opAssign is not called. Because you have a postblit. It's called instead of opAssign. -- Simen
Re: Copy instead of reference?
That was what I also expected. But opAssign is not called.
Re: Copy instead of reference?
On 05/23/13 11:47, Namespace wrote:
> I get this output:
>
>
>
>
> CTor 42
> DTor 0
> Return A
> Postblit 42
>
> DTor 84
> DTor 42
>
>
>
> with the following code. I'm a bit confused about the Postblit. I return by
> ref so I thought that I get a const ref of the original A.
> ref const(A) getA() const {
> writeln("Return A");
> return this._a;
> }
> A a = b.getA();
You do, but you then assign to another 'A'...
artur
Re: Copy instead of reference?
I've filled a bug report.
Re: Copy instead of reference?
Forget to say: I use dmd 2.062.
Copy instead of reference?
I get this output:
CTor 42
DTor 0
Return A
Postblit 42
DTor 84
DTor 42
with the following code. I'm a bit confused about the Postblit. I
return by ref so I thought that I get a const ref of the original
A.
[code]
import std.stdio;
struct A {
public:
int id;
this(int id) {
writeln("CTor ", id);
this.id = id;
}
this(this) {
writeln("Postblit ", this.id);
this.id *= 2;
}
~this() {
writeln("DTor ", this.id);
}
}
class B {
private:
A _a = void;
public:
this() {
this._a = A(42);
}
ref const(A) getA() const {
writeln("Return A");
return this._a;
}
}
void main() {
writeln("");
B b = new B();
A a = b.getA();
writeln("");
}
[/code]
Re: WindowProc in a class - function and pointer problem
On Thursday, 23 May 2013 at 06:31:02 UTC, Sean Cavanaugh wrote: I had a partial port of WTL over to D which worked well enough for what I needed, the core of the WndProc handling is down below. Each HWND is owned by the thread it was created on, so assigning it into D associative array (which is thread local) can do the trick. It involved a hack, before any call to the Win32 CreateWindow/CreateWindowEx APIs, to capture the association with the new HWND and to remove them when they get cleaned up. There is probably a better way but this worked enough to get started, and should work with multiple windows reasonably well. sure this is doable but it breaks the entire idea of oop. this is also can be put as static member, still it would break oop. that link i put here is show what is really needed, and it's clean and simple. simply there is only 2 required methods, one for creating(and binding) hwnd with class instance and another to retrieve that instance and do its own message handling, no other code necessary and everything incapsulated. but i don't remember if it works without gc messed up that instance while not falling to such tricks like arrays(because it is may be possible that gc collect instance while window is alive).
