http://www.informit.com/articles/article.aspx?p=1622265

Andrei

On 08/18/2010 05:13 AM, Andrei Alexandrescu wrote:
> http://www.informit.com/articles/article.aspx?p=1622265
>
> Andrei

Now on reddit:

http://www.reddit.com/r/programming/comments/d2j8n/d_programming_language_interview_with_andrei/

Thanks davebrk!


Andrei

On Wed, 18 Aug 2010 13:13:25 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> http://www.informit.com/articles/article.aspx?p=1622265

Thanks, that was an interesting read.

It's possible that I'm missing something, but I think that C++'s default constructors + reference-type structs/classes allow a pattern which isn't easily translatable to D. For example, in C++...

class A { /* a class with a default constructor */ };

struct B { A a; /* ... */ };

struct C { B b; /* ... */ };

Now, instantiating C will invoke A's constructors. In order for this to work, the compiler automatically generates hidden constructors for B and C. However, D doesn't have default constructors for structs (and, according to TDPL, never will)? D does seem to generate hidden postblit constructors and destructors, though.

If I had to port a C++ project to D which made heavy use of this pattern, what would be the best way to do it? The only ways I see is either rewriting the code to use classes (which means writing constructors with explicit instantiation, more dereferences and heap usage leading to worse performance...), or implementing and calling pseudo-constructors in both B and C, and (most importantly) all places which "instantiate" C. Did I miss anything?

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On 08/18/2010 06:46 AM, Vladimir Panteleev wrote:
> On Wed, 18 Aug 2010 13:13:25 +0300, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> http://www.informit.com/articles/article.aspx?p=1622265
>
> Thanks, that was an interesting read.
>
> It's possible that I'm missing something, but I think that C++'s default
> constructors + reference-type structs/classes allow a pattern which
> isn't easily translatable to D. For example, in C++...
>
> class A { /* a class with a default constructor */ };
>
> struct B { A a; /* ... */ };
>
> struct C { B b; /* ... */ };
>
> Now, instantiating C will invoke A's constructors. In order for this to
> work, the compiler automatically generates hidden constructors for B and
> C. However, D doesn't have default constructors for structs (and,
> according to TDPL, never will)? D does seem to generate hidden postblit
> constructors and destructors, though.

Don't forget that non-default constructors are fair game though. I agree that for this idiom it would be nice to have the default constructor guarantee execution of certain initializations.

> If I had to port a C++ project to D which made heavy use of this
> pattern, what would be the best way to do it? The only ways I see is
> either rewriting the code to use classes (which means writing
> constructors with explicit instantiation, more dereferences and heap
> usage leading to worse performance...), or implementing and calling
> pseudo-constructors in both B and C, and (most importantly) all places
> which "instantiate" C. Did I miss anything?

One simple technique I use is to write and use factory functions. They are particularly handy when C is also a template struct.


Andrei

Andrei Alexandrescu:
> http://www.reddit.com/r/programming/comments/d2j8n/d_programming_language_interview_with_andrei/

I will need time to digest this interesting second part of your interview, you say many complex things.

In the meantime that Reddit thread is one of the worst I've seen on that usually interesting site. Some C++ programmers seem to hate D a lot. Each new programming language is built on different values. Maybe D2 is not targeted to most of the experienced C++ programmers. Maybe D2 is more fit for other kinds of programmers, after all. I don't know.

Among all the comments written by axilmar, I agree that D tuples are not in good shape at all. There are two of them, one is limited (no way to return them) and auto-flattening, the other has no compiler support despite some syntax sugar helps a lot here.

Regarding this you have written in Reddit:
>Even moving classes should be fine with precautions, as moving garbage collectors have shown.<

Currently in the D2 GC there is no notion of pinned/unpinned class instances, but eventually an attribute as @pinned may be added to D3, plus its related semantics. It adds complexity to the language and it needs to interact with the GC, so it will get useful as the D GC becomes more modern (with different zones for newly allocated objects, etc).

Bye,
bearophile

bearophile wrote:
> Currently in the D2 GC there is no notion of pinned/unpinned class instances,
> but eventually an attribute as @pinned may be added to D3, plus its related
> semantics. It adds complexity to the language and it needs to interact with
> the GC, so it will get useful as the D GC becomes more modern (with different
> zones for newly allocated objects, etc).

There is no need for a pin attribute, the gc can determine if a class needs pinning or not.

On 2010-08-18 06:13:25 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> http://www.informit.com/articles/article.aspx?p=1622265
> 
> Andrei

Quoting:
"""
The most difficult scenario here is a class that has a struct as a member. If the struct has a destructor, it will be run non-deterministically—or possibly not at all.
"""

Or cause a race condition:
<http://d.puremagic.com/issues/show_bug.cgi?id=4624>

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Wednesday, August 18, 2010 09:59:27 bearophile wrote:
> Andrei Alexandrescu:
> > http://www.reddit.com/r/programming/comments/d2j8n/d_programming_language _interview_with_andrei/
> 
> I will need time to digest this interesting second part of your interview, you say many complex things.
> 
> In the meantime that Reddit thread is one of the worst I've seen on that usually interesting site. Some C++ programmers seem to hate D a lot. Each new programming language is built on different values. Maybe D2 is not targeted to most of the experienced C++ programmers. Maybe D2 is more fit for other kinds of programmers, after all. I don't know.

Every language has those who like it and those who don't. And everyone who uses a language has their own reasons for liking it or disliking. In many ways, D is striking the spot between C++ and Java/C#. It's trying to have the power and efficiency of C++ while having the saftey of Java and C#. As such, it will attract people from both camps, but there are going to be people from both camps who aren't going to like it, if nothing else because it goes too far towards the other end of the spectrum for them. And when you like one language and are well aware of its pros and cons and then go and look at another language, it's very easy to see things that don't match what you like about the language that you know, and without really working with it, you're not really going to be well enough of all of its pros and cons to really decide whether those differences are worth it. I'm both a C++ and Java programmer, and I love D. In many ways, it's exactly what I'm looking for in a language, which is why I'm so excited about it, but there are plenty of things in D which can be very annoying - like the lack of struct default constructors (or as you mentioned, the state of tuples).

Ultimately, the folks who are most likely to be interested in D are those who aren't entirely happy with the language that they're using and find D's feature set to be an attractive alternative - that and the folks who are forced to use it because that's what's being used on the project that they're working on, but that's likely fairly rare at this point.

In any case, I'm certain that there are a lot of C++ programmers who will love D and a lot who will hate it.

- Jonathan M Davis

Walter Bright, el 18 de agosto a las 10:08 me escribiste:
> bearophile wrote:
> >Currently in the D2 GC there is no notion of pinned/unpinned class instances, but eventually an attribute as @pinned may be added to D3, plus its related semantics. It adds complexity to the language and it needs to interact with the GC, so it will get useful as the D GC becomes more modern (with different zones for newly allocated objects, etc).
> 
> There is no need for a pin attribute, the gc can determine if a class needs pinning or not.

As long as the precise heap scanning patch is applied (and much better
if we can manage to scan the static data precisely too). Otherwise you
simply just can't move stuff around because you don't know what is
a pointer and what is not (thus you can't update pointer that point to
moved stuff).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hoy estuvimos en el museo de antropología, pero yo voy a volver
para estar por lo menos un día ahí adentro... es una locura, como Disney pero
de indigenas
	-- Carla Lucarella (10/2008 contando de su viaje a México)

Leandro Lucarella wrote:
> Walter Bright, el 18 de agosto a las 10:08 me escribiste:
>> bearophile wrote:
>>> Currently in the D2 GC there is no notion of pinned/unpinned class instances,
>>> but eventually an attribute as @pinned may be added to D3, plus its related
>>> semantics. It adds complexity to the language and it needs to interact with
>>> the GC, so it will get useful as the D GC becomes more modern (with different
>>> zones for newly allocated objects, etc).
>> There is no need for a pin attribute, the gc can determine if a
>> class needs pinning or not.
> 
> As long as the precise heap scanning patch is applied (and much better
> if we can manage to scan the static data precisely too). Otherwise you
> simply just can't move stuff around because you don't know what is
> a pointer and what is not (thus you can't update pointer that point to
> moved stuff).

Hence the objects with ambiguous references to them get automatically pinned by the gc. I've implemented such a gc before, it works fine. It's called a "mostly copying collector".

Besides, any scheme where you have to manually mark pinnable objects is doomed to have disastrously subtle and hard-to-find bugs.