On Friday, 12 February 2016 at 14:03:05 UTC, Steven Schveighoffer
wrote:
On 2/10/16 11:51 PM, Matt Elkins wrote:
* The in keyword. This is nice syntactic sugar over having a
special
trait in C++ which deduces whether to pass by value or
const-reference.
"foo(in bar)" is way more readable
On 2/12/16 9:37 AM, Matt Elkins wrote:
On Friday, 12 February 2016 at 14:03:05 UTC, Steven Schveighoffer wrote:
On 2/10/16 11:51 PM, Matt Elkins wrote:
* The in keyword. This is nice syntactic sugar over having a special
trait in C++ which deduces whether to pass by value or const-reference.
On 2/10/16 11:51 PM, Matt Elkins wrote:
* The in keyword. This is nice syntactic sugar over having a special
trait in C++ which deduces whether to pass by value or const-reference.
"foo(in bar)" is way more readable than something like
"foo(traits::fast_param bar)"
Hm... in is short for scope
On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
On Friday, 12 February 2016 at 15:12:19 UTC, Steven
Schveighoffer wrote:
On 2/12/16 9:37 AM, Matt Elkins wrote:
[...]
Pass by reference and pass by value means different treatment
inside the function itself, so it can't differ from
On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
note that 'in' and 'scope'(other than for delegates) parameter
storage class usage should be avoided.
It really should be a warning.
Add to docs!
On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer
wrote:
It could potentially differ based on the type being passed,
Yes, that's what I meant.
but I'm unaware of such an optimization,
Hm. Unfortunate.
and it definitely isn't triggered specifically by 'in'. 'in' is
On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer
wrote:
On 2/12/16 9:37 AM, Matt Elkins wrote:
[...]
Pass by reference and pass by value means different treatment
inside the function itself, so it can't differ from call to
call. It could potentially differ based on the type
On Friday, 12 February 2016 at 15:12:19 UTC, Steven Schveighoffer
wrote:
but I'm unaware of such an optimization, and it definitely
isn't triggered specifically by 'in'. 'in' is literally
replaced with 'scope const' when it is a storage class.
-Steve
I'd imagine GCC or LLVM may be able to
On Friday, 12 February 2016 at 17:29:54 UTC, Matt Elkins wrote:
On Friday, 12 February 2016 at 17:20:23 UTC, rsw0x wrote:
On Friday, 12 February 2016 at 15:12:19 UTC, Steven
Schveighoffer wrote:
On 2/12/16 9:37 AM, Matt Elkins wrote:
[...]
Pass by reference and pass by value means different
On Thursday, 11 February 2016 at 04:51:39 UTC, Matt Elkins wrote:
- Syntactic sugars (associtive arrays, powerful foreach,
slices...)
I'm still adjusting to the idea of AAs as part of the language
rather than library. Not sure I like it, but on the other hand
it doesn't really hurt. The
On Wednesday, 10 February 2016 at 20:21:22 UTC, Chris Wright
wrote:
On Wed, 10 Feb 2016 08:57:51 +, thedeemon wrote:
Currently (at least last time I checked) GC pauses the world,
then does all the marking in one thread, then all the sweeping.
Right.
We can do the
marking in several
On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
There are several reasons I want to use D rather than C# / Go /
something else:
I will focus on comparing against C++, because that has been my
favorite general purpose language for a long time. While I often
have to use C, Java, C#,
On Thursday, 11 February 2016 at 05:05:22 UTC, tsbockman wrote:
On Thursday, 11 February 2016 at 04:51:39 UTC, Matt Elkins
wrote:
- Syntactic sugars (associtive arrays, powerful foreach,
slices...)
I'm still adjusting to the idea of AAs as part of the language
rather than library. Not sure I
On Tuesday, 9 February 2016 at 17:41:34 UTC, NX wrote:
I would want it to be solved rather than being worked on...
which requires design change which is probably not going to
happen. There is still room for improvement though.
Right. I think there are at least two things that can improve
On Tuesday, 9 February 2016 at 13:01:29 UTC, NX wrote:
On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote:
The GC itself may still be far from perfect but its much
better than it was, and there are more options now. I have
found emsi containers (built on top of Andrei's
On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
There are several reasons I want to use D rather than C# / Go /
something else:
- Interfacing with native API without jumping through hoops
Well, but the hoops are there to get safe and fast GC.
- Incredibly high abstraction and
On Tuesday, 9 February 2016 at 13:01:29 UTC, NX wrote:
Well, GC being better than it used to be doesn't change the
fact it's still the > worst of it's kind. I don't know if
this[1] work actually got released or merged but looks like
it's abandoned. Pretty sad as it seemed very promising.
[1]
On Monday, 8 February 2016 at 17:51:02 UTC, Ola Fosheim Grøstad
wrote:
C++ compilers have lots of optional warnings/errors, so it is
quite possible. But I suppose those that want it would rather
use Go, C# or some other GC language than can do ahead of time
compilation.
There are several
On Monday, 8 February 2016 at 22:21:50 UTC, Laeeth Isharc wrote:
The GC itself may still be far from perfect but its much better
than it was, and there are more options now. I have found emsi
containers (built on top of Andrei's allocator) pretty nice
myself for my own use.
Well, GC being
On Tue, 09 Feb 2016 14:35:48 +, Ola Fosheim Grøstad wrote:
> On Tuesday, 9 February 2016 at 13:41:30 UTC, NX wrote:
>> There are several reasons I want to use D rather than C# / Go /
>> something else:
>> - Interfacing with native API without jumping through hoops
>
> Well, but the hoops are
On Tuesday, 9 February 2016 at 14:35:48 UTC, Ola Fosheim Grøstad
wrote:
Not incredibly high level abstraction... But I get what you
mean. It is fairly high level for a low level language.
Coming from C#, it looks amazing but probably not that incredible
when coming from C++.
So you want
On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC
implementations?
Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent
On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote:
http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
Well, the latest Intel CPUs have a theoretical throughput of
30GB/s... so that makes for up to 30MB/ms.
But language changes are needed, I think.
I also
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC
implementations?
Unions and easy type casting prevent precise GC.
Lack of write barriers for reference-type fields prevent fast
(generational and/or concurrent) GC. Some more detailed
On Mon, 08 Feb 2016 11:22:45 +, thedeemon wrote:
> On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
>> What language semantics prevent precise & fast GC implementations?
>
> easy type casting prevent precise GC.
To expand on this point:
A GC makes a tradeoff between allocating
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
Maybe we could. But it's never going to happen. Even if
Walter weren't fundamentally opposed to multiple pointer types
in D, it wouldn't happen.
You asked about things that prevent improvement, right? Here's
the big one, and a major
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
I see... By any chance, can we solve this issue with GC
managed pointers?
Maybe we could. But it's never going to happen. Even if
Walter weren't fundamentally opposed to
On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
I see... By any chance, can we solve this issue with GC managed
pointers?
Maybe we could. But it's never going to happen. Even if Walter
weren't fundamentally opposed to multiple pointer types in D, it
wouldn't happen.
You asked
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote:
On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote:
I see... By any chance, can we solve this issue with GC
managed pointers?
Maybe we could. But it's never going to happen. Even if
Walter weren't fundamentally opposed to
On Sunday, 7 February 2016 at 02:46:39 UTC, Marco Leise wrote:
My code would not see much ref counting in performance critical
loops. There is no point in ref counting every single point in
a complex 3D scene.
I could imagine it used on bigger items. Textures for example
since they may be used
On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad
wrote:
This prevents fast GC: Pointers.
Would it be possible to write a fast garbage collector that just
didn't track any pointers? Just offer a head's up that if you use
"this collector" and pointers on collectable data,
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise & fast GC
implementations?
This prevents fast GC: Pointers.
This prevents precise GC: internal Pointers + FFI.
Go now has <10ms latency for small heaps, <20ms latency for up to
100GB heaps and
On Saturday, 6 February 2016 at 15:14:06 UTC, Kagamin wrote:
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise
Lack of resources. Precise GC needs to know which fields are
pointers. Somebody must generate that map. AFAIK there was an
experiment
On Saturday, 6 February 2016 at 17:46:48 UTC, rsw0x wrote:
On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote:
Can't be done with the root class because classes never
trigger RAII outside of (deprecated) scope
On Saturday, 6 February 2016 at 17:46:00 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote:
Can't be done with the root class because classes never
trigger RAII outside of (deprecated) scope allocations.
Not sure what you mean. The class instance
On Saturday, 6 February 2016 at 17:38:30 UTC, rsw0x wrote:
Can't be done with the root class because classes never trigger
RAII outside of (deprecated) scope allocations.
Not sure what you mean. The class instance doesn't have to
trigger anything?
You "retain(instance)" to increase the
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad
wrote:
Nothing prevents you from creating your own reference counting
mechanism.
A struct wrapper doesn't give the things you need to reliably
handle inheritance.
interface A {}
interface B {}
class C : A, B {}
void
On Saturday, 6 February 2016 at 17:46:48 UTC, rsw0x wrote:
Might as well manually free and delete instead.
Not really, this was used in Objective-C before ARC.
But you can always move retain/release/borrow/unborrow into your
own pointer struct like shared_ptr.
On Saturday, 6 February 2016 at 17:36:28 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe
wrote:
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim
Grøstad wrote:
Nothing prevents you from creating your own reference
counting mechanism.
A
On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe wrote:
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim
Grøstad wrote:
Nothing prevents you from creating your own reference counting
mechanism.
A struct wrapper doesn't give the things you need to reliably
handle
Am Sat, 06 Feb 2016 11:47:02 +
schrieb Ola Fosheim Grøstad
:
> Of course, Swift does not aim for very high performance, but for
> convenient application/gui development. And frankly JavaScript is
> fast enough for that kind of programming.
My code would
Am Sat, 06 Feb 2016 23:18:59 +
schrieb Ola Fosheim Grøstad
:
> Things that could speed up collection:
> - drop destructors so you don't track dead objects
Interesting, that would also finally force external resources
off the GC heap and into deterministic
On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad
wrote:
What makes it impossible to have ref counted classes?
Nothing.
Then why do we need DIP74 ? And why documentation says RefCounted
doesn't work with classes?
So I came here to ask about things that prevent D to become
better.
What language semantics prevent precise & fast GC implementations?
What makes it impossible to have ref counted classes?
What are some other technical / design problems you encountered?
(other than poor implementation and
On Saturday, 6 February 2016 at 11:33:05 UTC, rsw0x wrote:
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim
Grøstad wrote:
reference counting is incredibly slow, DIP74 attempts to
partially amend that in D as it can't be done any other way
besides compiler help.
IIRC, it essentially
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
What language semantics prevent precise
Lack of resources. Precise GC needs to know which fields are
pointers. Somebody must generate that map. AFAIK there was an
experiment on that.
fast GC
Fast GC needs to be notified about
On Saturday, 6 February 2016 at 11:09:28 UTC, NX wrote:
On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim
Grøstad wrote:
What makes it impossible to have ref counted classes?
Nothing.
Then why do we need DIP74 ?
I think they aim for compiler optimizations, like ARC on Swift.
But
On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 6 February 2016 at 11:09:28 UTC, NX wrote:
On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim
Grøstad wrote:
What makes it impossible to have ref counted classes?
Nothing.
Then why do we need DIP74
48 matches
Mail list logo