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?

I would like to switch majority of my programming from C++ to D2 but the number of bugs and uncertainty of how exactly will non-garbage collected classes work makes me a bit cautious.(could someone please explain too)

Also, how much slower is D2 compared to C++? Will D2 final have comparable performance?

Thanks
Petr Janda

"Petr Janda" <janda.petr@gmail.com> wrote in message news:it6npg$6l8$1@digitalmars.com...
>
> Also, how much slower is D2 compared to C++? Will D2 final have comparable performance?
>

D2 already has comparable performance to C++. And various things like built-in slices and good metaprogramming make it easier to write fast code:

http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-parsequerymutateserialize/ http://dotnot.org/blog/archives/2008/03/10/xml-benchmarks-updated-graphs-with-rapidxml/ http://dotnot.org/blog/archives/2008/03/12/why-is-dtango-so-fast-at-parsing-xml/

http://www.semitwist.com/articles/EfficientAndFlexible/SinglePage/

"Petr Janda" <janda.petr@gmail.com> wrote in message news:it6npg$6l8$1@digitalmars.com...
> 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?
>

I already find D2, even with occasional bugs, to be *far* better than dealing with C++.

And no language is ever "final" unless it's a dead language. D2's already ready for production use IMO, and many people are already using it professionally.

> uncertainty of how exactly will non-garbage
> collected classes work makes me a bit cautious.(could someone please
> explain too)
>

Basically you can use either structs (which are not heap-allocated unless you specifically ask for them to be) or you use "emplace". For emplace, you allocate your own chunk of memory however you want, and then pass it to the emplace function in Phobos which will construct your object right there "in place" instead of allocating new GC'ed memory. Somebody else can explain the details better than I can, I've never actually used emplace myself.

Am 14.06.2011 07:24, schrieb Nick Sabalausky:
> "Petr Janda" <janda.petr@gmail.com> wrote in message news:it6npg$6l8$1@digitalmars.com...
>> 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?
>>
> 
> I already find D2, even with occasional bugs, to be *far* better than dealing with C++.
> 
> And no language is ever "final" unless it's a dead language. D2's already ready for production use IMO, and many people are already using it professionally.
> 
>> uncertainty of how exactly will non-garbage
>> collected classes work makes me a bit cautious.(could someone please
>> explain too)
>>
> 
> Basically you can use either structs (which are not heap-allocated unless you specifically ask for them to be) or you use "emplace". For emplace, you allocate your own chunk of memory however you want, and then pass it to the emplace function in Phobos which will construct your object right there "in place" instead of allocating new GC'ed memory. Somebody else can explain the details better than I can, I've never actually used emplace myself.
> 

Example of an custom (de)allocator for class-objects (using C
malloc/free and emplace()): http://pastebin.com/9Qgf3vc7

Cheers,
- Daniel

I see. Thank you.

I do have a couple of questions about myNew and myDelete though.

T ret = emplace!(T, Args)(objMem, args);
return ret; // return new custom allocated Object

So emplace runs the constructor of T.

1) Does emplace return a copy of T?
2) Is Object "ret"  constructed as a copy(via copy constructor) of
what emplace returns?
3) Is there some kind of internal reference counting/smart pointer
happening that I can't see?

And about myDelete:

core.stdc.stdlib.free(cast(void*)obj);

Casting object to a pointer to a heap allocated memory? That's neat!

Am 14.06.2011 08:55, schrieb Petr Janda:
> I see. Thank you.
> 
> I do have a couple of questions about myNew and myDelete though.
> 
> T ret = emplace!(T, Args)(objMem, args);
> return ret; // return new custom allocated Object
> 
> So emplace runs the constructor of T.
> 
> 1) Does emplace return a copy of T?

T is a class, not an object, so it can't return "a copy".
What emplace does is that it creates an object in the given memory
(objMem[] in my example), i.e. it initializes the memory and runs the
given constructor on it - just like new does with memory from the heap
that it allocates itself.
See also http://d-programming-language.org/phobos/std_conv.html#emplace
for a description of emplace (I used the "T em­place(T, Args...)(void[]
chunk, Args args);" version).

> 2) Is Object "ret"  constructed as a copy(via copy constructor) of
> what emplace returns?
> 3) Is there some kind of internal reference counting/smart pointer
> happening that I can't see?

No, not at all. My example just gets memory from the C heap (via
malloc()), "makes it an object" with emplace (this means, it will
contain all data an object created by new would contain) and returns
that object.
Just like in C++ you have to delete it (with myDelete) to prevent memory
leaks.
You could of course implement reference counting yourself, maybe with a
custom class and a custom myNew that creates objects of that class and
initializes the reference counter or something.

> 
> And about myDelete:
> 
> core.stdc.stdlib.free(cast(void*)obj);
> 
> Casting object to a pointer to a heap allocated memory? That's neat!

malloc() returned a void pointer (that was casted to void[] and then
made an object with emplace). By casting the Object to void* we get a
pointer pointing with the same value as the one returned by malloc()
before, so we can call free() on it.
But before that, clear() is used, so the Object's destructor is called.

Also note that malloc() and free() were just examples, you could also
use chunks of memory obtained by other means (like mmap) with emplace.

Cheers,
- Daniel

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)

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

With regard to bugs: the last release fixed more than half of the most important and difficult structural bugs remaining in the compiler, including some which had been deferred for years. There are a huge number of open bugs, of course, but we are on a downhill run now.

> I would like to switch majority of my programming from C++ to D2 but
> the number of bugs and uncertainty of how exactly will non-garbage
> collected classes work makes me a bit cautious.(could someone please
> explain too)
> 
> Also, how much slower is D2 compared to C++? Will D2 final have
> comparable performance?
> 
> Thanks
> Petr Janda

On 2011-06-14 02:07, 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)
> 
> 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".
> 
> With regard to bugs: the last release fixed more than half of the most important and difficult structural bugs remaining in the compiler, including some which had been deferred for years. There are a huge number of open bugs, of course, but we are on a downhill run now.

Yeah. It's been pretty amazing how much the speed of compiler development has picked up since we've moved to github. The situation with Phobos has been improving as well between the move to github and having new modules reviewed in the newsgroup, but it hasn't been improving at anywhere near the rate that the compiler has been - though there are certain classes of issues which require that the compiler be improved before they can be fixed in Phobos (such as adding some sort of conditional attributes to allow for pure, @safe, and nothrow on templated functions whose ability to have those attributes depends on the arguments that they're instantiated with). I do think that it's only natural that Phobos would be a bit behind the language itself since it has to use the language to do whatever it does, but we could definitely use more help developing Phobos - be it fixing bugs, implementing new features, or simply reviewing pull requests on github.

- Jonathan M Davis

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?)
* Redo xml (Tomek)
* Many other changes and additions


Andrei

Andrei Alexandrescu wrote:
> 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?)
> * Redo xml (Tomek)
> * Many other changes and additions
> 
> 
> Andrei

Added to the existing roadmap at:
http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel