tuskcode

I have been playing around with Docker and using it to access the latest features of GCC's libstd++

​

My docker file using is available here - it grabs the latest official GCC docker image

​

https://docdro.id/XIa6Xrp

​

And the example it is trying to compile is

​

#include <iostream>
#include <filesystem>
namespace fs = std::filesystem;
int main()
{
    std::cout << "Current path is " << fs::current_path() << '\n';
}

​

The compiler error I get is

​

Step 4/5 : RUN g++ -o hello_world main.cpp -lstdc++fs
 ---> Running in 3

This is an open ended question, so I am looking for general advice rather than specifics.

​

My problem relates to use of boost::filesystem within a large project where there appears to be an ABI incompatibility between the project itself and how boost::filesystem has been compiled. Ultimately, the use of boost::filesystem::path::operator/=(const string_type& s) results in a bad_alloc exception.

​

I am using boost 1.65.1 on Ubuntu 18.04.2 installed using apt install libboost-all-dev.

​

I have tried to replicate my issue with a smaller project. However, in the prepared minimum sample, no exceptions are raised and the same code works fine.

When compiling our visual studio open folder Cmake project targeting a Linux system, any change in source results in the entire project being rebuilt. Where do I even start looking for why this would be happening? This is a project that takes about 25 minutes on some systems.

I just finished listening to the latest cppcast, this was a handy reference to another C++ video blog / podcast. Haven't been able to find a announcement here on the cpp reddit

https://www.youtube.com/watch?v=1wcrwu_CxHU

I want a fixed size queue implementation. One where the size of the queue is statically configurable, another that is run time configurable. How do I provide the correct specialization of the following code to achieve this?

template<typename T, int N>
struct FixedSizeQueue
{
	using value_type = T;
	using queue = std::vector<value_type>;
	const int size_ = N;

	//... remainder of implementation
};

template<typename T>
struct FixedSizeQueue
{
	using value_type = T;
	using queue = std::vector<value_type>;
	const int size_;

	explicit FixedSizeQueue(int size) : size_(size)
	{
		/*implemen

I just had a lightbulb moment, thinking that the acceptance of string_view as parameters for std library functions would be great. As it turns out, Peter Sommerlad has already had this brain wave and has developed a proposal. Does anybody know the status of this paper? Are there any vendors looking at this?

I basically want to end up with POCO linked against OpenSSL, for use with VS2017 compiler. Has anyone had success doing this?

I've been toying with the build for a few hours now, with little success. I initially downloaded OpenSSL binaries for linking. In this scenario, I was able to build POCO, but when I try to link to POCO, it fails. The project linking to poco is configured with the additional dependency directories and files (both for POCO and OpenSSL).

I can get the link errors down to just a handful of unresolved external dependencies on __iob_func.

Can anyone with experience with building Poco with SSL for VS2017 provide some guidance?

It's a fairly contrived example, but I have a class that owns a std::vector<std::unique_ptr<Base>>, I wish to return a subset of this vector, as raw pointers, to represent the fact that ownership and/or lifetime management is to be handled by the library. In the example below, I have simulated this with the function getRawPointers.

What are 'safer' alternatives to this design pattern? Please observe that I do not wish to use shared_ptr semantics.

v#include <iostream> #include <memory> #include <vector> #include <algorithm>

class base
{
public:
    virtual ~base() = default;
    virtual void print() = 0;

};

c

I am using futures to execute a messaging system

void RaiseEvent(EventID messageID)
{
	mEventExecutors.push_back(std::move(std::async([=]{
			auto eventObject = mEventListeners.find(messageID);
			if (eventObject != mEventListeners.end())
			{
				for (auto listener : eventObject->second)
				{
					listener();
				}
			}
		})
	));
}

Is there anyway to automate the removal of the completed futures from mEventExecutors? Or do I need to monitor the state of the futures in the vector and manually erase these?