[cfe-dev] Dynamic memory allocation and deleted definitions

[David Blaikie]

I'm not sure this is quite the right wording (I was expecting something
that used the term "odr-used"), but:

5.3.4p17 states "... If the new expression creates an array of objects of
class type, access and ambiguity control are done for the destructor"


On Tue, Nov 26, 2013 at 6:42 AM, Rahul Jain <1989.rahuljain at gmail.com>wrote:

> Hi David, Halfdan,
>
>
> Thanks a lot for your valuable inputs. Got caught up in some personal work
> so couldnt reply
> before.
>
> I tried tracking down the exact wordings to confirm the behaviour, but was
> of no luck.
>
> We are basically putting a restriction on dynamic allocation of an array
> of objects by
> marking the destructor of that class as deleted.
>
> The standard says:
> A program that refers to a deleted function implicitly or explicitly,
> other than to declare it, is ill-formed.
>
> Please if you could help nail down the exact behaviour with reference to
> the standard??
> Would be of great help!
>
> Thanks,
> Rahul
>
>
> On Thu, Nov 14, 2013 at 2:45 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>>
>>
>>
>> On Wed, Nov 13, 2013 at 12:22 PM, Rahul Jain <1989.rahuljain at gmail.com>wrote:
>>
>>> Thanks David, Halfdan for your valuable inputs.
>>> Just need some more clarification so that I get the complete thing.
>>>
>>>
>>> Yes I understood that when we new[] an array of objects and the
>>> constructor of one of the objects throws, the already constructed objects
>>> should be destructed as the complete array construction could not get
>>> through successfully.
>>>
>>> But assume if the constructor is not throwing, and all the objects of
>>> the array get constructed completely, than where does the need of the
>>> destructor call arise from?
>>>
>>> Is it the possibility of a runtime throw which prevents the compiler
>>> from compiling a deleted destructor definition in case of an array
>>> allocation?
>>>
>>
>> Precisely - whether or not an exception occurs is a runtime property, so
>> the compiler can't know whether it will happen and needs to emit the code
>> to handle it regardless.
>>
>>
>>>
>>> Also what exactly is the difference in this context when we define a
>>> default constructor in our class vs a synthesized default constructor in
>>> our class?
>>>
>>
>>  It's possible that GCC is just being lazy, or that there's a requirement
>> that the default ctor is 'nothrow' then no dtors need be called.
>>
>>
>>> g++ seems to accept the synthesized version whereas errors when one
>>> defines a default constructor(as Halfsan mentioned above), whereas clang
>>> rejects both the versions. Who is at fault here?
>>>
>>
>> I'd have to go track down the wording. I don't know off hand.
>>
>>
>>>
>>> Thanks,
>>> Rahul
>>>
>>>
>>>
>>> On Thu, Nov 14, 2013 at 12:22 AM, Halfdan Ingvarsson <halfdan at sidefx.com
>>> > wrote:
>>>
>>>> On 13-11-13 01:39 PM, Rahul Jain wrote:
>>>>
>>>>> But why will the destructor get called if the array is not explicitly
>>>>> deleted?
>>>>>
>>>>
>>>> Because if you new[] an array of objects, and the constructor of one of
>>>> the objects throws an exception, then the already constructed objects will
>>>> get destructed (destroyed?).
>>>>
>>>> Example:
>>>> #include <iostream>
>>>>
>>>>
>>>> int i = 0;
>>>> struct A
>>>> {
>>>>     A() { id = i++; if(id == 5) throw std::exception(); }
>>>>     ~A() { std::cout << "Destroying " << id << "\n"; }
>>>>
>>>>     int id;
>>>> };
>>>>
>>>> int main()
>>>> {
>>>>     try
>>>>     {
>>>>     A *a = new A[10];
>>>>     }
>>>>     catch(...) {}
>>>>     return 0;
>>>> }
>>>>
>>>>  - ½
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131126/776d8ae7/attachment.html>