<html>
	<head>
		<title>N1695=04-0135, A Proposal to Make Pointers to Members Callable</title>
		<meta content="http://schemas.microsoft.com/intellisense/ie5" name="vs_targetSchema">
		<meta http-equiv="Content-Language" content="en-us">
		<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
	</head>
	<body bgColor="#ffffff">
		<ADDRESS>Document number: N1695=04-0135</ADDRESS>
		<ADDRESS>Programming Language C++, Evolution Working Group</ADDRESS>
		<ADDRESS>&nbsp;</ADDRESS>
		<ADDRESS>Peter Dimov &lt;<A href="mailto:pdimov@mmltd.net">pdimov@mmltd.net</A>&gt;</ADDRESS>
		<ADDRESS>&nbsp;</ADDRESS>
		<ADDRESS>September 09, 2004</ADDRESS>
		<h1>A Proposal to Make Pointers to Members Callable</h1>
		<h2>Introduction</h2>
		<p>Many standard library algorithms accept function objects - objects that can 
			appear to the left of a function call operator - as arguments. However, 
			pointers to members do not support the function call syntax and cannot be used 
			directly. Instead, they need to be wrapped with the help of <code>std::mem_fun</code>,
			<code>std::mem_fun_ref</code>, or <code>tr1::mem_fn</code>.</p>
		<P>This paper proposes an extension to the C++ language that will allow pointers to 
			member to appear to the left of the function call operator. This will make C++ 
			more regular and enable the more concise and intuitive <code>std::for_each( 
				v.begin(), v.end(), &amp;Shape::draw )</code>. In addition, the 
			specification of two of the components in TR1, <code>tr1::function</code> and <code>
				tr1::bind</code>, will be simplified by omitting the special handling of 
			pointers to members. <code>tr1::mem_fn</code> [<A href="../2003/n1432.htm">N1432</A>] 
			will become redundant and its implementation - the trivial identity function; a 
			pointer to member will have the same properties as the function object returned 
			by <code>tr1::mem_fn</code>.</P>
		<H2>Motivation</H2>
		<P>Expressing equivalent operations with a uniform syntax is important for generic 
			code. The standard library algorithms, such as <code>for_each</code>, can take 
			advantage of the fact that ordinary function pointers and user-defined function 
			objects support a common function call operator:</P>
		<pre>struct X
{
    void f() const;
};

void g(X const &amp; x);

struct H
{
    void operator()(X const &amp; x) const;
};

int main()
{
    std::vector&lt;X&gt; v;
    std::for_each( v.begin(), v.end(), g );
    std::for_each( v.begin(), v.end(), H() );
}
</pre>
		<P>However, calling a member function such as <code>&amp;X::f</code> requires a 
			different syntax, and cannot be performed by <code>for_each</code> directly. A 
			pointer to a member function needs to be adapted - wrapped in a function object 
			- first. The standard library supplies <code>mem_fun</code> and <code>mem_fun_ref</code>
			for this purpose:</P>
		<pre>int main()
{
    std::vector&lt;X&gt; v;
    std::for_each( v.begin(), v.end(), std::mem_fun_ref(&amp;X::f) );

    std::vector&lt;X*&gt; v;
    std::for_each( v.begin(), v.end(), std::mem_fun(&amp;X::f) );
}
</pre>
		<P>This is unnecessarily verbose. The simple</P>
		<code>std::for_each( v.begin(), v.end(), &amp;X::f );</code>
		<P>syntax feels more natural and is much easier to teach.</P>
		<P>The Library Extensions Technical Report [<A href="n1660.pdf">N1660</A>] contains 
			an enhanced member pointer adapter, <code>tr1::mem_fn</code> [<A href="../2003/n1432.htm">1432</A>], 
			that is more convenient than <code>std::mem_fun</code> and <code>std::mem_fun_ref</code>. 
			Nevertheless, its use is still verbose and can be made redundant by the 
			extension proposed herein, which is modeled on the proven semantics of <code>tr1::mem_fn</code>.</P>
		<P>As a reflection of the need for simpler and more accessible syntax, two 
			components of the Technical Report, <code>tr1::function</code> and <code>tr1::bind</code>, 
			treat member pointers exactly as if the proposed extension were already in 
			place. The specification and implementation of these components would be 
			considerably simpler in a language where this is already the case, as the 
			library workarounds implementing the illusion of member pointer callability 
			could be removed.</P>
		<H2>Proposed Text</H2>
		<P>Replace the second part of the third sentence in 5.2.2/1 ([expr.call]/1),</P>
		<BLOCKQUOTE>
			<P>or it shall have pointer to function type.</P>
		</BLOCKQUOTE>
		<P>with</P>
		<BLOCKQUOTE>
			<P>or it shall have pointer to function or pointer to member type.</P>
		</BLOCKQUOTE>
		<P>Add a new paragraph after 5.2.2/1 ([expr.call]/1):</P>
		<BLOCKQUOTE>
			<P>In an ordinary function call of the form <code>pm(a1, ..., aN)</code>, where <code>pm</code>
				is of type "pointer to member of <code>T</code>", <code>T</code> shall be a 
				completely defined class type and <code>N</code> shall be 1 when <code>pm</code>
				is a pointer to data member, <code>M+1</code> when <code>pm</code> is a pointer 
				to a member function taking <code>M</code> arguments. The behavior of the 
				function call when <code>pm</code> is a pointer to a member function is 
				equivalent to <code>(a1.*pm)(a2, ..., aN)</code>, when <code>a1</code> is of a 
				possibly cv-qualified class type of which <code>T</code> is a base class, <code>((*a1).*pm)(a2, 
					..., aN)</code> otherwise. The behavior of the function call when <code>pm</code>
				is a pointer to a data member is equivalent to <code>a1.*pm</code> when <code>a1</code>
				is of a possibly cv-qualified class type of which <code>T</code> is a base 
				class, <code>(*a1).*pm</code> otherwise.</P>
		</BLOCKQUOTE>
		<P>Add</P>
		<BLOCKQUOTE>
			<P>in this context.</P>
		</BLOCKQUOTE>
		<P>to the end of footnote 114.</P>
		<P>[Note: changes are relative to ISO/IEC 14882:2003(E).]</P>
		<H2>Impact on Existing Code</H2>
		<P>The proposal is a pure extension.</P>
		<ADDRESS>--end</ADDRESS>
	</body>
</html>
