As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
With C++03 it was (and still is) possible to write cross-platform code with both MSVC and GCC, sharing C++ code bases between Windows, Linux and Mac OS X.
Now, what is the situation with C++11? It seems that different C++ compilers implement different features of C++11. To build cross-platform C++11 code, is it safe to take MSVC10 (VS2010) as a kind of "least common denominator"? i.e. if we restrict the approved C++11 features to those implemented by MSVC10, will the resulting C++11 code be compilable with GCC (and so usable on both Linux and Mac OS X) ?
Or is it just better to wait for C++11 compilers to mature and stick with C++03 if we need cross-platform code?
Thanks.
You can compile code for Windows using GCC. You don't need to use Microsoft's compiler.
If you want to use C++11 features painlessly at the moment, that's going to be your best solution. Microsoft still has yet to implement a lot of C++11, and not all of it is slated to be in VS11, either.
Otherwise, yes, you can obviously just use the subset of the C++11 features that are supported by the compiler implementation that represents the lowest-common-denominator. You'll need to check and make sure that that is Microsoft's compiler for all of the new features rather than just assuming that it is.
I don't believe GCC has gotten around to everything yet, and there's no guarantee that their implementation of all the features is perfect and matches Microsoft's 100%. Writing completely portable code is and has always been hard.
Using only C++03 features is obviously the safe approach, but it doesn't allow you to use C++11 features (obviously). Rather or not that's important is a decision that only you can make.
C++11 is not ready for prime time yet, as you already figured out.
Not only is the parsing stage still being worked out by the various compilers, but there is also the issue that some, while appearing to accept some features, may have quirks and bugs in the releases you currently have.
The only sound approach I can think of is to first select the compilers you want to use:
you can use gcc/Clang on Windows (with libstdc++) however this will prevent you from interacting with libraries compiled by VC++
you can on the other hand validate your code for both gcc/Clang and VC++ (and perhaps a few others if you need to)
Once you have determined the compilers you want to use, you then have to pick the features of C++11 that you want to use, and that work on all those compilers.
gcc is probably the more advanced here
Clang does not have lambdas, but has move semantics and variadic templates
VC++ is the most behind I think
And you need to setup a test suite with all those compilers, and on all the platforms you target, and be especially wary of possible code generation issues. I recommend using Valgrind on Linux par example and perhaps Purify (or equivalent) on Windows as they both help spotting those runtime issues.
Beware that both VC++ and g++ may have extensions accepted by default that are not standard, and may also base their interpretation of the code on previous drafts of C++11.
Honestly, for production use, I think this is still a bit wonky.
If you are writing new code, you are probably not releasing it tomorrow.
So plan for your release date. There are some features, that will be accepted more slowly than the rest. Mostly hard to implemented features and duplicated features (like the range for loop).
I wouldn't worry much about using the new library features, those are already supported very well across all compilers.
Currently there isn't any least common denominator, since Microsoft decided to concentrate on the library first, while the rest has gone (mostly) for language features.
This depends largely on your project. If you ship only binaries you need to figure out a toolset you want to use and stick to what this toolset supports. Should your team use different tools everbody should make sure his code builds with the common build system (Be it C++03 or C++11).
The situation changes as soon as you ship headers that contain more than just declarations. First of all you need some infrastructure do determine what is supported by which compiler. You can either write those tests yourself and integrate them with your build system or stick to Boost.Config. Than you can ifdef platform dependent code. This sounds simple at first but really isn't. Everytime you have C++11 code that can be implemented with C++03 work-arounds you want to have both versions available for your users (e.g. variadic templates vs. the preprocessor). This leads to duplicated code and comes with a significant maintenance cost. I usually only include C++11 code if it provides a clear benefit over the workaround (better compiler error messages (variadic templates vs. macros), better performance (move semantics)).
Visual studio support for C++2011 is quite good, so if you use GCC 4.7 and VS2010 you will be able to use an ample set of the most interesting features of C++2011 while being cross platform.
Support for C++11 overview for VC10 and VC11
http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx
Table for all the compilers:
https://wiki.apache.org/stdcxx/C++0xCompilerSupport
GCC C++11 support:
http://gcc.gnu.org/projects/cxx0x.html
Also related: C++11 features in Visual Studio 2012
Use only those features of C++11 at the moment which improve your code in some manner.
Let me explain this, I don't look up C++11 features to use them, rather when they solve my problem I adopt them. (This is the way I learned about them, all on SO) This approach will change in future, but for now I am doing this.
I currently use only few features of c++11, which incidentally work in both VS2010 and GCC.
Also if there is a great feature, you want to use, and VS doesn't have it, why not use GCC. It is cross-platform, so will work on windows as well.
Related
I am on Windows, and suppose I want to use different implementation of standard C++ library for my projects - say, libstdc++ or libc++.
Is there a way to persuade my Visual Studio to use it instead of MSVC library, so I can still use #include <algorithm> and not #include <custom/algorithm>? I believe that I can achieve it by simply adding path to my headers into project, but I am looking for more "system-wise" way, so I wouldn't repeat it for every single project.
Will it actually worth the hassle - specifically in terms of modern C++ features being available / standart-compliant?
If so, what would be cons of such replacement, apart of possibility to use some features that are not present in other implementations?
Particulary, answers to this question mention that there may be compatibility issues with other libs - does this apply only to Linux world, or will I have problems on Windows too?
Note: this is mostly a theoretical question - I'm fine with MSVC library, but I'd really like to know more about different stdlib implementations.
Theoretically it's not impossible to swap out stdlib implementations. With clang, you can choose between libc++ (clang's) and libstdc++ (GCC's).
However, in practice, stdlib implementations are often tied fairly fundamentally to the internals of the compiler they ship with, especially when it comes to newer-added C++ features, and this is not truer for many compilers than Visual Studio.
Could you make it work with a lot of hacking around? Maybe. Would it be worthwhile? I very much doubt it. Even if you succeeded, you will have sacrificed a reproducible build environment and will be relying on some deeply dark arts. Your project will not be reusable.
There is no indication in your question as you why you think you need to switch implementations, but it seems unlikely that any reason you could come up with would be worth the trouble.
I work on large scale, multi platform, real time networked applications. The projects I work on lack any real use of containers or the Standard Library in general, no smart pointers or really any "modern" C++ language features. Lots of raw dynamically allocated arrays are common place.
I would very much like to start using the Standard Library and some of the C++11 spec, however, there are many people also working on my projects that are against because "STL / C++11 isn't as portable, we take a risk using it". We do run software on a wide variety of embedded systems as well as fully fledged Ubuntu/Windows/Mac OS systems.
So, to my question; what are the actual issues of portability with concern to the Standard Library and C++11? Is it just a case of having g++ past a certain version? Are there some platforms that have no support? Are compiled libraries required and if so, are they difficult to obtain/compile? Has anyone had serious issues being burnt by non-portable pure C++?
Library support for the new C++11 Standard is pretty complete for either Visual C++ 2012, gcc >= 4.7 and Clang >= 3.1, apart from some concurrency stuff. Compiler support for all the individual language features is another matter. See this link for an up to date overview of supported C++11 features.
For an in-depth analysis of C++ in an embedded/real-time environment, Scott Meyers's presentation materials are really great. It discusses costs of virtual functions, exception handling and templates, and much more. In particular, you might want to look at his analysis of C++ features such as heap allocations, runtime type information and exceptions, which have indeterminate worst-case timing guarantees, which matter for real-time systems.
It's those kind of issues and not portability that should be your major concern (if you care about your granny's pacemaker...)
Any compiler for C++ should support some version of the standard library. The standard library is part of C++. Not supporting it means the compiler is not a C++ compiler. I would be very surprised if any of the compilers you're using at the moment don't portably support the C++03 standard library, so there's no excuse there. Of course, the compiler will have to be have been updated since 2003, but unless you're compiling for some archaic system that is only supported by an archaic compiler, you'll have no problems.
As for C++11, support is pretty good at the moment. Both GCC and MSVC have a large portion of the C++11 standard library supported already. Again, if you're using the latest versions of these compilers and they support the systems you want to compile for, then there's no reason you can't use the subset of the C++11 standard library that they support - which is almost all of it.
C++ without the standard library just isn't C++. The language and library features go hand in hand.
There are lists of supported C++11 library features for GCC's libstdc++ and MSVC 2012. I can't find anything similar for LLVM's libc++, but they do have a clang c++11 support page.
The people you are talking to are confusing several different
issues. C++11 isn't really portable today. I don't think any
compiler supports it 100% (although I could be wrong); you can
get away with using large parts of it if (and only if) you limit
yourself to the most recent compilers on two or three platforms
(Windows and Linux, and probably Apple). While these are the
most visible platforms, they represent but a small part of all
machines. (If you're working on large scale networked
applications, Solaris will probably be important, and Sun CC.
Unless Sun have greatly changed since I last worked on it, that
means that there are even parts of C++03 that you can't count
on.)
The STL is a completely different issue. It depends partially
on what you mean by the STL, but there is certainly no
portability problem today in using std::vector. locale
might be problematic on a very few compilers (it was with Sun
CC—with both the Rogue Wave and the Stlport libraries),
and some of the algorithms, but for the most part, you can
pretty much count on all of C++03.
And in the end, what are the alternatives? If you don't have
std::vector, you end up implementing something pretty much
like it. If you're really worried about the presence of
std::vector, wrap it in your own class—if ever it's not
available (highly unlikely, unless you go back with a time
machine), just reimplement it, exactly like we did in the
pre-standard days.
Use STLPort with your existing compiler, if it supports it. This is no more than a library of code, and you use other libraries without problem, right?
Every permitted implementation-defined behaviour is listed in publicly available standard draft. There is next to nothing less portable in C+11 than in C++98.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
C++11 provides us with a lot of new great and immensly useful tools. GCC support of C++11 has already made good progress. So I have thought about when to switch to C++11. This question relates to gcc only, I do not expect to compile my (our) code with any other compiler.
Would you (did you) switch to C++11 before gcc supports the entire C++11 standard to benefit from the features already implemented? Would you still do this in a production environment where stability and correctness is very important? Do you think it would be a reasonable approach to allow developers only to use certain C++11 features?
How would you (do you) go about deciding when GCCs C++11 support is ready for a production environment?
(Note: I'm aware of this question, but it specifically relates to gcc 4.4 and is somewhat outdated)
It depends.
If it were to power my blog or something like this ? Definitely.
If it were to power a critical service ? Of course not.
I believe that the support of C++11 is too immature as it is now, to be called production ready.
You may settle on a version of gcc, but the truth is that because the successive drafts evolved as new problems were discovered and tackled, the code you write now may well be rejected by a later version, or the behavior may change lightly.
Therefore, I think this judgement truly depends on what you intend to be doing. There is a reason the space shuttle is powered by an old and proven technology: it's a matter of trade-off between ease of development and confidence in the tools.
It's your judgment, you know your situation better than we do.
The GCC C++ developers still think their C++03 support is not up to par, and therefore aren't even setting the __cplusplus version correctly (citation needed, I can look up the bug+discussion). They marked the support as experimental because they started implementing the basics before there was a final draft/standard. By now (ie GCC 4.6), most major flaws have been removed, although some details remain inconsistent with the exact standard wording.
If possible, you should also test with Clang, which IMHO strives and succeeds at better adhering to the puny details in most places where GCC lacks the necessary enforcement. Production use is something that's personal. Me, I think that every compiler has bugs, and although the chance of a bug in the "new stuff" is statistically more probably, chances are you'll also encounter an older bug messing with your perfectly compliant code. That's why I suggest using at least two compilers to prevent any incompatibilities (or at least reduce them as much as possible).
As for the Standard library, libstdc++ is functional for the most part, but lacking in some large and useful parts like <regex>, which is sad. If you're feeling lucky, you should be able to get LLVM's libc++ working on at least Linux and Mac, this is a feature complete c++11 library minus <atomic>), but also the "new kid on the block".
To summarize: the more compilers and Standard libraries you run your code against the better (although you should check which ones are correct, and which are buggy). This inevitably reduces the amount of C++11 features available to you, although if you go with GCC/Clang, only lambda's, uniform initializers and <atomic> fall outside your scope. MSVC is a different story...
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Since in some post on StackOverflow it was recommended to try to support multiple (in this case C/C++) compilers if feasible, since this forces you to code more standard compliant and helps finding bugs.
So I was looking for additional free C/C++ compilers I could add support for to my project (it is written C/C++ (both languages combined)). I found Open Watcom to be an interesting candidate.
So my question is: what are the advantages and disadvantages of Open Watcom C/C++ compiler in comparison to other ones (for example gcc/g++, Visual C++ etc.)?
There are probably no particular advantages since if portable code is your aim you would generally try to restrict your code to the standard subset implemented by all compilers. I would say lowest common denominator but that may seem somewhat derogatory.
The advantages of one compiler over another generally lie in either the extensions it provides, the libraries it includes, or the performance of the generated code, if portability is your aim, you are probably interested in neither. It is not the advantages of one compiler over another that should interest you in this case, but rather its adherence to and compliance with the ISO standards.
In its earlier commercial incarnation, Watcom was famously one of the best optimising compilers available; I doubt however whether it has kept pace with processor development since then however (or even the transition for 16 bit to 32 bit x86!).
Its one feature that may be seen as an advantage in some cases is that it supports DOS, OS/2 and Windows, but that is probably only an advantage if legacy systems maintenance is your aim. Efforts to port it to Linux and BSD and processors other than x86 exist but are not complete, while GCC is already there and has been for years.
I would suggest that if you can support GCC and VC++ you probably have sufficient compiler independence (but recommend you compile with high warning level settings (-Wall -Werrorin GCC and \W4 \Wx in VC++). I think that compiler portability is a trivial issue compared with OS portability, and what you really need to consider is cross-platform library support rather than compiler independent code support.
If however playing with compilers is your thing, also consider the Digital Mars compiler. Like Watcom, this also has commercial compiler heritage, having been the Zortech/Symantec C/C++ compiler in a previous life.
Something watcom has in favor if your a 'haxxor' is the fact you can define out of the ordinary calling conventions using #pragma aux. Other than that, I see no reason to even attempt to use such a dated compiler unless you had horrible hardware restrictions. Imo, there are only 3 to worry about, GCC, ICC and MSVC
Some people here use expressions having to do with the Watcom (actually OpenWatcom) compiler being "dated." So what does it mean?
It could mean that it doesn't implement the latest C standard. How
many "non-dated" compilers do?
It could mean that it doesn't provide frameworks as it is primarily
an environment for C and ForTran and somewhere far after that comes a
C++ implementation which I cannot judge.
It could mean that it cannot generate excellent assembly code from
garbage C code.
It could mean that it doesn't support x64 development.
It could mean that the debugger is rudimentary and supports assembly
debugging.
Now to what it does do - in addition to supporting 16-bit real and protected mode code:
It produces excellent 32-bit protected mode code in the flat memory
model everyone uses for the Win32 environment.
Its code generating capabilities are excellent and it's right up
there at the top with more "non-dated" compilers.
It's easy to tune multi-threaded code using its profiler.
How do you "feel" a compiler? I for one don't know how to do that. Is it how the error messages are written? Is it in the messages on the console log?
The world's greatest network operating system - Novell Netware - had Watcom as its development environment. That says a great deal about Watcom. And lest anyone forget: Netware died due to poor marketing management combined with Redmond foul play. It did not die from lack of technological excellence.
I guess what I'm trying to say is that you guys that don't know what you're talking about should perhaps be a little less eager to write answers.
I know I know it's all about getting those coveted points and badges and what have you. And how you get them is irrelevant, right?
The Open Watcom compiler is somewhat outdated and it feels. It is based on what was long time ago a good compiler for making MS DOS games. Currently it is not very standard compliant and its standard library is in immature state.
I would prefer more modern and popular compilers like Intel cc, g++, VC++ or CLang. Not sure about Borland C, haven't tried it long time.
Advantages:
it's free
it's open source. You can alter it and its runtime libraries any way you like
it is crossplatform. You can run it, among other platforms, on Windows and Linux. More, you can build programs with it for different platforms, using a single platform
Disadvantages:
it is outdated a bit, but not that much as in the past
Positive (2)
The code and projects are not bloated like the projects in Microsoft Visual Studio/C++ (Not hundreds of vproj and other files and folders). You can just generate a makefile like in GCC (Which is better to understand than the Visual Projects Makefiles...)
Even the installation takes no big time (on x64 Win 7), in comparisation to 2++ GBytes Visual Project...
Compared to GCC it may seem that it is better to handle
Negative
Clib is missing: strn... functions (strndup, strncmpi etc.), getoptlong
No ARM support (# 1st July 2015)
As Editor you should really use Notepad++, not the internal Editor
I read that MSVC is not fully compilant to the ISO C++ standard (German Wikipedia and several Tech sites).
In which ways isn't C++ standards compilant?
Actually no compiler is fully standard compliant, but MSVC gained its reputation for implementing everything that the standard didn't explicitly state in a profoundly stupid and unportable way.
I would say that the latest releases are relatively good when it comes to standard support, at least when you try to compile standard compliant code in MSVC.
But MSVC is still very lazy when it comes to pointing out code, that doesn't follow C++ standard (even on the strictest settings), so porting code from MSVC to anything else is always huge pain.
But there are still many flaws/bugs/etc... for example unlike GCC, MSVC will allow you to modify a set/map iterator.
Well, I think it depends on your definition of compliant. There are several things that have not been implemented in the standard by almost any compiler company (several suggestion from the 98ish revision and template definitions in implementation files). MS has extended the language somewhat also. However, if you write code in basic c++ without the MS extensions or libraries, it will most likely be portable to another compiler with very, very minimal work (if any).
It's been a while since I've looked into this, but the C++ library that I work on uses quite a lot of template metaprogramming (nothing horribly complicated, but still beyond the simplest levels), and for quite a while it wouldn't compile under MSVC due to bugs or missing functionality in their template resolution code, although it works fine in GCC and Intel's C++ compiler.
I don't think we've tried it in the latest couple of revisions of MSVC, so they may have fixed those bugs.
Also, IIRC, MSVC does not turn on run-time type information support by default (for performance reasons), and support for that is required by the C++ standard.