I've just "upgraded" MSVC2015 to Update 2 and encountered boost::asio issue 12115...
I'm glad to say that the workaround described in boost issue 12115 i.e. removing service_has_move from line 43 of basic_io_object.hpp works fine to change:
#if defined(BOOST_ASIO_HAS_MOVE)
...
static const bool value =
sizeof(service_has_move::eval(
static_cast<service_type*>(0),
static_cast<implementation_type*>(0))) == 1;
...
#endif // defined(BOOST_ASIO_HAS_MOVE)
to
#if defined(BOOST_ASIO_HAS_MOVE)
...
static const bool value =
sizeof(eval(
static_cast<service_type*>(0),
static_cast<implementation_type*>(0))) == 1;
...
#endif // defined(BOOST_ASIO_HAS_MOVE)
I'm not a great fan of editing libraries, especially not boost!
So can someone please tell me whether this is actually a boost issue or whether the issue is MSVC2015 changing it's move behaviour in Update 2?
FYI, the original code compiled and worked fine under MSVC2015 Update 1 and MinGW 4.9.2 (on Windows 10) and GCC 5.3.1 (on Fedora) using both boost 1.60.0 and 1.61.0.
I'm currently using boost 1.61.0 but boost issue 12115 was raised on boost 1.60.0.
I think it's pretty obvious who is at fault. If you had to delete something in boost to fix this, then boost is at fault, no? The macro BOOST_ASIO_HAS_MOVE is defined based on compiler detection in the boost config header(s). Obviously when you updated, the compiler version and other info that these headers relies on was not a match, so the namespace you had to delete was not defined.
Related
Within my bazel.rc file for the C++ Bazel build options, I have specified:
'build --cxxopt="-std=c++1y"'
When I try to change to build --cxxopt="-std=c++14", bazel Throws error of :
''build --cxxopt="-std=c++14"' is not an option'
, with a cursor below 4 in c++14. If I change the 4 to y (c++1y), it compiles with no problem. I tried adding 'std:make_unique' in my code (c++14 addition) , and it clearly does not compile (make _unique is not part of std) which is assume is complaining that c++14 is not set as the standard, hence no make_unique for me.
What is the latest supported version of C++ in bazel? More specifically, how do I enable C++14 / C++17 (and even C++2x) for Bazel build, it those are supported? Thanks!
NOTE: this is not the same as How to set C++ standard version when build with Bazel??. (I am not asking about cpp 11 and I am asking about a very specific toolchain -- GCC/g++) I am not using any of the tools suggested by that thread. I am using GCC / g++ and am restricted in not being able to use the tools suggested by the answer in the previous question, I've RTFMd and googled. Thanks in advance.
I am trying to run an old project in Xcode, which is written in C++, but I get several errors with boost library.
The first was this issue, but the second comment provided a nice workaround and it worked.
Then I did a clean build again and now I am getting the error, which is in the title, namely:
Unknown type name 'reference_type_of_temporary_wrapper'
I can't find any solution for this issue. Anybody has any suggestions?
I am using:
Mac OSX 10.10
Xcode Version 6.1 (in the project C++ language dialect and C++ standard library are set to Compiler default)
Boost 1.56
There is already an accepted answer but it bypasses the issue, doesn't really fix it so I thought I would respond with a more up-to-date answer for those searching.
In more recent versions of Boost, there are preprocessor definitions that you can pass to your app that will disable certain C++11 features. For the particular error in this post, passing this to the compiler fixes the issue (GCC here):
-DBOOST_NO_CXX11_REF_QUALIFIERS
There is a nice long list on this SO question of all the C++11-related Boost preprocessor definitions that can be set.
I managed to pass through this error, with a temporary workaround. It is not the nicest solution probably, but works...
What I did is just simply commented out these lines from boost/optional.hpp:
// reference_type_of_temporary_wrapper operator *() && { return boost::move(this->get()) ; }
// reference_type_of_temporary_wrapper value() &&
// {
// if (this->is_initialized())
// return boost::move(this->get()) ;
// else
// throw_exception(bad_optional_access());
// }
I have installed boost_1_54 on windows by checkout from svn and then
bootstrap
.\b2
QuantLib library dependent on boost compiles well all but one project: test-suite which uses BOOST_MESSAGE. this is undefined. I can see that there is no BOOST_MESSAGE in my version of boost.
Therefore is this QuantLib incompatibility or have I missed something?
On my linux boost version the same thing applies to BOOST_MESSAGE - it is undefined
I have seen this but I am not sure how to interpret this.
I'm afraid you gave us more credit than we deserved :)
We haven't compiled QuantLib against Boost svn yet. The latest I've tried is Boost 1.53 (the latest released version) in which BOOST_MESSAGE was still available.
Thanks for the heads-up, though. I'll patch the library so that it's ready for next version. As mentioned in the comments, it should be as simple as adding
#if BOOST_VERSION > 105300
#define BOOST_MESSAGE(msg) BOOST_TEST_MESSAGE(msg)
#endif
to test-suite/utilities.hpp.
on linux I had to add
libboost_unit_test_framework.so
to the Linker->Libraries and
#include <boost/test/unit_test.hpp>
#define BOOST_MESSAGE( M ) BOOST_TEST_MESSAGE( M )
is already present in test/test_tools.hpp.
on windows I have different #defines and this is not present, so I added it to the
unit_test_log.hpp
where BOOST_TEST_MESSAGE is defined (in boost files to avoid same issue again in the case of other applications using BOOST_MESSAGE).
BOOST_MESSAGE issue resolved but still can't disambiguate
const void* = boost::test_tools::check_is_close
and
const void* = boost::test_tools::check_is_small
because these are templates. so the solution is to remove it (test-suite compiles well) or use appropriate pointers to function templates
on Windows, after romoval or function
_use_check
in utilities.hpp
changed to not have pointers to TEMPLATE functions as default, so changed to:
void _use_check(
const void*,
const void*) const {}
there were still errors while building test-suite project. unresolved externals: fdmhestonfwdop, fdmblackscholesfwdop, fdmsquarerootfwdop. obviously this classes (headers+source) I had to add to Quantlib project, build library QuantLib-vc110-mt-gd.lib again and rebuild test-suite project then.
after pleasure with VS linker error "lnk1210 exceeded internal ilk size limit link with incremental no" (it really likes RAM, but on windows I have this resource quite limited), it is OK. compiled. : p
I have the projects setup as described in the readme, and have GLib 2.28.8 installed and compiling. When I get to compiling gstreamer, I get thousands of errors that indicate to me that something is wrong with the build setup or with GLib versions. I couldn't find an easy source of other GLib versions for windows (I've tried both the dev and sources version of GLib here: http://www.gtk.org/download/win32.php ).
The first compile error is:
...\build\gstreamer-1.0.5\gst/gstobject.h(170): error C2079: 'lock' uses undefined struct '_GMutex'
In gstobject, lock is defined as:
GMutex lock; /* object LOCK */
Which Visual studio finds as defined in gthread.h
typedef struct _GMutex GMutex;
So everything looks fine to me, but maybe I'm overlooking something. glibconfig.h also defines _GMutex* as GStaticMutex, could that be interfering?
I am using glib.2.28.8, also encountered the same problem. The following two threads (1 and 2) also discuss the related problem.
In my case, just add
struct _GMutex
{
/*< private >*/
gpointer p;
guint i[2];
};
before
struct _GMutex GMutex;
Maybe you should try to update your Glib to 2.32.0
I successfully build GStreamer-1.0.5 both on Linux and Windows Xp, with Glib 2.32.4
See configure.ac
dnl GLib
GLIB_REQ=2.32.0
AG_GST_GLIB_CHECK([$GLIB_REQ])
After following the steps in this post I managed to make Eclipse (Indigo) recognize unique_ptr (and other C++11 new stuff). The problem is that operator-> for unique_ptr seems not to be supported in Eclipse. Here you have an example:
class Foo { void bar() { /* ... */ } };
std::unique_ptr<Foo> foo;
(*foo).bar(); // 1
foo->bar(); // 2
Case 1 works as expected: there is no error and autocompletion works. For case 2, however, Eclipse marks the statement with an error ("Method 'bar' could not be resolved"), plus autocompletion from foo-> does not work.
Most interestingly, I do not have any problems with std::shared_ptr. It only happens for std::unique_ptr.
Has anyone experienced the same problem? Does anyone know a way to fix it?
EDIT: just for clarifying purposes, the compilation process goes fine for the code snippet shown above. So, the problem is not in the compiler itself, but on Eclipse.
I have finally found a bug report in CDT describing the very same problem that I am suffering. So far, there is not a real fix for the problem but there is a workaround explained in that bug report:
Yes, GCC 4.5 is the latest GCC version whose library headers can be accurately
indexed by CDT. The main reason for failing to index 4.6 headers is CDT's lack
of support for 'constexpr' and 'nullptr', which are used extensively in the 4.6
headers (any chance of that being implemented for Juno, by the way?).
I have worked around this by having both GCC 4.5 and 4.6 installed on my
system, and pointing CDT to 4.5's headers (by setting the compiler invocation
command to 'g++-4.5' in Discovery Options) while actually compiling with 4.6.
This issue has been recently fixed, in cdt 8.1.1. Just go help->check for updates and it will be downloaded and installed. I've tested unique_ptr and it is properly indexed.