On 2/26/15 11:56 AM, Andrei Alexandrescu wrote:
On 2/26/15 8:44 AM, Steven Schveighoffer wrote:
On 2/24/15 3:03 PM, Andrei Alexandrescu wrote:
On 2/24/15 11:55 AM, Steven Schveighoffer wrote:
Note, you need to GC.addRange all the elements if the type has
references, or else you cannot have GC
On 2/26/15 8:44 AM, Steven Schveighoffer wrote:
On 2/24/15 3:03 PM, Andrei Alexandrescu wrote:
On 2/24/15 11:55 AM, Steven Schveighoffer wrote:
Note, you need to GC.addRange all the elements if the type has
references, or else you cannot have GC pointers in the array. For
example, an array of c
On 2/24/15 3:03 PM, Andrei Alexandrescu wrote:
On 2/24/15 11:55 AM, Steven Schveighoffer wrote:
Note, you need to GC.addRange all the elements if the type has
references, or else you cannot have GC pointers in the array. For
example, an array of class references could potentially result in those
Wednesday, 25 February 2015 at 20:01:51 UTC, Andrei Alexandrescu
wrote:
On 2/25/15 11:04 AM, Ivan Timokhin wrote:
OK, thank you. I wasn't asking about DIP25 in particular (I
think I
understand what it's about), but about your (and Walter's)
plans on
the topic in general.
The medium-term pla
On 2/25/15 11:04 AM, Ivan Timokhin wrote:
OK, thank you. I wasn't asking about DIP25 in particular (I think I
understand what it's about), but about your (and Walter's) plans on
the topic in general.
The medium-term plan is two-pronged: (a) immediately apply DIP25 to
http://wiki.dlang.org/?tit
On Wed, Feb 25, 2015 at 08:06:48AM -0800, Andrei Alexandrescu wrote:
> On 2/25/15 1:58 AM, Ivan Timokhin wrote:
> > Oh. So, whenever you pass a reference-counted slice around, you need to do
> > it with the full inc/dec protocol, which, as Walter has mentioned several
> > times already, leads to co
On 2/25/15 1:58 AM, Ivan Timokhin wrote:
Oh. So, whenever you pass a reference-counted slice around, you need to do
it with the full inc/dec protocol, which, as Walter has mentioned several
times already, leads to code bloat and performance hits. So... no to
efficient reference counting? Also, no
On Tuesday, 24 February 2015 at 22:11:36 UTC, Andrei Alexandrescu
wrote:
On 2/24/15 1:55 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
" wrote:
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei
Alexandrescu wrote:
So: does DIP25 allow safe slices? Looks that way
I believe it does, but at the cost of
Andrei Alexandrescu wrote:
> On 2/24/15 1:33 PM, Ivan Timokhin wrote:
>> Is there any plan to allow safe conversions to T[] (in restricted
>> circumstances, of course)?
>
> We'd want to avoid it because that would necessitate the whole "scope"
> paraphernalia - e.g you can convert a reference cou
On 2/24/2015 4:41 PM, deadalnix wrote:
Why ? There is very little chance that malloc + GC.addRange becomes any faster
that GC.malloc in the first place.
1. GC is designed to do GC, which is more than malloc/free is designed to do.
Less work usually is faster.
2. There are many malloc/free im
On Wednesday, 25 February 2015 at 00:11:28 UTC, Walter Bright
wrote:
Generally using malloc is not the right way forward. I do
think that, even for
RCed resource, we want them backed by the GC. It will allow
for cycle
collection.
If cycles are not possible, malloc/free should be used. Cycles
On 2/24/2015 2:45 PM, deadalnix wrote:
Using malloc make the GC blind. It means you can't stored anything GCed in this.
GC.addRange() solves this problem.
Generally using malloc is not the right way forward. I do think that, even for
RCed resource, we want them backed by the GC. It will allo
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu
wrote:
I modified Walter's sample code to this:
http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the
array and the reference count, and also uses @trusted
minimally. I inserted assert()s here and there to clarify the
On 2/24/15 1:55 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= "
wrote:
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu wrote:
So: does DIP25 allow safe slices? Looks that way
I believe it does, but at the cost of forced reference counting. As I
pointed out, the `ref` solution
What is
On 2/24/15 1:33 PM, Ivan Timokhin wrote:
Is there any plan to allow safe conversions to T[] (in restricted
circumstances, of course)?
We'd want to avoid it because that would necessitate the whole "scope"
paraphernalia - e.g you can convert a reference counted slice to
something like scope(T[
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu
wrote:
So: does DIP25 allow safe slices? Looks that way
I believe it does, but at the cost of forced reference counting.
As I pointed out, the `ref` solution is not applicable to slices,
therefore it needs to return an RCArray.
On Tuesday, 24 February 2015 at 20:46:28 UTC, H. S. Teoh wrote:
On Tue, Feb 24, 2015 at 08:21:53PM +, ketmar via
Digitalmars-d wrote:
On Tue, 24 Feb 2015 20:11:17 +, weaselcat wrote:
> On Tuesday, 24 February 2015 at 20:04:27 UTC, Andrei
> Alexandrescu wrote:
>> On 2/24/15 12:03 PM, w
On Tue, 24 Feb 2015 21:13:42 +, weaselcat wrote:
> Working with C++ after using D does leave one feeling... disillusioned.
that's why i'm not even considering c++ for writing new code anymore.
either D, or good old C, if D is not appropriate.
actually, i haven't written a line of c++ for se
On Tue, Feb 24, 2015 at 09:13:42PM +, weaselcat via Digitalmars-d wrote:
> On Tuesday, 24 February 2015 at 20:46:28 UTC, H. S. Teoh wrote:
[...]
> >Yep, that's exactly why D has ruined my life, I just can't go back to
> that C++ garbage anymore.
>
> Working with C++ after using D does leave on
Andrei Alexandrescu wrote:
> I modified Walter's sample code to this:
> http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the array
> and the reference count, and also uses @trusted minimally. I inserted
> assert()s here and there to clarify the workings. Nothing big except for
> the car
On 2/24/2015 11:55 AM, Steven Schveighoffer wrote:
Note, you need to GC.addRange all the elements if the type has references, or
else you cannot have GC pointers in the array.
Yes. I deliberately left that out in order to keep attention focused on the use
of 'return ref'.
Ironically, if th
On Tuesday, 24 February 2015 at 20:46:28 UTC, H. S. Teoh wrote:
http://bartoszmilewski.com/2013/09/19/edward-chands/
I'm not generally one to read comments on blogs, but the replies
to that blog are jawdropping.
I have to assume most of these people are either new to C++ or
are being
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu
wrote:
I modified Walter's sample code to this:
http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the
array and the reference count, and also uses @trusted
minimally. I inserted assert()s here and there to clarify the
On Tue, Feb 24, 2015 at 08:21:53PM +, ketmar via Digitalmars-d wrote:
> On Tue, 24 Feb 2015 20:11:17 +, weaselcat wrote:
>
> > On Tuesday, 24 February 2015 at 20:04:27 UTC, Andrei Alexandrescu wrote:
> >> On 2/24/15 12:03 PM, weaselcat wrote:
> >>> On Tuesday, 24 February 2015 at 19:40:35
On Tue, 24 Feb 2015 20:11:17 +, weaselcat wrote:
> On Tuesday, 24 February 2015 at 20:04:27 UTC, Andrei Alexandrescu wrote:
>> On 2/24/15 12:03 PM, weaselcat wrote:
>>> On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu
>>> wrote:
...
>>>
>>> Off-topic, sorry Are we still g
On Tue, 24 Feb 2015 12:03:36 -0800, Andrei Alexandrescu wrote:
> On 2/24/15 11:55 AM, Steven Schveighoffer wrote:
>> Note, you need to GC.addRange all the elements if the type has
>> references, or else you cannot have GC pointers in the array. For
>> example, an array of class references could po
On Tuesday, 24 February 2015 at 20:04:27 UTC, Andrei Alexandrescu
wrote:
On 2/24/15 12:03 PM, weaselcat wrote:
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei
Alexandrescu wrote:
...
Off-topic, sorry
Are we still going to get a Trusted block, or just going to
use trusted
lambdas?(They'
On Tue, 24 Feb 2015 14:55:14 -0500, Steven Schveighoffer wrote:
> Note, you need to GC.addRange all the elements if the type has
> references, or else you cannot have GC pointers in the array. For
> example, an array of class references could potentially result in those
> references being collecte
On 2/24/15 12:03 PM, weaselcat wrote:
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu wrote:
...
Off-topic, sorry
Are we still going to get a Trusted block, or just going to use trusted
lambdas?(They're kind of ugly TBH)
We're going to lambdas. Ugliness is a feature.
But
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu
wrote:
...
Off-topic, sorry
Are we still going to get a Trusted block, or just going to use
trusted lambdas?(They're kind of ugly TBH)
But I was bummed that e.g. I found no way to call emplace()
@safe-ly.
I assumed emplace
On Tue, 24 Feb 2015 11:40:34 -0800, Andrei Alexandrescu wrote:
> 3. opIndex ("here's the magic") is the most interesting part of the
> proposal. It disallows unsafe use such as:
>
> @safe ref int fun()
> {
> auto a = RCArray!int([1, 2, 3]);
> return a[1];
> }
this is the important part f
On 2/24/15 11:55 AM, Steven Schveighoffer wrote:
Note, you need to GC.addRange all the elements if the type has
references, or else you cannot have GC pointers in the array. For
example, an array of class references could potentially result in those
references being collected before the array is
On 2/24/15 2:40 PM, Andrei Alexandrescu wrote:
I modified Walter's sample code to this:
http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the array
and the reference count, and also uses @trusted minimally. I inserted
assert()s here and there to clarify the workings. Nothing big except
I modified Walter's sample code to this:
http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the array
and the reference count, and also uses @trusted minimally. I inserted
assert()s here and there to clarify the workings. Nothing big except for
the careful use of @trusted.
I'll use t
34 matches
Mail list logo
