>> Overhaul std.container to use it; add classic containers to
std.container (doubly-linked list, hash, deque)

Hi Andrei,

I think it would be fantastic if D could have most, if not all of the C++ containers, so that D also has containers that do not rely on garbage collection. I believe I read somewhere that D arrays rely on the GC which may not be desirable in certain situations (OS programming etc).

Can you let me know what you think as you are seemingly the chief Phobos developer.

Thank you,
Petr Janda

Am 15.06.2011 02:12, schrieb Petr Janda:
>>> Overhaul std.container to use it; add classic containers to
> std.container (doubly-linked list, hash, deque)
>
> Hi Andrei,
>
> I think it would be fantastic if D could have most, if not all of
> the C++ containers, so that D also has containers that do not rely
> on garbage collection. I believe I read somewhere that D arrays rely
> on the GC which may not be desirable in certain situations (OS
> programming etc).
>
> Can you let me know what you think as you are seemingly the chief
> Phobos developer.
>
> Thank you,
> Petr Janda

The core of D's arrays don't rely on an GC. You can malloc, slice the pointer and free it again.
Only concatening and appending use the GC, everything else should work without a GC.

Mafi

On 6/14/11 7:12 PM, Petr Janda wrote:
>>> Overhaul std.container to use it; add classic containers to
> std.container (doubly-linked list, hash, deque)
>
> Hi Andrei,
>
> I think it would be fantastic if D could have most, if not all of
> the C++ containers, so that D also has containers that do not rely
> on garbage collection. I believe I read somewhere that D arrays rely
> on the GC which may not be desirable in certain situations (OS
> programming etc).

I'm currently trying to figure out a design that offers the following:

* several allocation schemes (GC, refcounting, malloc, regions, reaps, tempalloc)

* two approaches to safety (safe vs. unsafe); sealing can make use of malloc safe.

* how to distribute responsibility of the above between containers and what I call "storage models" (which are akin to STL allocators).


Andrei

Den 14-06-2011 15:17, Andrei Alexandrescu skrev:
> On 6/14/11 4:07 AM, Don wrote:
>> Petr Janda wrote:
>>> Hi,
>>>
>>> Can someone please explain what needs to be done (other than fixing
>>> the plethora of bugs) to call D2 final? And if someone can provide
>>> an approximate estimate of when?
>>
>> There are a couple of areas of major missing functionality:
>> * CTFE should support pointers (upcoming release 2.054) and classes
>> (2.055).
>> * alias this, inout, safe aren't fully implemented, and will probably
>> require language changes/clarifications.
>> * Built-in struct functions (opEquals, toString, etc) need more thought.
>> * I suspect that we'll see changes to the modifiers for function
>> parameters (in, out, inout, ref, auto ref)
>
> * Work last kinks out of qualified constructors and destructors
> * Low-level threading support with shared; change language to match TDPL
> (that means e.g. shared/synchronized methods is at class level, not
> method level).
> * Minor touches such as user-defined operator '$', @disable etc.
>
> Work that is not quintessential for using D but very important:
>
> * Finish typechecking for SafeD
> * Make SafeD == CompileTimeD
>
> We should put this list somewhere.
>
>> At the current rate of progress I estimate we are about six months from
>> having the language implemented (but still with bugs).
>> But there will still be bugs which can only be fixed by making small
>> changes to the language spec.
>>
>> Phobos is quite a bit further away from being "final".
>
> * Define allocator abstraction
> * Overhaul std.container to use it; add classic containers to
> std.container (doubly-linked list, hash, deque)
> * Define streaming abstraction (already in my head)
> * Add high-level networking (Jonas, where art thou?)

Finishing off some major changes to the curl wrapper. I'm posting a RFC on the updated code in a sec.

> * Redo xml (Tomek)
> * Many other changes and additions
>
>
> Andrei

On 06/18/2011 03:23 PM, jdrewsen wrote:
> Finishing off some major changes to the curl wrapper. I'm posting a RFC
> on the updated code in a sec.

Can't wait, thanks for doing this work!

I wonder whether we can distribute the libcurl libraries on Windows.


Andrei

This seems to be a good roundup of all issues involved with distributing libcurl.

http://curl.haxx.se/legal/licmix.html

TL;DR Yes, you can include a libcurl binary but a lot care needs to be taken with the other libraries libcurl can use.

On Sat, Jun 18, 2011 at 2:32 PM, Andrei Alexandrescu < SeeWebsiteForEmail@erdani.org> wrote:

> On 06/18/2011 03:23 PM, jdrewsen wrote:
>
>> Finishing off some major changes to the curl wrapper. I'm posting a RFC on the updated code in a sec.
>>
>
> Can't wait, thanks for doing this work!
>
> I wonder whether we can distribute the libcurl libraries on Windows.
>
>
> Andrei
>
>