In a C++ program, I'm using a library which uses std::once_flag, but it seems like the compiler (arm-none-eabi-g++) doesn't support that. Is there a polyfill for this std::once_flag?
I saw this on Code Review: https://codereview.stackexchange.com/questions/117468/stdonce-flag-and-stdcall-once-implementation but I was wondering whether there is an official polyfill.
It doesn't matter whether the polyfill supports multithreading or not, as my target device doesn't support it anyways.
There is no such thing as an "official" polyfill. The standard is the official definition of the language and it is up to compilers to implement that. If you cannot use GCC 4.8 (the first GCC to implement "complete" C++11) then you will have to live with reproducing its behaviour as best you can, with code written by yourself or others.
(It's possible that your problem stems not from the GCC version, but from the specific port/package/platform; however, since you did not tell us the name/version of your toolchain, or your build command, or the actual problem that you encounter, I will simply assume that this is not the case here.)
So, the code you found is what you've got. However, you should bear in mind that your program will have undefined behaviour. Ideally you will upgrade your compiler or switch back to C++03-compatible coding. Personally I'd recommend falling back on Boost.Thread until you're using C++11 in totality.
Or, y'know, simply don't use std::once_flag, a helper structure for std::call_once, which is all about multithreading… which you claim that your device doesn't support.
Related
I am using C++ in Xcode version 8.1. I need to use the functionality of boost::any but am strongly opposed to pulling any part of Boost into our project (let's not debate it please).
I see that std::any is "merged into C++17" here.
I want to use this in my Xcode 8.1 project. I have tried using -std=c++1z as a custom flag on the project, but I can't seem to find a header for it.
How can I use std::any or std::experimental::any in my Xcode project?
Can I download the appropriate headers from an implementation and throw them into my project's sourcecode? Or, even better, is actually available to now in my version of Xcode/Clang/C++?
You can't say "I want the default Xcode compiler [which has no support for any]" and at the same time request it to support any. You also can't mix standard library headers for different compiler versions.
You can either
use a compiler version that provides std::any or
use any third party library that provides another any-like type.
Your installation setup does not have the c++17 standard. std::any simply is not available to you unless you get a compiler with at least experimental support for what you want.
Clang Cxx Status
You'd have a lot better luck just using boost::any probably.
If you're really set on not bringing a third party library into play, the reality is that creating your own any isn't that difficult. I don't recommend reinventing the wheel but in this case it's not that difficult.
Here's a SO question with an answer showing a way to do 'any'.
It is illegal to inject new types into std via a third party library. You can upgrade your compiler, get a distinct std library your compiler supports, or use a 3rd party library that provides any in another namespace, or write your own.
The first you said no to.
The second is hard, as xcode does not advertise what its compiler actually is. There are generally two common std libraries that work with clang-llvm derived compilers; libc++ and libstdc++. That kind of swap tends to be very expensive even if the other one has the feature you want.
The third is basically "use boost" or equivalent.
The last isn't hard; a few days work (mostly bugs after the fact), based on writing types of similar complexity, assuming "good enough" is good enough (ie, not getting caught up in ideal exception guarantees, or matching standard exactly, etc). An implementation will require hyperbolic effort to approach perfection, naturally.
Xcode 9.0 beta can now be downloaded (https://developer.apple.com/download/). It supports the c++17 flag option.
Edit: Xcode 9.2 is publically available with std::any support.
This is a very uninformed question, but:
I would like to start using C++11. Can I continue to use my large collection of libraries which were compiled with my old gcc 4.2.1 compiler or do I need to recompile them all with a new compiler? I would think (or hope) the answer is no, but I am only a dabbler.
So that I may have at least part of my ignorance removed, can you explain why in either case?
Thanks
Yes, you should.
The weaker reason is not binary compatibility, the problem is about expectations. A C++11 enabled compiler will expect a number of features to be available (move constructors among them) and use them when appropriate. And that's only scratching the tip of the iceberg, there are several other incompatibilities (auto, 0 and its interaction with pointers, ...).
It means that any inline method in a header may suddenly be interpreted differently, in light of the C++11 Standard.
The stronger reason is that each version of the compiler comes with its own Standard Library implementation. You don't really want start mixing various versions around and especially not when they have undergone such major changes (once again, rvalue references...).
Believe me, it's simpler to recompile now rather than having that nagging thought that each bug that appear may be due to an incompatibility between old and new libraries...
It's a compiler question. For instance, if you have a single compiler which supports both C++03 and C++11 depending on a compiler switch, you can very likely mix libraries. There's nothing new in C++11 that forces an incompatibility with C++03.
Howeve, you mentioned that your libraries were compiled with GGC 4.2.1. Since C++11 was just an idea back then, it's quite likely that GCC back then was implemented in ways that turned out to be incompatible with C++11.
For instance, std::list::size() must be O(1) in C++11, but it could be O(N) in C++03. GCC chose a O(N) implementation back then, not knowing the future requirements. The current GCC std::list::size implementation is compatible with both C++11 and C++03, since O(1) is better than O(N).
The answer totally depends on the API of your library and its implementation dependencies.
The conditions that guarantee that you don't need to recompile are:
-- Your library doesn't use C++ specific features in its public API.
That implies:
Your library doesn't provide classes/class-templates/function-templates/other C++ specific stuff.
You don't accept/return C++ classes to/from your library functions.
You don't pass function parameters by reference.
You don't provide public inline functions with C++ specific implementations.
You don't throw exceptions from your functions.
You don't (because you have no reason to) include C++ specific library headers in your public headers. (It wouldn't hurt if you do include them but everything must be OK if you remove such includes. It is like an indicator.)
-- Your library depends only on the libraries that binary-compatible with those available in your new build environment.
If those conditions are not satisfied then there is no guarantee that your library will work correctly. In most cases it is much easier to recompile than to make sure that everything works correctly.
Either way if you are going to make binary compatible API that satisfies the conditions above then it is much better to design and implement C language API. This way you automatically satisfy the above conditions and don't fall into sin of writing C-style C++ code.
You can use large parts of C++11 without recompiling (assuming ABI compatability), but a particular important part, for me atleast, will not be accessible to the already compiled code - move semantics.
Move semantics can make your code faster just by recompiling with a C++11 compiler (and preferably, a C++11 stdlib).
There are also other reasons. Maybe your preferred library has become C++11 aware since you last compiled it, and is now more efficient, safer or easier to use if compiled with a C++11 compiler?
For your own libraries, with C++11 you surely can make it them more efficient, safer and easier to use? :)
If your interfaces to the compiled code uses any template which was modified by C++11, then yes, you have to recompile. Otherwise you probably can continue to use your old libraries (unless the compiler provider also decided to make changes of the ABI at the same time, because it's a great opportunity to fix long-standing ABI bugs which are otherwise often refrained from fixing because of binary incompatibilities).
I was wondering if it is safe to use the latest GCC version, or do people usually go a few versions back (and if so how many). Are there trusted versions which can be assumed to be (relatively) bug free, or can i safely assume (for non life saving programs) that the latest GCC version is safe to use?
EDIT:
By safe - i mean mainly bug free, i.e. in terms of execution.
In the absence of specific requirements to the contrary, I tend to use whichever version of gcc is supplied by my (reasonably up-to-date) Linux distribution. This policy has worked pretty well for me so far.
I tend to use the latest version, because it implements the latest features, fix bugs, but unfortunately introduce new bugs. Introduces bugs are usually on some weird corner cases, so I would assume it is safe to always use the latest version.
Better C++ 11 support is on the latest gcc version. You might to compile it yourself though Note that gcc 4.7 is almost ready for release, so, you might want to give it a try. I have done it quite often, with almost all gcc versions starting from 4, for the improved C++ standards compliance, and, quite often, gains in compilation time and improvements on the optimizer.
In general, it is a good idea to use the latest g++ compiler.
However, in a few occasions I have had problems with the libraries that I use. For example, the version 4.5 of g++ broke the version of boost::xpressive that I was using. Or better said, it revealed something broken in the library. Plus, the higher you go with g++, the more problems you will have trying to compile your code with other compilers, lagging on new features implementation.
My take on that is to yes, use the latest compiler version, and use the good things that the new standard has, because they make me more productive and a happier programmer. Then, if I have to port my code to another compiler, I just tweak the parts of the code that I need to, which at the end doesn't take that much time.
On the normal host system, I would go with what is provided by the OS/distribution, and maybe install a few versions in parallel. On my macosx system gcc-4.2 (OSX standard), gcc-4.6.2, gcc-llvm (OSX standard) and gcc-HEAD installed. That way I can pretty easily try out things, update gcc-HEAD to have the bleeding edge, but continue to have working and supported versions for my day to day development.
In a commercial/work setting, I would recommend being very anal in writing down the version numbers used, and actually backup the whole compiler toolchain, so that you can come back to a working identical system later on if maintenance needs it. Nothing is more annoying than having a compiler change slightly in annoying ways (missing defines, etc...).
This is even more important for embedded development, so far that I actually save the compiler toolchain into git. A slight bump in version in gcc could mean either a horribly annoying compiler bug (those happen much more often on embedded platforms I have the impression), or a bump in size of for example 40 bytes, which could completely obliterate your project.
I have a pretty big c++ code base (not self written).
Numerous libraries, some not so syntactically heavy, some extremely so.
Among others there's heavy use of Boost, some Eigen.
I just love some of the new features of 0x and a quick compile/test tells me that it seems all good.
This question, and this one suggest that there are some things that smell funny.
My current state is:
gcc4.4.3
libstc++6-4.4
boost-1.40
eigen 3.0 - beta3
using the std=c++0x flag.
I know the standards committee has agonized about backwards compatibility and endured serious pain.
My question is, did it work? Can I take all that code, switch on c++0x and be certain, that everything does not only compile but also work as expected?
I don't use high 0x magic, just auto and some of the usual favorites explicitly marked "implemented" on GNU C++0x status.
I would certainly recommend using GCC 4.5, as it sports more bug fixes and a more solid implementation of the latest C++0x.
With regard to the questions you linked:
This is just a type definition on a new platform. Don't worry about this, it won't really break anything or be hard to fix.
This is one of the more complicated C++0x features, but shouldn't have that much of an influence on backwards compatibility (except if boost tries to hack itself into a feature that is to become a compiler/language feature).
The only real way to check if there are problems, is to turn on the compiler flag, and see if any problems pop up. Better yet, turn on full-fledged warnings (at least on GCC, MSVC has some nagging problems in this regard) to detect as many subverted problems as possible. This isn't waterproof though. You might want to use different compilers (GCC/MSVC/Intel/Clang) to cross-check compatibility, but in the case of c++0x you'll be very limited to the common subset of the compilers you use to check. Currently I use C++0x extensively, and intend to fix any problems that come into being when the finalized standard is implemented.
There is no answer to your question, it depends on your code. Try to compile, fix compile-time problems. Once it compiles, run your test cases, and fix whatever needs to be fixed.
If you don't have test code, start there.
This cannot be answered without knowledge of the code base. In particular, with 100% backwards compatibility you might find the same issues that you can find by upgrading/changing a compiler within the same standard:
If your code is not standard, if it uses features that are specific to the compiler or version, if it has any instance of undefined behavior or depends on unspecified behaviors that just happen to work in your current platform, then if might not compile (if you are lucky) or exhibit different behavior at runtime (if you are not lucky).
Is anyone using the GCC 4.4.0 C++0x support in production? I'm thinking about using it with the latest MinGW, but I'm not sure if it's mature enough.
I'm interested in:
TR1 support
auto
initializer lists
IMHO, TR1 support and auto are safe to use. In the case of auto it was one of the first features to be included into the standard and is a relatively small change to the language. I would therefore have no problem using it.
I would be a bit more hesitant about using initializer lists. On some other forums (eg. comp.lang.c++.moderated) there are questions about their behaviour and its possible that they may change closer to the release of the standard.
I'm not using GCC 4.4.0 C++0x support in production but I'm using the TR1 features with the help of the Boost Library http://www.boost.org/.
The Boost Library is well tested and often used in production environments. If you convert to the C++0x standard later the only thing you have to do is changing your include Directives http://www.boost.org/doc/libs/1_40_0/doc/html/boost_tr1.html.
In my opinion it's currently better to use the Boost Library until the standard is finished. It's a much more compiler independent way.
MinGW simply won't compile with '-std=c++0x'. Strange enough, '-std=gnu++0x' works. Anyway it seems buggy and I won't count on it.