How to use Asio standalone in Xcode C++11 without Boost - c++

According to this page, using Asio without Boost should be fairly straightforward, but I still cannot compile any file with an include that looks like any of these:
#include <asio>
#include <asio.hpp>
#include <asio/version.hpp>
I have set my compiler to use c++11 (which it was already doing, though I did switch from gnu++11 to c++11), and I have placed #define ASIO_STANDALONE before the various includes I am trying.
Is there some extra work necessary for accessing c++11 Asio headers beyond this? I just get file not found errors during compilation with any of the above attempts.

Asio can be used without Boost if the following conditions are met:
C++11 (or later) compiler in C++11 (or later) compile mode. Exactly how to enable this mode varies based on compiler. For GCC/clang use the -std=c++11 flag. For Xcode set the C++ language dialect to C++11 or later in project settings
Asio headers are downloaded from think-async.com. Asio is not part of the standard library (yet). It is bundled with Boost and is available standalone from the authors website. How exactly to add Asio to your include path varies based on compiler. For GCC/clang use -I/path/to/asio or place the Asio headers in /use/local/include. Xcode will also read /usr/local/include or you can specify a custom header path in the header search paths section of your project config.
#define ASIO_STANDALONE before including Asio headers. This define tells Asio to use the C++11 standard library features for things like error codes, shared pointers, etc rather than using Boost's polyfills.

Related

Build Fails Using GCC-11 Due to Some Missing Standard Library Headers

After upgrading to gcc-11, which is shipped with Ubuntu 22.04, I started to get new compiler errors due to some missing Standard Library header files. Whereas previous gcc versions don't.
When I started to look into it, I learned from Porting to GCC 11 page, under the "Header dependency changes" section, that this is a new behavior due to some new specs in the standard itself.
Now, my question is: does the implementation of a particular C++ standard (i.e. C++17) change from one gcc version to another (i.e. gcc-9 and gcc-11)? I mean, how can the build fail if I'm building with different gcc versions but against the same C++ standard version (i.e. -std=c++17)?
And is that C++ Standard Library new requirement - of not to include other headers that were being used internally by the library - part of C++17 or C++20?
To get over this...
I manually included those header files where they were missing, and the build just succeeded.
However, I was expecting behavior to be consistent when I build against a certain C++ version with different gcc versions. Or, am I missing something?
Thanks to JaMiT note, I realized that I got the note from GCC wrong.
It's only their implementation of the Standard that got changed in GCC 11, and not the Standard itself.
When you thoroughly read the referenced section from that article, you can see that.
Header dependency changes
Some C++ Standard Library headers have been changed to no longer
include other headers that were being used internally by the library.
As such, C++ programs that used standard library components without
including the right headers will no longer compile.
The following headers are used less widely in libstdc++ and may need
to be included explicitly when compiled with GCC 11:
<limits> (for std::numeric_limits)
<memory> (for std::unique_ptr, std::shared_ptr etc.)
<utility> (for std::pair, std::tuple_size, std::index_sequence etc.)
<thread> (for members of namespace std::this_thread.)

Should I use #ifndef Q_MOC_RUN as much a possible?

I have a Qt/C++ project that uses Boost library, and I see Boost headers are included like this:
#ifndef Q_MOC_RUN
#include <boost/date_time/posix_time/posix_time.hpp>
#include <boost/date_time/gregorian/gregorian.hpp>
#endif
I read that if you don't do this, MOC might cause problems.
The question is, shouldn't I then use this guard for including all other headers that definitely don't contain Q_OBJECT marco? Standard library headers for example, and other non-Qt libraries? Wouldn't it save a lot of time when MOC preprocessor runs?
From the topic Qt5 moc error in combination with boost:
First, this is a known MOC issue. The MOC can't expand some of the
macros used in the Boost library. I believe the reason Qt 4.8 works is
that a workaround for specific Boost macro definitions was added to
the MOC configuration for that version.
What you need to do to work around this issue: As stated above, use
Q_MOC_RUN to comment out problematic headers. You ONLY need to use
Q_MOC_RUN in files that produce a moc file (e.g. myheader.h will
produce moc_myheader.cpp). You can limit the hack to just those files.
So you don't need to #ifndef all usages of Boost headers in your
project which limits the pain of implementing this solution quite a
bit.
Seems this issue was fixed quite a long time ago, so whether you don't have any problems and don't need to support old versions of Qt, you may won't add this macro to your future code.

clang++, boost::spirit and c++11

I'm using clang++ (clang-421.0.60), packaged with Xcode 4.6, and came across an issue with boost::spirit. If I compile without any flags, everything compile fine. If I compile with '-std=c++11', then I get the following error (on including of "boost/spirit/include/qi.hpp"):
In file included from test_spirit11.cpp:1:
In file included from /usr/local/include/boost/spirit/include/qi.hpp:16:
In file included from /usr/local/include/boost/spirit/home/qi.hpp:14:
In file included from /usr/local/include/boost/spirit/home/qi/action.hpp:14:
In file included from /usr/local/include/boost/spirit/home/qi/action/action.hpp:21:
/usr/local/include/boost/spirit/home/support/action_dispatch.hpp:21:10: fatal error:
'type_traits' file not found
#include <type_traits>
The problem is that the default library used (stdlibc++) has type_traits defined as 'tr1/type_traits', whereas boost::spirit expects just 'type_traits'. I can of course fix this problem by doing:
clang++ -std=c++11 -stdlib=libc++ <...>
While I would love to use libc++, the practicality of doing so is difficult (many libraries still use and depend on stdlibc++). Thus, I am forced to not use libc++.
Does anyone have any suggestions on how to deal with this? I really wish that either more library maintainers support libc++ or that Apple provided a newer version of stdlibc++. It's been a major frustration to have access to new c++11 features, but not be able to fully use them due to lack of library support.
The problem is that the default library used (stdlibc++)
It's called libstdc++
has type_traits defined as 'tr1/type_traits', whereas boost::spirit expects just 'type_traits'.
<tr1/type_traits> is not the same thing, it's a different header entirely. boost::spirit wants the C++11 header <type_traits> which is a different header (though they do contain some similar functionality, in different namespaces.)
The problem is probably that you're using the libstdc++ that comes with Apple's ancient version of GCC (4.2) which doesn't support C++11.
If you want to use C++11 you either need to use clang with libc++ or install a newer GCC to get a newer libstdc++. Apple won't provide a newer GCC for licensing reasons, but you can install it yourself and tell Xcode how to find the headers and libs.
If you don't want to use C++11 features in boost you can disable it.
Edit boost clang.hpp to manage features.
For example to disable type_traits file not found error you can add to the end:
#define BOOST_NO_VARIADIC_TEMPLATES

Is there a support for c++11 in netbeans ide 7.1.1

I need to ask is there support for c++11 (making use of libaries as thread,chrono) in netbeans 7.1.1 .
I had this code :-
#include<thread>
#include<chrono>
while(true)
{
std::this_thread::sleep_for(std::chrono::seconds(1)); <- there is an error at
"this_thread"
test4();
}
actually i am working on making something that calls this function after every minute(by this i mean when the system time changes by a minute )
thanks
Three things (Compiler, IDE and OS) are ALL important here.
1) Compiler: GCC 4.6 already has good C++11 support and has the <thread> and <chrono> headers. But you must compile with -std=c++0x. If you use an IDE, it must be configured to generate makes as such (so check the compiler option)
2) OS is also important: The <thread> header is essentially a set of wrappers around the POSIX concept of ptherad, mutex and condition_variable. On Windows, condition_variable are natively present only from 0x600 (Vista), Up to 0x505 (XP) you have to deal with the native "synchronization EVENT objects", which can be equivalent, bu have different semantics (boost::thread implements adaptors, but GCC just skips the entire thread implementation: hence... if you are writing for more OSes, check if you are using a library implementation that exist on all of them!)
3) The IDE also has its importance: the way the editors parse the text and display completion information, as well as "syntax error while typing" etc. doen NOT depend on the compiler but on the parser they use.
In particular, GCC when configured with -std=c++0X, it assumes the implicit definition of the __GXX_EXPERIMENTAL_CXX0X__ symbol, that is not automatically assumed by the IDE (that parses the headers wrongly)
You have so also to configure the IDE to consider the __GXX_EXPERIMENTAL_CXX0X__ symbol as "defined" while parsing.
Your problem is most likely related to point 3
You have to ask whether you compiler supports C++11, not your IDE.
Well, for g++, it supports most of c++11 features in its 4.7 release.

Boost.Asio as header-only

I want to use ASIO library from Boost in my project. Its doc say it can be header-only if regex is not used and SSL not used. However, running bcp for asio pulls a very many libraies some of which are with sources so need compiling, bjam etc.
Can I somehow use ASIO in project as only headers, without libs/source? I only need ASIO, not other part of Boost.
EDIT: ASIO want Boost.System which has a lib to link - can this dependency not be so that I can use header only ASIO?
AFAIK you can get the non-boost version of asio from http://think-async.com/Asio/AsioAndBoostAsio
"— Boost.Asio uses the Boost.System library to provide support for error codes ( boost::system::error_code and boost::system::system_error). Asio includes these under its own namespace ( asio::error_code and asio::system_error). The Boost.System version of these classes currently supports better extensibility for user-defined error codes.
— Asio is header-file-only and for most uses does not require linking against any Boost library. Boost.Asio always requires that you link against the Boost.System library, and also against Boost.Thread if you want to launch threads using boost::thread."
UPDATE – 07/25/2019:
As noted in the comment below by #OleThomsenBuus (thank you!), from Boost 1.69 onward, Boost.System is now header-only, so there's no need to jump through all these hoops to eliminate the need to link with it.
ORIGINAL ANSWER:
The accepted answer is 100% effective and recommended, but another option—if you really want/need to use Boost Asio—is to try compiling your application with -DBOOST_ERROR_CODE_HEADER_ONLY. Use of this macro (documented here) should get around the need to link with Boost.System. However, it's worth reading the caveats pointed out in this answer. In particular, you may need to create a 'dummy' CPP file containing:
#define BOOST_ERROR_CODE_HEADER_ONLY
#include <boost/system/error_code.hpp>
and disable optimization for that file only. (Personally, I didn't need to do this, but YMMV...)
I think bcp pulls the regex library because it can be used (and on Windows machines it is used by default). I expect that you can delete the regex library source files no problem. Make sure you add the correct compiler flags if you are compiler on windows
(-DBOOST_DATE_TIME_NO_LIB and -DBOOST_REGEX_NO_LIB)
The details are from this page (which by the sounds of it you have already found).
I'm not sure how smart bcp is - I'm don't think you can pass it the defines given above that prevent it following the mscv route.