I understand that if a temporary is bound to a reference member in the constructor's initializer list, the object will be destroyed as the constructor returns.
However, consider the following code:
#include <functional>
#include <iostream>
using callback_func = std::function<int(void)>;
int
func(const callback_func& callback)
{
struct wrapper
{
const callback_func& w_cb;
wrapper(const callback_func& cb) : w_cb {cb} { }
int call() { return this->w_cb() + this->w_cb(); }
};
wrapper wrp {callback};
return wrp.call();
}
int
main()
{
std::cout << func([](){ return 21; }) << std::endl;
return 0;
}
This looks perfectly valid to me. The callback object will live during the whole execution of the func function and no temporary copy should be made for wrapper's constructor.
Indeed, GCC 4.9.0 compiles fine with all warnings enabled.
However, GCC 4.8.2 compiler gives me the following warning:
$ g++ -std=c++11 -W main.cpp
main.cpp: In constructor ‘func(const callback_func&)::wrapper::wrapper(const callback_func&)’:
main.cpp:12:48: warning: a temporary bound to ‘func(const callback_func&)::wrapper::w_cb’ only persists until the constructor exits [-Wextra]
wrapper(const callback_func& cb) : w_cb {cb} { }
^
Is this a false positive or am I misunderstanding the object lifetimes?
Here are my exact compiler versions tested:
$ g++ --version
g++ (GCC) 4.8.2
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ g++ --version
g++ (GCC) 4.9.0 20140604 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This is a bug in gcc 4.8 that has been fixed in 4.9. Here is the bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
As pointed out by Howard Hinnant and already indicated by R Sahu's comment, this is a bug (which used to be required by the then-broken standard; thanks to Tony D for pointing this out) in the way GCC 4.8 is treating initializer lists.
Changing the constructor in my original example from
wrapper(const callback_func& cb) : w_cb {cb} { }
to
wrapper(const callback_func& cb) : w_cb (cb) { }
makes the warning with GCC 4.8.3 go away and the created executable Valgrind clean. The diff of the two assembly files is huge so I don't post it here. GCC 4.9.0 creates identical assembly code for both versions.
Next, I replaced the std::function with a user-defined struct and deleted copy and move constructors and assignment operators. Indeed, with GCC 4.8.3, this retains the warning but now also gives a (slightly more helpful) error that the above line of code calls the deleted copy constructor of the struct. As expected, there is no difference with GCC 4.9.0.
Related
Hi: I'm using WSL+Ubuntu20.04 on win10, installed g++ using sudo apt-get.
g++ --version
g++ (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Fairly new, then I have this code modified from cppreference.com:
#include <iostream>
#include <thread>
#include <shared_mutex>
#include <mutex>
using namespace std;
class Counter {
int value;
shared_mutex m;
public:
...
My command line is:
g++ rwlock.cpp -std=c++11
It doesn't compile, saying that:
error: ‘shared_mutex’ does not name a type
10 | shared_mutex m;
And some other errors, all point to that I don't have these c++11 types defined.
Did I missing anything while installing g++ or should add more command line options when compiling?
Thanks!
The std::shared_mutex was not provided until c++ 17. https://en.cppreference.com/w/cpp/thread/shared_mutex
So to fix this issue, you just need to change the compilation command to
g++ rwlock.cpp -std=c++17
with _GLIBCXX_USE_CXX11_ABI=0
std::function of GCC-4 is different of GCC-5 and follwing versions.
The following code show you the fact:
==> lib.cc <==
#include <functional>
std::function<int(const void*p)> holder;
int run_holder(const void *p)
{
return holder(p);
}
==> main.cc <==
#include <stdio.h>
#include <functional>
extern int run_holder(const void*p);
extern std::function<int(const void*p)> holder;
int foo(const void* p)
{
printf("p=%p\n", p);
return 0;
}
int main()
{
holder = foo;
foo((void*)0x12345678);
holder((void*)0x12345678);
run_holder((void*)0x12345678);
}
==> make.sh <==
#!/bin/bash
GCC4=/usr/bin/g++
GCCN="scl enable devtoolset-5 -- g++"
$GCC4 -std=c++11 -c -g lib.cc -shared -o libfoo.so &&
$GCCN -std=c++11 -L. -lfoo -g main.cc -o a.out &&
LD_LIBRARY_PATH=. ./a.out
expected result, something like:
p=0x12345678
p=0x12345678
p=0x12345678
actual result:
p=0x12345678
./make.sh: line 6: 973 Segmentation fault LD_LIBRARY_PATH=. ./a.out
The reason is the implementation of std::function changes without document.
gcc4: /usr/include/c++/4.8.2/functional:2430
typedef _Res (*_Invoker_type)(const _Any_data&, _ArgTypes...);
gcc5: /opt/rh/devtoolset-4/root/usr/include/c++/5.3.1/functional:2226
gcc8: /opt/rh/devtoolset-8/root/usr/include/c++/8/bits/std_function.h:609
using _Invoker_type = _Res (*)(const _Any_data&, _ArgTypes&&...);
So I can not write a .so using std::function compiled by gcc4 and used by gcc5/6/7/8. There is no macro like _GLIBCXX_USE_CXX11_ABI can control the behavior.
So I can not write a .so using std::function compiled by gcc4 and used by gcc5/6/7/8.
Correct. Neither Red Hat nor the GCC project has ever claimed that's possible, quite the opposite. C++11 support in GCC 4.x was incomplete and unstable, and subject to ABI changes and API changes. What you're trying to do was never supported.
I've explained this in more detail at https://stackoverflow.com/a/49119902/981959
The Developer Toolset documentation covers it too (emphasis mine):
"A compiler in C++11 or C++14 mode is only guaranteed to be compatible with another compiler in C++11 or C++14 mode if they are from the same release series (for example from Red Hat Developer Toolset 6.x).
...
"Using the C++14 language version is supported in Red Hat Developer Toolset when all C++ objects compiled with the respective flag have been built using Red Hat Developer Toolset 6 or later. Objects compiled by the system GCC in its default mode of C++98 are also compatible, but objects compiled with the system GCC in C++11 or C++14 mode are not compatible."
There is no macro like _GLIBCXX_USE_CXX11_ABI can control the behavior.
We do not provide macros to control things that are unsupported and cannot work.
If you want to use C++11 with a mix of GCC versions you need to use a release that has stable, non-experimental support for C++11. So not GCC 4.x.
I get an error with this code
struct Foo { };
struct Bar { friend Foo; };
int main() { }
error: a class-key must be used when declaring a friend
error: friend declaration does not name a class of function
According to answers here this is just what the standard mandates. However, what puzzles me is that I get the error with gcc 4.4.7 but not with the newer gcc 4.8.5 (in both cases no compiler flags, but only defaults, ie no C++11). Why is that?
Has gcc decided to drop its standard compliance on this point, because thats what all others compilers do, or what is going on here?
And if possible, I would like to know if I can get gcc 4.8 to issue an error on that (or alternatively make gcc 4.4 swallow it without complaints).
When trying to install OpenMPI the .configure filed failed in the section checking for ISO C99 ability of the selected compiler.
Puzzled as gcc of course has both the std=gnu99 and std=c99 option, I pruning the 20,000 lines configure file to isolate the offending section. In the end I traced it back to gcc 5 not compiling variable argument functions.
The below code generates the "suffix or operands invalid for `movq'" error, which is the root cause of the .configure file failing.
(The step-by-step installation for OpenMPI I followed is here https://wiki.helsinki.fi/display/HUGG/Installing+Open+MPI+on+Mac+OS+X)
Anyone has seen this and knows how to fix it?
//-----------------------------------------------------------------------------
// This fails to compile with gcc 5.3
//
// Command: gcc test4.c
//
// Error is:
// /var/folders/4s/gkkpz000gn/T//ccAraq59.s:47:suffix or operands invalid for `movq'
// /var/folders/4s/gkg0r000gn/T//ccAraq59.s:52:suffix or operands invalid for `movq'
//
// gcc version is 5.3.0:
//
// $ gcc --version
// gcc (GCC) 5.3.0
// Copyright (C) 2015 Free Software Foundation, Inc.
// This is free software; see the source for copying conditions. There is NO
// warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
//
//-----------------------------------------------------------------------------
// Check varargs
static void
test_varargs (const char *format, ...)
{
}
//--------------------------------------------------------------
// MAIN {}
//--------------------------------------------------------------
int
main ()
{
//====================================================
// Check varargs.
// test_varargs ("s", "string"); //WORKS
// test_varargs ("d' ", 65); //WORKS
// test_varargs ("s, d' ", "string", 65); //WORKS
test_varargs ("f .", 34.234); // FAILS!!!
test_varargs ("s, d' f .", "string", 65, 34.234); //ALSO FAILS
//====================================================
return 0;
}
TLDR: conflict between brew and XCode gcc installs.
I ended up uninstalling all gcc versions installed, deleting g++, deleting all dangling links left over. Next I upgraded from XCode 6 to 7 and used the gcc version coming with it. This fixed the above problem.
Deleting all dangling symlinks and the unziped tar-ball of OpenMPI and then re-unzipping allowed the OpenMPI to be installed without a hitch. cd ./examples, make all, mpirun -np 4 hello_c worked and we have a happy MPI installation.
How can I cross compile on Linux for Windows with code that uses C++11 features? So far I've attempted the following:
#include <stdio.h>
class foo
{
public:
const char* getstr() { return "hello world"; }
};
int main()
{
printf("Hello, World!\n");
foo f;
f.getstr();
auto q = f.getstr();
return 0;
}
This fails to build with:
i586-mingw32msvc-g++ cpp11_test.cpp
cpp11_test.cpp: In function ‘int main()’:
cpp11_test.cpp:15: error: ISO C++ forbids declaration of ‘q’ with no type
cpp11_test.cpp:15: error: invalid conversion from ‘const char*’ to ‘int’
No problem I thought, I just need the -std=c++11 option:
i586-mingw32msvc-g++ cpp11_test.cpp -std=c++11
cc1plus: error: unrecognized command line option "-std=c++11"
Still no luck, --version output is:
i586-mingw32msvc-g++ --version
i586-mingw32msvc-g++ (GCC) 4.2.1-sjlj (mingw32-2)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Is there another option to make this work? Or a new version? How would I get a new version if its not in the package manager, would I have to build a newer compiler from source using the host OS'es compiler?