I am trying to use std::experimental::detect_or_t from <experimental/type_traits>.
What compiler, option, version or library do I need to compile the following example from http://en.cppreference.com/w/cpp/experimental/is_detected ?
#include <experimental/type_traits>
#include <cstddef>
template<class T>
using diff_t = typename T::difference_type;
template <class Ptr>
using difference_type = std::experimental::detected_or_t<std::ptrdiff_t, diff_t, Ptr>;
struct Meow { using difference_type = int; };
struct Purr {};
int main()
{
static_assert(std::is_same<difference_type<Meow>, int>::value, "Meow's difference_type should be int!");
static_assert(std::is_same<difference_type<Purr>, std::ptrdiff_t>::value, "Purr's difference_type should be ptrdiff_t!");
}
I tried using clang++ -std=c++14 and g++ -std=c++14. Also with -std=c++1y and -std=c++17. I always get this:
main.cpp:8:44: error: 'detected_or_t' in namespace 'std::experimental' does not name a template type
Those traits were first added to libstdc++ in GCC 6.1.0, as documented in the GCC 6 release notes:
Experimental support for most features of the second version of the Library Fundamentals TS.
And the implementation status tables in the manual, at
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/libstdc++/manual/manual/status.html#table.cxx1z_ts_status
I'm less sure about libc++, but they're not supported by the version in Clang 3.9.1 but are supported by the current trunk, so I think they first appeared in Clang 4.0.0
Related
// some_library.h
class MyLib {
public:
int field_a;
int field_b; // Only available on some versions
int field_c; // Only available on some versions
int ...;
};
A library I'm using have a variable number of public fields depending on versions.
In Cmake, is it possible to detect if a certain field from library header exists?
(perhaps similar to the CHECK_FUNCTION_EXISTS)
You can use check_symbol_exists for a C symbol.
Doc: https://cmake.org/cmake/help/latest/module/CheckSymbolExists.html
Or check_cxx_symbol_exists for a CXX symbol.
Doc: https://cmake.org/cmake/help/v3.18/module/CheckCXXSymbolExists.html
You can use check_struct_has_member from CheckStructHasMember. See https://cmake.org/cmake/help/latest/module/CheckStructHasMember.html
CMakeLists.txt
include(CheckStructHasMember)
Check_struct_has_member("class MyLib" field_a ${CMAKE_CURRENT_SOURCE_DIR}/MyLib.h HAS_FIELD_A LANGUAGE CXX)
I'm following Kate Gregory's C++ course on Pluralsight and understand that C++17 introduced a feature for compilers to deduce the type in a template, however the code below returns the error: missing template arguments before 'numbers'
#include <vector>
using std::vector;
int main()
{
vector numbers{ 0, 1, 2 };
return 0;
}
I'm using the MinGW gcc compiler (version 6.3.0) and using "g++ -std=c++1z *.cpp" in the command prompt, so I'm not sure what I'm doing wrong.
I know I can fix it by declaring the type but I wanted to check in case I miss out on other C++17 features through some basic error I'm making.
Your code is OK (but I suggest not to use using std::vector).
The problem is your compiler, g++ 6.3.0, that is too old to support the feature you're trying to use: class template argument deduction and deduction guides.
You need g++ 7 or newer.
I'd like to check for intel intrinsics such as _mm_popcnt_u32 or _mm_blendv_epi8 using cmake. However the function check_symbol_exists doesn't work properly depending on the compiler. (it works with Clang but not with GCC). Indeed it is documented
If the header files declare the symbol as a function or variable then the symbol must also be available for linking (so intrinsics may not be detected).
Is there a simple way to check for those ?
As the CMake documentation also states:
If the symbol is a type, enum value, or intrinsic it will not be
recognized (consider using CheckTypeSize or CheckCSourceCompiles).
So, try to compile a small example with the Intel intrinsic using CheckCSourceCompiles. E.g.:
include(CheckCSourceCompiles)
check_c_source_compiles("
int main() {
int tmp = _mm_popcnt_u32(0);
return 0;
}
"
HAVE_INTRINISC
)
I'm trying to use DateTime from rust-chrono crate to my own trait.
#[derive(Debug, RustcEncodable, RustcDecodable)]
pub struct Accomplishment {
name: String,
accomplishment_type: String,
date: DateTime<UTC>
}
When I try to compile this it complains that
src/lib.rs:11:33: 11:47 error: the trait `rustc_serialize::serialize::Decodable` is not implemented for the type `chrono::datetime::DateTime<chrono::offset::utc::UTC>` [E0277]
src/lib.rs:11 #[derive(Debug, RustcEncodable, RustcDecodable)]
When I checked the github repo of chrono it had the rustc_serialize support implemented. But it is as a feature. In commit log it has
cargo test -v --features rustc-serialize
I'm not sure how to have this feature for my project. Can someone help me on how to use chrono with rustc-serialize?
There is a similar question regarding this. But what I wanted is to use the serialization support available in chrono in my project without implementing a wrapper trait.
Add the feature to your dependency in the Cargo.toml
[dependencies.chrono]
version = "*"
features = ["rustc-serialize"]
The relevant Documentation can be found here
I need to recover method names dynamically, via reflection calls at runtime. But get strange results for some.
My TestClass contains a method like:
- (void)testMethod6_NSRect:(NSRect)a1 int:(int)a2 int:(int)a3 bool:(Boolean)a4 {
...
}
When enumerating the above classes methods using class_copyMethodList() and fetching the method selectors via method_getName(), I get:
"testMethod6_NSRect:int:int:_Bool:"
Thus, the selector was rewritten somehow (by gcc?) to make "_Bool" from "bool". As far as I tested yet, this seems to be done only for a "bool" selector-part - if I change it to int:(int), as in:
- (void)testMethod1_int:(int)a1 int:(int)a2 int:(int)a3 int:(int)a4 {
...
}
I get the expected:
"testMethod1_int:int:int:int:"
Q:
Does anyone know the rules or a pointer to where I could find them for this "selector rewriting", or am I missing something? Is this only done for "bool"?
I also need to know if this behavior is depending on the gcc-version, osx-version or runtime library version.
I am using (gcc --version):
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
on a (uname -a)
10.8.0 Darwin Kernel Version 10.8.0:
The problem lies in an ugly piece of preprocessor magic in the C99 standard header <stdbool.h>:
#define bool _Bool
C99 defines a type named _Bool which behaves like C++'s bool type. The define is there to be able to use it in C but with the C++ identifier.
Solution:
#undef bool
Try using BOOL instead of Boolean