Passing a pointer of constructor

[seank76]

While going through my company's existing codebase, I saw a bunch of
weird lines.

Take a look at this one:

class A
{
public:
A(Foo *f) : _f(f) {}

private:
Foo *_f;
};

class B : public A
{
public:
B() : A(&(Foo &)Foo())) {}
};

How can you pass "Foo()" as the argument to the constructor of A ?
Wouldn't the memory that is allocated to Foo() get destroyed as soon
as we are out of the scope of B()?

What does this mean?

[pmouse]

On May 5, 1:35 pm, pmouse <pmo...@cogeco. cawrote:

On May 4, 10:14 pm, Gianni Mariani <gi3nos...@mari ani.wswrote:

pmouse wrote:

On May 4, 11:51 am, seank76 <sean...@gmail. comwrote:

...

~A () { if ( _pF ) delete _pF; }

~A () { delete _pF; }

The if ( _pF ) is already checked by delete.

Not in GCC/g++, and many other compilers that I use.
deleting a piece of memory twice will cause a double free exception
(run time)
On the other hand, free() does check for zero pointers.

Regards,

PQ

nevermind, I wasn't thinking.

Regards,

PQ

[James Kanze]

On May 5, 7:35 pm, pmouse <pmo...@cogeco. cawrote:

On May 4, 10:14 pm, Gianni Mariani <gi3nos...@mari ani.wswrote:

pmouse wrote:

On May 4, 11:51 am, seank76 <sean...@gmail. comwrote:

...

~A () { if ( _pF ) delete _pF; }

~A () { delete _pF; }

The if ( _pF ) is already checked by delete.

Not in GCC/g++, and many other compilers that I use.

It is in every compiler I've ever used. Including g++.

deleting a piece of memory twice will cause a double free exception
(run time)

But there's nothing in your code above which has anything to do
with deleting an object twice. You're checking if the pointer
is null. (It would, of course, be better to do so explicitly,
rather than relying on implicit conversions.) And invoking
delete on a null pointer is legal, and works perfectly well with
all major compilers.

-
James Kanze (Gabi Software) email: ja*********@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jim Langston]

"seank76" <se*****@gmail. comwrote in message
news:11******** **************@ y5g2000hsa.goog legroups.com...

On May 3, 5:55 pm, "Alf P. Steinbach" <[e-mail] rote:

>* seank76:

[quoting signatures]

Please don't quote signatures, please read the FAQ before posting.

Please don't say Bullshit to a topic you don't understand.
Please read "Internet Etiquette" manual before you post.

Seank, please don't argue with Victor or Alf. They are the de facto C++
gurus in this newsgroup. They know more than everyone else combined. If
they say something is undefined, it is undefined.

Victor never said it was bullshit. He said to go buy a lottery ticket
because today is your lucky day. A tongue in cheek way of saying, you are
extremely lucky the code is working right now.

What your colliege told you, however, is bullshit as far as the C++ standard
is concerned, which is what we discuss in this newsgroup. If it happens to
work on your compiler in it's current version and OS doesn't mean it's not
undefined behavior. Undefined behavior is just that, undefined. Anything
can happen, including working as you want it to work. Just because it works
doesn't mean it's right.

The next version of your compiler the designers may decide to change
something internal that will break your code, as they have all the right to
do, since they only need to support well defined behavior.

Believe me, I have never seen Alf or Victor respond incorrectly to a topic
they didn't understand. It was just that I, or someone else, didn't
understand the topic ourselves. Victor was right, you are [un]lucky it
works. It is a crap shoot. Go ahead and buy yourself a lottery ticket.