View mode: basic / threaded / horizontal-split · Log in · Help
January 09, 2013
Re: manual memory management
On Wednesday, January 09, 2013 00:37:10 Joseph Rushton Wakeling wrote:
> 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?

It's a container. Turning a container into a range is just begging for 
trouble. For instance, what happens when you iterate over it? You remove all 
of its elements, because you keep calling popFront on it. Making a container 
into a range is an incredibly bad idea. Things are already weird enough with 
the built-in arrays.

> > 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? Or just for
> D's concept of a container?

A container owns and manages its elements. It may not manage their memory 
(e.g. it could all be garbage collected, or if its elements are references or 
pointers, it's really the references or pointers that it owns and manages, not 
what they point to, so it's not managing the memory that they point to). This 
is in direct contrast to a slice which is simply a view into a container. You 
can mess with a slice as much as you want without altering the container 
itself. It's just that altering the elements in the slice alters those in the 
container, because they're the same. You can also have multiple slices which 
view the same container. But you only have one copy of a given container, and 
so it's the owner of its elements. Copying the container would mean copying 
the elements themselves, whereas copying a slice would only copy the state of 
the view into the container and wouldn't copy any elements at all.

A container contains elements. A slice is a view into a container and doesn't 
actually, technically contain them. It has no control over their memory or 
existence whatsoever. It only provides a way to view them.

A lot of what makes D arrays (and therefore ranges) so confusing is the fact 
that arrays don't own their elements. They're slices. It's the runtime that 
owns and manages the elements. But people think of arrays as being containers, 
so they end up getting confused.

- Jonathan M Davis
January 09, 2013
Re: manual memory management
On Wed, Jan 09, 2013 at 12:21:05AM +0100, deadalnix wrote:
> On Tuesday, 8 January 2013 at 16:12:41 UTC, Benjamin Thaut wrote:
> >My impression so far: No one who is writing a tripple A gaming
> >title or engine is only remotly interested in using a GC. Game
> >engine programmers almost do anything to get better performance on
> >a certain plattform. There are really elaborate taks beeing done
> >just to get 1% more performance. And because of that, a GC is the
> >very first thing every serious game engine programmer will kick.
> >You have to keep in mind that most games run at 30 FPS. That means
> >you only have 33 ms to do everything. Rendering, simulating
> >physics, doing the game logic, handling network input, playing
> >sounds, streaming data, and so on.
> >Some games even try to get 60 FPS which makes it even harder as
> >you only have 16 ms to compute everything. Everything is
> >performance critical if you try to achive that.
> >
> 
> That is a real misrepresentation of the reality. Such people avoid
> the GC, but simply because they avoid all kind of allocation
> altogether, preferring allocating up-front.

Interesting, that sounds like the heapless programming of the old, old
days where you map out everything beforehand, and limit yourself to use
only what is there. Y'know, with fixed-sized arrays, stacks, etc., fixed
maximum number of objects, etc.. Not a bad approach if you want to
tightly control everything.

Well, except that you do have preallocation, presumably during runtime
at startup (and between game levels, perhaps?), so it's not as rigid,
but during gameplay itself this is pretty much what it amounts to,
right?


T

-- 
Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
January 09, 2013
Re: manual memory management
On Tuesday, 8 January 2013 at 23:30:34 UTC, David Nadlinger wrote:
> On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote:
>> The only major thing that concerns me is the lack of proper 
>> shared library support. I hope this omission is resolved soon.
>
> What do you need it for? Runtime loading of D shared objects? 
> Or just linking to them (i.e. binding by ld/dyld at load time)? 
> I'm trying to collect data on real-world use cases resp. 
> expectations right now.
>
> David

I *really* need runtime loading of plug-in code for a server 
application. This allows the server code to remain untouched 
while allowing extensions to be added on by a 3rd party.

Runtime linked shared libs are also nice to have for the simple 
reason that shared libraries can be updated (to a point) without 
having to rebuild and relink all applications that make use of 
the libraries. There are pros and cons to static vs dynamic 
linking, but definitely both are useful to have.

I'm very surprised that not too many people have been screaming 
for dynamic linking and runtime loading. It's very hard for me to 
imagine not having the feature because it's so darn useful and an 
essential feature if your strategy is to allow 3rd parties to 
extend an application without hacking at the source code.

If there's another better way, I'd sure like to know about it!

--rt
January 09, 2013
Re: manual memory management
On Wed, Jan 09, 2013 at 03:49:33AM +0100, Rob T wrote:
> On Tuesday, 8 January 2013 at 23:30:34 UTC, David Nadlinger wrote:
> >On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote:
> >>The only major thing that concerns me is the lack of proper
> >>shared library support. I hope this omission is resolved soon.
> >
> >What do you need it for? Runtime loading of D shared objects? Or
> >just linking to them (i.e. binding by ld/dyld at load time)? I'm
> >trying to collect data on real-world use cases resp. expectations
> >right now.
> >
> >David
> 
> I *really* need runtime loading of plug-in code for a server
> application. This allows the server code to remain untouched while
> allowing extensions to be added on by a 3rd party.
> 
> Runtime linked shared libs are also nice to have for the simple
> reason that shared libraries can be updated (to a point) without
> having to rebuild and relink all applications that make use of the
> libraries. There are pros and cons to static vs dynamic linking, but
> definitely both are useful to have.
> 
> I'm very surprised that not too many people have been screaming for
> dynamic linking and runtime loading. It's very hard for me to
> imagine not having the feature because it's so darn useful and an
> essential feature if your strategy is to allow 3rd parties to extend
> an application without hacking at the source code.

I haven't been screaming yet because (so far) I haven't gotten to
writing applications that need dynamic loading in D. But I did tell
myself that I will be screaming when I do get to it, because it's a pain
to have to recompile the entire application just to add a single addon.


> If there's another better way, I'd sure like to know about it!
[...]

Another way, yes. Better, I don't know. You *could* load plugins as
separate processes and communicate via some kind of IPC mechanism, like
Unix pipes. But that's a royal pain (requires serialization /
deserialization, with the associated overhead, and a network stack or
equivalent, just to interface with each other).


T

-- 
Latin's a dead language, as dead as can be; it killed off all the
Romans, and now it's killing me! -- Schoolboy
January 09, 2013
Re: manual memory management
On Wednesday, 9 January 2013 at 00:50:29 UTC, Jonathan M Davis 
wrote:
> On Wednesday, January 09, 2013 00:37:10 Joseph Rushton Wakeling 
> wrote:
>> 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?
>
> It's a container. Turning a container into a range is just 
> begging for
> trouble. For instance, what happens when you iterate over it? 
> You remove all
> of its elements, because you keep calling popFront on it. 
> Making a container
> into a range is an incredibly bad idea. Things are already 
> weird enough with
> the built-in arrays.
>

It seems to me like a container should be able to provide a range 
to iterate its content (but yeah, the container shouldn't be the 
range itself).
January 09, 2013
Re: manual memory management
On Tuesday, 8 January 2013 at 23:30:34 UTC, David Nadlinger wrote:
> On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote:
>> The only major thing that concerns me is the lack of proper 
>> shared library support. I hope this omission is resolved soon.
>
> What do you need it for? Runtime loading of D shared objects? 
> Or just linking to them (i.e. binding by ld/dyld at load time)? 
> I'm trying to collect data on real-world use cases resp. 
> expectations right now.
>
> David

1/ Load 3rd party code that the core app have no idea about 
(plugins).
2/ Reduce the feedback loop for projects that take ages to link 
during dev.
January 09, 2013
Re: manual memory management
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.
January 09, 2013
Re: manual memory management
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.
January 09, 2013
Re: manual memory management
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.


He said _safety_... memory leaks are perfectly safe.

Then again, doesn't Java also have memory leaks when e.g. you 
create a thread and never run it? Doesn't C# have memory leaks 
when you attach an event handler to a static event and never 
remove it?

What exactly does a GC bring to the table here?
January 09, 2013
Re: manual memory management
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
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home