kfrlib/cometa

Lightweight, header-only C++14 metaprogramming library. Pattern matching, compile-time stuffs and algorithms (arrays, type information (CTTI), string manipulation), 'value-or-errorcode' union-like type, type for passing named arguments, useful constexpr functions and many more. (MIT license)

cometa's Issues

Returning reference from cometa::function results in compile error on Windows/Clang/LLVM.

When returning a reference type from cometa::function<something & (some parameters...)> on Windows VC14/Update3 with Clang/LLVM (http://llvm.org/builds/) a compiler error is raised. Returning a pointer cometa::function<something * (some parameters...)> works fine, and is obviously a work-around, but it would be nice to have a reference returned.

edited: clarify what I intended to say.

Cometa bug, sending VCPkgSrv to the moon (and back)

The following describes the problem as reported to MS and their answer.

I want to follow-up on the feedback you have submitted, as you described:
"The Package Server seems to go into an infinite loop on inclusion of the cometa.hpp of this library: https://github.com/kfrlib/cometa. The library is pretty good, particularly the cometa::function, which reduces the footprint of std::function<> from 64 bytes to (cometa::function<>) 8 bytes (on _WIN64), and does the same. Seems like a candidate to include in the MS-STL. Please forward to Steven T.L.!"

I have investigated the issue with VCPkgSrv you have described when using the library. It turns out the library is making wrong assumptions on the compiler implementation defined behavior, resulting in extremely deep template instantiation chain. Factually, the compiler is not in an infinite loop, but rather performing the work that it has been requested to do (that is, until it runs out of other resources like memory).

Going into specifics, IntelliSense compiler is using a different implementation (EDG) than the batch compiler in Visual Studio. They return different values for the FUNCSIG macro. CoMeta library contains function “ctype_name” intending to perform a compile-time substring operation on the result of that macro. The implementation is subtracting a length of the “known” hard-coded prefix of the FUNCSIG result without checking for unsigned integer overflow. In case of IntelliSense compiler the hard-coded prefix is longer than the actual prefix, resulting in integer wrap-around and a very large value passed subsequently to “csizeseq” instantiation, which in turn is performing recursive instantiations based on that value.

The problem should be corrected in the library source code.

Best regards,
Łukasz Mendakiewicz