On 2013-05-23 06:27, Ellery Newcomer wrote:
In the context of shared libraries, with gcc
__attribute__((constructor))
void myfunc() { .. }
is used to make myfunc be called upon loading of the shared library (you
can tell I know what I am talking about here) via some field in the ELF
headers,
On 5/22/2013 8:49 PM, evilrat wrote:
On Wednesday, 22 May 2013 at 21:42:32 UTC, D-sturbed wrote:
Yes I'm in the multiple Window case, every window is wraped in a
class and has its own message handler. I know that Win, in its
callback system, often lets you retrieve a pointer to something, and
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
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;
Forget to say: I use dmd 2.062.
I've filled a bug report.
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
That was what I also expected. But opAssign is not called.
On Thu, 23 May 2013 13:29:49 +0200, Namespace rswhi...@googlemail.com
wrote:
That was what I also expected. But opAssign is not called.
Because you have a postblit. It's called instead of opAssign.
--
Simen
On Thursday, 23 May 2013 at 11:31:19 UTC, Simen Kjaeraas wrote:
On Thu, 23 May 2013 13:29:49 +0200, Namespace
rswhi...@googlemail.com 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;
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
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
I know that D has (sadly) no C++ references, but I still think
that
A a = some_existing_A;
should call opAssign.
And if I do this:
A a;
a = b.getA();
I get what I want. What a spasm...
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.
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 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
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: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
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
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?
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
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
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 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
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
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
jcrapuchet...@gmail.com wrote:
Can anyone tell me why this doesn't compile? Dmd 2.062 says that it
cannot
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 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
jcrapuchet...@gmail.com wrote:
Can anyone tell me why
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
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
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.
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... 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
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);
}
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...
Thank you for the help. Bug report at http://d.puremagic.com/issues/
show_bug.cgi?id=10156
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
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
39 matches
Mail list logo
