On 3/5/15 8:50 AM, monarch_dodra wrote:
Still, you shouldn't need end, and bounds checking would just
work.
Correct. -- Andrei
On Thursday, 5 March 2015 at 15:20:47 UTC, monarch_dodra wrote:
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright
wrote:
private:
E[] array;
size_t start, end;
int* count;
What is the point of keeping start/end? Aren't those baked into
the array slice? Not storing start
On Thursday, 5 March 2015 at 16:19:09 UTC, Marc Schütz wrote:
On Thursday, 5 March 2015 at 15:20:47 UTC, monarch_dodra wrote:
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright
wrote:
private:
E[] array;
size_t start, end;
int* count;
What is the point of keeping start/end?
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
private:
E[] array;
size_t start, end;
int* count;
What is the point of keeping start/end? Aren't those baked into
the array slice? Not storing start end means not having to do
index arithmetic (minor), reducing
On Wednesday, 4 March 2015 at 17:12:38 UTC, Steven Schveighoffer
wrote:
No tiring like it is to have to explain obvious details to a
child.
Safety system is only partially proactive in a sense it doesn't
cover all possible scenarios, of one finds a bug, he provides an
example, illustrating
On Wednesday, 4 March 2015 at 15:39:43 UTC, Steven Schveighoffer
wrote:
Wow, you really aren't getting it. I give up, it's tiring.
Tiring? Did it take that much effort to not say what you mean?
On 3/4/15 2:26 AM, Kagamin wrote:
On Tuesday, 3 March 2015 at 18:38:11 UTC, Steven Schveighoffer wrote:
int *myglobal;
repeat same code, but access what myglobal points to instead of
setting to 42. Memory corruption is what @safe code is trying to
prevent. This would lead to memory corruption.
On 3/4/15 11:02 AM, Kagamin wrote:
On Wednesday, 4 March 2015 at 15:39:43 UTC, Steven Schveighoffer wrote:
Wow, you really aren't getting it. I give up, it's tiring.
Tiring? Did it take that much effort to not say what you mean?
No tiring like it is to have to explain obvious details to a
On Tuesday, 3 March 2015 at 14:42:40 UTC, Steven Schveighoffer
wrote:
// trigger assert in A.dtor.
You mean assert breaks something?
On 3/3/15 9:57 AM, Kagamin wrote:
On Tuesday, 3 March 2015 at 14:42:40 UTC, Steven Schveighoffer wrote:
// trigger assert in A.dtor.
You mean assert breaks something?
OK, if you want to be pedantic:
int *myglobal;
repeat same code, but access what myglobal points to instead of setting
On Tuesday, 3 March 2015 at 18:38:11 UTC, Steven Schveighoffer
wrote:
int *myglobal;
repeat same code, but access what myglobal points to instead of
setting to 42. Memory corruption is what @safe code is trying
to prevent. This would lead to memory corruption.
You mean, the class destructor
On Tue, 03 Mar 2015 08:53:03 -0500, Steven Schveighoffer wrote:
Classes are expected to be GC allocated.
O_O
classes are expected to be heap-allocated, methinks, and heap is not
necessary garbage collected.
it's quite possible to write a GC that behaves correctly here.
it's *almost*
On Tue, 03 Mar 2015 14:22:15 +, Kagamin wrote:
On Saturday, 28 February 2015 at 04:18:38 UTC, ketmar wrote:
His case is not @safe, so we can ignore that problem.
the compiler tends to disagree:
=== test.d ===
int myglobal;
class A {
~this () @safe { if (myglobal == 42) assert(0);
On 3/2/15 10:38 PM, ketmar wrote:
On Mon, 02 Mar 2015 15:43:42 -0500, Steven Schveighoffer wrote:
I think in this case, the compiler can probably statically reject the
code.
it can't, 'cause it doesn't know how the given object is going to be
allocated. i may completely skip GC and use my
On Saturday, 28 February 2015 at 04:18:38 UTC, ketmar wrote:
His case is not @safe, so we can ignore that problem.
the compiler tends to disagree:
=== test.d ===
int myglobal;
class A {
~this () @safe { if (myglobal == 42) assert(0); }
}
void main () {
auto a = new A;
}
==
dmd -w
On 3/3/15 9:22 AM, Kagamin wrote:
On Saturday, 28 February 2015 at 04:18:38 UTC, ketmar wrote:
His case is not @safe, so we can ignore that problem.
the compiler tends to disagree:
=== test.d ===
int myglobal;
class A {
~this () @safe { if (myglobal == 42) assert(0); }
}
void main () {
On Mon, 02 Mar 2015 15:43:42 -0500, Steven Schveighoffer wrote:
On 2/27/15 11:18 PM, ketmar wrote:
On Fri, 27 Feb 2015 20:51:54 +, deadalnix wrote:
On Friday, 27 February 2015 at 04:13:03 UTC, Steven Schveighoffer
wrote:
In that case, you shouldn't be subject to any kind of race
On 2/27/15 11:18 PM, ketmar wrote:
On Fri, 27 Feb 2015 20:51:54 +, deadalnix wrote:
On Friday, 27 February 2015 at 04:13:03 UTC, Steven Schveighoffer wrote:
In that case, you shouldn't be subject to any kind of race conditions.
But we can't make the library/language based on this
On Saturday, 28 February 2015 at 04:27:36 UTC, weaselcat wrote:
On Saturday, 28 February 2015 at 04:18:38 UTC, ketmar wrote:
On Fri, 27 Feb 2015 20:51:54 +, deadalnix wrote:
On Friday, 27 February 2015 at 04:13:03 UTC, Steven
Schveighoffer wrote:
In that case, you shouldn't be subject to
On Saturday, 28 February 2015 at 04:18:38 UTC, ketmar wrote:
On Fri, 27 Feb 2015 20:51:54 +, deadalnix wrote:
On Friday, 27 February 2015 at 04:13:03 UTC, Steven
Schveighoffer wrote:
In that case, you shouldn't be subject to any kind of race
conditions.
But we can't make the
On Fri, 27 Feb 2015 20:51:54 +, deadalnix wrote:
On Friday, 27 February 2015 at 04:13:03 UTC, Steven Schveighoffer wrote:
In that case, you shouldn't be subject to any kind of race conditions.
But we can't make the library/language based on this assumption. Your
case is the exceptional
On Friday, 27 February 2015 at 04:13:03 UTC, Steven Schveighoffer
wrote:
In that case, you shouldn't be subject to any kind of race
conditions. But we can't make the library/language based on
this assumption. Your case is the exceptional case.
His case is not @safe, so we can ignore that
On Thursday, 26 February 2015 at 23:04:28 UTC, Steven
Schveighoffer wrote:
On 2/26/15 4:40 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Thursday, 26 February 2015 at 18:08:28 UTC, Steven
Schveighoffer wrote:
On 2/26/15 12:56 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net
On Thu, 26 Feb 2015 23:13:01 -0500, Steven Schveighoffer wrote:
I think it's going to be difficult to impossible to prevent people from
using TLS in destructors anyway. It can probably be a guideline more
than a compiler error.
and a warning, please! a warning that i can silence, of course.
On 2015-02-26 21:07:26 +, Andrei Alexandrescu said:
On 2/26/15 12:54 PM, deadalnix wrote:
On Thursday, 26 February 2015 at 16:57:51 UTC, Andrei Alexandrescu wrote:
On 2/26/15 8:51 AM, Steven Schveighoffer wrote:
As talked about before, running dtors in the originating thread can
solve
On 2/26/15 8:51 AM, Steven Schveighoffer wrote:
As talked about before, running dtors in the originating thread can
solve this problem.
Yah, that will solve the nonatomic reference counting. What do you think
about http://forum.dlang.org/thread/mcllre$1abs$1...@digitalmars.com?
Andrei
On 2/24/15 3:34 PM, Walter Bright wrote:
On 2/24/2015 6:56 AM, Steven Schveighoffer wrote:
Actually, RCArray can never be allocated on GC, or you may corrupt
memory. count
may be non-null, and point at invalid memory when the dtor is called.
Just set count to null after the delete.
No, the
On Thursday, 26 February 2015 at 16:51:30 UTC, Steven
Schveighoffer wrote:
As talked about before, running dtors in the originating thread
can solve this problem.
This probably implies forcibly destroying objects whose creating
thread terminated.
On 2/26/15 11:57 AM, Andrei Alexandrescu wrote:
On 2/26/15 8:51 AM, Steven Schveighoffer wrote:
As talked about before, running dtors in the originating thread can
solve this problem.
Yah, that will solve the nonatomic reference counting. What do you think
about
On 2/26/15 12:56 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Thursday, 26 February 2015 at 16:51:30 UTC, Steven Schveighoffer wrote:
As talked about before, running dtors in the originating thread can
solve this problem.
This probably implies forcibly destroying objects whose
On 2/26/15 12:56 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Thursday, 26 February 2015 at 16:51:30 UTC, Steven Schveighoffer wrote:
As talked about before, running dtors in the originating thread can
solve this problem.
This probably implies forcibly destroying objects whose
On 2/26/15 12:54 PM, deadalnix wrote:
On Thursday, 26 February 2015 at 16:57:51 UTC, Andrei Alexandrescu wrote:
On 2/26/15 8:51 AM, Steven Schveighoffer wrote:
As talked about before, running dtors in the originating thread can
solve this problem.
Yah, that will solve the nonatomic reference
On Thursday, 26 February 2015 at 16:57:51 UTC, Andrei
Alexandrescu wrote:
On 2/26/15 8:51 AM, Steven Schveighoffer wrote:
As talked about before, running dtors in the originating
thread can
solve this problem.
Yah, that will solve the nonatomic reference counting. What do
you think about
On Thursday, 26 February 2015 at 18:04:11 UTC, Steven
Schveighoffer wrote:
I think possibly a better solution is to have a finalize
function, similar to how tango does it, so the dtor is only
called from destroy/delete, and the finalize method is called
from the GC.
Ugh, so you still have to
On Thursday, 26 February 2015 at 18:08:28 UTC, Steven
Schveighoffer wrote:
On 2/26/15 12:56 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Thursday, 26 February 2015 at 16:51:30 UTC, Steven
Schveighoffer wrote:
As talked about before, running dtors in the originating
thread can
On 2/26/15 4:40 PM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Thursday, 26 February 2015 at 18:08:28 UTC, Steven Schveighoffer wrote:
On 2/26/15 12:56 PM, Marc =?UTF-8?B?U2Now7x0eiI=?=
schue...@gmx.net wrote:
On Thursday, 26 February 2015 at 16:51:30 UTC, Steven Schveighoffer
On Thursday, 26 February 2015 at 21:07:26 UTC, Andrei
Alexandrescu wrote:
Could you please walk me through what the matter is here.
Thanks. -- Andrei
1/ The originating thread is likely to be dead by the time we
collect.
2/ The RefCounted Stuff crossed thread boundaries so even if we
kept
On Thu, 26 Feb 2015 18:04:28 -0500, Steven Schveighoffer wrote:
That's true. However, what if the destructors access global
(thread-local) variables? Is that already disallowed?
Hm... I don't know. Is it disallowed? I don't think so (a simple test
would suffice), but if any code exists
On Thu, 26 Feb 2015 21:56:30 -0500, Steven Schveighoffer wrote:
On 2/26/15 7:34 PM, ketmar wrote:
On Thu, 26 Feb 2015 18:04:28 -0500, Steven Schveighoffer wrote:
That's true. However, what if the destructors access global
(thread-local) variables? Is that already disallowed?
Hm... I don't
On 2/26/15 10:56 PM, ketmar wrote:
On Thu, 26 Feb 2015 21:56:30 -0500, Steven Schveighoffer wrote:
I can't see a situation where this would be what you wanted. Accessing
global data should be fine, but thread-local data is not.
let's assume that i have a program that has only one thread. i
On 2/26/15 7:34 PM, ketmar wrote:
On Thu, 26 Feb 2015 18:04:28 -0500, Steven Schveighoffer wrote:
That's true. However, what if the destructors access global
(thread-local) variables? Is that already disallowed?
Hm... I don't know. Is it disallowed? I don't think so (a simple test
would
On Wednesday, 25 February 2015 at 00:20:25 UTC, Walter Bright
wrote:
On 2/24/2015 2:27 PM, deadalnix wrote:
I have to admit, that is pretty cool. But it is only gonna
work with value types.
I don't see that limitation at all.
Just try to do the same with opSlice() and you will see what he
On Tuesday, February 24, 2015 01:44:07 Walter Bright via Digitalmars-d wrote:
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote:
The issue is that delete is considered @safe by the compiler,
I thought more people would be interested in how to do a memory safe reference
counted
On 2/24/2015 6:56 AM, Steven Schveighoffer wrote:
Actually, RCArray can never be allocated on GC, or you may corrupt memory. count
may be non-null, and point at invalid memory when the dtor is called.
Just set count to null after the delete.
Only safe way to do this is to C malloc/free the
On Monday, February 23, 2015 23:02:03 Walter Bright via Digitalmars-d wrote:
On 2/23/2015 9:59 PM, Jonathan M Davis via Digitalmars-d wrote:
And delete is supposed to have been deprecated ages ago, but yeah, it
_definitely_ shouldn't be considered @safe.
Managing memory always is going to
On Tuesday, 24 February 2015 at 10:16:00 UTC, Ulrich Küttler
wrote:
On Tuesday, 24 February 2015 at 10:13:36 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
That's why:
this(this)
{
if
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
This is pretty straightforward. More could be done:
1. small array optimization
2. support for ranges as constructor args
3. present a range interface
4. support for malloc/free instead of GC
5. bounds checking
6. the array[] and
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright wrote:
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote:
The issue is that delete is considered @safe by the compiler,
I thought more people would be interested in how to do a memory
safe reference counted container.
On Tuesday, 24 February 2015 at 10:13:36 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
That's why:
this(this)
{
if (count)
++*count;
}
Hmm, I don't see why that's why...
On Tuesday, 24 February 2015 at 10:13:36 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright
wrote:
On 2/24/2015 1:32 AM, Jonathan M Davis
On Tuesday, 24 February 2015 at 10:11:02 UTC, Namespace wrote:
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright
wrote:
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d
wrote:
The issue is that delete is
On Tuesday, 24 February 2015 at 10:08:23 UTC, matovitch wrote:
On Tuesday, 24 February 2015 at 09:44:13 UTC, Walter Bright
wrote:
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote:
The issue is that delete is considered @safe by the compiler,
I thought more people would be
On 2/24/2015 1:32 AM, Jonathan M Davis via Digitalmars-d wrote:
The issue is that delete is considered @safe by the compiler,
I thought more people would be interested in how to do a memory safe reference
counted container.
Does DIP25 means we can turn resources into RC types and be done
with non-deterministic destructor calls by the GC, without using
RefCounted or Unique?
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
This is pretty straightforward. More could be done:
1. small array
On 2/24/15 8:17 AM, Michel Fortin wrote:
On 2015-02-23 22:15:46 +, Walter Bright said:
int* count;
[...] if (count --*count == 0) [...]
Careful!
This isn't memory safe and you have to thank the GC for it. If you ever
use RCArray as a member variable in a class, the RCArray destructor
On 2/23/15 6:05 PM, Walter Bright wrote:
On 2/23/2015 5:41 PM, weaselcat wrote:
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
ref E opIndex(size_t i) return // here's the magic
exactly what is this doing? I don't see this explained in DIP25 at all.
The 'this' is
On 2015-02-23 22:15:46 +, Walter Bright said:
int* count;
[...] if (count --*count == 0) [...]
Careful!
This isn't memory safe and you have to thank the GC for it. If you ever
use RCArray as a member variable in a class, the RCArray destructor is
going to be called from a random
On 2/24/15 3:14 AM, ponce wrote:
Does DIP25 means we can turn resources into RC types and be done with
non-deterministic destructor calls by the GC, without using RefCounted
or Unique?
That's what we're aiming for. -- Andrei
On 2/24/15 5:17 AM, Michel Fortin wrote:
On 2015-02-23 22:15:46 +, Walter Bright said:
int* count;
[...] if (count --*count == 0) [...]
Careful!
This isn't memory safe and you have to thank the GC for it. If you ever
use RCArray as a member variable in a class, the RCArray destructor
On 2/24/2015 2:34 PM, deadalnix wrote:
Maybe we want to fix the GC, exceptions and delegates or disable them in @safe
code because they all cause implicit sharing.
Andrei already filed a bug report on the GC issue. If there aren't bug reports
on the other two, file them.
On Wednesday, 25 February 2015 at 00:13:03 UTC, Walter Bright
wrote:
On 2/24/2015 2:34 PM, deadalnix wrote:
Maybe we want to fix the GC, exceptions and delegates or
disable them in @safe
code because they all cause implicit sharing.
Andrei already filed a bug report on the GC issue. If there
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
struct RCArray(E) {
this(E[] a)
{
array = a.dup;
start = 0;
end = a.length;
count = new int;
*count = 1;
}
This may not be @safe depending on the type of E. Also, this do
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
struct RCArray(E) {
this(E[] a)
{
array = a.dup;
start = 0;
end = a.length;
count = new int;
*count = 1;
}
This may not be @safe depending on the type of E. Also, this do
On Tuesday, 24 February 2015 at 20:35:04 UTC, Walter Bright wrote:
Only safe way to do this is to C malloc/free the count. And
yes, at that point,
you need atomics.
No, RCArray is not intended for shared access between threads.
Shared containers and local containers are different enough
On Tuesday, 24 February 2015 at 15:51:42 UTC, Andrei Alexandrescu
wrote:
On 2/23/15 6:05 PM, Walter Bright wrote:
On 2/23/2015 5:41 PM, weaselcat wrote:
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright
wrote:
ref E opIndex(size_t i) return // here's the magic
exactly what is
On 2/24/2015 2:27 PM, deadalnix wrote:
This may not be @safe depending on the type of E.
The code is a template, and so relies on inference.
Also, this do not really solve the garbage problem
Steven pointed out the correct fix for that.
Also, there are no way to ensure that the array
On 2/24/2015 4:32 PM, deadalnix wrote:
On Wednesday, 25 February 2015 at 00:13:03 UTC, Walter Bright wrote:
On 2/24/2015 2:34 PM, deadalnix wrote:
Maybe we want to fix the GC, exceptions and delegates or disable them in @safe
code because they all cause implicit sharing.
Andrei already filed
This is pretty straightforward. More could be done:
1. small array optimization
2. support for ranges as constructor args
3. present a range interface
4. support for malloc/free instead of GC
5. bounds checking
6. the array[] and the count could be allocated together
7. array[] could be just a
On 2/23/2015 5:01 PM, Max Klyga wrote:
I thought that delete is deprecated, yet here Walter himself promotes a solution
that uses it.
Can we *PLEASE* finally deprecate things that are supposed to be deprecated and
remove things that are supposed to be removed?
That isn't the point. I could
On 2/23/2015 4:13 PM, bearophile wrote:
5. bounds checking
When you go past bounds of a built-in array you get an error located in the user
code, while if you put a pre-condition in your Array struct to detect the same
errors, you get a run-time error message located in that pre-condition
I thought that delete is deprecated, yet here Walter himself promotes a
solution that uses it.
Can we *PLEASE* finally deprecate things that are supposed to be
deprecated and remove things that are supposed to be removed?
On 2015-02-23 22:15:46 +, Walter Bright said:
This is pretty
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
ref E opIndex(size_t i) return // here's the magic
exactly what is this doing? I don't see this explained in DIP25
at all.
Walter Bright:
5. bounds checking
When you go past bounds of a built-in array you get an error
located in the user code, while if you put a pre-condition in
your Array struct to detect the same errors, you get a run-time
error message located in that pre-condition instead. I'd like
some
On 2/23/2015 5:41 PM, weaselcat wrote:
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright wrote:
ref E opIndex(size_t i) return // here's the magic
exactly what is this doing? I don't see this explained in DIP25 at all.
The 'this' is passed by reference. So the 'return' is
On 2/23/2015 9:59 PM, Jonathan M Davis via Digitalmars-d wrote:
And delete is supposed to have been deprecated ages ago, but yeah, it
_definitely_ shouldn't be considered @safe.
Managing memory always is going to be unsafe. The idea is to encapsulate that,
which RCArray shows how to do.
On Tuesday, 24 February 2015 at 02:06:07 UTC, Walter Bright wrote:
On 2/23/2015 5:41 PM, weaselcat wrote:
On Monday, 23 February 2015 at 22:15:54 UTC, Walter Bright
wrote:
ref E opIndex(size_t i) return // here's the magic
exactly what is this doing? I don't see this explained in
DIP25
On Monday, February 23, 2015 15:28:21 Andrei Alexandrescu via Digitalmars-d
wrote:
On 2/23/15 2:15 PM, Walter Bright wrote:
This is pretty straightforward.
[snip]
The code builds if you slap a @safe: at the top. There is one bug in
the compiler: delete must not be allowed in @safe code.
On 2/23/15 2:15 PM, Walter Bright wrote:
This is pretty straightforward.
[snip]
The code builds if you slap a @safe: at the top. There is one bug in
the compiler: delete must not be allowed in @safe code. The destructor
must be @trusted.
Understanding that this code (sans delete) is @safe
78 matches
Mail list logo
