Mike S:
> I figured the eager ones wouldn't be a problem, but I wondered whether
> the lazy ones might be a pain. Guess not, so cool. :)
Lazy ones are just a struct/class instance that contains an opApply method (or
that follows the Range protocol methods). Very easy.
> As far as D3 goes tho
On Thu, 01 Apr 2010 11:01:38 -0400, Mike S
wrote:
I suppose the abstraction makes it a QOI though, so depending on the
compiler and GC used in the future it could become a question again. As
it stands, I'm less interested in its precise current state and more
interested in keeping an ey
Mike S wrote:
bearophile wrote:
How difficult do you think that would be for the compiler devs to
implement in the semantic sense? Assuming it can be done without
major hardship or compromising the design of the language, that would
be really cool.<
They are easy to implement. Even the lazy
Steven Schveighoffer wrote:
Its abstracted to the GC, but the current GC is well defined. If you
request to allocate blocks with length of a power of 2 under a page, you
will get exactly that length, all the way down to 16 bytes. If you
request to allocate a page or greater, you get a contigu
bearophile wrote:
How difficult do you think that would be for the compiler devs to implement in the
semantic sense? Assuming it can be done without major hardship or compromising
the design of the language, that would be really cool.<
They are easy to implement. Even the lazy ones. See Shed
On Thu, 01 Apr 2010 01:41:02 -0400, Mike S
wrote:
Steven Schveighoffer wrote:
> What do you mean by nondeterministic? It's very deterministic, just
not
always easy to determine ;) However, given enough context, it's really
easy to determine.
When I say deterministic, I'm referring t
Mike S:
>Well, writing code Java-style is certainly no problem for game devs,<
Right. Here I was talking about D uses more in general, sorry, like young
programmers coming out of the university.
>it'll still be a long time before someone actually starts from scratch to
>write a new kernel usi
Steven Schveighoffer wrote:
> What do you mean by nondeterministic? It's very deterministic, just
not
always easy to determine ;) However, given enough context, it's really
easy to determine.
When I say deterministic, I'm referring to determinism from the user's
point of view, where the al
On Wed, 31 Mar 2010 17:57:07 -0400, Mike S
wrote:
Steven Schveighoffer wrote:
You are correct, setCapacity ensures that *at least* the given number
of elements will be available for appending.
I planned on making the function a property (but a bug would not allow
that), the original int
bearophile wrote:
The short D1 history shows that designers of small games are willing to use D.
Some game designers seem almost desperate to find an usable language simpler
than C++. So I agree with you that D2 can be designed keeping an eye at game
designers too. But that's very demanding pe
Mike S:
>the needs of game programmers should be taken seriously while considering D's
>evolution:<
The short D1 history shows that designers of small games are willing to use D.
Some game designers seem almost desperate to find an usable language simpler
than C++. So I agree with you that D2
bearophile wrote:
Mike S:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
It's a nice read. I don't see them switching to D soon. If you whisper them
that D is based on a GC they will run away screaming :-)
Bye,
bearophile
Hah...well, there's a reason I'm still just look
Mike S:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
It's a nice read. I don't see them switching to D soon. If you whisper them
that D is based on a GC they will run away screaming :-)
Bye,
bearophile
Steven Schveighoffer wrote:
You are correct, setCapacity ensures that *at least* the given number of
elements will be available for appending.
I planned on making the function a property (but a bug would not allow
that), the original intended usage was:
a.capacity = 1;
Reserve doesn't
On Thu, 04 Mar 2010 13:38:30 -0500, grauzone wrote:
Steven Schveighoffer wrote:
So it probably should be marked as unsafe.
Doesn't it conform to Andrei's ideas about memory safety? It can stomp
over other data, but it can't be used to subvert the type system.
I think the idea is that a
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 12:43:32 -0500, grauzone wrote:
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but
enabling to reuse the old memory would be nice:
int[] a = data;
a =
On Thu, 04 Mar 2010 12:43:32 -0500, grauzone wrote:
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but enabling
to reuse the old memory would be nice:
int[] a = data;
a = null;
a ~= 1; //reallocates
On Thu, 04 Mar 2010 12:29:25 -0500, Clemens wrote:
Steven Schveighoffer Wrote:
int[] a;
a.setCapacity(1); // pre-allocate at least 1 elements.
I would prefer the name reserve(). It has precedent in the STL, and the
method doesn't actually always set the capacity, only if the curre
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but enabling
to reuse the old memory would be nice:
int[] a = data;
a = null;
a ~= 1; //reallocates (of course)
a.length = 0;
a ~= 1; //will reallocate (fo
Steven Schveighoffer Wrote:
> int[] a;
> a.setCapacity(1); // pre-allocate at least 1 elements.
I would prefer the name reserve(). It has precedent in the STL, and the method
doesn't actually always set the capacity, only if the current capacity is less
then the argument. Even then it m
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but enabling to
reuse the old memory would be nice:
int[] a = data;
a = null;
a ~= 1; //reallocates (of course)
a.length = 0;
a ~= 1; //will reallocate (for safety), used not to reall
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 04:02:46 -0500, KF wrote:
I hope this is the right place to post it.
In my work, I often need to add elements at the end of dynamic arrays
and remove them from the end. This incremental changes would most
conveniently be performed by a~=e for ad
On Thu, 04 Mar 2010 04:02:46 -0500, KF wrote:
I hope this is the right place to post it.
In my work, I often need to add elements at the end of dynamic arrays
and remove them from the end. This incremental changes would most
conveniently be performed by a~=e for addition of e at the end of a,
I hope this is the right place to post it.
In my work, I often need to add elements at the end of dynamic arrays and
remove them from the end. This incremental changes would most
conveniently be performed by a~=e for addition of e at the end of a, and say
a=a[0..$-1]. Unfortunately, ~= always cre
24 matches
Mail list logo
