View mode: basic / threaded / horizontal-split · Log in · Help
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 07:06:03 UTC, Mehrdad wrote:
> On Wednesday, 9 January 2013 at 06:57:34 UTC, deadalnix wrote:
>> On Wednesday, 9 January 2013 at 06:56:00 UTC, Mehrdad wrote:
>>> On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright 
>>> wrote:
>>>> One thing I'd add is that a GC is *required* if you want to 
>>>> have a language that guarantees memory safety
>>>
>>>
>>>
>>> Pardon?  shared_ptr anyone? You can totally have a language 
>>> that only provides new/delete facilities and which only 
>>> access to memory through managed pointers like shared_ptr... 
>>> without a GC. I don't see where a GC is "required" as you say.
>>
>> Such a program is guaranteed to have memory leak, unless you 
>> add a GC on top of the managed pointers.
>
> Oh and you should also take a look at Newlisp

I certainly wont if you don't even bother explain why I should.
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 07:14:19 UTC, deadalnix wrote:
> On Wednesday, 9 January 2013 at 07:06:03 UTC, Mehrdad wrote:
>> On Wednesday, 9 January 2013 at 06:57:34 UTC, deadalnix wrote:
>>> On Wednesday, 9 January 2013 at 06:56:00 UTC, Mehrdad wrote:
>>>> On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright 
>>>> wrote:
>>>>> One thing I'd add is that a GC is *required* if you want to 
>>>>> have a language that guarantees memory safety
>>>>
>>>>
>>>>
>>>> Pardon?  shared_ptr anyone? You can totally have a language 
>>>> that only provides new/delete facilities and which only 
>>>> access to memory through managed pointers like shared_ptr... 
>>>> without a GC. I don't see where a GC is "required" as you 
>>>> say.
>>>
>>> Such a program is guaranteed to have memory leak, unless you 
>>> add a GC on top of the managed pointers.
>>
>> Oh and you should also take a look at Newlisp
>
> I certainly wont if you don't even bother explain why I should.

'cause it's memory-safe LISP and without a GC?
January 09, 2013
Re: manual memory management
09-Jan-2013 03:37, Joseph Rushton Wakeling пишет:
> On 01/08/2013 10:43 PM, Jonathan M Davis wrote:
>> std.container.Array and built-in arrays are _very_ different. Array is a
>> container, not a range. You can slice it to get a range and operate on
>> that,
>> but it's not a range itself.
>
> Is there a particular reason why Array can't have a range interface itself?
>

Of course, there is - it then will have to keep around the head pointer 
or to truly remove say front element by shift the rest of the array. 
Aside from awful implementation contortions it probably can be done but 
I'd strongly argue against it.

>> On the other hand, built-in arrays aren't true containers. They don't
>> own or
>> manage their own memory in any way, shape, or form, and they're ranges.
>
> Forgive the naive question, but what _is_ the definition of a 'true
> container'?  Is managing its own memory a necessary component?

Managing its own memory is required for container.
Ranges don't manage memory they don't have insert/delete whatever.
Built-in arrays are strange beasts but for good reason.

> Or just
> for D's concept of a container?


-- 
Dmitry Olshansky
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 07:16:15 UTC, Mehrdad wrote:
> On Wednesday, 9 January 2013 at 07:14:19 UTC, deadalnix wrote:
>> On Wednesday, 9 January 2013 at 07:06:03 UTC, Mehrdad wrote:
>>> On Wednesday, 9 January 2013 at 06:57:34 UTC, deadalnix wrote:
>>>> On Wednesday, 9 January 2013 at 06:56:00 UTC, Mehrdad wrote:
>>>>> On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright 
>>>>> wrote:
>>>>>> One thing I'd add is that a GC is *required* if you want 
>>>>>> to have a language that guarantees memory safety
>>>>>
>>>>>
>>>>>
>>>>> Pardon?  shared_ptr anyone? You can totally have a language 
>>>>> that only provides new/delete facilities and which only 
>>>>> access to memory through managed pointers like 
>>>>> shared_ptr... without a GC. I don't see where a GC is 
>>>>> "required" as you say.
>>>>
>>>> Such a program is guaranteed to have memory leak, unless you 
>>>> add a GC on top of the managed pointers.
>>>
>>> Oh and you should also take a look at Newlisp
>>
>> I certainly wont if you don't even bother explain why I should.
>
> 'cause it's memory-safe LISP and without a GC?

"Sharing of sub-objects among objects, cyclic structures, or 
multiple variables pointing to the same object are not supported 
in newLISP."

Well, you CAN indeed, create a dumbed down language that is 
memory safe and don't require a GC.
January 09, 2013
Re: manual memory management
On 1/8/2013 10:55 PM, Mehrdad wrote:
> On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote:
>> One thing I'd add is that a GC is *required* if you want to have a language
>> that guarantees memory safety
>
>
>
> Pardon?  shared_ptr anyone? You can totally have a language that only provides
> new/delete facilities and which only access to memory through managed pointers
> like shared_ptr... without a GC. I don't see where a GC is "required" as you say.

Reference counting is a valid form of GC.

C++'s shared_ptr, however, is both optional and allows access to the underlying 
raw pointers. Hence, memory safety cannot be guaranteed.
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote:
> Well, you CAN indeed, create a dumbed down language that is 
> memory safe and don't require a GC.


Yeah, that's 1 of my 2 points.


The other one you still ignored: the GC doesn't bring much to the 
table. (Re C# Java etc.)
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 07:23:16 UTC, Walter Bright wrote:
> On 1/8/2013 10:55 PM, Mehrdad wrote:
>> On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright 
>> wrote:
>>> One thing I'd add is that a GC is *required* if you want to 
>>> have a language
>>> that guarantees memory safety
>>
>>
>>
>> Pardon?  shared_ptr anyone? You can totally have a language 
>> that only provides
>> new/delete facilities and which only access to memory through 
>> managed pointers
>> like shared_ptr... without a GC. I don't see where a GC is 
>> "required" as you say.
>
> Reference counting is a valid form of GC.
>
> C++'s shared_ptr, however, is both optional and allows access 
> to the underlying raw pointers. Hence, memory safety cannot be 
> guaranteed.


Right, I never claimed C++ is memory safe.

I just said that a language that does something similar without
giving you raw pointer access is perfectly possible and (short of
memory leaks due to cycles) also perfectly safe.
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote:
> On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote:
>> Well, you CAN indeed, create a dumbed down language that is 
>> memory safe and don't require a GC.
>
>
> Yeah, that's 1 of my 2 points.
>
>
> The other one you still ignored: the GC doesn't bring much to 
> the table. (Re C# Java etc.)

There is a point being made here that is perfectly valid. There 
is a form of memory leak that a GC can never catch, such as when 
when memory is allocated and simply never deallocated by mistake 
due to a persistent "in use" pointer that should have been nulled 
but wasn't.

In addition, the GC itself may fail to deallocated freed memory 
or even free live memory by mistake. I've seen bugs described to 
that effect. There simply is no panacea to the memory leak 
problem. What a GC does do, is free the programmer from a ton of 
tedium, and even allow for constructs that would normally not be 
practical to implement, but it can never guarantee anything more 
than that.

--rt
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 07:33:24 UTC, Rob T wrote:
> On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote:
>> On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote:
>>> Well, you CAN indeed, create a dumbed down language that is 
>>> memory safe and don't require a GC.
>>
>>
>> Yeah, that's 1 of my 2 points.
>>
>>
>> The other one you still ignored: the GC doesn't bring much to 
>> the table. (Re C# Java etc.)
>
> There is a point being made here that is perfectly valid. There 
> is a form of memory leak that a GC can never catch, such as 
> when when memory is allocated and simply never deallocated by 
> mistake due to a persistent "in use" pointer that should have 
> been nulled but wasn't.
>
> In addition, the GC itself may fail to deallocated freed memory 
> or even free live memory by mistake. I've seen bugs described 
> to that effect. There simply is no panacea to the memory leak 
> problem. What a GC does do, is free the programmer from a ton 
> of tedium, and even allow for constructs that would normally 
> not be practical to implement, but it can never guarantee 
> anything more than that.
>
> --rt



Yup.


Also might mention, we implemented a compiler for a subdialect of 
Python (including full closures) for our compilers course, which 
the compiler subsequently translated to C++.

GC wasn't required (we were allowed to never deallocate), but 
since I didn't feel like doing that I added reference counting 
using a lot of shared_ptr's and intrusive_ptr's.

I also added a GC just for the sake of catching cyclic 
references, but it was just that -- everything was reference 
counted, so if you never had cyclic references, the GC _never_ 
kicked in, period.


(True, it wouldn't give you the power of a systems language, but 
that's quite obviouly not my point -- the point is that it's a 
_perfectly possible_ memory-safe language which we made, so I 
don't understand Walter's comment about a GC being "required" for 
a memory-safe language.)
January 09, 2013
Re: manual memory management
On 1/8/2013 11:42 PM, Mehrdad wrote:
> (True, it wouldn't give you the power of a systems language, but that's quite
> obviouly not my point -- the point is that it's a _perfectly possible_
> memory-safe language which we made, so I don't understand Walter's comment about
> a GC being "required" for a memory-safe language.)


The misunderstanding is you are not considering reference counting as a form of 
GC. It is.
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home