 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Dread Quixadhal
Guest
|
 Posted: Fri Nov 05, 2004 5:15 pm Post subject: polymorphic utility function? |
 |
|
Hello!
First, let me apologize if this is in five FAQ's and say that C++ is a
complicated enough beasties to need an FAQ for the FAQ. :)
I have a little pet project I'm toying with, and part of my socket class
would like to deal with lines of text as a set of lines. Another part
would rather deal with a buffer as one big chunk of bytes.
So, I have a socket class and decided to write a couple of utility
functions. I put them into a namespace, since other classes might want
to use them, and they really don't belong to anything of their own.
The functions I wanted are simple string implode/explode calls which
would break up a text block by delimiter, or combine a set using a
delimiter. Easy enough.
In writing this, I though it might be nice to make versions that use
linked lists or arrays, and here's where the compiler and I seem to
differ in our attitudes.
Given the following prototypes:
namespace StringUtil {
std::string implode ( std::list<std::string> l, const std::string
pattern );
std::list<std::string> explode ( std::string source, const
std::string pattern );
std::string implode ( std::vector<std::string> v, const std::string
pattern );
std::vector<std::string> explode ( std::string source, const
std::string pattern );
}
*I* think it's obvious that were I to say:
std::vector<std::string> myarray = StringUtil::explode("foornbar",
"rn");
I'd expect myarray to be a vector of the strings "foo" and "bar".
Alas, g++ doesn't agree with my vision and thinks the functions are
ambiguous. In fact, it won't even let me try to use them, it complains
just having the definitions in place. Individually (if I wrap an #if 0
around one pair), they do what I expect, just not together.
I've pondered (in my n00b way) using templates, or just putting them
into a class, but the first seems like building a slaughterhouse just to
get a hamburger, and the second doesn't feel right. I don't want an
object with methods, I just want a polymorphic utility function.
Suggestions are welcome! I'm an old C horse, so try not to dig the
spurs in too hard. :)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Dread Quixadhal
Guest
|
| Posted: Sun Nov 07, 2004 12:05 pm Post subject: Re: polymorphic utility function? |
|
|
Howard wrote:
| Quote: | Dread Quixadhal <quixadhal (AT) yahoo (DOT) com> wrote:
In fact, it won't even let me try to use them, it complains
just having the definitions in place.
As well it should. You aren't allowed to differentiate between
functions by return value alone.
|
While I'm sure the answer is "Because it was designed that way", my
question is, why not? This isn't perl, we have strong types with the
exception of the void pointer, thus the compiler should be perfectly
capable of taking the return type into consideration when deciding what
function call to actually use. It certainly knows if you try to assign
a return value to the wrong type variable, so that check is being done.
I know there are lots of way around this, perhaps the simplest being to
pass in a reference instead of using the return value, but they all seem
to be ugly kludges. Since this is a pet project and not something for
work, I have the luxury of trying to find an elegant solution.
Thanks! Now that I know it's the return value, I can slap a band-aid on
it while I try to find a better way :)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
johnchx
Guest
|
| Posted: Sun Nov 07, 2004 12:08 pm Post subject: Re: polymorphic utility function? |
|
|
Dread Quixadhal <quixadhal (AT) yahoo (DOT) com> wrote
| Quote: | Given the following prototypes:
namespace StringUtil {
std::string implode ( std::list<std::string> l, const std::string
pattern );
std::list<std::string> explode ( std::string source, const
std::string pattern );
std::string implode ( std::vector<std::string> v, const std::string
pattern );
std::vector<std::string> explode ( std::string source, const
std::string pattern );
}
*I* think it's obvious that were I to say:
std::vector<std::string> myarray = StringUtil::explode("foornbar",
"rn");
I'd expect myarray to be a vector of the strings "foo" and "bar".
Alas, g++ doesn't agree with my vision and thinks the functions are
ambiguous. In fact, it won't even let me try to use them, it complains
just having the definitions in place. Individually (if I wrap an #if 0
around one pair), they do what I expect, just not together.
I've pondered (in my n00b way) using templates, or just putting them
into a class, but the first seems like building a slaughterhouse just to
get a hamburger, and the second doesn't feel right. I don't want an
object with methods, I just want a polymorphic utility function.
|
The snag you're running into is that C++ overload resolution doesn't
distinguish between functions based on their return types. The
following, for example, doesn't work:
int foo( int );
long foo( int );
int main() {
long l = foo(0); // ambiguous
int i = foo(0); // ambiguous
}
The simplest way to get around this is to use "out parameters" - have
the function do its work by modifiying one of the parameters you're
passing in - instead of the usual return mechanism. In your case this
could look like:
// std:: qualifiers omitted
void explode( const string& source,
const string& pattern,
vector<string> & output )
{
vector<string> temp;
// do work, put results into temp
temp.swap( output );
}
void explode( const string& source,
const string& pattern,
list<string> & output )
{
list<string> temp;
// do work, put results into temp
temp.swap( output );
}
int main()
{
list<string> ls;
explode("lalalala", "a", ls);
vector<string> vs;
explode("lalalala", "a", vs);
}
If you like, you can go further and make explode a function template:
template < class T >
void explode( const string& source,
const string& pattern,
T& output )
{
T temp;
// do work, put results in temp
temp.swap( output );
}
If you do this, be careful how you put the results ino the temp
container. Common functions like push_back() aren't defined for all
containers. The form:
temp.insert( temp.end(), some_value );
will, if I recall correctly, work for all of the standard containers.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Mon Nov 08, 2004 11:45 pm Post subject: Re: polymorphic utility function? |
|
|
Dread Quixadhal <quixadhal (AT) yahoo (DOT) com> wrote
| Quote: | I have a little pet project I'm toying with, and part of my socket
class would like to deal with lines of text as a set of lines.
Another part would rather deal with a buffer as one big chunk of
bytes.
So, I have a socket class and decided to write a couple of utility
functions. I put them into a namespace, since other classes might
want to use them, and they really don't belong to anything of their
own.
The functions I wanted are simple string implode/explode calls which
would break up a text block by delimiter, or combine a set using a
delimiter. Easy enough.
In writing this, I though it might be nice to make versions that use
linked lists or arrays, and here's where the compiler and I seem to
differ in our attitudes.
Given the following prototypes:
namespace StringUtil {
std::string implode ( std::list<std::string> l, const std::string
pattern );
std::list<std::string> explode ( std::string source, const
std::string pattern );
std::string implode ( std::vector<std::string> v, const std::string
pattern );
std::vector<std::string> explode ( std::string source, const
std::string pattern );
}
*I* think it's obvious that were I to say:
std::vector<std::string> myarray = StringUtil::explode("foornbar",
"rn");
I'd expect myarray to be a vector of the strings "foo" and "bar".
Alas, g++ doesn't agree with my vision and thinks the functions are
ambiguous. In fact, it won't even let me try to use them, it
complains just having the definitions in place. Individually (if I
wrap an #if 0 around one pair), they do what I expect, just not
together.
|
C++ doesn't support overloading on return types, for a number of
reasons. The usual solution to this problem is to return a proxy. In
your case, you might have explicit functions (e.g. explodeList,
explodeVector, etc.), or possibly some template solution (e.g. template<
typename Return > Return doExplode). The explode function doesn't do
much itself; it just returns a proxy class, with a conversion operator,
say:
class Proxy
{
public:
template< typename T >
operator T() const
{
return doExplode< T >( ... ) ;
}
// ...
} ;
This way, there's no abiguity on the explode function, since the
function isn't overloaded. And the compiler will resolve the ambiguity
of the type conversion, because it only tries to do the conversion when
it knows what type it really needs (and notes that this type isn't
Proxy, which is what it has).
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Allan W
Guest
|
| Posted: Tue Nov 09, 2004 12:28 pm Post subject: Re: polymorphic utility function? |
|
|
Dread Quixadhal <quixadhal (AT) yahoo (DOT) com> wrote
| Quote: | Howard wrote:
You aren't allowed to differentiate between
functions by return value alone.
While I'm sure the answer is "Because it was designed that way",
|
Yes, of course it is.
| Quote: | my
question is, why not? This isn't perl, we have strong types with the
exception of the void pointer, thus the compiler should be perfectly
capable of taking the return type into consideration when deciding what
function call to actually use.
|
Imagine that you could differentiate between functions based only on
return type.
int foo(int); // #1
short foo(int); // #2
int a1 = foo(1); // Calls 1
short a2 = foo(1); // Calls #2
double a3 = foo(1); // Whoops! Standard promotion rules -- but which one?
void bar(int, short);
void bar(short, int);
bar(foo(1),foo(1)); // Which is which?!?
// Sometimes we don't even use the return type!
foo(1); // Which one does this call?
Also, look up "proxy" return values, where the return type is never the
one that the user plans to use (it returns a class type with two or
more conversion operators). Would this continue to work?
Solving these issues in a way that fits in with the rest of the language,
would be very complicated.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Michiel Salters
Guest
|
| Posted: Tue Nov 09, 2004 12:35 pm Post subject: Re: polymorphic utility function? |
|
|
Dread Quixadhal <quixadhal (AT) yahoo (DOT) com> wrote
| Quote: | Howard wrote:
Dread Quixadhal <quixadhal (AT) yahoo (DOT) com> wrote:
In fact, it won't even let me try to use them, it complains
just having the definitions in place.
As well it should. You aren't allowed to differentiate between
functions by return value alone.
While I'm sure the answer is "Because it was designed that way", my
question is, why not? This isn't perl, we have strong types with the
exception of the void pointer, thus the compiler should be perfectly
capable of taking the return type into consideration when deciding what
function call to actually use.
|
How can you take the return type into account? You're assigning it
to a vector<string>, true. But that assignment is just another
function call. So basically, you have an expression of the form
foo( bar(X) );. You want to overload on the return type of bar()
as well? Before determining which foo() to use? Or after? This
would give you two degrees of freedom, where you really can have
only one. So C++ chose to have overloading on argument type
instead of overloading on return type.
BTW, the problem is even worse if foo( T ) is a template. Do
you instantiate foo( T ) for every return type of bar()?
| Quote: | It certainly knows if you try to assign
a return value to the wrong type variable, so that check is being done.
|
True, that's a separate function call. But it can do that check
because it knows which of the overloaded assignment operators
are viable, and none of them match.
| Quote: | I know there are lots of way around this, perhaps the simplest being to
pass in a reference instead of using the return value, but they all seem
to be ugly kludges. Since this is a pet project and not something for
work, I have the luxury of trying to find an elegant solution.
|
Just use a template parameter for the return type.
Regards,
Michiel Salters
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Thomas Richter
Guest
|
| Posted: Tue Nov 09, 2004 12:36 pm Post subject: Re: polymorphic utility function? |
|
|
Hi,
| Quote: | While I'm sure the answer is "Because it was designed that way", my
question is, why not?
|
Well, of course because it was designed that way, but not without a reason.
Consider the following situation: You've two classes, A and B, and B is
a specialization of A:
class A {... };
class B : public A { ... };
Thus, you can use a B whereever you need an A. Consider further that A's and
B's are made by the use of factory classes, one for A's and one for B's:
class AFactory {
virtual A *makeNew();
}
class BFactory {
virtual B *makeNew();
}
Now clearly, BFactory should be a specialization of AFactory (since it makes
more specialized objects), and thus, we would like to use this instead:
class BFactory : public AFactory {...}
Now, if the return type would be part of the function type, then BFactory's
makeNew() would not overload AFactory's makeNew(), but this is what a good
design should tell us, namely to use a BFactory transparently wherever an
AFactory is required. And thus, the return type should *not* matter.
So long,
Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
johnchx
Guest
|
| Posted: Tue Nov 09, 2004 9:47 pm Post subject: Re: polymorphic utility function? |
|
|
Dread Quixadhal <quixadhal (AT) yahoo (DOT) com> wrote
| Quote: | Howard wrote:
As well it should. You aren't allowed to differentiate between
functions by return value alone.
While I'm sure the answer is "Because it was designed that way", my
question is, why not?
|
The key thing to notice is that the return type of a function is not
just another parameter type. It determines the type of the
function-call expression.
In C++, every expression (and sub-expression thereof) has a type, and
that type is determined in a "bottom-up" fashion. That is, the type
of an expression may depend on the types of the sub-expressions it
contains, but it never depends on the context in which the expression
appears.
Bottom-up type determination allows overloading on parameters, but not
return type:
void f( int );
void f( long );
int g( int );
long g( long );
f( g( 0 ) );
Reading from the bottom up gives:
literal zero has type int
threfore call g( int ) which has type int
therefore call f(int);
Alternatively, a language might be specified to determine expression
types from the top down, in which case we could overload on return
type, but not parameter types:
// ++C, a mythical top-down-typed language
void f( long ); // note: only one f()
int g( int );
long g( long );
f( g( 0 ) );
Reading from the top down:
parameter of f() has type long
therefore call long g(?)
therefore parameter of g() has type long
threfore convert literal 0 to 0L
In theory, I suspect that it would be possible to define a statically
typed language that supported both top-down and bottom-up type
determination, but it would be complex, both for the compiler and for
the user. (Basically, the compiler would need to identify cycles in
the "type dependency graph" as errors; these could often come as
surprises to the programmer.)
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
kanze@gabi-soft.fr
Guest
|
| Posted: Thu Nov 11, 2004 11:11 am Post subject: Re: polymorphic utility function? |
|
|
[email]johnchx2 (AT) yahoo (DOT) com[/email] (johnchx) wrote in message
news:<4fb4137d.0411091234.2bdc059 (AT) posting (DOT) google.com>...
| Quote: | Dread Quixadhal <quixadhal (AT) yahoo (DOT) com> wrote
Howard wrote:
As well it should. You aren't allowed to differentiate between
functions by return value alone.
While I'm sure the answer is "Because it was designed that way", my
question is, why not?
The key thing to notice is that the return type of a function is not
just another parameter type. It determines the type of the
function-call expression.
In C++, every expression (and sub-expression thereof) has a type, and
that type is determined in a "bottom-up" fashion. That is, the type
of an expression may depend on the types of the sub-expressions it
contains, but it never depends on the context in which the expression
appears.
|
That's only almost true. There is at least one notable exception. What
is the type of &std::find, for example? It's a legal expression -- I
can write:
int* (*pf)( int*, int*, int ) = &std::find ;
for example. But the type of the expression &std::find depends on the
context -- in this case, the type of the variable it is being used to
initialize.
[...]
| Quote: | In theory, I suspect that it would be possible to define a statically
typed language that supported both top-down and bottom-up type
determination, but it would be complex, both for the compiler and for
the user.
|
Never the less, such a language exists, and it is called C++ .
(I don't want to get on to you too much, because what you say IS
generally true, and the exception, above, is just that, and results in
some horrible hacks.)
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Ahti Legonkov
Guest
|
| Posted: Thu Nov 11, 2004 8:29 pm Post subject: Re: polymorphic utility function? |
|
|
Dread Quixadhal wrote:
| Quote: | Given the following prototypes:
namespace StringUtil {
std::string implode ( std::list<std::string> l, const std::string
pattern );
std::list<std::string> explode ( std::string source, const
std::string pattern );
std::string implode ( std::vector<std::string> v, const std::string
pattern );
std::vector<std::string> explode ( std::string source, const
std::string pattern );
}
*I* think it's obvious that were I to say:
std::vector<std::string> myarray = StringUtil::explode("foornbar",
"rn");
|
You can't overload functions that differ by return type only!
Why don't you do it like the algorithms in STL do - work on
iterators, not on specific containers? This way your code is not
limited to std::vector<std::string> and std::list<std::string> only.
template <typename Iterator>
std::string implode(Iterator first, Iterator last,
std::string const& pattern);
template <typename Iterator>
void explode(std::string const& source, std::string const& pattern,
Iterator i);
And the you would use them this way:
std::vector<std::string> marray;
StringUtil::explode("foornbar", "rn",
std::back_inserter(marray));
--
Ahti Legonkov
leg zero at hot dot ee
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Thomas Mang
Guest
|
| Posted: Fri Nov 12, 2004 12:11 pm Post subject: Re: polymorphic utility function? |
|
|
"johnchx" <johnchx2 (AT) yahoo (DOT) com> schrieb im Newsbeitrag
news:4fb4137d.0411091234.2bdc059 (AT) posting (DOT) google.com...
| Quote: | Dread Quixadhal <quixadhal (AT) yahoo (DOT) com> wrote
Howard wrote:
As well it should. You aren't allowed to differentiate between
functions by return value alone.
While I'm sure the answer is "Because it was designed that way", my
question is, why not?
The key thing to notice is that the return type of a function is not
just another parameter type. It determines the type of the
function-call expression.
In C++, every expression (and sub-expression thereof) has a type, and
that type is determined in a "bottom-up" fashion. That is, the type
of an expression may depend on the types of the sub-expressions it
contains, but it never depends on the context in which the expression
appears.
|
Mostly, yes.
However, there are exceptions:
struct test
{
operator double();
operator int();
};
int main()
{
test T;
double D = T; // works
char C = T; // doesn't work
}
As you see, the type of the expression T depends on the context in which it
is used.
Another example are the adresses of overloaded functions.
Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
johnchx
Guest
|
| Posted: Fri Nov 12, 2004 7:27 pm Post subject: Re: polymorphic utility function? |
|
|
[email]kanze (AT) gabi-soft (DOT) fr[/email] wrote
| Quote: | johnchx2 (AT) yahoo (DOT) com (johnchx) wrote in message
news:<4fb4137d.0411091234.2bdc059 (AT) posting (DOT) google.com>...
The key thing to notice is that the return type of a function is not
just another parameter type. It determines the type of the
function-call expression.
In C++, every expression (and sub-expression thereof) has a type, and
that type is determined in a "bottom-up" fashion. That is, the type
of an expression may depend on the types of the sub-expressions it
contains, but it never depends on the context in which the expression
appears.
That's only almost true. There is at least one notable exception. What
is the type of &std::find, for example? It's a legal expression -- I
can write:
int* (*pf)( int*, int*, int ) = &std::find ;
for example. But the type of the expression &std::find depends on the
context -- in this case, the type of the variable it is being used to
initialize.
[...]
|
Good point, I overlooked that case (13.4).
I've pondered this for a while, trying to put my finger on why
accomodating this special case would be significantly easier on
compiler writers than allowing overload resolution to take account of
return types, and I'm not seeing it.
I attempted this formulation of the reason becasue I found the other
explanations in this thread unsatisfactory. So far, the explanations
I've read boil down to: "Programmers could write amgiguous code." But
the existing overloading rules allow programmers to write ambiguous
code, and the solution is simple: the compiler complains. Potential
ambiguity is a non-problem.
So I'm back to square one: is there a reason that overload resolution
can't or shouldn't take return type into account? I feel like I'm
missing something blindingly obvious here.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
David Olsen
Guest
|
| Posted: Sat Nov 13, 2004 2:49 am Post subject: Re: polymorphic utility function? |
|
|
Thomas Mang wrote:
| Quote: | "johnchx" <johnchx2 (AT) yahoo (DOT) com> schrieb im Newsbeitrag
news:4fb4137d.0411091234.2bdc059 (AT) posting (DOT) google.com...
In C++, every expression (and sub-expression thereof) has a type, and
that type is determined in a "bottom-up" fashion. That is, the type
of an expression may depend on the types of the sub-expressions it
contains, but it never depends on the context in which the expression
appears.
Mostly, yes.
However, there are exceptions:
struct test
{
operator double();
operator int();
};
int main()
{
test T;
double D = T; // works
char C = T; // doesn't work
}
As you see, the type of the expression T depends on the context in which it
is used.
|
I disagree with this example. The type of the expression "T" is "test".
That type does not depend on context. Objects of type "test" can be
implicitly converted to certain other types (such as double and int),
but that doesn't change the type of the expression "T" itself.
| Quote: | Another example are the adresses of overloaded functions.
|
That is the one good example.
int f(int);
double f(double);
The expression "&f" all by itself doesn't have a type that is
expressible in the C++ type system. Its type has to come from the
context in which it is used, such as
int (*fp)(int) = &f;
--
David Olsen
[email]qg4h9ykc5m (AT) yahoo (DOT) com[/email]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Thomas Mang
Guest
|
| Posted: Sat Nov 13, 2004 2:52 am Post subject: Re: polymorphic utility function? |
|
|
"Thomas Mang" <nospam (AT) pop (DOT) ucsd.edu> schrieb im Newsbeitrag
news:41937c7d$0$9314$3b214f66 (AT) usenet (DOT) univie.ac.at...
| Quote: |
struct test
{
operator double();
operator int();
};
int main()
{
test T;
double D = T; // works
char C = T; // doesn't work
}
As you see, the type of the expression T depends on the context in which
it
is used.
|
Please let me withdraw this.
It is obviously a different issue.
Thomas
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
johnchx
Guest
|
| Posted: Sat Nov 13, 2004 3:24 am Post subject: Re: polymorphic utility function? |
|
|
"Thomas Mang" <nospam (AT) pop (DOT) ucsd.edu> wrote
| Quote: | "johnchx" <johnchx2 (AT) yahoo (DOT) com> schrieb
In C++, every expression (and sub-expression thereof) has a type, and
that type is determined in a "bottom-up" fashion. That is, the type
of an expression may depend on the types of the sub-expressions it
contains, but it never depends on the context in which the expression
appears.
Mostly, yes.
However, there are exceptions:
struct test
{
operator double();
operator int();
};
int main()
{
test T;
double D = T; // works
char C = T; // doesn't work
}
As you see, the type of the expression T depends on the context in which it
is used.
|
No, it really doesn't. The initializer expression has the type test
in both cases. The compiler looks for a valid, unambiguous best
conversion from the type of the initializer expression to the type of
the variable being initialized.
In effect, the compiler adds an intermediate sub-expression, like
this:
test T;
double D = double( T );
char C = char( T );
| Quote: |
Another example are the adresses of overloaded functions.
|
Yes, that *is* an exception. And it troubles me.
I suspect that, in principle, it would be possible to rewrite the
rules to eliminate the exception, by treating an overload set as a
type unto itself (with implicit conversions to function pointers of
the appropriate types). (We'd also have to define address-of to be
the identity operation when applied to an overload set, avoiding the
notion of "pointer-to-overload-set".)
I *think* the semantics wind up being identical to what we have now.
What I'm wondering is whether the fact that we can do that means that
overloading on return type is easier than I thought at first. Because
they really are the same thing.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
