Am 24.10.2011, 03:57 Uhr, schrieb Sean Silva :
For example, if you look in the LLVM source tree, you'll see that they
bend over backwards to avoid heap allocations. For example, in some
cases, std::vector causes too much heap traffic so they have
SmallVector which preallocates a certain amount o
Am 23.10.2011, 06:04 Uhr, schrieb Jonathan M Davis :
I'd have to go digging through the newsgroup archives to give all of the
reasons but it basically comes down to the fact that people very rarely
want
to pass containers by value, and the fact that C++ makes it so that the
default behavior o
Sean Silva:
> in some
> cases, std::vector causes too much heap traffic so they have
> SmallVector which preallocates a certain amount of storage *inside* of
> the object itself in order to avoid heap traffic if the number of
> elements doesn't exceed some predetermined amount.
I expect Phobos to
On 24.10.2011 5:57, Sean Silva wrote:
== Quote from Dmitry Olshansky (dmitry.o...@gmail.com)'s article
Less efficient is a moot point.
When you do iteration and other stuff you'd use range, like you'd
use
iterators in c++. Range gets stack/register allocated pointers
directly
to data (or clo
== Quote from Dmitry Olshansky (dmitry.o...@gmail.com)'s article
> Less efficient is a moot point.
> When you do iteration and other stuff you'd use range, like you'd
use
> iterators in c++. Range gets stack/register allocated pointers
directly
> to data (or close to it, that depends on container)
On 23.10.2011 7:25, Sean Silva wrote:
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
On Sunday, October 23, 2011 00:01:42 Sean Silva wrote:
They're all supposed to be reference types.
What prompted the decision for that? Doesn't that incur an extra heap
allocation for the
cont
On Sunday, October 23, 2011 03:25:48 Sean Silva wrote:
> == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
>
> > On Sunday, October 23, 2011 00:01:42 Sean Silva wrote:
> > They're all supposed to be reference types.
>
> What prompted the decision for that? Doesn't that incur an extra
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> On Sunday, October 23, 2011 00:01:42 Sean Silva wrote:
> They're all supposed to be reference types.
What prompted the decision for that? Doesn't that incur an extra heap
allocation for the
containers, and an extra level of indirect
On Sunday, October 23, 2011 00:01:42 Sean Silva wrote:
> == Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
>
> > On Saturday, October 22, 2011 17:04:57 Sean Silva wrote:
> > The main planned changes that I'm aware of are to
> > 1. Make all containers final classes (Array and SList are
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> On Saturday, October 22, 2011 17:04:57 Sean Silva wrote:
> The main planned changes that I'm aware of are to
> 1. Make all containers final classes (Array and SList are currently
reference-
> counted structs).
What is the rationale f
On Saturday, October 22, 2011 17:04:57 Sean Silva wrote:
> I don't doubt anything that you just said. But as you said, Phobos
> *currently* doesn't have what I want, which is an issue if I am
> wanting to develop code now or soon. The path of least resistance in
> the interim is to just implement s
== Quote from Jonathan M Davis (jmdavisp...@gmx.com)'s article
> The built-in sort on arrays is going away. std.algorithm.sort should
be used
> instead. I'm afraid that I don't understand what your comments on
the STL have
> to do with the GC though. And stuff in Phobos (such as
std.algorithm) is v
On Saturday, October 22, 2011 04:12:36 Sean Silva wrote:
> > You _can_ use D with no to minimal GC, but you have to be very careful.
> > A good chunk of the standard library would be completely unusable
> > without the GC (primarily anything which might allocate or append to an
> > array), you have
> You _can_ use D with no to minimal GC, but you have to be very careful. A good
> chunk of the standard library would be completely unusable without the GC
> (primarily anything which might allocate or append to an array), you have to
> be very careful when using arrays (since appending to them wo
On Saturday, October 22, 2011 01:20:05 Sean Silva wrote:
> == Quote from Trass3r (u...@known.com)'s article
>
> > Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva
>
> :
> > > == Quote from Jesse Phillips (jessekphillip...@gmail.com)'s
>
> article
>
> > >> Right now D isn't ready to be used in this
== Quote from Trass3r (u...@known.com)'s article
> Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva
:
> > == Quote from Jesse Phillips (jessekphillip...@gmail.com)'s
article
> >> Right now D isn't ready to be used in this fashion
> >
> > It looks there's a more-or-less functional kernel written in D
(a
On 2011-10-20 00:59, Trass3r wrote:
Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva :
== Quote from Jesse Phillips (jessekphillip...@gmail.com)'s article
Right now D isn't ready to be used in this fashion
It looks there's a more-or-less functional kernel written in D (and
pretty well documented
Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva :
== Quote from Jesse Phillips (jessekphillip...@gmail.com)'s article
Right now D isn't ready to be used in this fashion
It looks there's a more-or-less functional kernel written in D (and
pretty well documented too):
http://wiki.xomb.org/index.php?
== Quote from Jesse Phillips (jessekphillip...@gmail.com)'s article
> Right now D isn't ready to be used in this fashion
It looks there's a more-or-less functional kernel written in D (and
pretty well documented too):
http://wiki.xomb.org/index.php?title=Main_Page
Sean Silva Wrote:
> I have just finished reading Alexandrescu's The D Programming Language, but it
> doesn't seem to talk at all about how to use D as a stand-in for C/C++ almost
> at
> all. E.g., the part of D that doesn't depend on a runtime or garbage
> collector.
There isn't any real docume
On 2011-10-18 12:50, Trass3r wrote:
ahead = n._next;
The C/C++ equivalent of this is `ahead = n->next;`, or equivalently
`ahead = (*n).next;`. This is a difference in semantics from C/C++
with respect to the `.`---it seems like D turns pointer to struct
property accesses into property access wit
ahead = n._next;
The C/C++ equivalent of this is `ahead = n->next;`, or equivalently
`ahead = (*n).next;`. This is a difference in semantics from C/C++ with
respect to the `.`---it seems like D turns pointer to struct property
accesses into property access with indirection.
Yes. It w
I have just finished reading Alexandrescu's The D Programming Language, but it
doesn't seem to talk at all about how to use D as a stand-in for C/C++ almost at
all. E.g., the part of D that doesn't depend on a runtime or garbage collector.
It's not that I have anything against those niceties---it
23 matches
Mail list logo