Am 23.10.2011, 06:04 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:
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
Am 24.10.2011, 03:57 Uhr, schrieb Sean Silva chisophu...@gmail.com:
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
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
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 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
== 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) so
== 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
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 some
== 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 for
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 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
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 heap
== Quote from Trass3r (u...@known.com)'s article
Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva
chisophu...@gmail.com:
== 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
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
chisophu...@gmail.com:
== Quote from Jesse Phillips (jessekphillip...@gmail.com)'s
article
Right now D isn't ready to be used in
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
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 to be
On 2011-10-20 00:59, Trass3r wrote:
Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva chisophu...@gmail.com:
== 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
== 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
Am 20.10.2011, 00:06 Uhr, schrieb Sean Silva chisophu...@gmail.com:
== 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):
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
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
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
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
