I have a class MyClass<size_t, type>.
I would like to add conditional template instantiation using std::is_same and std::conditional.
However, both types for the first parameter are the same and are size_t.
As expected when MYSIZE1 and MYSIZE2 are the same, class<MYSIZE,int> will give an error.
How can I perform this conditional compilation considering that the only change is in the value of the template parameter?
template class MyClass<
std::conditional< (!std::is_same<MyClass<MYSIZE1,int>,
MyClass<MYSIZE2,int>
>::value),
MyClass<DUMMYSIZE,int>,
Myclass<MYSIZE1, int>
>::type,
int>;
This does not work obviously as conditional returns MyClass type.
Related
In a templated class, I would like to make an alias of a variadic parameter, something like:
template<typename ... TYPES>
class X
{
using Types = TYPES;
};
It is easy to make a std::tuple of it, but is there a syntax for doing the above.
The reason is I would like to reference this from the templated class in another class.
Given the following code to parse:
template <typename T, int N=3>
class Base {};
using BaseFloat1 = Base<float, 1>;
I can get the TypeAliasDecl from the last line, get the CXType from that, and the use clang_Type_getNumTemplateArguments() to see that there are two template arguments there, but the only option for retrieving the arguments is clang_Type_getTemplateArgumentAsType(), which obviously fails for the second, IntegerLiteral argument.
Is there any way to get the non-type template argument directly, other than inspecting the children of the TypeAliasDecl cursor?
I'm reading the source code of the main json11 header file.
It contains the following declaration:
template <class T, class = decltype(&T::to_json)>
Json(const T & t) : Json(t.to_json()) {}
I'm trying to find some documentation about this usage of decltype and class inside a template declaration but no success.
Does this construction/usage has a name in C++? Any good reference about it?
It's using SFINAE ("Substitution Failure Is Not An Error"), a common technique for advanced template stuff. In this case, it's used as a crude(1) test whether the type T has a function named to_json.
How it works: if the expression T::to_json is well-formed (there is something named to_json inside the type T), decltype(T::to_json) denotes a valid type and the constructor template can be used normally.
However, if T::to_json is ill-formed (i.e. if there is no to_json member inside T), it means substituting the template argument for T has failed. Per SFINAE, this is not an error of the entire program; it just means that the template is removed from further consideration (as if it was never part of the class).
The effect is thus that if type T has a member to_json, you can use an object of type T to initialise a Json object. If there is no such member in T, the constructor will not exist.
(1) I'm saying crude test because this only checks that T has such a member. It doesn't check that the member is a function which can be invoked without arguments and returns something another constructor of Json can accept. A tighter-fitting test might look something like this:
template <class T, class = std::enable_if_t<std::is_constructible<Json, decltype(std::declval<const T>().to_json())>::value>>
Json(const T & t) : Json(t.to_json()) {}
[Live example]
Consider following
struct dummy{};
dummy d1;
dummy d2;
template<dummy* dum>
void foo()
{
if (dum == &d1)
; // do something
else if (dum == &d2)
; // do something else
}
Now, it is possible to call foo like this
foo<&d1>();
foo<&d2>();
and everything works as expected. But following does not
constexpr dummy* dum_ptr = &d1;
foo<dum_ptr>();
With this error from Visual studio
error C2975: dum_ptr: invalid template argument for foo, expected compile-time constant expression
While this works
constexpr dummy& dum_ref = d1;
foo<&dum_ptr>();
In visual studio, but not in G++, because of
note: template argument deduction/substitution failed:
error: & dum_ref is not a valid template argument for dummy* because it is not the address of a variable
foo<&dum_ref>();
EDIT:
Since C++17, std::addressof is being marked as constexpr, so I would guess it should work.
GCC is right on this one.
The expressions are definitely constant-expressions*, since they are assigned to a constexpr variable. However, until c++14, there are additional restrictions on what is allowed for a pointer template argument.
C++14 draft N4140 [temp.arg.nontype]
1 A template-argument for a non-type, non-template template-parameter shall be one of:
for a non-type template-parameter of integral or enumeration type, a converted constant expression (5.19) of the type of the
template-parameter; or
the name of a non-type template-parameter; or
a constant expression (5.19) that designates the address of a complete object with static storage duration and external or internal
linkage or a function with external or internal linkage, including
function templates and function template-ids but excluding non-static
class members, expressed (ignoring parentheses) as
&id-expression, where the id-expression is the name of an object or
function, except that the & may be omitted if the name refers to a
function or array and shall be omitted if the corresponding
template-parameter is a reference; or
a constant expression that evaluates to a null pointer value (4.10); or
a constant expression that evaluates to a null member pointer value (4.11); or
a pointer to member expressed as described in 5.3.1; or
a constant expression of type std::nullptr_t.
For foo<dum_ptr>(), dum_ptr isn't expressed as &name, and for foo<&dum_ref>(), dum_ref isn't the name of the object, it's the name of a reference to the object, so both are disallowed as template arguments.
These restrictions are lifted in c++17 to allow any constexpr, so thats why it works there:
C++17 draft N4606 - 14.3.2 Template non-type arguments [temp.arg.nontype]
1 A template-argument for a non-type template-parameter shall be a
converted constant expression (5.20) of the type of the
template-parameter. For a non-type template-parameter of reference or
pointer type, the value of the constant expression shall not refer to
(or for a pointer type, shall not be the address of):
(1.1) a subobject (1.8),
(1.2) a temporary object (12.2),
(1.3) a string literal (2.13.5),
(1.4) the result of a typeid expression (5.2.8), or
(1.5) a predefined __func__ variable (8.4.1).
As usual, clang gives the best error messages:
https://godbolt.org/g/j0Q2bV
*(see Address constant expression and Reference constant expression)
I have taken a look at a C# struct FooStruct in ILDASM, and have seen the following:
ILDASM here displays two differing declarations:
one starting with .class value public (rear window & front window's title bar)
one starting with just .class public (front window)
And I wonder which syntax (if not both) is the correct one for declaring a value type? Is the value modifier strictly necessary, or optional, or a syntax error?
Short answer: Value type definitions only require extends [mscorlib]System.ValueType; the value attribute appears to be optional and has no apparent effect.
I assume that the CLI specification (ECMA-335) would be the best place to look for an authorative answer.
MUST a value type definition include the value attribute?
Section II.10 deals with defining types. More specifically, subsection II.10.1.3 states:
The type semantic attributes specify whether an interface, class, or value type shall be defined. … If [the interface] attribute is not present and the definition extends
(directly or indirectly) System.ValueType, and the definition is not for System.Enum, a value type shall be defined (§II.13). Otherwise, a class shall be defined (§II.11).
The value attribute is not mentioned at all in the whole section.
Conclusion: A correct value type definition does not have to include value. Deriving from System.ValueType is sufficient.
MAY a value type definition include the value modifier?
The CLI standard also contains a grammar for ILASM (in section VI.C.3). According to that grammar, there exists a value attribute for .class type definitions. I additionally searched the standard for concrete value type definitions and found these examples:
.class public sequential ansi serializable sealed beforefieldinit System.Double extends System.ValueType …
.class private sealed Rational extends [mscorlib]System.ValueType …
.class value sealed public MyClass extends [mscorlib]System.ValueType …
Conclusion: A value attribute may be included in a value type definition.
And what does the value attribute MEAN?
I tried to compile these three IL type definitions into an assembly:
.class public sealed … A extends [mscorlib]System.ValueType { … }
.class value public sealed … B extends [mscorlib]System.ValueType { … }
.class value public sealed … C extends [mscorlib]System.Object { … } // !!!
There was no compilation error, even though the value attribute is used in a reference type declaration (see last line). Looking at the resulting assembly using Visual Studio 2012's Object Browser reveals two value types (struct) A and B, and one reference type (class) C.
Speculation: The presence of the value attribute has no effect whatsoever on the type definition. It is only there as a potential aid for humans in spotting value type definitions.
This great book contains simple
answer: when you provide extends clause then value flag is ignored, but if you doesn't provide
extends and use value then ilasm will declare given type as value type.
In other words value was introduced as syntactic sugar, to quickly declare value type.