Re: Low-overhead components

2013-07-28 Thread Kagamin
For a hashtable to know about its container is probably more wasteful than having a pointer to the allocator. If you don't like deep nesting, write a shortcut function, which will do the entire job for you similar to the read function: http://dlang.org/phobos/std_file.html#.read

Re: "body" keyword is unnecessary

2013-07-28 Thread Vlad
Hate to reopen old threads.. but I didn't find another one on this topic. Supposing someone wants to implement a browser in D. And his bindings to JavaScript need to expose HTMLDocument.body property. Is that a use case that would work for allowing body not to be a keyword? -- Vlad

Re: Low-overhead components

2013-07-28 Thread Andrei Alexandrescu
On 7/27/13 11:20 PM, Vladimir Panteleev wrote: Not really an article or anything - this was planned as just a post to this newsgroup, but I decided to put it somewhere suitable for larger blocks of text with formatting: http://blog.thecybershadow.net/2013/07/28/low-overhead-components/ Nice! A

Re: Strict aliasing in D

2013-07-28 Thread deadalnix
On Saturday, 27 July 2013 at 09:03:57 UTC, monarch_dodra wrote: On Saturday, 27 July 2013 at 08:58:22 UTC, Walter Bright wrote: On 7/27/2013 1:08 AM, monarch_dodra wrote: 1. Does strict aliasing apply to slices? I don't know what you mean. double d; uint* p = cast(int*)&d; //unsafe aliasing

Re: Low-overhead components

2013-07-28 Thread Kagamin
BTW, there's no fast way to boundcheck two-ptr range. It should work similar to opSlice: T opIndex(size_t index) { static if (CHECKED) assert(index < end-ptr); return *(ptr + index); }

Proposal for pull request review process

2013-07-28 Thread Joseph Rushton Wakeling
Hi all, I originally posted this idea in the course of a thread in D.announce but thought I'd put it here so that more people can pitch in. It's generally recognized that the reviewing and merging pull requests is one of the major bottlenecks in D's development process. My own experience submitt

Re: Low-overhead components

2013-07-28 Thread Vladimir Panteleev
On Sunday, 28 July 2013 at 12:31:46 UTC, Kagamin wrote: For a hashtable to know about its container is probably more wasteful than having a pointer to the allocator. Why? The difference is one indirection. Are you referring to the impact of template bloat and code cache misses? If you don't

buildPath() and absolute paths

2013-07-28 Thread Lars T. Kyllingstad
Currently, std.path.buildPath() is designed so that if one of the path segments is rooted, then the preceding segments are simply dropped. That is, assert(buildPath("foo", "bar", "/baz") == "/baz"); The only reason I wrote it like this is that this was how the old (now deprecated and remov

Re: buildPath() and absolute paths

2013-07-28 Thread Jonathan M Davis
On Sunday, July 28, 2013 23:09:53 Lars T. Kyllingstad wrote: > Currently, std.path.buildPath() is designed so that if one of the path > segments is rooted, then the preceding segments are simply dropped. > That is, > > assert(buildPath("foo", "bar", "/baz") == "/baz"); > > The only reason I w

Re: Low-overhead components

2013-07-28 Thread Vladimir Panteleev
On Sunday, 28 July 2013 at 18:51:15 UTC, Kagamin wrote: BTW, there's no fast way to boundcheck two-ptr range. It should work similar to opSlice: T opIndex(size_t index) { static if (CHECKED) assert(index < end-ptr); return *(ptr + index); } That's a bug, thanks. But non-release-build

Re: buildPath() and absolute paths

2013-07-28 Thread Vladimir Panteleev
On Sunday, 28 July 2013 at 21:09:55 UTC, Lars T. Kyllingstad wrote: Currently, std.path.buildPath() is designed so that if one of the path segments is rooted, then the preceding segments are simply dropped. That is, assert(buildPath("foo", "bar", "/baz") == "/baz"); The only reason I wrote

Re: Strict aliasing in D

2013-07-28 Thread Denis Shelomovskij
27.07.2013 12:59, Walter Bright пишет: On 7/27/2013 1:57 AM, David Nadlinger wrote: On Saturday, 27 July 2013 at 06:58:04 UTC, Walter Bright wrote: Although it isn't in the spec, D should be "strict aliasing". This is because: 1. it enables better code generation 2. there are ways, such as un