I got Netbeans 7.4 installed today with supports for PHP, Java, and C++.
However, it seems that I only have partial support for C++11 (even with GCC 4.8.1 with -std=c++11 or -std=C++0x).
I've looked at the header files (e.g. chrono) and there's a inlined namespace named _V2 that follows the following comments :
// To support the (forward) evolution of the library's defined
// clocks, wrap inside inline namespace so that the current
// defintions of system_clock, steady_clock, and
// high_resolution_clock types are uniquely mangled. This way, new
// code can use the latests clocks, while the library can contain
// compatibility definitions for previous versions. At some
// point, when these clocks settle down, the inlined namespaces
// can be removed. XXX GLIBCXX_ABI Deprecated
So, for instance, if I want to use high_resolution_clock, I need
chrono::_V2::high_resolution_clock
Instead of
chrono::high_resolution_clock
Also to_string from string is also declared as undefined.
Am I missing somethng? Do I have to update my headers in Netbeans? If so, may I ask you to advise me on how to proceed?
Thanks a lot!
Related
I need functionality that will be added in the next C++ version (C++17). I am using MS Visual Studio, which implements C++11. I expect that in a few years I'll upgrade my compilation tools, so this functionality will be available via the Standard library.
In the meantime, I need to implement it manually. How can I define it so it will be easy to migrate in the future?
Let's take std::clamp as an example.
I can implement it with a different name, e.g. my_clamp. When I am able to use C++17, I can start using std::clamp, and optionally do a global replace of my_clamp by std::clamp. This looks ugly but probably will generate no surprises.
I can implement it in my namespace my::std, and do using namespace my. This way, I can start using the name std::clamp today, and not change it later. However, is it dangerous/forbidden?
I can somehow detect C++ version, and if it's less than 17, stuff clamp into std namespace. This is UB, but will probably work.
Is there a method without disadvantages?
Is there an accepted/customary way of doing this?
What I usually do in these cases is:
1. try to use a recent C++ compiler and library that already includes the functions/facilities that I need.
2. failing that (i.e. I'm forced to stay with an older C++ standard version, let's say C++11, because of old toolchains), find a library that has what I need
3. better yet, if what I need is already included in a newer C++ standard or a "reference implementation" library already exists, I try to use the reference implementation or a close one, this will reduce future changes in your code.
4. get familiar with the boost library, as there may be a good chance that it already includes what you need, and it may well be the reference implementation for the future C++ standard stuff.
5. failing all the above, for whatever reason, write your own implementation, but try to keep its interface similar to the standard proposal.
For anything not coming from the std:: namespace, use namespace aliasing to further reduce future changes (when switching to newer toolchain and std:: ).
Note 1: C++17 IS the current C++ standard, the next should be C++20.
Note 2: MS VS2017 (and 2015 to some extent) already includes some or most of the stuff from C++17.
Edited to include an example of how to use namespace alias
This example is related to C++ filesystem stuff, it is not (yet) updated to use C++17 , but it's still limited to .
It mainly rely on preprocessor #defines (i.e. HAVE_CXX_EXPERIMENTAL_FILESYSTEM) to enable/disable the wanted portion.
I usually use CMake to detect compiler and library features and to define those macros in an automated fashion.
#if _MSC_VER >= 1900 // Microsoft Visual C++ 2015
#define HAVE_CXX_EXPERIMENTAL_FILESYSTEM
#endif
#if defined(HAVE_CXX_EXPERIMENTAL_FILESYSTEM)
// Have Filesystem TS
#include <experimental/filesystem>
namespace filesystem = std::experimental::filesystem;
using std::error_code;
#elif !defined(NO_BOOST)
// Fall-back to Boost.Filesystem library
#include <boost/version.hpp>
#if (BOOST_VERSION >= 103400)
#include <boost/filesystem.hpp>
#else
#include <boost/filesystem/path.hpp>
#include <boost/filesystem/convenience.hpp>
#include <boost/filesystem/exception.hpp>
#endif // (BOOST_VERSION >= 103400)
namespace filesystem = boost::filesystem;
using boost::system::error_code;
// Hack to fix differences with C++17 Filesystem TS
#define copy_options copy_option
#define overwrite_existing overwrite_if_exists
#else
#warning Not implemented
// or #include custom stuff
#endif
What the above basically does is a fall-through:
1. use and alias the namespace if available
2. use boost.filesystem (if not explicitly excluded with NO_BOOST)
3. [optional] fallback to a custom implementation or other library if needed.
Disclaimer: this solution may not be perfect, but it's reasonably working for my needs.
I'm a bit new to c++ and I have a coding assignment with a lot of files already done, but I noticed that VS2012 seems to have an issue with the following statement:
typedef std::uint32_t identifier;
However, it seems that changing it to
typedef uint32_t identifier;
gets rid of the error. There are no includes and this is in the header file. I noticed that the definition is in stdint.h. If that's the case, why is this code acceptable outside of VS (ie. compiles properly using g++) but is unacceptable in VS? Can anyone please explain this?
The difference is that one is inside a namespace and the other isn't. Otherwise they should be the same. The first is supposed to be the C version and the second is the C++ version. Before C++11 it was mandated that including the prefixed versions instead of the C standard library version brings in all C definitions inside the standard namespace. In C++11 this restriction has been relaxed as this is not always possible.
It could be that your compiler defines this type implicitly. In any case, you should include cstdint to make the version in the namespace std available (and possibly the one in the global namespace). Including stdint.h should just make the unqualified version available.
Earlier version of Visual Studio shipped without this header, so this is bound to be troublesome.
Due all this madness, most people will fall back on a third-party implementation such as boost/cstdint.hpp.
Edit: They are the same and serve the same purpose. As a rule: If you want to use the version in the std namespace, include cstdint. If you want the one in the global namespace, include stdint.h. For C++ it is recommended to use the one in the std namespace. As a rule: Always include what you use and don't rely on other headers including things for you.
uint32_t (aka ::uint32_t i.e. the one in the global namespace) is declared in <stdint.h>. That header might also declare it in namespace std, as std::uint32_t, but it's not required to do so.
std::uint32_t (i.e. the one in namespace std) is declared in <cstdint>. That header might also declare it in the global namespace, as ::uint32_t, but it's not required to do so.
If that's the case, why is this code acceptable outside of VS (ie. compiles properly using g++) but is unacceptable in VS? Can anyone please explain this?
If you want to use std::uint32_t then you must #include <cstdint>, or the code may not compile. If it does compile with G++ then presumably some other header indirectly includes <cstdint> but you shouldn't rely on that, include the right headers for the names you use.
In what cases should we include cassert?
In short, don't use it; use <assert.h>.
C++11 removed any formal guarantee of a "c...." header not polluting the global namespace.
It was never an in-practice guarantee, and now it's not even a formal guarantee.
Hence, with C++11 there is no longer any conceivable advantage in using the "c...." header variants, while there is the distinct and clear disadvantage that code that works well with one compiler and version of that compiler, may fail to compile with another compiler or version, due to e.g. name collisions or different overload selection in the global namespace.
SO, while cassert was pretty meaningless in C++03 (you can't put a macro in a namespace), it is totally meaningless -- even as a special case of a general scheme -- in C++11.
Addendum, Dec 22 2013:
The standard defines each C++ C header <X.h> header in terms of the <cX> header, which in turn is defined in terms of the corresponding C library header.
C++11 §D.5/2:
“Every C header, each of which has a name of the form name.h, behaves as if each name placed in the standard library namespace by the corresponding cname header is placed within the global namespace scope.”
C++11 §D.5/3 (non-normative example):
“The header <cstdlib> assuredly provides its declarations and definitions within the namespace std. It may also provide these names within the global namespace. The header <stdlib.h> assuredly provides the same declarations and definitions within the global namespace, much as in the C Standard. It may also provide these names within the namespace std.”
Stack Overflow user C.R.’s comment made me aware that some versions of g++, such as MinGW g++ 4.7.2, are quite non-standard with respect to the <X.h> headers, lacking the overloads of e.g. sin that the C++ standard requires:
I already knew that MinGW g++ 4.7.2 also entirely lacks functions such as swprintf, and that it has ditto shortcomings in the pure C++ library such as lacking C++11 std::to_string. However, the information about it lacking the C function overloads was new to me.
In practice the lacking overloads with g++ means
ignoring the g++ issue, or
avoiding using the missing g++ overloads,
e.g. using only double sin( double ), or
using the std namespace overloads
(one then needs to include <cmath> to guarantee their presence with g++).
In order to use the g++ std namespace overloads unqualified, one practical approach is to define headers wrappers for this compiler. I've used that approach to address g++ shortcomings wrt. to the printf family. For as David Wheeler once remarked, “All problems in computer science can be solved by another level of indirection”…
Then things can be arranged so that standard code that uses g++'s missing overloads, also compiles with g++. This adjusts the compiler to the standard, with a fixed amount of code.
Just like any other header file, you #include <cassert> when you use something declared in that header file, such as assert().
See an easily accessible reference
#include <iostream>
// uncomment to disable assert()
// #define NDEBUG
#include <cassert>
int main()
{
assert(2+2==4);
std::cout << "Execution continues past the first assert\n";
assert(2+2==5);
std::cout << "Execution continues past the second assert\n";
}
assert.h defines one macro function that can be used as a standard debugging tool.
I was trying out some CUDA/Thrust code on Linux/GCC and wanted to use some TR1 libraries, when I noticed something peculiar: Most libraries will invariably pull in tr1_impl/type_traits (4.4) or just type_traits (4.6), and that header will always contain variadic templates, like so:
template<typename _Res, typename... _ArgTypes>
struct is_function<_Res(_ArgTypes...)>
: public true_type { };
However, these headers also get used when I run GCC in C++98 or C++03 mode! How can this work?
The actual problem I encountered is that the CUDA toolchain doesn't recognize C++0x constructions, and cudafe++ (the CUDA front end, i.e. the program that separates the joint source code into host and device source code) rightly aborts with an error when encountering the variadic template parameter.
So... how can GCC support and rely on variadic templates in non-0x dialects of C++? And is there a way to obtain a genuine C++03 version of TR1?
Welp, an implementation is not required to provide headers. It's required that an #include <stuff> does The Right Thing. So that means that if an implementation decides to use headers for this functionality, it's not required that those headers be conforming C++. And in fact GCC has supported variadic templates as an extension for quite some time.
Furthermore, I can't help but notice
#pragma GCC system header
in the <tr1/random> header that you mention. GCC will treat the file specially, and e.g. not report errors warnings in it. I would have thought using an extension in conforming mode can easily be turned into an error so I'm not sure what's going on but at least legally it's an option.
There's also the special status of TR1, which is not binding. On my implementation as far I can tell the only C++03 header that includes <type_traits> is <functional> and it properly only does that in C++0x mode (i.e. the rest of the time it's a valid C++03 file via preprocessing, unlike <tr1/random>). (I didn't check for other cases though.)
I'm looking to have two versions of BOOST compiled into a project at the same time. Ideally they should be usable along these lines:
boost_1_36_0::boost::shared_ptr<SomeClass> someClass = new SomeClass();
boost_1_35_0::boost::regex expression("[0-9]", boost_1_35_0::boost::regex_constants::basic);
I read (well scanned) through the development list discussion. There's no easy solution. To sum up:
Wrapping header files in a namespace declaration
namespace boost_1_36_0 {
#include <boost_1_36_0/boost/regex.hpp>
}
namespace boost_1_35_0 {
#include <boost_1_35_0/boost/shared_ptr.hpp>
}
Requires modifying source files
Doesn't allow for both versions to be included in the same translation unit, due to the fact that macros do not respect namespaces.
Defining boost before including headers
#define boost boost_1_36_0
#include <boost_1_36_0/boost/regex.hpp>
#undef boost
#define boost boost_1_35_0
#include <boost_1_35_0/boost/shared_ptr.hpp>
#undef boost
Source files can simply be compiled with -Dboost=boost_1_36_0
Still doesn't address macro conflicts in a single translation unit.
Some internal header file inclusions may be messed up, since this sort of thing does happen.
#if defined(SOME_CONDITION)
# define HEADER <boost/some/header.hpp>
#else
# define HEADER <boost/some/other/header.hpp>
#endif
But it may be easy enough to work around those cases.
Modifying the entire boost library to replace namespace boost {..} with namespace boost_1_36_0 {...} and then providing a namespace alias. Replace all BOOST_XYZ macros and their uses with BOOST_1_36_0_XYZ macros.
This would likely work if you were willing to put into the effort.
Using bcp can install boost library to a specific location and can replace all 'namespace boost' in their code to a custom alias. Assuming our alias is 'boost_1_36_0' all 'namespace boost' code blocks will start with 'boost_1_36_0'. Something like
bcp --namespace=boost_1_36_0 --namespace-alias shared_ptr regex /path/to/install
, but check the documentation in the link yourself because I'm not sure if it is legal syntaxis.
#Josh:
While I agree with the shivering, I still believe this is the better course of action. Otherwise, linking troubles are a certainty. I've had the situation before where I had to hack the compiled libraries using objcopy to avoid definition conflicts. It was a nightmare for platform interoperability reasons because the name mangling works very differently even in different versions of the same compilers (in my case, GCC).
You'll have a world of trouble linking because the mangled names will be different. And yes, I see you knew that, but it seems like it will be trouble all around.