In my API I have a function that returns std::istringstream.
The std::istringstream class is non-copyable but supports moving so on a conforming compiler there is no problem returning a local std::istringstream.
However, on gcc 4.9, there is no support for moving std::istringstream.
Is there some workaround that I can use that std::istringstream without changing the API from the user's perspective?
The workaround suggested here, of using a unique_ptr<std::istringstream> will change the semantics of the API.
Answering my own question for completeness and future reference.
The goal was to find a workaround for the gcc (< 5) bug where
std::istringstreamdoes not provide a move ctor that will work in cases where I want to return the un-copyable and (bugly-) unmovable stream.As mentioned in the comments, I can in fact change my function signature (at least on gcc < 5) to return a proxy object that allows copying or moving without changing the API for code used on newer/other compilers.
The idea, suggested and implemented by a colleague, is to create a proxy object around
std::istringstreamwhich provides a similar API, but also provides a copy-ctor which manually creates and initializes a new internalstd::istringstreamfrom the copied-from stream. This proxy is used only on the offending compilers.The code in its natural habitat is here.
Here's the relevant part: