extern(C++) and struct (constness mangling problem ?)

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Nov 29 18:07:21 PST 2011


On 11/29/11 2:22 PM, Timon Gehr wrote:
> On 11/29/2011 10:09 PM, Andrei Alexandrescu wrote:
>> On 11/29/11 11:39 AM, deadalnix wrote:
>>> Le 29/11/2011 19:52, Andrei Alexandrescu a écrit :
>>>> On 11/29/11 10:50 AM, deadalnix wrote:
>>>>> 2/ Use that stract/class as a value type. You can do POD, but also
>>>>> define constructor and destructor, copy constructor and overload
>>>>> assignement. Anyway, you'll never be able to use proper polymorphism
>>>>> here, because it would require virtual destructor at least. This is
>>>>> IMO,
>>>>> what D's struct should achieve.
>>>>
>>>> Yes.
>>>>
>>>>> The 2/ case is overly used in almost any C++ program. And D struct
>>>>> should be able to match them. It wouldn't require much to make it
>>>>> working :
>>>>> - Default constructor.
>>>>
>>>> No.
>>>>
>>>
>>> No, as "No it will never be done for reason xxx" or as in "No you are
>>> wrong and it not necessary, here the way to do : xxx".
>>>
>>> In both cases, the xxx is the most interesting part :'(
>>
>> Neither :o). The default initializer that doesn't do any real "work",
>> does not throw, and puts the object in a state without ex-situ ownership
>> has brought D too many benefits to ignore.
>>
>> We should be able to define types that refuse default initialization (a
>> la non-null pointers), but if the default initializer exists, it's good
>> as it is.
>>
>>
>> Andrei
>>
>
> The default initializer can easily be disabled:
>
> struct S{
> int x;
> @disable this();
> @disable void[0] init;
> @disable this(this);
> }
>
> Now nobody can do
> auto x = S.init;
>
> But it is still possible to do:
>
> S[1] x;
>
> I'd have expected that to fail with disabled this(). Is this a bug?

Yes.

Andrei


More information about the Digitalmars-d mailing list