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 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
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() {
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
On 11/02/2013 16:06, Regan Heath wrote:
On Sun, 10 Feb 2013 12:36:38 -, Ben Davis ent...@cantab.net 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
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
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 corrective action listed
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 lParam2) nothrow
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/issues/show_bug.cgi?id=3956
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 09/02/2013 20:44, Andrej Mitrovic wrote:
On 2/9/13, Ben Davis ent...@cantab.net 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 all
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 also got all
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
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 wrote:
Hi
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;
}
void
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
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*'. Or, if you
forget the , then it will infer
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
18 matches
Mail list logo
