By L. F.


2019-04-15 10:20:12 8 Comments

Consider the following code:

#include <cctype>
#include <functional>
#include <iostream>

int main()
{
    std::invoke(std::boolalpha, std::cout); // #1

    using ctype_func = int(*)(int);
    char c = std::invoke(static_cast<ctype_func>(std::tolower), 'A'); // #2
    std::cout << c << "\n";
}

Here, the two calls to std::invoke are labeled for future reference. The expected output is:

a

Is the expected output guaranteed?

(Note: there are two functions called tolower — one in <cctype> and the other in <locale>. The explicit cast is introduced to select the desired overload.)

1 comments

@L. F. 2019-04-15 10:20:12

Short answer

No.

Explanation

[namespace.std] says:

Let F denote a standard library function ([global.functions]), a standard library static member function, or an instantiation of a standard library function template. Unless F is designated an addressable function, the behavior of a C++ program is unspecified (possibly ill-formed) if it explicitly or implicitly attempts to form a pointer to F. [Note: Possible means of forming such pointers include application of the unary & operator ([expr.unary.op]), addressof ([specialized.addressof]), or a function-to-pointer standard conversion ([conv.func]). — end note ] Moreover, the behavior of a C++ program is unspecified (possibly ill-formed) if it attempts to form a reference to F or if it attempts to form a pointer-to-member designating either a standard library non-static member function ([member.functions]) or an instantiation of a standard library member function template.

With this in mind, let's check the two calls to std::invoke.

The first call

std::invoke(std::boolalpha, std::cout);

Here, we are attempting to form a pointer to std::boolalpha. Fortunately, [fmtflags.manip] saves the day:

Each function specified in this subclause is a designated addressable function ([namespace.std]).

And boolalpha is a function specified in this subclause. Thus, this line is well-formed, and is equivalent to:

std::cout.setf(std::ios_base::boolalpha);

But why is that? Well, it is necessary for the following code:

std::cout << std::boolalpha;

The second call

std::cout << std::invoke(static_cast<ctype_func>(std::tolower), 'A') << "\n";

Unfortunately, [cctype.syn] says:

The contents and meaning of the header <cctype> are the same as the C standard library header <ctype.h>.

Nowhere is tolower explicitly designated an addressable function.

Therefore, the behavior of this C++ program is unspecified (possibly ill-formed), because it attempts to form a pointer to tolower, which is not designated an addressable function.

Conclusion

The expected output is not guaranteed. In fact, the code is not even guaranteed to compile.


This also applies to member functions. [namespace.std] doesn’t explicitly mention this, but it can be seen from [member.functions] that the behavior of a C++ program is unspecified (possibly ill-formed) if it attempts to take the address of a member function declared in the C++ standard library. Per [member.functions]/2:

For a non-virtual member function described in the C++ standard library, an implementation may declare a different set of member function signatures, provided that any call to the member function that would select an overload from the set of declarations described in this document behaves as if that overload were selected. [ Note: For instance, an implementation may add parameters with default values, or replace a member function with default arguments with two or more member functions with equivalent behavior, or add additional signatures for a member function name. — end note ]

And [expr.unary.op]/6:

The address of an overloaded function can be taken only in a context that uniquely determines which version of the overloaded function is referred to (see [over.over]). [ Note: Since the context might determine whether the operand is a static or non-static member function, the context can also affect whether the expression has type “pointer to function” or “pointer to member function”. — end note ]

Therefore, the behavior of a program is unspecified (possibly ill-formed) if it explicitly or implicitly attempts to form a pointer to a member function in the C++ library.

(Thanks for the comment for pointing this out!)

@lubgr 2019-04-15 10:32:16

Related, interesting read (though this article doesn't touch on the concept of an addressable function).

@L. F. 2019-04-15 10:33:54

@lubgr Good point! It should suffice in general.

@zwol 2019-04-15 17:24:04

It is interesting to observe that the C standard takes exactly the opposite perspective: N1570 7.1.4 "...unless explicitly stated otherwise in the detailed descriptions...it is permitted to take the address of a library function." (setjmp is an example of a C library function whose address may not be taken, see 7.13p3.)

@L. F. 2019-04-16 09:37:45

Good to know! This shows that C++ is quite defensive in library usage ;-)

@P.W 2019-05-10 05:37:18

@L.F. Does this also apply to member functions of containers? For example would &std::vector<int>::operator[]; be wrong? I believe this is not covered in the above citation from the standard

@L. F. 2019-05-10 07:54:03

Yes, it applies to member functions. &std::vector<isn’t>::operator[] is wrong. I will update my answer to reflect this when I have time.

@Caleth 2019-05-10 10:50:44

I'd like to see what the definition of an isn’t is

@L. F. 2019-05-10 10:54:45

@Caleth I'm sorry! Blame the spell checker ...

Related Questions

Sponsored Content

5 Answered Questions

23 Answered Questions

[SOLVED] Is there a standard sign function (signum, sgn) in C/C++?

  • 2009-12-14 22:27:15
  • batty
  • 314691 View
  • 370 Score
  • 23 Answer
  • Tags:   c++ c math

1 Answered Questions

11 Answered Questions

[SOLVED] Why is f(i = -1, i = -1) undefined behavior?

1 Answered Questions

2 Answered Questions

[SOLVED] Addition of two matrix using struct

0 Answered Questions

Why this function overloading fails in C++?

  • 2015-08-11 07:00:53
  • Kamel
  • 119 View
  • 2 Score
  • 0 Answer
  • Tags:   c++ overloading

0 Answered Questions

std::atomic_is_lock_free(shared_ptr<T>*) didn't compile

  • 2014-02-10 05:32:27
  • 大宝剑
  • 1026 View
  • 6 Score
  • 0 Answer
  • Tags:   c++ c++11

3 Answered Questions

[SOLVED] Why Will This Compile in Visual Studio 2012 But Not UNIX?

  • 2013-10-28 08:25:52
  • Jesse Martinez
  • 336 View
  • 0 Score
  • 3 Answer
  • Tags:   c++ c++11

Sponsored Content