Function Signatures

[daniell]

I created a function:
void round(double & num)

In the same class file I have also included the cmath header filer
When I try to compile I get an ambiguity error. If I recall
correctly, doesn't the cmath round file have a signature:
double round(double)?
So would not mine be different since I am passing by reference as
opposed to the pass by value of the cmath header file? Or have I been
misunderstanding this aspect of overloading?

 

[Rolf Magnus]

I created a function:
void round(double & num)

In the same class file I have also included the cmath header filer
When I try to compile I get an ambiguity error. If I recall
correctly, doesn't the cmath round file have a signature:
double round(double)?
So would not mine be different since I am passing by reference as
opposed to the pass by value of the cmath header file? Or have I been
misunderstanding this aspect of overloading?

How do you expect the compiler to determine which function to call if you
give it a double?

 

[daniell]

How do you expect the compiler to determine which function to call if you
give it a double?

My questions is, "Does the compiler not consider passing by reference
different from passing by value when determining a signature?"

 

[Lionel B]

I created a function:
void round(double & num)

In the same class file I have also included the cmath header filer When
I try to compile I get an ambiguity error. If I recall correctly,
doesn't the cmath round file have a signature:
double round(double)?
So would not mine be different since I am passing by reference as
opposed to the pass by value of the cmath header file? Or have I been
misunderstanding this aspect of overloading?

But when you call your function, say:

double x = 3.27;
round(x);

how could the compiler know which round() you intended?

Easiest would be to place your function in a namespace, or simply give it
a different name.

 

[daniell]

But when you call your function, say:

double x = 3.27;
round(x);

how could the compiler know which round() you intended?

Easiest would be to place your function in a namespace, or simply give it
a different name.

Ahh ok. Sorry I am very new to c++ programming.

So is there a way to have the compiler always choose my defined
function before using the one included in cmath header file?

 

[Victor Bazarov]

My questions is, "Does the compiler not consider passing by reference
different from passing by value when determining a signature?"

Yes, that's your question. And the answer is, yes. For the purposes
of determining the type of the function, passing by value and passing
by reference are different. Now, if you have

// two _different_ functions 'foo':
void foo(double) {}
void foo(double&) {}

int main() {
double pi = 3.1415926;
foo(pi);
}

How should the compiler know whether you mean to use the value (and
call the former 'foo') or the reference (and call the latter 'foo')?

V

 

[Victor Bazarov]

Ahh ok. Sorry I am very new to c++ programming.

So is there a way to have the compiler always choose my defined
function before using the one included in cmath header file?

Yes, that's simple: give them different names.

V

 

[daniell]

Yes, that's simple: give them different names.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask- Hide quoted text -

- Show quoted text -

ok.

 

[daniell]

ok.- Hide quoted text -

- Show quoted text -

Sorry I meant to give my thanks a misclicked.

In any case, thanks for the prompt responses.

 

[Marcus Kwok]

I created a function:
void round(double & num)

In the same class file I have also included the cmath header filer
When I try to compile I get an ambiguity error. If I recall
correctly, doesn't the cmath round file have a signature:
double round(double)?
So would not mine be different since I am passing by reference as
opposed to the pass by value of the cmath header file? Or have I been
misunderstanding this aspect of overloading?

How would the compiler determine which version of the function to call?

double d = 42.0;
round(d);

 

[Gavin Deane]

Yes, that's simple: give them different names.

Of course, they *should* already have different names. The one in
<cmath> should be called std::round. The OP may have a using
declaration or directive somewhere negating that effect, or it could
just be that they happen not to be using one of the vanishingly few
compilers that implement <cxxx> headers correctly.

Gavin Deane

 

[daniell]

How would the compiler determine which version of the function to call?

double d = 42.0;
round(d);

I thought cmath was a header file compatible with original C
language. And to my knowledge, original C language does not support
namespaces.

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

I thought cmath was a header file compatible with original C
language. And to my knowledge, original C language does not support
namespaces.

No, the whole idea behind the cxxx headers is that they are not
completely the same as the corresponding xxx.h-file, if you want to use
the C-header just use math.h.

 

[Lionel B]

Of course, they *should* already have different names. The one in
<cmath> should be called std::round. The OP may have a using declaration
or directive somewhere negating that effect, or it could just be that
they happen not to be using one of the vanishingly few compilers that
implement <cxxx> headers correctly.

Quite likely the latter, I suspect; gcc, the Intel compiler icc and
Comeau online all accept ::round() but not std::round().

What exactly does the standard say about this?

 

[James Kanze]

Quite likely the latter, I suspect; gcc, the Intel compiler icc and
Comeau online all accept ::round() but not std::round().

When you include <cmath>? Of the three compilers I have
available (g++, Sun CC and VC++), all accept std::sin; all but
Sun CC also accept (incorrectly) just plain sin or ::sin.

With the exception of g++ under Linux (but not under Solaris),
none accept std::round or plain round, as this function isn't
defined in <cmath>. Under Linux, g++ accepts ::round, but not
std::round.

If I include <math.h>, all of the compilers accept both std::sin
and ::sin. VC++ and g++ under Linux also accept ::round (but
not std::round).

What exactly does the standard say about this?

Today:
-- With <cmath>: the functions should only be visible in std::
(not in :, and there is no function round.
-- With <math.h>: the functions should be visible in both std::
and ::, and there is no function round.

The function round() is defined in C99; the current C++ standard
is based on C90 (where it didn't exist). The next version of
C++ will almost certainly support it as well, under the same
rules as the other C functions: in std:: only, if you include
<cmath>, and in both std:: and :: if you include <math.h>. In
the meantime:

-- I expect that generally speaking, most implementations
support it as an extension, at least in <math.h>. This is
the case of VC++, and the GNU libc used by g++ under Linux.

-- Support does depend on the library, and not the compiler.
Thus, g++ does not support it under Solaris, for the simple
reason that the system level <math.h> doesn't support it.

-- G++ still doesn't implement the correct scoping in <cmath>,
probably because it wants to leverage off the system
<math.h>. The other implementations seem to get it right.

 

[Gavin Deane]

When you include <cmath>? Of the three compilers I have
available (g++, Sun CC and VC++), all accept std::sin; all but
Sun CC also accept (incorrectly) just plain sin or ::sin.

In the meantime:

-- G++ still doesn't implement the correct scoping in <cmath>,
probably because it wants to leverage off the system
<math.h>. The other implementations seem to get it right.

Am I missing something? As I read your first paragraph, you observed
incorrect implementation of the scoping of the sin function in g++
*and* VC++.

Gavin Deane

 

[James Kanze]

<snip a lot>

<snip a bit>

Am I missing something? As I read your first paragraph, you observed
incorrect implementation of the scoping of the sin function in g++
*and* VC++.

That's true. When I made the list of points to keep in mind, I
was basically repeating the points *I* keep in mind. And I
don't particularly keep anything in mind about VC++, simply
because it doesn't run on any of the platforms I'm concerned
with.