On 26/02/2013 06:21, Charles Hixson wrote:
On 02/24/2013 05:39 PM, H. S. Teoh wrote:
On Sun, Feb 24, 2013 at 03:14:01PM -0800, Charles Hixson wrote:
Given a struct with:
~this()
{ close();}
voidclose()
{ if(currentKey !is null)currentKey=null;
if(cursor is nu
On 26/02/2013 18:41, bearophile wrote:
Kenji Hara:
auto return is a little different with others. To infer return type,
the method body is aggressively analyzed in compilation.
So that usage of "auto" sounds like something to avoid if you want D
compiler to compile quickly a lot of code.
I
On 18/02/2013 21:25, Michael wrote:
Yes, it's comes from C#.
So, there is no static for classes at module level. Good to have a msg
for it at compile-time.
import std.stdio;
public final abstract class Test
{
static this() { writeln("in static ctor"); }
static :
void foo() { writ
On 17/02/2013 22:25, Jonathan M Davis wrote:
On Sunday, February 17, 2013 23:00:19 Michael wrote:
That's not the meaning of static in that context.
As I understand a static class can't be instantiated.
I have no idea how you came to that conclusion.
In fairness, it is the natural guess you
On 16/02/2013 15:19, Jacob Carlborg wrote:
On 2013-02-16 15:13, Ben Davis wrote:
As for 'volatile', there's some info at
http://dlang.org/deprecate.html#volatile about how it used to be
available for marking statements as 'do not optimise field accesses'.
The correcti
On 16/02/2013 03:54, Charles Hixson wrote:
Does D have an equivalent to the C marking of volatile?
Currently I'm just going to try removing all variables from the struct,
as it's never declared in D or accessed from within D, and I just want
to avoid cast(void*)s, but I may need to access someth
On 11/02/2013 16:06, Regan Heath wrote:
On Sun, 10 Feb 2013 12:36:38 -, Ben Davis wrote:
DllMain is a weird one - it creates all sorts of linker errors if I
try it with extern(C) instead of extern(Windows) (which is different
from the other methods, which compile fine with extern(C) and
On 10/02/2013 14:11, Ben Davis wrote:
Which would imply the bug was fixed at some point.
...though of course it would need verifying with the example actually
quoted in the bug, since there may be subtle differences. (Hopefully I'm
just stating the obvious.)
On 10/02/2013 12:39, Benjamin Thaut wrote:
Am 10.02.2013 13:36, schrieb Ben Davis:
With the def, I get lines like "DriverProc = _DriverProc@20".
Without it, I get lines like "_DriverProc@20 = _DriverProc@20".
Then you did hit this 3 year old bug:
http://d.puremagic.com/is
On 10/02/2013 08:17, Benjamin Thaut wrote:
Am 10.02.2013 03:03, schrieb Ben Davis:
My functions are "export extern (Windows)" - I think they're global...?
For example:
export extern(Windows) LRESULT DriverProc(DWORD_PTR dwDriverId, HDRVR
hdrvr, UINT msg, LONG lParam1, LONG l
On 09/02/2013 20:39, Benjamin Thaut wrote:
Am 09.02.2013 21:35, schrieb Ben Davis:
Hi,
I'm working on a multimedia driver DLL, i.e. one that Windows loads on
behalf of any program that uses the Windows multimedia API.
I'm using a .def file with an EXPORTS section, and I've a
On 09/02/2013 20:44, Andrej Mitrovic wrote:
On 2/9/13, Ben Davis wrote:
Hi,
I'm working on a multimedia driver DLL, i.e. one that Windows loads on
behalf of any program that uses the Windows multimedia API.
I'm using a .def file with an EXPORTS section, and I've also got a
Hi,
I'm working on a multimedia driver DLL, i.e. one that Windows loads on
behalf of any program that uses the Windows multimedia API.
I'm using a .def file with an EXPORTS section, and I've also got all the
relevant functions marked as 'export' in the code.
What I'm finding is, if I remove
Never mind, I found the answer in the 'templates' page of the spec:
class Super {
T doStuff(this T)() { ...; return cast(T)this; }
}
Sub x = (new Sub()).doStuff();
It seems a bit of a shame that I need the cast, but it's a small thing :)
On 15/09/2012 22:53, Ben Davis wro
Hi,
Is it possible in D to achieve this effect:
class Super {
typeof(this) doStuff() { ...; return this; }
}
class Sub : Super {
//doStuff is NOT explicitly overridden here
}
Sub x = (new Sub()).doStuff();
The last line doesn't compile because doStuff() returns Super. Is there
a way to m
If you had a "const lazy SomeClass con" and a "lazy SomeClass mut", you
could write "mut.x=y" but not "con.x=y". I think.
On 11/01/2012 04:46, bearophile wrote:
I ask here first before submitting about this to Bugzilla.
If lazy arguments can't be lvalues:
void foo(lazy int x) {
x = x;
}
I also meant to say: 80x25? Epic :D
On 08/01/2012 20:25, Ben Davis wrote:
There are two things going on in your example:
1. Use of 'auto' where I'm currently having to write 'MapTile*' and
wanted to write 'ref MapTile'. It will infer 'MapTile*'
There are two things going on in your example:
1. Use of 'auto' where I'm currently having to write 'MapTile*' and
wanted to write 'ref MapTile'. It will infer 'MapTile*'. Or, if you
forget the &, then it will infer 'MapTile' and do the copy that I want
to avoid. So it might be slightly more e
Hi,
Is there a reason 'ref' is disallowed for local variables? I want to
write something like:
MapTile[] map; // It's a struct
ref MapTile tile=map[y*w+x];
tile.id=something;
tile.isWall=true;
My actual case is more complicated, so inlining the expression
everywhere would be messy. I can't
19 matches
Mail list logo
