C++11 binding std function to a overloaded static method - c++11

this question seems a little bit silly to me but I can't find any similar question so sorry if it's trivial
let's say we have a struct:
struct C {
static void f(int i) { std::cerr << (i + 15) << "\n"; }
static void f(std::string s) { std::cerr << (s + "15") << "\n"; }
};
now somewhere else:
std::function<void(int)> f1 = C::f; // this does not compile
void (*f2)(std::string s) = C::f; // this compiles just fine
the error I'm getting is
error: conversion from ‘’ to
non-scalar type ‘std::function’ requested
is there any way to use std::function in such context? what am I missing?
thanks

std::function<void(int)> f1 = C::f; // this does not compile
C::f is an overload set which does not have an address. You can create a wrapper FunctionObject around it:
std::function<void(int)> f1 = [](int x){ return C::f(x); };
void (*f2)(std::string s) = C::f; // this compiles just fine
This line compiles because you're "selecting" the std::string overload of the C::f overload set by explicitly assigning it to a void(*)(std::string) pointer.
You can do the same thing for f1:
std::function<void(int)> f1 = static_cast<void(*)(int)>(&C::f);

Related

How does C++ store variables captured by a lambda that have gone out of scope?

If a function returns a lambda that captures and mutates a value declared in the scope of the function, where/how is that value stored in memory so the lambda may safely use it?
This example is from listing 6.7 in 'Functional Programming in C++' by Ivan Čukić. It's a utility memoization method that caches results for fast lookup later. The contrived usage computes and then retrieves a cached Fibonacci number:
#include <iostream>
#include <map>
#include <tuple>
template <typename Result, typename... Args>
auto make_memoized(Result (*f)(Args...)) {
std::map<std::tuple<Args...>, Result> cache;
return [f, cache](Args... args) mutable -> Result {
const auto args_tuple = std::make_tuple(args...);
const auto cached = cache.find(args_tuple);
if (cached == cache.end()) {
auto result = f(args...);
cache[args_tuple] = result;
return result;
} else {
return cached->second;
}
};
}
unsigned int fib(unsigned int n) {
return n < 2 ? n : fib(n - 1) + fib(n - 2);
}
int main() {
auto fibmemo = make_memoized(fib);
std::cout << "fib(15) = " << fibmemo(15) << '\n';
std::cout << "fib(15) = " << fibmemo(15) << '\n';
}
My expectation was that cache would be destroyed when make_memoized returned, so a retrospective call to the lambda would have referred to a value that has gone out of scope. However it works fine (g++ 9.1 on OSX).
I can't find a concrete example of this sort of usage on cppreference.com. Any help leading me to the right terminology to search for is greatly appreciated.
The [f, cache] captures the vars by value. Once captured by value, the life of the captured var should be same as the lambda itself.
EDIT: If captured by reference (e.g. [f, &cache]), the life of cache and the lambda are no longer linked. So, while the code will still compile, it is no longer safe to use the returned lambda as cache has already been destroyed by then.

Why reference_wrapper behaves differently for built-in types?

I have the following use of std::reference_wrapper for a build in type (double) and for a user defined type (std::string).
Why do they behave differently in the case of the stream operator?
#include<functional> //reference wrapper
#include<iostream>
void fd(double& d){}
void fs(std::string& s){}
int main(){
double D = 5.;
std::reference_wrapper<double> DR(D);
std::cout << "DR = " << DR << std::endl; //ok
fd(DR); // ok
std::string S = "hello";
std::reference_wrapper<std::string> SR(S);
std::cout << "SR = " << static_cast<std::string&>(SR) << std::endl; // ok
std::cout << "SR = " << SR << std::endl; // error: invalid operands to binary expression ('basic_ostream<char, std::char_traits<char> >' and 'std::reference_wrapper<std::string>')
fs(SR); // ok
}
http://coliru.stacked-crooked.com/a/fc4c614d6b7da690
Why in the first case DR is converted to double and printed and in the second it is not? Is there a work around?
Ok, I see now, in the ostream case I was trying to called a templated function that is not resolved:
#include<functional> //reference wrapper
void double_fun(double const& t){};
template<class C>
void string_fun(std::basic_string<C> const& t){};
int main(){
double D = 5.;
std::reference_wrapper<double> DR(D);
double_fun(DR); //ok
std::string S = "hello";
std::reference_wrapper<std::string> SR(S);
string_fun(SR); // error: no matching function for call to 'string_fun'
string_fun(SR.get()); // ok
string_fun(static_cast<std::string&>(SR)); // ok
string_fun(*&SR); // would be ok if `std::reference_wrapper` was designed/coded differently, see http://stackoverflow.com/a/34144470/225186
}
For the first part TC gave you the answer. That is, operator<< for basic_string is templated, and template argument deduction doesn't look through implicit conversions.
You could alternatively call SR.get() if you don't want to explicitly to static_cast your reference wrapper.
Now for the second part, string_fun takes as input arguments std::basic_string<C> objects. When you call:
string_fun(SR);
with SR as input parameter which is of type std::reference_wrapper<std::string>, naturally you get a type mismatch.
What you can do is provide an additional overload:
template<class C>
void string_fun(std::reference_wrapper<std::basic_string<C>> const& t) {
};
Live Demo
Or if you want a more unified treatment you could define your string_fun to take template template arguments, and resolve the type with some kind of type trait magic like bellow:
template<template<typename...> class C, typename T>
void
string_fun(C<T> const &t) {
std::cout <<
static_cast<std::conditional_t<
std::is_same<
std::reference_wrapper<T>, C<T>>::value, T, std::basic_string<T>>>(t) << std::endl;
}
Live Demo

ASIO handler arguments and boost::bind, compile time error

I am struggling with compile time errors, and try as I might, I dont see in what way am I doing it wrong or different from handler function signature as set out in documentation/examples. (I am using Boost 1.41 on Linux)
Please help me understand the error! (included below as snippet)
My application has objects whose methods are handlers for async_* functions. Below is the code snippet. The error is reported in the line labelled as "line 58", where I use boost::bind
class RPC {
public:
char recv_buffer[56];
void data_recv (void) {
socket.async_read_some (
boost::asio::buffer(recv_buffer),
boost::bind ( &RPC::on_data_recv, this, _1, _2 )
); // **<<==== this is line 58, that shows up in error listing**
global_stream_lock.lock();
std::cout << "[" << boost::this_thread::get_id()
<< "] data recvd" << std::endl;
global_stream_lock.unlock();
} // RPC::data_recv
void on_data_recv (boost::system::error_code& ec, std::size_t bytesRx) {
global_stream_lock.lock();
std::cout << "[" << boost::this_thread::get_id()
<< "] bytes rcvd: " << std::endl;
global_stream_lock.unlock();
data_recv(); // call function that waits for more data
} // RPC::on_data_recv
}; // RPC class def
There is a huge error output, but the relevant lines seem to be:
../src/besw.cpp:58: instantiated from here
/usr/include/boost/bind/bind.hpp:385: error: no match for call to ‘(boost::_m fi::mf2<void, RPC, boost::system::error_code&, long unsigned int>) (RPC*&, boost::asio::error::basic_errors&, int&)’
/usr/include/boost/bind/mem_fn_template.hpp:272: note: candidates are: R boost::_mfi::mf2<R, T, A1, A2>::operator()(T*, A1, A2) const [with R = void, T = RPC, A1 = boost::system::error_code&, A2 = long unsigned int]
/usr/include/boost/bind/mem_fn_template.hpp:291: note: R boost::_mfi::mf2<R, T, A1, A2>::operator()(T&, A1, A2) const [with R = void, T = RPC, A1 = boost::system::error_code&, A2 = long unsigned int]
make: *** [src/besw.o] Error 1
When I remove the place holders (_1 and _2) and have a handler without arguments, then it compiles and executes without errors. Here's that modified code snippet.
void data_recv (void) {
socket.async_read_some (
boost::asio::buffer(recv_buffer),
boost::bind ( &RPC::on_data_recv, this )
);
global_stream_lock.lock();
std::cout << "[" << boost::this_thread::get_id()
<< "] data recvd" << std::endl;
global_stream_lock.unlock();
} // RPC::data_recv
void on_data_recv (void) {
...
}
The error code cannot be taken by reference. Make it by-value or by const&:
void on_data_recv(boost::system::error_code/* ec */, size_t /*bytes_transferred*/) {
Also, consider using the Asio specific placeholders:
socket.async_read_some(boost::asio::buffer(recv_buffer),
boost::bind(&RPC::on_data_recv, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred));
Also use proper lock guards. We're in C++! It's easy to make things exception-safe, so why not?
Live On Coliru
#include <boost/asio.hpp>
#include <boost/bind.hpp>
#include <iostream>
#include <boost/thread.hpp>
static boost::mutex global_stream_lock;
class RPC {
char recv_buffer[56];
public:
void data_recv() {
socket.async_read_some(boost::asio::buffer(recv_buffer),
boost::bind(&RPC::on_data_recv, this, boost::asio::placeholders::error, boost::asio::placeholders::bytes_transferred));
boost::lock_guard<boost::mutex> lk(global_stream_lock);
std::cout << "[" << boost::this_thread::get_id() << "] data recvd" << std::endl;
global_stream_lock.unlock();
}
void on_data_recv(boost::system::error_code/* ec */, size_t /*bytes_transferred*/) {
{
boost::lock_guard<boost::mutex> lk(global_stream_lock);
std::cout << "[" << boost::this_thread::get_id() << "] bytes rcvd: " << std::endl;
}
data_recv(); // call function that waits for more data
}
boost::asio::io_service service;
boost::asio::ip::tcp::socket socket{service};
}; // RPC class def
int main() {}

Is this an example of reference reassignment? C++11

As I understand it, one cannot change the reference variable once it has been initialized. See, for instance, this question. However, here is a minmal working example which sort of does reassign it. What am I misunderstanding? Why does the example print both 42 and 43?
#include <iostream>
class T {
int x;
public:
T(int xx) : x(xx) {}
friend std::ostream &operator<<(std::ostream &dst, T &t) {
dst << t.x;
return dst;
}
};
int main() {
auto t = T(42);
auto q = T(43);
auto &ref = t;
std::cerr << ref << std::endl;
ref = q;
std::cerr << ref << std::endl;
return 0;
}
You're not changing the reference here.
You are replacing the object the reference is referring to.
In other words: after the assignment, your t is replaced by q.
ref is still a reference to t.
That does not perform a reference reassignment. Instead, it copy assigns the object in variable q into the object referenced by ref (which is t in your example).
This also justifies why you got 42 as output: the default copy assignment operator modified the first object.

Constness of captured reference

An object can be captured by mutable reference, and changed inside a member function which takes the same object as const.
void g(const int& x, std::function<void()> f)
{
std::cout << x << '\n';
f();
std::cout << x << '\n';
}
int main()
{
int y = 0;
auto f = [&y] { ++y; };
g(y, f);
}
An object is mutated in a scope where it is const. I understand that the compiler can't enforce constness here without proving that x and y are aliases. I suppose all I'm looking for is confirmation that this is undefined behavior. Is it equivalent in some sense to a const_cast - using a value as non-const in a context where it should be?
Reference or pointer to const doesn't mean the referenced object cannot be modified at all - it just means that the object cannot be modified via this reference/pointer. It may very well be modified via another reference/pointer to the same object. This is called aliasing.
Here's an example that doesn't use lambdas or any other fancy features:
int x = 0;
void f() { x = 42; }
void g(const int& y) {
cout << y;
f();
cout << y;
}
int main() {
g(x);
}
There's nothing undefined going on, because the object itself is not const, and constness on aliases is primarily for the user's benefit. For thoroughness, the relevant section is [dcl.type.cv]p3:
A pointer or reference to a cv-qualified type need not actually point
or refer to a cv-qualified object, but it is treated as if it does; a
const-qualified access path cannot be used to modify an object even if
the object referenced is a non-const object and can be modified
through some other access path. [ Note: Cv-qualifiers
are supported by the type system so that they cannot be subverted without casting (5.2.11). —end note ]

Resources