Who originated the term "Miranda function"?

  • Thread starter Robert Allan Schwartz
  • Start date
R

Robert Allan Schwartz

I've heard the phrase "Miranda function" used to refer to the 6 member
functions supplied by the compiler:

default constructor
copy constructor
destructor
operator=
operator& const
operator&

Does anyone know who was the first person to use that phrase?

I'd like to credit them in my training materials.

Thanks,

Robert Schwartz
Senior Instructor
Tessellation Training
http://www.tessellation.com
 
A

Alf P. Steinbach

* Robert Allan Schwartz:
I've heard the phrase "Miranda function" used to refer to the 6 member
functions supplied by the compiler:

default constructor
copy constructor
destructor
operator=
operator& const
operator&

The last two are not supplied by the compiler.
 
R

Richard Herring

Alf P. Steinbach said:
* Robert Allan Schwartz:

The last two are not supplied by the compiler.
So you can't take the address of an object of class type?
 
J

JKop

Robert Allan Schwartz posted:
I've heard the phrase "Miranda function" used to refer to the 6 member
functions supplied by the compiler:

default constructor
copy constructor
destructor
operator=
operator& const
operator&

Does anyone know who was the first person to use that phrase?

I'd like to credit them in my training materials.

Thanks,

Robert Schwartz
Senior Instructor
Tessellation Training
http://www.tessellation.com

Stephen R. Davis

Author of C++ for Dummies.


He says something like:

"...which I like to call the Miranda functions, ie. if you can't supply your
own, the court will supply them for you"


It's being a good while since I've read the book but that's the jist of it.


-JKop
 
R

Richard Herring

Alf P. Steinbach said:
* Richard Herring:

What do you mean, if anything?
I mean, if you have this,

class T {}
T a;
T * p = & a;

what makes the third line work? _I_ certainly didn't define
T::eek:perator&().
 
D

Dietmar Kuehl

* Robert Allan Schwartz:

The last two are not supplied by the compiler.

I typically don't implement the address-of operators for the classes I write
but I still can take the address of the corresponding objects. Thus, it
seems that the compiler actually implements these methods. Without thinking
too hard about it, I can come up with at least one more function which is
also supplied by the compiler for all types: the comma operator. Also,
'operator new()' and 'operator delete()' are supplied. Of course, none of
these function is necessarily really generated but they are conceptually
used. ... and the supplied comma operator even follows ruls not available
to an explicit implementation (the order of argument evaluation). However,
the supplied constructors and destructors are also not necessarily generated.
 
R

Richard Herring

Richard Herring said:
I mean, if you have this,

class T {} ; // oops!
T a;
T * p = & a;

what makes the third line work? _I_ certainly didn't define
T::eek:perator&().
 
A

Alf P. Steinbach

* Richard Herring:
I mean, if you have this,

class T {}

You need a semicolon after that.

T a;
T * p = & a;

what makes the third line work? _I_ certainly didn't define
T::eek:perator&().

Heh. The first four functions are "special member functions"
which the compiler generates if you don't define them yourself.
The special member functions are listed and discussed in §12,
which is titled "Special member functions".

The address operator is not a special member function, and no
address operator is generated by the compiler. I gather that
the "for dummies" book refererred to elsewhere in this thread
says otherwise. If so that's just Another Glaring Error (TM).

The third line of your example works the same as e.g. the
expression 2+x for int x, namely, it is directly translated by
the compiler. Note that the compiler knows the address. In a
reasonable implementation no code is generated for the operator
itself or its application, only for the usage of the result.

Perhaps you or the "for dummies" author have been misled by
§13.6/1 which states in a note that "because built-in operators
take only operands with non-class type, ...".

That wording is possibly a defect in the standard (it is
contradicted a large number of places including the definition of
the address operator and §13.3.1.2/9, "if the operator is the
operator ',', the unary operator '&', or the operator '->', and
there are no viable functions, then the operator is assumed to
be the built-in operator"); it was however not corrected in TC1.
 
A

Alf P. Steinbach

* Dietmar Kuehl:
I typically don't implement the address-of operators for the classes I write
but I still can take the address of the corresponding objects.

That's according to §13.3.1.2/9, which says the built-in operator is used
if no viable function is found for operator ',', unary '&' or '->'.

Thus, it seems that the compiler actually implements these methods.

On the contrary.

The first four functions are special member functions (that's not my use of
"special" but the standard's terminology) which the compiler generate if you
don't define them; unary '&' is not a special member function.
 
R

Richard Herring

Alf P. Steinbach said:
* Richard Herring:

You need a semicolon after that.

True - corrected elsethread.
Heh. The first four functions are "special member functions"
which the compiler generates if you don't define them yourself.
The special member functions are listed and discussed in §12,
which is titled "Special member functions".

The address operator is not a special member function,

Granted. But I think you are the first to raise this concept.
and no
address operator is generated by the compiler.

That's just semantics. The compiler certainly "supplies" the necessary
provision for the taking-the-address operation. Whether you can refer to
that as a built-in
I gather that
the "for dummies" book refererred to elsewhere in this thread
says otherwise. If so that's just Another Glaring Error (TM).

I wouldn't know about that.
The third line of your example works the same as e.g. the
expression 2+x for int x, namely, it is directly translated by
the compiler.

Indeed. Is effect is to apply the operator + to two ints. Arguing about
whether operator+(int, int) really "exists" or is "built-in" is again
just a matter of semantics.
Note that the compiler knows the address. In a
reasonable implementation no code is generated for the operator
itself or its application, only for the usage of the result.

Nor is any code generated for the compiler-generated "destructor" in
many cases, so you can't use code generation as a test for the reality
of a function.
Perhaps you or the "for dummies" author have been misled by
§13.6/1 which states in a note that "because built-in operators
take only operands with non-class type, ...".

Not me.
 
A

Alf P. Steinbach

* Richard Herring:
Granted. But I think you are the first to raise this concept.

To repeat myself, they're discussed in §12.

The address operator is not one, _and_ there are other operators
like the address operator not in the list given by Robert.

RTFM.
 
P

Paul Mensonides

Alf said:
* Richard Herring:

To repeat myself, they're discussed in §12.

The address operator is not one, _and_ there are other operators
like the address operator not in the list given by Robert.

The view that the address-of operator is magically supplied by the compiler is
not inaccurate from a certain point of view. At the same time, from a
technically accurate point of view, Alf is correct. As a proof, you can do
this:

struct X { };
X& (X::* pf)(const X&) = &X::eek:perator=;

but you can't do this:

struct Y { };
Y* (Y::* pf)(void) = &Y::eek:perator&;

Granted, you can't take the address of constructors and destructors, but *if*
you could, then those would work as well.

Regards,
Paul Mensonides
 
M

Mike Wahler

Richard Herring said:
So you can't take the address of an object of class type?

Yes you can, using the built-in address operator (&).

A member operator&() would overload the bitwise 'and' operator
for the class.

-Mike
 
R

Richard Herring

Mike said:
Yes you can, using the built-in address operator (&).

A member operator&() would overload the bitwise 'and' operator
for the class.

No, that would be T::eek:perator&(const T&)
 
O

Old Wolf

Mike Wahler said:
Yes you can, using the built-in address operator (&).

A member operator&() would overload the bitwise 'and' operator
for the class.

operator& with one parameter overloads bitwise and, but with no
parameter, overloads the address-of operator. This is used by
smart-pointer classes, for example.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top