Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Address of a function under GCC
33 views
Skip to first unread message
Alf P. Steinbach
Jan 16, 2016, 4:38:40 PM1/16/16
to
On 1/16/2016 9:46 PM, Stefan Ram wrote:
>
> Does this mean that »the address of 'int f()' will always
> evaluate as 'true'« is false?
No. It means that the interpretion where this says that `&f` is the
value `true`, is meaningless.
> If it is false, what had the author in mind?
That the address of a function converts implicitly to `true`, and never
to `false`, since it's always non-zero.
This is also the case with the address of a variable, but iostreams have
an overload of `<<` that takes a pointer to void, which will be used
unless it's address of a `char`, which will be interpreted as a C
string. So, for data pointers the `bool` overload isn't considered.
These overloads are not considered for address of function, because
there's no implicit conversion between data pointers and function
pointers (apparently in support of Harvard architectures), and until
C++11 an implementation was not even formally allowed to support
`reinterpret_cast` between them, which was and is required by Posix, and
by the Windows API, and other in-practice programming.
Cheers & hth.,
- Alf
>
> Does this mean that »the address of 'int f()' will always
> evaluate as 'true'« is false?
No. It means that the interpretion where this says that `&f` is the
value `true`, is meaningless.
> If it is false, what had the author in mind?
That the address of a function converts implicitly to `true`, and never
to `false`, since it's always non-zero.
This is also the case with the address of a variable, but iostreams have
an overload of `<<` that takes a pointer to void, which will be used
unless it's address of a `char`, which will be interpreted as a C
string. So, for data pointers the `bool` overload isn't considered.
These overloads are not considered for address of function, because
there's no implicit conversion between data pointers and function
pointers (apparently in support of Harvard architectures), and until
C++11 an implementation was not even formally allowed to support
`reinterpret_cast` between them, which was and is required by Posix, and
by the Windows API, and other in-practice programming.
Cheers & hth.,
- Alf
Paavo Helde
Jan 16, 2016, 4:51:17 PM1/16/16
to
On 16.01.2016 22:46, Stefan Ram wrote:
> int f(){ return 7; }
> int main() { ::std::cout << f << "\n"s; }
> 9 29 [Warning] the address of 'int f()' will always evaluate as 'true' [-Waddress]
... in this context.
All statements always need to be interpreted in a context. Like, that
the statement is written in English, it is about C++, and it talks
about the usage of f in the indicated source code line.
> int f(){ return 7; }
> int main() { ::std::cout << f << "\n"s; }
> 9 29 [Warning] the address of 'int f()' will always evaluate as 'true' [-Waddress]
... in this context.
All statements always need to be interpreted in a context. Like, that
the statement is written in English, it is about C++, and it talks
about the usage of f in the indicated source code line.
Juha Nieminen
Jan 18, 2016, 5:13:35 AM1/18/16
to
Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> In function 'int main()':
You don't understand what the compiler's message is saying. It's saying that
"*here* the address always evaluates to true". In other words, where the address
is being used at that line.
If you change the line, then it might not just evaluate to 'true' anymore.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
> In function 'int main()':
> 9 29 [Warning] the address of 'int f()' will always evaluate as 'true' [-Waddress]
>
> Let me test this!
>
You don't understand what the compiler's message is saying. It's saying that
"*here* the address always evaluates to true". In other words, where the address
is being used at that line.
If you change the line, then it might not just evaluate to 'true' anymore.
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
0 new messages