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 ru
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 thi
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
Thank you for the help. Bug report at http://d.puremagic.com/issues/
show_bug.cgi?id=10156
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...
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");
}
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 implicitl
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.
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.
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
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 dl
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
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
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
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
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
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
{
/**
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
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
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?
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 us
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 eit
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
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 opAss
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
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.
And if I do this:
A a;
a = b.getA();
I get what I want. What a spasm...
I know that D has (sadly) no C++ references, but I still think
that
A a = some_existing_A;
should call opAssign.
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 ha
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 4
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 : memc
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
That was what I also expected. But opAssign is not called.
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
I've filled a bug report.
Forget to say: I use dmd 2.062.
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;
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 (whi
38 matches
Mail list logo
