replace() doesn't work in CTFE anymore cause it was modified to be based on
Appender.
According to klickverbot, other phobos functions share that fate.
I think something should be done about this. Couldn't Appender be implemented
without using a pointer to a struct?
Trass3r:
> I think something should be done about this. Couldn't Appender be implemented
> without using a pointer to a struct?
There's no need for this, there is __ctfe (that thanks to fixing bug 4177 is
usable in pure functions too), that allows to create two paths inside the
Appender, one f
Am 03.03.2011 14:12, schrieb bearophile:
Trass3r:
I think something should be done about this. Couldn't Appender be implemented
without using a pointer to a struct?
There's no need for this, there is __ctfe (that thanks to fixing bug 4177 is
usable in pure functions too), that allows to cr
On Thu, 03 Mar 2011 07:41:49 -0500, Trass3r wrote:
replace() doesn't work in CTFE anymore cause it was modified to be based
on Appender.
According to klickverbot, other phobos functions share that fate.
I think something should be done about this. Couldn't Appender be
implemented without u
On 2011-03-03 14:12, bearophile wrote:
Trass3r:
I think something should be done about this. Couldn't Appender be implemented
without using a pointer to a struct?
There's no need for this, there is __ctfe (that thanks to fixing bug 4177 is
usable in pure functions too), that allows to creat
On Thu, 03 Mar 2011 10:28:00 -0500, Jacob Carlborg wrote:
On 2011-03-03 14:12, bearophile wrote:
Trass3r:
I think something should be done about this. Couldn't Appender be
implemented without using a pointer to a struct?
There's no need for this, there is __ctfe (that thanks to fixing bug
On 3/3/11 4:28 PM, Jacob Carlborg wrote:
So much for the "having the same implementation for the compile time
function and the runtime function".
Well, that's exactly what __ctfe allows for in this case – optimizing a
small section of the code for performance using runtime-only stuff,
while s
On 3/3/11 8:34 AM, Steven Schveighoffer wrote:
On Thu, 03 Mar 2011 07:41:49 -0500, Trass3r wrote:
replace() doesn't work in CTFE anymore cause it was modified to be
based on Appender.
According to klickverbot, other phobos functions share that fate.
I think something should be done about this
On 2011-03-03 16:35, Steven Schveighoffer wrote:
On Thu, 03 Mar 2011 10:28:00 -0500, Jacob Carlborg wrote:
On 2011-03-03 14:12, bearophile wrote:
Trass3r:
I think something should be done about this. Couldn't Appender be
implemented without using a pointer to a struct?
There's no need for
On 3/3/11 10:05 AM, Jacob Carlborg wrote:
On 2011-03-03 16:35, Steven Schveighoffer wrote:
On Thu, 03 Mar 2011 10:28:00 -0500, Jacob Carlborg wrote:
On 2011-03-03 14:12, bearophile wrote:
Trass3r:
I think something should be done about this. Couldn't Appender be
implemented without using a
On Thu, 03 Mar 2011 11:03:31 -0500, Andrei Alexandrescu
wrote:
On 3/3/11 8:34 AM, Steven Schveighoffer wrote:
On Thu, 03 Mar 2011 07:41:49 -0500, Trass3r wrote:
replace() doesn't work in CTFE anymore cause it was modified to be
based on Appender.
According to klickverbot, other phobos fun
On 03/03/2011 05:03 PM, Andrei Alexandrescu wrote:
On 3/3/11 8:34 AM, Steven Schveighoffer wrote:
On Thu, 03 Mar 2011 07:41:49 -0500, Trass3r wrote:
replace() doesn't work in CTFE anymore cause it was modified to be
based on Appender.
According to klickverbot, other phobos functions share tha
On Thu, 03 Mar 2011 11:19:12 -0500, Steven Schveighoffer
wrote:
Using trivial benchmarks, I found Appender is about 5x faster than ~=.
code attached if anyone is interested.
-Steve
testappender.d
Description: Binary data
On Thu, 03 Mar 2011 11:22:00 -0500, spir wrote:
On 03/03/2011 05:03 PM, Andrei Alexandrescu wrote:
On 3/3/11 8:34 AM, Steven Schveighoffer wrote:
On Thu, 03 Mar 2011 07:41:49 -0500, Trass3r wrote:
replace() doesn't work in CTFE anymore cause it was modified to be
based on Appender.
Accordi
On Thu, 03 Mar 2011 11:20:44 -0500, Steven Schveighoffer
wrote:
On Thu, 03 Mar 2011 11:19:12 -0500, Steven Schveighoffer
wrote:
Using trivial benchmarks, I found Appender is about 5x faster than ~=.
code attached if anyone is interested.
err... you can comment out the assert and sanity
Even without performance issue, Appender is necessary because it
configures output range.
Currently std.array.put does not allow empty array as its argument.
int[] arr = [];
arr.put(1); // invalid. this does not means appending.
Therefore building an array its length is not known beforehand
requ
On 3/3/11 10:54 AM, kenji hara wrote:
Even without performance issue, Appender is necessary because it
configures output range.
Currently std.array.put does not allow empty array as its argument.
int[] arr = [];
arr.put(1); // invalid. this does not means appending.
Therefore building an array
On Thu, 03 Mar 2011 11:54:58 -0500, kenji hara wrote:
Even without performance issue, Appender is necessary because it
configures output range.
Currently std.array.put does not allow empty array as its argument.
int[] arr = [];
arr.put(1); // invalid. this does not means appending.
Therefore
I'm sorry my point was irrelevant.
Kenji
2011/3/4 Steven Schveighoffer :
> On Thu, 03 Mar 2011 11:54:58 -0500, kenji hara wrote:
>
>> Even without performance issue, Appender is necessary because it
>> configures output range.
>>
>> Currently std.array.put does not allow empty array as its argum
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> I see nothing wrong with the occasional forking conditioned by __ctfe.
> Even today, code may fork an optimized but nonportable implementation of
> some algorithm. The main requirement is that such forks are rare enough
>
Am 04.03.2011 09:51, schrieb Kevin Bealer:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
I see nothing wrong with the occasional forking conditioned by __ctfe.
Even today, code may fork an optimized but nonportable implementation of
some algorithm. The main requi
21 matches
Mail list logo
