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
Related
Just installed C++Builder 10.4 Community Edition. My app is a console multi-threaded app, and uses std::scoped_lock (C++17).
It seems that C++Builder chooses a <mutex> header file that does not define scoped_lock in C:\Program Files (x86)\Embarcadero\Studio\21.0\include\dinkumware64, where the <mutex> header file that is in C:\Program Files (x86)\Embarcadero\Studio\21.0\include\dinkumware64\Dinkum\threads actually does define them, but is not the one used during include resolution.
What am I missing? Has this ever been tested?
Launch C++Builder fresh from install, create a new console, multi-threaded application, take the pre-generated shim code for main() and add this code:
#pragma hdrstop
#pragma argsused
#include <mutex>
#ifdef _WIN32
#include <tchar.h>
#else
typedef char _TCHAR;
#define _tmain main
#endif
#include <stdio.h>
std::mutex m;
int _tmain(int argc, _TCHAR* argv[])
{
std::scoped_lock lock(m);
return 0;
}
And that will fail with an error:
no member named "std::scoped_lock" in namespace "std"
The application is 32 bits, debug. I've tried 64 bits as the <mutex> header is strangely located under dinkumware64/mutex, and debug no/debug, I've tried changing various options but no avail.
Now under dinkumware64/Dinkum/threads/, there is another "mutex" package that includes scoped_lock, but I have no idea why C++Builder selects it or not, and it's not in the std namespace anyway.
The standard library is located in dinkumware64 for 32-bit programs as well, so you should be looking there.
Problem is that scoped_lock is missing from the standard library.
You can easily implement this class by yourself by using std::lock, or just use std::lock_guard if you only have one mutex.
I am currently not sure how I should seperate my code best. I currently programming a software which should run on Linux and Windows. So I decided to put all OS-secificstuff in thier own folder/files.
For example
This is the header file:
#ifdef __linux__
#include <unistd.h>
#elif _WIN64
#include <Windows.h>
#endif
#include <string>
#include <iostream>
#pragma once
class SystemTools
{
public:
// Delay in secounds until the programm continues
static void sleep(int delay);
private:
};
and the OS specific implementation is in the linux/windows folder
Linux:
#ifdef __linux__
#include "../SystemTools.h"
void SystemTools::sleep(int delay)
{
usleep(delay*1000000);
}
#endif
Windows:
#ifdef _WIN64
#include "../SystemTools.h"
void SystemTools::sleep(int delay)
{
Sleep(delay*1000);
}
#endif
This works and I have no problems so far, but when I now have methods which don´t need any OS specific code I created an additional folder "Generic" so I can write the code in there and don´t have to mantain the same code in the linux and windows file. For example like that:
Generic:
#include "../SystemTools.h"
void SystemTools::sleepMin(int delay)
{
sleep(delay*60);
}
#endif
That still workes on Linux but not on Windows (no error but does not compile, used codeblockes for that on windows). So how do I organize my code correct? Should I use only one file with ifdef even it that gets very fast ugly?
(compiler Linux: g++, Windows: should be MinGW)
Firstly I'd suggest you to use the most recent of C++ (C++20 or so) on your project. This way, we can abstract many OS related calls (like threading, synchronization, random numbers and etc).
That means, you won't really need to use too many of OS specific APIs. IE: C++11 and earlier already have a standard way to sleep:
https://en.cppreference.com/w/cpp/thread/sleep_for
In the end, if you really need to call OS specific things on windows and on linux, using a library could be interesting and pay attention that windows C++ compiler (visual studio) really like to use 'pre compiled headers' so, it's interesting to have a single header file where all windows specific headers can be included.
Basically that. You can have a standard Cmake or makefile for your linux build and use .sln Visual Studio project to build it to windows.
That's the way I would do that
I've set up a cross compiler for my raspberry pi, the one I found here: Installing Raspberry Pi Cross-Compiler
Now this has been working fine, up to the point where I want to use an I2c library (i2c-dev.h).
When compiling the code below with the arm-linux-gnueabihf-g++ compiler, I get an error:
In file included from src/I2c.cpp:8:0:
src/../Include/I2c.h:29:18: error: field ‘message’ has incomplete type
struct i2c_msg message;
^
Meanwhile, when I compile the code on a raspi, it simply runs.
#ifndef I2C_H_
#define I2C_H_
#include <linux/i2c-dev.h> // Defines i2c_msg
#include ...
using namespace std;
typedef struct {
struct i2c_msg message;
void (*callback)(int);
int messageID;
} t_msgQueue;
Any ideas on a possible cause, or a solution on how I can make the cross compiler work properly?
My first suspect would be differing GCC versions between the RPi and your cross compiler; GCC has been known to change how it processes #include statements over time.
Barring a version difference, check to ensure that a host include file hasn't been picked up somwhere by accident.
Problem was solved by adding a
#include <linux/i2c.h>
before the i2c-dev headers. Still no idea why the two compilers gave different results...
I'm experiencing .Call issues when running functions built with Rcpp on Windows, if my c++ code uses C++11 std::regex and I have found no way out so far.
Unlike prior questions on similar issues, I have had neither building nor linking issues. The Rcpp package builds and links fine using the C++11 plugin, making usable packages on my platform. constexpr and C++11-specific functions like std::stoi cause no issue when std::regex is not used.
Using Windows boost libs, I experienced linking issues, even when specifying PKG_LIBS="-L/path/to/boost/libs -lboost_regex", so I'd rather stick to std::regex.
The same packages build, install and run fine under linux, using vanilla std::regex or boost::regex.
I unfortunately found no solution in the fine Rcpp gallery examples.
Windows platform is :
R version 3.2.3 (2015-12-10)
x86_64-w64-mingw32/x64 (64-bit)
Running under:
Windows >= 8 x64 (build 9200)
Rcpp_0.12.3
Rtools 3.3.0.1959 running g++ 4.9.3 (x86_64-posix-seh,
built by MinGW-W64 project), normally C++11-compatible.
PKG_CXXFLAGS="-std=c++11"
The linux platform is similar except for g++ (version 5.3).
Below is a simplified code chunk for duplication.
#include <Rcpp.h>
#if defined(__linux__) && ! defined(FORCE_STL_BUILD)
#include <boost/regex.hpp>
#define reglib boost
#else
#include <regex>
#define reglib std
#endif
#include <string>
using namespace Rcpp;
// [[Rcpp::plugins(cpp11)]]
constexpr int a[3]= {2, 10, 15};
// [[Rcpp::export]]
int my_test(int prop, const std::string& index)
{
#ifndef NO_REG
static const reglib::regex test {"H.*A", reglib::regex::icase};
#endif
int index_int = std::stoi(index) + a[1] + prop;
return index_int;
}
This code runs OK when built using -DNO_REG. Otherwise invoking test::my_test(1, "1000") returns:
`Error in .Call("test_my_test", PACKAGE = "test", prop, index) :
"test_my_test" not available for .Call() for package "test"`
EDIT:
1. The question focuses on std::regex. Boost issues are only incidental comments.
2. Issues only arise after packaging, not using Rcpp::source("cppfile")
3. Packaging code:
R console:
Rcpp::Rcpp.package.skeleton("test", attributes=TRUE, example_code=FALSE, cpp_files="test.cpp")
Rcpp::compileAttributes("test")
CMD console:
REM paths to R/bin/x64 and Rtools/bin, Rtools/mingw_64/bin added to PATH
set PKG_CXXFLAGS=-std=c++11
R CMD build test
R CMD INSTALL test_1.0.tar.gz
ADDITIONAL EDIT:
.Call issues arise as soon as a regex is declared in the C++ code. Using it or no (as in std::regex_match) makes no change.
Can you try disentangling this some more? You are mixing a lot of things here.
Try maybe 'just' C++ from R first, with the newer g++ 4.9.3 compiler and see if that lets you use Boost as you hope. Your use case there is local and non-standard, so you have to work this out. We generally just recommend using BH without linking.
I don't actually see an Rcpp issue here. You are simply pushing the (working, tested, trusted) Rcpp setup into a corner it has not been used in yet. So you may need to work some things out yourself.
Also note that g++ 4.9.3 for R is not really released yet.
I am a novice in C++ and I am struggling to make my program to wait a few minutes before executing a function.
I know there are lots of topics about it but I have a problem with my compiler. I can't seem to use the boost library nor the thread library. And since I can't use the thread library, I can't use the chrono library either.
I am using GNU GCC Compiler. I have MinGW installed. Is it outdated or something? What is the best compiler to code in C++?
My OS is Windows.
You could use this
#include <unistd.h>
...
usleep(1000); // Time in microseconds
or
#include "stdafx.h"
#include "windows.h"
#include "iostream"
using namespace std;
int main(){
int sleepTime = 1000;
Sleep(sleepTime);
return 0;
}
<thread> is only available starting with C++11.
It's likely you don't have the proper flags to tell GCC you want to enable C++11 support, which is disabled by default.
The command line parameter is -std=c++11.
Then, you can use std::this_thread::sleep_for() for cause your program to fall asleep. Note that if you only have one thread in your program, it will probably stop responding to user actions during that time.