Re: @nogc vs IAllocator

2016-07-17 Thread Chris Wright via Digitalmars-d
nogc code" > 2) a standard OOP solution, very DOM style, but then I have to say > "Phobos provides a full DOM Level 3 implementation that does not use the > GC, but cannot be marked @nogc; if you don't trust me, check the > profiler" With templates, you have XmlParser!I

Re: @nogc vs IAllocator

2016-07-16 Thread The D dude via Digitalmars-d
On Saturday, 16 July 2016 at 17:46:12 UTC, Lodovico Giaretta wrote: Background: working on a replacement for std.xml. Designing the DOM API. [...] Another problem that you soon will encounter is that your templated can never be @safe, nothrow or pure again - even if you use the GCAllocator

Re: @nogc vs IAllocator

2016-07-16 Thread Dicebot via Digitalmars-d
Oops, this looks like dark side of XML spec I wish I have never learned about :X Sorry for irrelevant comment.

Re: @nogc vs IAllocator

2016-07-16 Thread Lodovico Giaretta via Digitalmars-d
On Saturday, 16 July 2016 at 18:34:31 UTC, Dicebot wrote: What kind of features do you mean? I'd personally want only compile-time configuration and minimal to no OOP. Thank you for your time. The DOM specification provides "DOM features"[1] as a mean to extend the DOM with custom informations

Re: @nogc vs IAllocator

2016-07-16 Thread Dicebot via Digitalmars-d
What kind of features do you mean? I'd personally want only compile-time configuration and minimal to no OOP.

Re: @nogc vs IAllocator

2016-07-16 Thread Lodovico Giaretta via Digitalmars-d
And of course I forgot to link the relevant documentation... [1] https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html I have no idea why anyone would prefer IAllocator approach to efficient and inline-able template based version. I doubt template bloat from dozens of different

Re: @nogc vs IAllocator

2016-07-16 Thread Dicebot via Digitalmars-d
I have no idea why anyone would prefer IAllocator approach to efficient and inline-able template based version. I doubt template bloat from dozens of different allocators in one project is realistic concern for std.xml

@nogc vs IAllocator

2016-07-16 Thread Lodovico Giaretta via Digitalmars-d
tor is quite complex and ugly. The "standard DOM way" of dealing with any additional thing (as is the allocator selection) is to use hasFeature/getFeature; this are standard OOP interface methods, so the work very very well with IAllocator, thus allowing an easy, straightforward solut

Re: IAllocator

2016-01-04 Thread Andrei Alexandrescu via Digitalmars-d
On 01/03/2016 11:50 PM, Rikki Cattermole wrote: On 04/01/16 11:44 AM, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=15509 is up. Any takers? -- Andrei Now I'm worried, this will break a lot of my code. May break if you use the IAllocator type explicitly a lot; you

Re: IAllocator

2016-01-03 Thread Rikki Cattermole via Digitalmars-d
On 04/01/16 11:44 AM, Andrei Alexandrescu wrote: https://issues.dlang.org/show_bug.cgi?id=15509 is up. Any takers? -- Andrei Now I'm worried, this will break a lot of my code. I'm just not convinced that RefCounted is the correct tool for this job. It changes the allocator type. IAl

IAllocator

2016-01-03 Thread Andrei Alexandrescu via Digitalmars-d
https://issues.dlang.org/show_bug.cgi?id=15509 is up. Any takers? -- Andrei