On Tuesday, 18 October 2016 at 10:35:44 UTC, Nordlöw wrote:
On Monday, 2 May 2016 at 17:43:56 UTC, Namespace wrote:
immutable auto a = [1,2,3].s;
Will that have zero run-time overhead compared to:
immutable int[3] a = [1,2,3];
?
I'm not quite sure if pragma(inline, true) would result
On 10/18/16 6:35 AM, Nordlöw wrote:
On Monday, 2 May 2016 at 17:43:56 UTC, Namespace wrote:
immutable auto a = [1,2,3].s;
Will that have zero run-time overhead compared to:
immutable int[3] a = [1,2,3];
Neither will have zero runtime overhead, but use the disassembler to see
if there
On Monday, 2 May 2016 at 17:43:56 UTC, Namespace wrote:
immutable auto a = [1,2,3].s;
Will that have zero run-time overhead compared to:
immutable int[3] a = [1,2,3];
?
On Monday, 2 May 2016 at 17:43:56 UTC, Namespace wrote:
I still like
auto s(T, size_t n)(T[n] arr) {
return arr;
}
Wooah, this trick is awesome. But actually it does the same thing
that what I've proposed before. Exactly the same code is
generated. So I'd say that it's rather a
On 5/2/16 4:14 PM, Namespace wrote:
I used it very often, but always assigned the result to an auto-type
variable, never to a slice.
Using auto is fine, but the slice should not happen if you are assigning
slice to a local var. There is a bug report on this:
https://issues.dlang.org/show_bug
On Monday, 2 May 2016 at 20:05:15 UTC, Steven Schveighoffer wrote:
On 5/2/16 3:38 PM, Namespace wrote:
The assembler might be safe in some instances, but that
doesn't
reflect the original internal representation in the compiler.
Some
other configuration of calls may allow the compiler to reuse
On 5/2/16 3:38 PM, Namespace wrote:
The assembler might be safe in some instances, but that doesn't
reflect the original internal representation in the compiler. Some
other configuration of calls may allow the compiler to reuse that
memory, and then you run into problems.
I'm wondering if you us
The assembler might be safe in some instances, but that doesn't
reflect the original internal representation in the compiler.
Some other configuration of calls may allow the compiler to
reuse that memory, and then you run into problems.
I'm wondering if you used my rewrite if it would actually
On 5/2/16 3:12 PM, Namespace wrote:
On Monday, 2 May 2016 at 19:08:52 UTC, Steven Schveighoffer wrote:
On 5/2/16 3:02 PM, Namespace wrote:
On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
A slice of a no-longer-existing temporary! Admittedly, this is not an
issue with your code, but a d
On Monday, 2 May 2016 at 19:08:52 UTC, Steven Schveighoffer wrote:
On 5/2/16 3:02 PM, Namespace wrote:
On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
A slice of a no-longer-existing temporary! Admittedly, this
is not an
issue with your code, but a deeper issue of allowing slicing
of r
On 5/2/16 3:02 PM, Namespace wrote:
On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
A slice of a no-longer-existing temporary! Admittedly, this is not an
issue with your code, but a deeper issue of allowing slicing of rvalues.
This works:
int[] as = [1, 2, 3].s;
writeln(as[2]);
O
A slice of a no-longer-existing temporary! Admittedly, this is
not an issue with your code, but a deeper issue of allowing
slicing of rvalues.
This works:
int[] as = [1, 2, 3].s;
writeln(as[2]);
Bug or feature? Or did I may misunderstood you?
You can drop auto. It's just a placeholder
On Monday, 2 May 2016 at 18:57:49 UTC, Namespace wrote:
A slice of a no-longer-existing temporary! Admittedly, this is
not an issue with your code, but a deeper issue of allowing
slicing of rvalues.
This works:
int[] as = [1, 2, 3].s;
writeln(as[2]);
Of course this slice is only valid as
On 5/2/16 1:43 PM, Namespace wrote:
On Monday, 2 May 2016 at 13:00:27 UTC, Erik Smith wrote:
Is there a way to initialize a static array and have it's size
inferred (and that works for arrays of structs using braced
literals)? This would make it easier to maintain longer static array
definition
On Monday, 2 May 2016 at 13:00:27 UTC, Erik Smith wrote:
Is there a way to initialize a static array and have it's size
inferred (and that works for arrays of structs using braced
literals)? This would make it easier to maintain longer static
array definitions. The code below doesn't work whe
I tried to combine the two solutions (Basile with the wrapper,
Marco with the struct initializer support) but it didn't work.
The struct initializer is not a array literal (seems obvious
now). I might go with the 2nd but it's pretty heavy just to get
the size.
Thanks.
struct S {
int a
Am Mon, 2 May 2016 18:52:11 +0200
schrieb ag0aep6g :
> On 02.05.2016 15:53, Marco Leise wrote:
> >immutable tab = { static enum S[] s = [
>
> `static enum`? What kind of black magic is this?
I don't know, but it works, haha.
--
Marco
On 02.05.2016 15:53, Marco Leise wrote:
immutable tab = { static enum S[] s = [
`static enum`? What kind of black magic is this?
Am Mon, 02 May 2016 13:00:27 +
schrieb Erik Smith :
> Is there a way to initialize a static array and have it's size
> inferred (and that works for arrays of structs using braced
> literals)? This would make it easier to maintain longer static
> array definitions. The code below doesn't w
On Monday, 2 May 2016 at 13:22:01 UTC, Basile B wrote:
On Monday, 2 May 2016 at 13:00:27 UTC, Erik Smith wrote:
Is there a way to initialize a static array and have it's size
inferred (and that works for arrays of structs using braced
literals)? This would make it easier to maintain longer
st
On Monday, 2 May 2016 at 13:00:27 UTC, Erik Smith wrote:
Is there a way to initialize a static array and have it's size
inferred (and that works for arrays of structs using braced
literals)? This would make it easier to maintain longer static
array definitions. The code below doesn't work whe
21 matches
Mail list logo
