Does "void func(MyClass *& myCls)" make sense?

[modemer]

I saw someone use the following code:

void func(MyClass *& myCls)
{
myCls->test();
}

// call func():
func(new MyClass);

Some compiler could compile, but some not.

I don't understand the meaning of function prototype. I guess it's not
a stand C++ prototype. Please don't guess like me if you are not 100%
understanding it because probably I'll have further question if
you answer.

 

[Dietmar Kuehl]

void func(MyClass *& myCls)
{
myCls->test();
}

The above code is OK: it is a function taking a pointer by reference.
It is apparently unnecessary to pass the argument by reference,
though, as it is not changed. If would be a better example if it had
a body like this:

{
myCls = new MyClass();
}

// call func():
func(new MyClass);

However, no compiler shall accept this code with the above
declaration. The function's argument is a temporary pointer to an
object but temporaries cannot be bound to non-const references.

 

[Victor Bazarov]

I saw someone use the following code:

void func(MyClass *& myCls)
{
myCls->test();
}

// call func():
func(new MyClass);

Some compiler could compile, but some not.

I don't understand the meaning of function prototype. I guess it's not
a stand C++ prototype. Please don't guess like me if you are not 100%
understanding it because probably I'll have further question if
you answer.

There is no prototype here. The function 'func' as defined/declared,
takes one argument which is a reference to a non-const pointer to
an object of MyClass.

A Standard-compliant compiler should not compile

func(new MyClass);

because the 'new' expression returns an r-value and a reference to
a non-const pointer cannot be bound to an r-value. You can change
it to

void func(MyClass * const & myCls)
{
myCls->test();
}

then all compilers should compile

func(new MyClass);

, however, this will be a memory leak because the value of the pointer
obtained from 'new' is lost and the memory is never freed and the object
is never destroyed.

V

 

[Pete Becker]

A Standard-compliant compiler should not compile

func(new MyClass);

My usual comment: A Standard-compliant compiler must issue a diagnostic.
The standard doesn't say that this should not compile. Similarly,
Dietmar's "no compiler shall accept this code..." should be "no compiler
shall accept this code without issuing a diagnostic...". Once it issues
a diagnostic the compiler is free to do whatever the compiler writer
wants, including generating an executable file. Of course, the standard
doesn't say what such an executable file should do.

 

[=?iso-8859-1?Q?Ali_=C7ehreli?=]

modemer wrote:

void func(MyClass * const & myCls)
{
myCls->test();
}

then all compilers should compile

func(new MyClass);

, however, this will be a memory leak because the value of the pointer
obtained from 'new' is lost and the memory is never freed and the object
is never destroyed.

That has been exactly my comment after reviewing some code at a previous
company.

It turned out that the member function (here 'test') was actually
registering the 'this' pointer in some static container and such objects
were in fact being deleted later on. Argh!

Memory leak or not, I still know that it's an error to design like that

Ali

 

[modemer]

Victor,

Such appreciate your perfect explanation about "*&"!!!