On May 23, 2:45 pm, Marcel <mstamp...@gmail.com> wrote:

> a. FooBar2 *fb3 = new Foo;
> b. FooBar2 &fb2 = dynamic_cast<Foo&>(new FooBar2);
> c. Foo &foo = dynamic_cast<Foo&>(*(new FooBar2));
> d. Foo &foo = static_cast<Foo&>(FooBar2 f);
> e. Foo &foo2 = new FooBar;

The only valid one is c, but it is extremely stupid and bad practice.
1) there is no need for any cast
2) you don't have any pointer remaining to your dynamically allocated
data. That's a memory leak.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On May 24, 2:12 am, Mathias Gaunard <loufo...@gmail.com> wrote:
> On May 23, 2:45 pm, Marcel <mstamp...@gmail.com> wrote:
>
> > a. FooBar2 *fb3 = new Foo;
> > b. FooBar2 &fb2 = dynamic_cast<Foo&>(new FooBar2);
> > c. Foo &foo = dynamic_cast<Foo&>(*(new FooBar2));
> > d. Foo &foo = static_cast<Foo&>(FooBar2 f);
> > e. Foo &foo2 = new FooBar;
>
> The only valid one is c, but it is extremely stupid and bad practice.
> 1) there is no need for any cast
> 2) you don't have any pointer remaining to your dynamically allocated
> data. That's a memory leak.

But you could do a delete &foo, right?


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On May 24, 10:58 am, mliptak <Meht...@gmail.com> wrote:

> But you could do a delete &foo, right?

Yes, but I wouldn't want to have such a thing in real code.



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hi,

Mathias Gaunard wrote:
> On May 24, 10:58 am, mliptak <Meht...@gmail.com> wrote:
> 
>> But you could do a delete &foo, right?
> 
> Yes, but I wouldn't want to have such a thing in real code.

I guess the implication here is that a reference should never denote
ownership? If so, what are the arguments supporting this idea?

Thanks!
-Al-

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On May 25, 12:55 pm, Al <t...@haik.us> wrote:

> I guess the implication here is that a reference should never denote
> ownership? If so, what are the arguments supporting this idea?

Consistency.
References usually don't own what they reference (they're only
references to other variables, as it becomes obvious when you pass
values by reference for example).

If you need to call delete on some references and not on some others,
it rapidly becomes a mess where any error is fatal.



-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Hi,

Mathias Gaunard wrote:
> On May 25, 12:55 pm, Al <t...@haik.us> wrote:
> 
>> I guess the implication here is that a reference should never denote
>> ownership? If so, what are the arguments supporting this idea?
> 
> Consistency.
> References usually don't own what they reference (they're only
> references to other variables, as it becomes obvious when you pass
> values by reference for example).
> 
> If you need to call delete on some references and not on some others,
> it rapidly becomes a mess where any error is fatal.

Er... this is circular logic. We don't do A because we don't usually do
A. The same thing could be said of pointers.

Cheers,
-Al-







-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Al wrote:
> Hi,
> 
> Mathias Gaunard wrote:
>> On May 24, 10:58 am, mliptak <Meht...@gmail.com> wrote:
>>
>>> But you could do a delete &foo, right?
>>
>> Yes, but I wouldn't want to have such a thing in real code.
> 
> I guess the implication here is that a reference should never denote
> ownership? If so, what are the arguments supporting this idea?

Because a reference does not manage the object that it refers to.
When it goes out of scope, the object will cause a memory leak.

On the same grounds, I wouldn't let a (raw) pointer point to the object
it "owns"; using a smart pointer of some sort is always preferred.

Nevertheless, using a reference to denote ownership is much worse than
using a (raw) pointer for the same purpose, because references are
almost never used that way. But (raw) pointers are sometimes used that
way; primarily because the 'new' expression returns a raw pointer, and
it's only discipline that leads to consistent use of smart pointers.
On the other hand, using the dereference operator to get the reference
from the new expression, keeping the reference, and using the address-of
operator at the delete expression... is just an obfuscation, hardly with
justification.

-- 
Seungbeom Kim

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Al wrote:
> Hi,
> 
> Mathias Gaunard wrote:
>> On May 25, 12:55 pm, Al <t...@haik.us> wrote:
>>
>>> I guess the implication here is that a reference should never denote
>>> ownership? If so, what are the arguments supporting this idea?
>>
>> Consistency.
>> References usually don't own what they reference (they're only
>> references to other variables, as it becomes obvious when you pass
>> values by reference for example).
>>
>> If you need to call delete on some references and not on some others,
>> it rapidly becomes a mess where any error is fatal.
> 
> Er... this is circular logic. We don't do A because we don't usually do
> A.

Circular logic is bad if you need to prove something, but it's not
necessarily bad if you just need to explain why for something. There are
things that we don't do primarily because we don't usually do them.
(Of course, it's often the case that there are good reasons behind,
though not evident or outright.)

If you try something not "customary" even if there are more "customary"
ways to do it, people will think it's "weird" and begin to wonder why
you did it that way, distracted from more important things.
On the other hand, there are things so "customary" that people can
instantly recognise them; we call them "idioms" or "patterns", and they
are good because they facilitate understanding.

> The same thing could be said of pointers.

True. But doing it [carrying ownership] on references is much more
"weird" than doing it on pointers, for some reasons I mentioned in
another post of mine. Another reason is that references are harder to
tell apart from the objects they refer to, than pointers are to tell
apart from the objects they point to.

-- 
Seungbeom Kim

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]