One thing that I really miss from most of the discussions about RC is
support for weak references, which IMO should definitely be supported in
the standard RC implementation. Event if they are only needed rarely,
there are some things that simply do not work without them. And I don't
think they
Maybe I'm missing something, but can't the length just be size_t?
I doubt there is much you could do with code which generates
finite sequences larger than the addressable memory space, aside
from very abstract and inefficient mathematical calculations
which skip over elements. iota would proba
On 02/14/2016 03:08 AM, Sönke Ludwig wrote:
For them to work natively, the lifetime of the allocated memory block
and that of the reference count must be separate.
Not necessarily. C++ makes this work for make_shared by keeping the
memory allocated around (but not the object) until the last we
When I was interested in D some time ago, I believe GC was
aborting the application on allocation failures. Is that still
the case today? I am looking into using D for my new application,
but I need some guarantees that I can at least save some critical
data, when such thing happens, perhaps fr
Since you want such fine grained control, you probably don't want to use
the GC to allocate with.
Take a look at [0].
That should give you the fine grained control you desire.
Most importantly make, makeArray, expandArray, shrinkArray and dispose.
You would need to be a bit careful with some la
On Sunday, 14 February 2016 at 12:10:34 UTC, Jardík wrote:
When I was interested in D some time ago, I believe GC was
aborting the application on allocation failures. Is that still
the case today? I am looking into using D for my new
application, but I need some guarantees that I can at least
On Sunday, 14 February 2016 at 11:14:59 UTC, Andrei Alexandrescu
wrote:
We can do the same, but we also have a better alternative. Most
of our allocators support shrink-in-place. For now I haven't
exposed it as a primitive but that's short work. When the
object goes away we can shrink memory in
On Saturday, 13 February 2016 at 22:42:34 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 13 February 2016 at 21:41:06 UTC, Lars T.
Kyllingstad wrote:
Whose expectations? The formal expectation, as per the C++
standard, is that the moved-from object be left in a "valid
but unspecified state". Ba
On Sunday, 14 February 2016 at 10:59:41 UTC, w0rp wrote:
Maybe I'm missing something, but can't the length just be
size_t? I doubt there is much you could do with code which
generates finite sequences larger than the addressable memory
space, aside from very abstract and inefficient mathematica
On Sunday, 14 February 2016 at 12:53:08 UTC, Lars T. Kyllingstad
wrote:
I know you said afterwards you didn't need a reference, but
I'll give you one anyway. :) That is the formal requirement
for C++ standard library types; see sec. 17.6.5.15
[lib.types.movedfrom] of the C++ specification.
k
On Sunday, 14 February 2016 at 14:12:09 UTC, Ola Fosheim Grøstad
wrote:
You can work around it by having extra pointers/containers in
or held by the struct (pointers to the source that is pointing
to you). But that takes more space.
In the not-multithreaded version. In the multithreaded versio
This may be a pipe dream, but I want to create (with the help of
other developers, of course) a DAW using D.
The reasons are mainly:
+ The design can be very complex
+ Realtime playback is a requirement
+ You can do a lot of things with audio
It would be interesting to see how D could handle a
My current attack plan is:
+ Use SDL2 wrappings in GFM as a base
+ Create helper libraries for mixing etc.
+ Create a simple keyboard-controlled program that uses the
helper libraries to play notes.
After that, a comprehensive design of the actual program should
be created.
That is where your
So here is how I see the current situation.
- Multiple image libraries, no current leader
- Multiple windowing solutions, no current leader
- No audio solutions (atleast reasonably)
I'm currently working on image + windowing for Phobos [0].
Manu Evans is working on color primitives.
Currently no
On 2/13/2016 2:27 AM, Daniel N wrote:
"Abstract
This is the proposed wording for a unified call syntax based on the idea that
f(x,y) can invoke a member function, x.f(y), if there are no f(x,y). The inverse
transformation, from x.f(y) to f(x,y) is not proposed."
They were considering 6 alternati
On Saturday, 13 February 2016 at 10:27:59 UTC, Daniel N wrote:
"Abstract
This is the proposed wording for a unified call syntax based on
the idea that f(x,y) can invoke a member function, x.f(y), if
there are no f(x,y). The inverse transformation, from x.f(y) to
f(x,y) is not proposed."
They
On Monday, 15 February 2016 at 06:12:30 UTC, Walter Bright wrote:
On 2/13/2016 2:27 AM, Daniel N wrote:
"Abstract
This is the proposed wording for a unified call syntax based
on the idea that
f(x,y) can invoke a member function, x.f(y), if there are no
f(x,y). The inverse
transformation, from
17 matches
Mail list logo
