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.

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?

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

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.

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.

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.)

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.

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

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.)

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.