Is there any way to emulate an inline namespace with MSVC?
LLVM's libc++ uses this to create a hidden versioned namespace like so:
#define _LIBCPP_BEGIN_NAMESPACE_STD namespace std {inline namespace _LIBCPP_NAMESPACE {
#define _LIBCPP_END_NAMESPACE_STD } }
#define _VSTD std::_LIBCPP_NAMESPACE
namespace std {
inline namespace _LIBCPP_NAMESPACE {
}
}
And emulates it on GCC like so:
#define _LIBCPP_BEGIN_NAMESPACE_STD namespace std { namespace _LIBCPP_NAMESPACE {
#define _LIBCPP_END_NAMESPACE_STD } }
#define _VSTD std::_LIBCPP_NAMESPACE
namespace std {
namespace _LIBCPP_NAMESPACE {
}
using namespace _LIBCPP_NAMESPACE __attribute__((__strong__));
}
Now my question is, how do I achieve the same with MSVC? If it's not possible, I'll be happy with a solution that leaves out the versioning (for now), which I guess would be
#define _LIBCPP_BEGIN_NAMESPACE_STD namespace std {
#define _LIBCPP_END_NAMESPACE_STD }
#define _VSTD std
But kind of defeats the purpose...
I'm afraid there is no possibility of such emulation. Microsoft seems to be very uninterested in symbol versioning, even though they break ABI on their standard library on every single new revision of their compiler. The GCC emulation works because strong using was the basis for the inline namespace feature. Microsoft never had a similar thing, so you can't emulate inline namespaces. I'm afraid you're stuck with not versioning libc++ for now.
There is one feature in Microsoft's compiler that may help. This is #pragma detect_mismatch:
http://msdn.microsoft.com/en-us/library/ee956429.aspx
Basically, you put
#pragma detect_mismatch("libcxx_version", "1.0")
into a central libc++ header file, and every module that includes that file will have a record placed in it that contains the key and value. The Microsoft linker checks, when linking modules, that all such records have the same value for any given name, and complains if there is a mismatch.
The end result is that you can't have multiple parallel versions of libc++ in a single program, but at least you won't get silent corruption from linking incompatible object files that cause nasty crashes at runtime.
Edit: forgot to mention: this feature is new in VS2010, but porting libc++ to a compiler without rvalue refs is probably rather hopeless anyway.
Related
Suppose I'm writing a library which targets C++14-capable compilers.
In C++14, several standard library facilities were introduced as experimental, e.g. optional and filesystem.
Is it:
safe (for downstream developers)
legitimate
for me to utilize these features in my library even if only C++14 is supported? e.g. in the form
#if __cplusplus >= 201703L
#include <optional>
namespace mylib {
using std::optional;
using std::nullopt;
}
#else
static_assert(__cplusplus >= 201402L, "C++2014 is required to compile this program");
#include <experimental/optional>
namespace mylib {
using std::experimental::optional;
using std::experimental::nullopt;
}
#endif
Note: Of course, I mean in the case of downstream developers actually having to use these features themselves, not just for the case when I use them internally only with no outside exposure.
I wanted to practice with standard C++ threads instead of UNIX ones, but soon encountered a problem, whenever I write std::thread CLion underlines it with red and says Can't resolve namespace member 'thread'. I checked my CMake file it's set for C++11. I reinstalled the latest version of MinGW (6.3.0) and ticked a box with G++ compiler. I have been told by my friend that he uses Cygwin and everything works. But is it still possible to make it work with MinGW?
#include <iostream>
#include <thread>
#define BUFFER_SIZE 3
#define PROD_NUM 3
#define CONS_NUM 2
void produce(){
//production
}
void consume(){
//consumption
}
int main() {
std::cout << "Hello, World!" << std::endl;
int i,j;
std::thread producer(produce);
std::thread consumer (consume);
return 0;
}
The code itself has literally nothing
EDIT
in thread library there is
#pragma GCC system_header
#if __cplusplus < 201103L
# include <bits/c++0x_warning.h>
#else
#include <chrono>
#include <functional>
#include <memory>
#include <cerrno>
#include <bits/functexcept.h>
#include <bits/functional_hash.h>
#include <bits/gthr.h>
#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
/**
* #defgroup threads Threads
* #ingroup concurrency
*
* Classes for thread support.
* #{
*/
/// thread
class thread
{
public:
// Abstract base class for types that wrap arbitrary functors to be
// invoked in the new thread of execution.
struct _State
{
virtual ~_State();
virtual void _M_run() = 0;
};
can you make sure if the library is available in the CLion toolchain? For example Cygwin does have the include.
CLion shows things red when it can't link codes with the library.
It is possibly a host environment variable error. Make sure your CMakeLists.txt is working and your environment variables, standard library linkage is correct as well as your compiler setup.
Compiler version and and standard libraries compatible. (e.g. you are using a cross-compiler (RasPi, Android) but environment vars shows host library etc. will make it fail)
Check this relevant post, it may help.
C++11 std::threads vs posix threads
Ok, so I finally solved the problem. I installed Cygwin and in CLion Settings I manually linked C/C++ compilers (for some reason CLion was unable to auto-detect them). Cleared all and re-indexed the project. Now it shows no errors and code compiles.
Regarding MinGW, I read on cplusplus.com some posts regarding the issue but they were about previous versions of MinGW and it was said that they finally fixed it, however I tell: No, they didn't. Here there is a nice repository and its README file suggests that thread of win32 rely on gthreads, however i found gthread file in my libraries everything seemed ok... so still need to investigate the issue. Write your ideas and experience here if you know more.
As for now solution is Cygwin, use it instead of MinGW.
P.S. Thanks #KillzoneKid for links
I'm trying to compile CppUTest as a library on IAR Workbench v6.3.3 for the AVR UC3C0512C on Windows 7 x64 but when I compile it, it says that the std namespace is not defined.
Here is the snippet of code where I get the first error, the file is SimpleString.h:
#if CPPUTEST_USE_STD_CPP_LIB
#include <string>
#include <stdint.h>
SimpleString StringFrom(const std::string& other);
The last line contains the std::string and this brings me 190 errors all related to this. The message is:
Error[Pe276]: name followed by "::" must be a class or namespace name
C:\COM\SRC\cpputest35\include\CppUTest\SimpleString.h 143
I have tried using the line below but it does not help:
using namespace std;
Under Library Configuration I select Normal DLIB, I also tried with Full DLIB but IAR can't see the std library
Any ideas please?
According to the IAR manuals
The std namespace is not used in either standard EC++ or in Extended EC++. If you
have code that refers to symbols in the std namespace, simply define std as nothing;
for example:
#define std // Nothing here
I would like to use the TR1 libraries that ship with modern versions of GCC and MSVC, but there are subtle differences: in GCC, I have to say
#include <tr1/memory>
std::tr1::shared_ptr<int> X;
while in MSVC I have to say
#include <memory>
std::shared_ptr<int> X;
I have two questions: 1) Does MSVC automatically operate in C++0x-mode (equivalent to GCC's std=c++0x), or does it also work in C++98/03 mode by default? 2) How can I unify the includes and namespaces? I was thinking about a preprocessor macro of the sort "INCLUDE_TR1(memory)" or something like that.
To clarify, I want to use the traditional, standard C++98/03; not C++0x (otherwise there'd be no problem).
I'd be most grateful for any suggestions!
VC++ 2010 only operates in C++0x mode; previous versions had no C++0x support. That said, much of the standard library in VC++ 2010 is is still based on TR1 (e.g. std::result_of<> uses the TR1 result_of protocol instead of being decltype-based); in fact, much of the standard library in VC++ 2010 is not actually defined in namespace std, but rather in namespace std::tr1 and pulled into namespace std with a using directive.
Use Boost.TR1 -- it will #include the appropriate headers according to your platform, or if your platform doesn't have TR1 support, #include the corresponding Boost implementations and pull them into namespace std::tr1 with using declarations.
VC++ 2010 always operates in C++0x mode, but the classes exist in both the std and std::tr1 namespaces. You’ll have to detect the compiler with an #if _MSC_VER to choose which headers to include (see this answer).
The Boost.TR1 library can automatically include your compiler’s headers and fill in any missing functionality using Boost. It might help.
OK, after having several inconsistent and unsurmountable problems with Boost.TR1, especially when trying to use GCC's native TR1 libraries, I decided to ditch Boost entirely and use a small #define workaround. Here is my "tr1.h":
#ifndef _TR1_INCLUDE_H
#define _TR1_INCLUDE_H
/** Usage: #include TR1INCLUDE(unordered_map)
**
** Configuration: Define HAVE_TR1_SUBDIR if you need #include <tr1/unordered_map>; otherwise we take #include <unordered_map>.
**
**/
#define QUOTE(arg) <arg>
#ifdef HAVE_TR1_SUBDIR
# define TR1IFY(arg) tr1/arg
#else
# define TR1IFY(arg) arg
#endif
#define TR1INCLUDE(arg) QUOTE(TR1IFY(arg))
#endif
Now I can just write my programs like this:
#include "tr1.h"
#include TR1INCLUDE(unordered_map)
The different versions of MSVC have the features they have. There is no way of turning them on or off.
Some of them might also have both tr1 and std versions of some features. With slightly different semantics!
I have this very strange problem while compiling the project.
MOC seems to be adding a namespace to the class name being moc'ed, although it's not mentioned anywhere in the file/class.
The namespace, however, exists in a library which I use, but it's hidden far away in the header files and I don't use it in the UI files. This is what MOC generates:
const QMetaObject SmpTl::CaptureController::staticMetaObject = {
{ &QObject::staticMetaObject, qt_meta_stringdata_SmpTl__CaptureController,
qt_meta_data_SmpTl__CaptureController, 0 }};
The SmpTl namespace is not mentioned anywhere in the declaration of CaptureController, but it appears in the MOC-generated .cpp file.
I'm using Visual Studio with the QT integration.
I also ran into this problem. I had code that looked like this:
namespace foo {
#ifdef _WIN32
... // This code was fine
#else
#error Not Supported
#endif
}
This confused MOC into thinking namespace foo never closed. Apparently, it didn't know _WIN32 was defined, and got tripped up by the fact that I forgot to put quotes around the error message. Changing it to:
#error "Not Supported"
fixed my problem.
SmpTl is the namespace CaptureController is defined in, as it was found by MOC.
The Q_OBJECT macro expands into the declaration of the staticMetaObject-variable inside your class definition (among other things it expands into). The MOC-file contains the definition of that variable.
If this is not correct, please post your Qt version and a stripped down version of your header-file.