extern template class vector

This started out as a question of: "Why isn't it possible to explicitly instantiate an std::vector of std::unique_ptr?" as in:

template class std::vector<std::unique_ptr<int>>;

although following explicit instantiations and variables are fine:

template class std::vector<int>;
template class std::unique_ptr<int>;

int main() {
    std::vector<int> ints;
    std::vector<std::unique_ptr<int>> pointers;
}

But the question changed to: "What would be the alternatives?"

I'll post my though walk-through to answer both, since I didn't find a question that felt similar enough. I am also looking for alternatives, if any other.

Unable to compile LLVM 5.0.0 with MSVC 14.0

I am trying to compile LLVM 5.0.0 from source on Windows 10 with Visual Studio 14.0 (2015).

I used the following cmake flags:

CMAKEOPTIONS += -D PYTHON_EXECUTABLE:PATH=$(PYTHON_PATH)/bin/python
CMAKEOPTIONS += -D LLVM_ENABLE_TERMINFO=0
CMAKEOPTIONS += -D LLVM_ENABLE_EH=1
CMAKEOPTIONS += -D LLVM_ENABLE_RTTI=1
CMAKEOPTIONS += -D LLVM_ENABLE_ASSERTIONS:BOOL=ON -D LLVM_ABI_BREAKING_CHECKS:STRING="FORCE_OFF"

The compilation fails with:

Severity Code Description Project File Line Suppression State Error C2039 'iterator_facade_base,0,1>

,std::forward_iterator_tag,llvm::PHINode const ,__int64,llvm::PHINode const *,llvm::PHINode const &>': is not a member of 'llvm::BasicBlock::phi_iterator_impl' (compiling source file S:\authama\3p-tmw\3p\derived\win64\LLVM5\llvm-debug\lib\Target\AMDGPU\Utils\AMDGPUBaseInfo.cpp) LLVMAMDGPUUtils s:\authama\3p-tmw\3p\derived\win64\llvm5\llvm-debug\include\llvm\ir\basicblock.h 294

Which points to:

290     bool operator==(const phi_iterator_impl &Arg) const { return PN == Arg.PN; }
291 
292     PHINodeT &operator*() const { return *PN; }
293 
294     using phi_iterator_impl::iterator_facade_base::operator++;
295     phi_iterator_impl &operator++() {
296       assert(PN && "Cannot increment the end iterator!");
297       PN = dyn_cast<PHINodeT>(std::next(BBIteratorT(PN)));
298       return *this;
299     }

The source compiles with GCC 4.9/Debian8, so I am guessing I missed something to do with setting up the compiler correctly. Any suggestions for me to try?

Building static strings with C++ Metaprogramming

I'm writing an open source sqlite interface library (mSqliteCpp for instance) that uses c++ classes and types to correctly manage sqlite databases.

So far the library is heavily using TMP to build SQL strings, but I found a possible issue that may somehow affect the efficiency of the library.

I'm using classes to manage Fields definitions, classes definitions, queries and statements. Basically to define a table or a SELECT statement, one defines the fields using proper FieldDef<T> objects, then pass them to a statement builder that returns the correctly formatted SQL statement.

For example:

auto fldId = sqlite::makeFieldDef("id", sqlite::FieldType::Integer());
auto fldName = sqlite::makeFieldDef("name", sqlite::FieldType::Text());
auto fldValue = sqlite::makeFieldDef("value", sqlite::FieldType::Real());

sqlite::statements::Select select("Table", fldId, fldName, fldValue);

ASSERT_EQ(select.string(), "SELECT id,name,value FROM Table;");

Note that each field is strongly typed by the FieldType type passed to the makeFieldDef function, but different fields with similar type can be exchanged. For this reason the SQL statement in the ASSERT call is built at runtime.

I would like to have them built at compile time, at least under certain conditions. For example, developer could use a different class or maybe the constexpr keyword. But at this time I've no idea if this could be achieved.

What are the possible patterns? Can strings be statically built through TMP? I'm using C++11/14.

Thank you.

How to build plot in gtkmm-plplot?

I need simple example for plot building with gtkmm-plplot. I try to read official documentation but it is very hard for me. Can you show me how to build sinusoidal plot?

How to use unique_lock in a class that calls other functions that use unique_lock?

I have a class that I need to make thread-safe. I'm trying to do this by putting a unique lock at the top of every function in the class. The problem is that as soon as one function calls another function (in this class) the mutexes seem to lock each other, despite being in different functions. How can I stop this from happening?

Template specialization and perfect forwarding

So I am trying to build a "sanitizer" function to filter formatting arguments before they are forwarded to printf.

template<typename A>
_CR_INLINE decltype(auto) sanitize_forward(A&& arg) {
    return std::forward<A>(arg);
}

template<>
_CR_INLINE decltype(auto) sanitize_forward<std::string>(std::string&& arg) {
    return std::forward<const char*>(arg.c_str());
}

So every std::string is supposed to "decay" into a const char*, in order to be properly formatted.

template<typename...Args>
_CR_INLINE void printf_safe(const std::string& format, Args&&...args) {
    std::printf(format.c_str(), sanitize_forward<Args>(args)...);
}

I want the arguments to be perfectly forwarded to printf, which is why I return std::forward. But I can't really wrap my head around how this should be implemented.

1) Is decltype(auto) correct? It should preserve the r-value referenceness of the return of std::forward, right?

2) How should I specialize my template: std::string&& or std::string?

3) Deduced forwarding references should be the same as the actual type, right?

Storing OpenGL color attachments in constexpr GLenum array

I am using the following constexpr GLenum array to represent GL_COLOR_ATTACHMENTx (where x is an unsigned integer between 0 and 7):

constexpr std::array<GLenum, 8> opengl_color_attachment{GL_COLOR_ATTACHMENT0, GL_COLOR_ATTACHMENT1, GL_COLOR_ATTACHMENT2, GL_COLOR_ATTACHMENT3, GL_COLOR_ATTACHMENT4, GL_COLOR_ATTACHMENT5, GL_COLOR_ATTACHMENT6, GL_COLOR_ATTACHMENT7};

This works fine for only the first eight available color attachments (which the OpenGL specification states to be the minimum). However, there is a possibility of more attachments, which is implementation defined. As the macro GL_MAX_COLOR_ATTACHMENTS represents the number of attachments available, I wanted to edit this constexpr array to include ALL available attachments to the limit, instead of the minimum of 8.

I created the following macro in an attempt to solve this issue myself:

#define OPENGL_COLOR_ATTACHMENT(x) GL_COLOR_ATTACHMENT##x

Although I wanted to use this in a constexpr function to create the array in compile-time, it failed because preprocessor macros are obviously processed before compilation. Although the OpenGL standard guarantees that GL_TEXTURE1 == GL_TEXTURE0 + 1, it does not seem to guarantee this for the GL_COLOR_ATTACHMENTx macro.

Is there a way for me to create the constexpr array fully from GL_COLOR_ATTACHMENT0 to GL_COLOR_ATTACHMENTx where x = GL_MAX_COLOR_ATTACHMENTS, with or without preprocessor macros?