January 09, 2013
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
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
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
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
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
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
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
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
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
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