Don:
>Using CTFE will be a completely different experience after the next release.<
What kind of limits do you want to lift? :-)
I think now LDC uses a compile-time garbage collector (beside the second one in
the D runtime and the third one used by LLVM), so using CTFE&templates is
better alrea
Daniel Keep:
> In my own code, I usually record my intent by using "inout" for
> variables I intend to modify and "ref" for ones which I don't.
> Always seemed reasonable to me.
for the compiler they mean the same thing, but inout is being deprecated.
Bye,
bearophile
On Fri, 21 Aug 2009 13:54:38 -0400, div0
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jarrett Billingsley wrote:
On Fri, Aug 21, 2009 at 1:36 PM, div0 wrote:
That's what he's suggesting, and it does make sense. When you write a
template, *either* it's meant to be used as a mixin,
div0 wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ary Borenszweig wrote:
div0 wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jarrett Billingsley wrote:
On Fri, Aug 21, 2009 at 1:36 PM, div0 wrote:
That's what he's suggesting, and it does make sense. When you write a
template,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ary Borenszweig wrote:
> div0 wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Jarrett Billingsley wrote:
>>> On Fri, Aug 21, 2009 at 1:36 PM, div0 wrote:
>>>
>>> That's what he's suggesting, and it does make sense. When you write a
>>
div0 wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jarrett Billingsley wrote:
On Fri, Aug 21, 2009 at 1:36 PM, div0 wrote:
That's what he's suggesting, and it does make sense. When you write a
template, *either* it's meant to be used as a mixin, *or* it's meant
to be used some other wa
On Fri, Aug 21, 2009 at 10:36 AM, div0 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Chad J wrote:
>> Regarding template mixins, I'm curious, why is the decision to mixin a
>> template made at the call site and not at the declaration of the
>> template/mixin?
>>
>> In other words, wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jarrett Billingsley wrote:
> On Fri, Aug 21, 2009 at 1:36 PM, div0 wrote:
>
> That's what he's suggesting, and it does make sense. When you write a
> template, *either* it's meant to be used as a mixin, *or* it's meant
> to be used some other way. Mi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jarrett Billingsley wrote:
> On Fri, Aug 21, 2009 at 11:10 AM, Dan wrote:
>> Is there a way to export static data from a DLL written in D?
>>
>> I'd like to write some extension DLLs for a program, but they need to have
>> certain static data exports
On Fri, Aug 21, 2009 at 1:36 PM, div0 wrote:
> Not sure what the original choice was based on, but what you suggest
> looks wrong to me. You aren't necessarily using a template in order to
> mix it in somewhere.
>
> With that syntax it looks like you can only use foo as a mixin.
That's what he's s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chad J wrote:
> Regarding template mixins, I'm curious, why is the decision to mixin a
> template made at the call site and not at the declaration of the
> template/mixin?
>
> In other words, why do we write
>
> template foo()
> {
>
On Fri, Aug 21, 2009 at 2:47 AM, Lutger wrote:
> The following doesn't compile, I was wondering whether this is a temporary
> limitation, bug or by design?
>
> struct Bar
> {
> int baz;
> }
>
> struct Foo
> {
> Bar bar;
> alias bar.baz this; // error
> }
Problem I would guess is that bar.
On Fri, Aug 21, 2009 at 11:10 AM, Dan wrote:
> Is there a way to export static data from a DLL written in D?
>
> I'd like to write some extension DLLs for a program, but they need to have
> certain static data exports to be recognized. I've been able to export
> functions, but no data appears in
Steven Schveighoffer wrote:
> ...
>
> The issue is possibly with ref. There are two reasons to use ref, 1 is
> to be able to change the data referenced, 2 is for passing speed.
>
> 1 is bad for rvalues. 2 should be ok for rvalues.
>
> If there was a way to signify you only want to use ref fo
Is there a way to export static data from a DLL written in D?
I'd like to write some extension DLLs for a program, but they need to have
certain static data exports to be recognized. I've been able to export
functions, but no data appears in the export table of the DLL.
In MSVC 6 I can do it as
On Fri, 21 Aug 2009 10:42:08 -0400, Daniel Keep
wrote:
Lutger wrote:
By const ref seems reasonable to allow, but by ref is bug prone. Why is
it
handy?
struct Vector4
{
float[4] xyzw;
Vector opAdd(ref Vector rhs);
}
Vector code can be made much faster using ref arguments, but i
Daniel Keep:
>Vector code can be made much faster using ref arguments,<
You are right regarding DMD (that's what I was asking for), but LDC often is
able to inline everything (if the method is short), so using ref leads to the
same (high) performance.
Bye,
bearophile
Lutger wrote:
> By const ref seems reasonable to allow, but by ref is bug prone. Why is it
> handy?
struct Vector4
{
float[4] xyzw;
Vector opAdd(ref Vector rhs);
}
Vector code can be made much faster using ref arguments, but if you use
ref arguments, you can't have anything more compl
Don wrote:
Lars T. Kyllingstad wrote:
Don wrote:
Jarrett Billingsley wrote:
I don't think you can call struct methods at compile-time. Kind of
lame, I know. Try making norm a free function.
Can the D2 compiler modified/improved to allow this?
It sure would be nice.
In fact the D1 compi
Lars T. Kyllingstad wrote:
Don wrote:
Jarrett Billingsley wrote:
I don't think you can call struct methods at compile-time. Kind of
lame, I know. Try making norm a free function.
Can the D2 compiler modified/improved to allow this?
It sure would be nice.
In fact the D1 compiler should s
By const ref seems reasonable to allow, but by ref is bug prone. Why is it
handy?
The following doesn't compile, I was wondering whether this is a temporary
limitation, bug or by design?
struct Bar
{
int baz;
}
struct Foo
{
Bar bar;
alias bar.baz this; // error
}
22 matches
Mail list logo
