On Mon, 08 Apr 2013 09:58:15 +0100, Manu <turkeyman@gmail.com> wrote:
> I suspect Andrei for one knows this, and that's why the D containers are
> so... barely existing. The language is not yet ready to say with confidence
> how they should look.

That, and before you can design the containers you need a concrete allocator interface design.  Actually, this is likely the same blocker for GC-free D as well.

D should have a set of global allocator hooks.  If it did, you could easily catch unexpected allocations in tight loops and realtime code.  If it did, GC-free D would be trivial - just replace the default GC based allocator with a malloc/free one, or any other scheme you like.

The hooks would ideally pass __FILE__ and __LINE__ information down from the call site in debug mode, etc.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 8 April 2013 20:57, Regan Heath <regan@netmail.co.nz> wrote:

> On Mon, 08 Apr 2013 09:58:15 +0100, Manu <turkeyman@gmail.com> wrote:
>
>> I suspect Andrei for one knows this, and that's why the D containers are
>> so... barely existing. The language is not yet ready to say with
>> confidence
>> how they should look.
>>
>
> That, and before you can design the containers you need a concrete allocator interface design.  Actually, this is likely the same blocker for GC-free D as well.
>
> D should have a set of global allocator hooks.


True. I've been saying for a long time that I'd really like filesystem hooks too while at it!


If it did, you could easily catch unexpected allocations in tight loops and
> realtime code.  If it did, GC-free D would be trivial - just replace the default GC based allocator with a malloc/free one, or any other scheme you like.
>

D doesn't have a delete keyword, which is fairly important if you want to manually manage memory...


The hooks would ideally pass __FILE__ and __LINE__ information down from
> the call site in debug mode, etc.
>

On Monday, 8 April 2013 at 11:14:13 UTC, Manu wrote:
> D doesn't have a delete keyword, which is fairly important if you want to
> manually manage memory...

I'd argue that. If concept of global allocator is added, new/delete can be done as library solutions (similar to current emplace/destroy). Defining those in language may have some benefits but definitely is not a requirement.

On 2013-04-08 12:08, Dicebot wrote:

> Erm. How so? Same C library is dynamically linked both for D and C
> programs so I am comparing raw binary size honestly here (and it is the
> same).

You're comparing a D executable, statically linked with its runtime and standard library to a C executable which is dynamically linked with instead. It's not rocket science that if you put more into the executable it will become larger.

> If you mean size of druntime is not that relevant if you link it
> dynamically - embedded application can often be the only program that
> runs on given system ("single executive" concept) and it makes no
> difference (actually, dynamic linking is not even possible in that case).

Then you have to include the size of the C runtime and standard library when comparing.

-- 
/Jacob Carlborg

On 2013-04-08 11:39, Manu wrote:

> I don't see how. I noticed that the ancillary data kept along with class
> definitions and other stuff was quite significant, particularly when a
> decent number of templates appear.
> Dynamic linkage of the runtime can't affect that.

That's the result I got when I tried, don't know why.

-- 
/Jacob Carlborg

On 2013-04-08 11:36, Manu wrote:

> Haha, yeah I remember discussing that with you some time back when we
> were discussing iPhone.
> Rather humorous ;)

Yeah :)

> I do wonder if there's room in D for built-in Obj-C compatibility;
> extern(ObjC) ;)
> OSX and iOS are not minor platforms by any measure. At least support for
> the most common parts of the Obj-C calling convention. D doesn't offer
> full C++ either, but what it does offer is very useful, and it's
> important that it's there.

I really think so. Michel Fortin was working on that. When he announced that I think Walter agreed it would be a good idea to include.

http://michelf.ca/projects/d-objc/

-- 
/Jacob Carlborg

On Monday, 8 April 2013 at 11:36:40 UTC, Jacob Carlborg wrote:
> You're comparing a D executable, statically linked with its runtime and standard library to a C executable which is dynamically linked with instead. It's not rocket science that if you put more into the executable it will become larger.

You have got it wrong. I am comparing D executable with no runtime and standard library and C executable (-betterC -defaultlib=). And they are roughly the same, what is good, because indicates that there is nothing wrong with plain binary code gen.

On Monday, 8 April 2013 at 10:13:36 UTC, Timon Gehr wrote:
> On 04/08/2013 07:55 AM, Paulo Pinto wrote:
>> On Sunday, 7 April 2013 at 22:59:37 UTC, Peter Alexander wrote:
>>> On Sunday, 7 April 2013 at 22:33:04 UTC, Paulo Pinto wrote:
>>>> Am 08.04.2013 00:27, schrieb Timon Gehr:
>>>>> Every time a variable is reassigned, its old value is destroyed.
>>>>
>>>> I do have functional and logic programming background and still fail
>>>> to see how that is manual memory management.
>>>
>>> Mutable state is essentially an optimisation that reuses the same
>>> memory for a new value (as opposed to heap allocating the new value).
>>> In that sense, mutable state is manual memory management because you
>>> have to manage what has access to that memory.
>>
>> If you as a developer don't call explicitly any language API to
>> acquire/release resource and it is actually done on your behalf by the
>> runtime, it is not manual memory management.
>
> a = b;
>   ^- explicit "language API" call

I give up

On 2013-04-08 12:10, Dicebot wrote:

> Hm, so you propose to use something like Malloced!Data / Stack!Data
> instead of marking whole function with @nogc? Interesting, I have never
> though about this approach, may be worth trying as proof-of-concept.

I don't know. The thread safe example probably works better with an annotated type than nogc.

But the problem is still how to make it not use the GC. I mean, the red code/green code talk is more about statically enforce some property of your code. If you cannot accomplish that property in your code, regardless if it's statically enforced or not, I don't think that talk will help.

-- 
/Jacob Carlborg

On 2013-04-08 12:57, Regan Heath wrote:

> D should have a set of global allocator hooks.  If it did, you could
> easily catch unexpected allocations in tight loops and realtime code.
> If it did, GC-free D would be trivial - just replace the default GC
> based allocator with a malloc/free one, or any other scheme you like.

You can already do that:

https://github.com/D-Programming-Language/druntime/tree/master/src/gcstub

-- 
/Jacob Carlborg