Avoid writing constructor every union style class in C++17 - c++

I'm stuck with c++17 for a project, so I don't have access to designated initializers. I have a bunch of union types that I want to avoid initializing this way (because it is annoying):
MyUnionType x;
x.value = value_set_for_all_union_members;
I want to instead have this
MyUnionType x(value_set_for_all_union_members);
But I also want to avoid writing an implementation for each union I create. I know that all my union types are going to be of the following structure, each union is meant to actually represent bit a bit field, so I actually do want type pruning here, I know it is "UB" according to C++, but that is on the C++ committee, in C it is not undefined behavior, and thus all compilers that I care about will do what I want here.
union Example{
integer_type value;
custom_safe_bitfield_abstraction<...> a;
custom_safe_bitfield_abstraction<...> b;
...
};
I thought, okay, I'll just inherit the constructor, and use CRTP to extract the appropriate integer_type. Of course I can't inherit on a union directly, so instead I opted for this strategy:
struct Example : Base<Example>{
union{
integer_type value;
custom_safe_bitfield_abstraction<...> a;
custom_safe_bitfield_abstraction<...> b;
...
};
};
using an anonymous union, I should be able to use it the same exact way as before (example.value should be the value inside of union).
Then in the implementation I do the following:
template<class Derived_T>
struct Base{
using value_type = decltype(Derived_T::value);
explicit Base(value_type v){
static_cast<Derived_T*>(this)->value = v;
}
}
This however doesn't work:
error: Incomplete type 'Example' used in nested name specifier
> using value_type = decltype(Derived_T::value);
Apparently we aren't allowed to refer to a member before it has been declared. Okay... but there must be some way to extract the type data out, after all I don't care about any memory alignment or anything.
The only other thing I can think of, is include the type in the CRTP template parameter (ie Base<Derived_T, value_type>) but I want to avoid doing that. I imagine there is some method for writing a function or specifying an internal type on each derived class, I don't want to do that either (and sort of defeats the purpose of what I'm doing anyway).
Is there a way to avoid writing the constructor per class, and with out sacrificing the other code duplication minimization goals I have?

Not exactly what you asked... but you can use the fact that you can use the type of D::value inside a member function... so using SFINAE over a template contructor...
I mean, you can write something as
template <typename D>
struct Base
{
template <typename T>
static constexpr bool is_value_type ()
{ return std::is_same_v<decltype(D::value), T>; }
template <typename T, bool B = is_value_type<T>(),
std::enable_if_t<B, int> = 0>
explicit Base (T v)
{ static_cast<D*>(this)->value = v; }
};
where the template constructor is enabled only if the deduced type of the argument is of the same type of B::value.
Remember also to add the using
using Base<Example>::Base;
inside Example.
The following is a full compiling example
#include <type_traits>
template <typename D>
struct Base
{
template <typename T>
static constexpr bool is_value_type ()
{ return std::is_same_v<decltype(D::value), T>; }
template <typename T, bool B = is_value_type<T>(),
std::enable_if_t<B, int> = 0>
explicit Base (T v)
{ static_cast<D*>(this)->value = v; }
};
struct Example : Base<Example>
{
using Base<Example>::Base;
union
{
long value;
long a;
long b;
};
};
int main ()
{
//Example e0{0}; // compilation error
Example e1{1l}; // compile
//Example e2{2ll}; // compilation error
}

Related

Check if T is a bitfield?

Is it possible to check at compile time if T is a bitfield?
I'd like to use it in:
template <typename Allowed>
struct explicitly_constructible
{
template <typename T, typename = std::enable_if_t<is_bitfield_v<T>>>
constexpr operator T() const;
};
Example usage:
struct normal
{
int foo;
};
struct with_bitfield
{
int bar : 2;
};
normal n{explicitly_constructible<int>()}; // well-formed
with_bitfield m{explicitly_constructible<int>()}; // must be ill-formed
I am implementing a reflection library that provides for_each and get<Index> tuple-like functions for pod-like structs. Unfortunately, you can't use it on a struct with bitfields since it is UB to get an address of a bit-field. So I want to detect if a struct contains a bitfield to fire a compile-time error. Now I have some workaround - I compare struct size against evaluated, but I would like a simpler approach.

can C++ template detect members of specific type?

can C++ template detect members of specific type? As code below,
template <typename T>
class Element {
};
template <typename T>
class Container {
public:
Container() {
// check if T has member which type is "Element<whatever>"
// how many Element<whatever>s?
// offset?
}
};
I have a template class named Container, and I want to check:
If the passed in type T has member which type is Element<whatever>?
If so, can I get how many members which type is Element<whatever>?
If so, can I get the offset to the beginning of the class?
Explain more about requirement 3:
What I want is to access these fields(if exist) when I get a piece of data which is cast by reinterpret_cast<T>
This is doable in C++20 if the T of Container<T> is an aggregate ; I use the boost::pfr library as it simplifies this idiom but it is easily reimplementable by hand (boost::pfr's source is very simple to read)
#include <boost/pfr.hpp>
template<typename T, typename Target>
auto count_members_of_type()
{
unsigned int count = 0;
boost::pfr::for_each_field<T>(T{}, [&] <typename U> (U&&) {
count += std::is_same_v<std::remove_reference_t<U>, Target>;
});
return count;
}
given
struct Foo {
Element<int> a, b;
Element<float> c;
std::string d;
};
then
count_members_of_type<Foo, Element<int>>() == 2
Running example on gcc.godbolt.org: https://gcc.godbolt.org/z/srhn8GfWb

Prevent templated member function from being instantiated for a given type

I have a templated matrix class that I explicitly instantiate for various POD types and custom class types. Some of the member functions however don't make sense for a few of such custom types. For example:
Matrix<int> LoadFile(....); // This makes sense
Matrix<My_custom_class> LoadFile(...); //This doesn't make sense in the context of the custom class
Can I prevent the instantiation of the LoadFile function (which is a member function) for Matrix objects of select types? So far I have avoided the issue by making LoadFile a friend function and then explicitly controlling its instantiation. But I want to know if I can do this when LoadFile is a member function of Matrix.
The first question is whether you really need to control this. What happens if they call that member function on a matrix that stores My_custom_class? Can you provide support in your class (or the template) so that the member function will work?
If you really want to inhibit the use of those member functions for some particular type, then you can use specialization to block the particular instantiation:
template <typename T>
struct test {
void foo() {}
};
template <>
inline void test<int>::foo() = delete;
Or even just add static_asserts to the common implementation verifying the preconditions for what types is it allowed or disallowed?
template <typename T>
struct test {
void foo() {
static_assert(std::is_same<T,int>::value || std::is_same<T,double>::value,
"Only allowed for int and double");
// regular code
}
};
with std::enable_if, this is the best I can come up with
template< typename T >
struct Matrix {
template< typename T >
Matrix< typename std::enable_if<std::is_integral<T>::value, T>::type >
LoadFile()
{
return Matrix<T>();
}
};
Matrix<int> a;
Matrix<int> b = a.LoadFile<int>()
only type int compile while other don't.
Can I prevent the instantiation of the LoadFile function (which is a member function) for Matrix objects of select types?
Your best bet here would be to use a static_assert that would create a compiler error when you attempt to call the method in a version of the class instantiated with a blocked type. Using std::enable_if, and other methods that would selectively "disable" a method itself would require you to create partial or full specializations of the class with and without the methods in question in order to prevent compiler errors. For instance, AFAIK, you cannot do the following:
template <typename T>
struct test
{
static const bool value = false;
};
template<>
struct test<double>
{
static const bool value = true;
};
template<typename T>
struct example
{
void print() { cout << "Printing value from print()" << endl; }
typename enable_if<test<T>::value, T>::type another_print()
{
cout << "Printing value from another_print()" << endl;
return T();
}
};
If you attempted to instantiate an example<int>, etc., you would end up with a compiler error at the point of instantiation of the object type. You couldn't simply call example<int>::print() and be okay, and only run into a problem if you chose to call example<int>::another_print(). Specializations of example<T> could get you around the issue, but that can be a bit of a mess. As originally surmised, a static_assert would probably be the easiest case to handle, along with a nice message to the end-user explaining what went wrong.
Keep in mind that creating compiler errors is the goal, and it's a good one to have. If you blocked a method from being instantiated, and the end-user decided to invoke it, you'd end up with a compiler error either way. The version without the static_assert will leave a lot of head-scratching as the user of your class attempts to parse a probably very verbose compiler error message, where-as the static_assert method is direct and to the point.
If the selected set of types is known at compile time, and you are using c++11 with a compiler that supports type aliases, uniform initialization and constexpr (for example gcc 4.7) you can make your code a bit cleaner like this (from previous example above by yngum):
template <bool Cond, class T = void>
using enable_if_t = typename std::enable_if<Cond, T>::type;
template< typename T >
struct Matrix {
template< typename T >
//std::is_integral has constexpr operator value_type() in c++11. This will work thanks to uniform init + constexpr. With the alias, no more need for typename + ::type
Matrix<enable_if_t<std::is_integral<T>{}>>
LoadFile()
{
return Matrix<T>();
}
};
Matrix<int> a;
Matrix<int> b = a.LoadFile<int>();
Beware of compatibility of this code, though, because these features have been only recently supported and some compilers don't do yet. You can see more about c++11 compiler support here.
If you could use the TypeLists from the ( http://www.amazon.com/Modern-Design-Generic-Programming-Patterns/dp/0201704315 ) - Loki you could implement something like:
template<bool>
struct Static_Assert;
template<>
struct Static_Assert<true>{};
class B{};
template<typename T>
class A{
public:
A(){
Static_Assert< 0 == utils::HasType<T, TYPELIST_2(B,int) >::value >();
}
};
Then your HasType would be something like:
template<typename T, typename TList>
struct HasType{
enum { value = 0+HasType< T, typename TList::Tail >::value };
};
template<typename T>
struct HasType< T, NullType >{
enum { value = 0 };
};
template<typename T, typename U>
struct HasType< T, TypeList<T, U> >{
enum { value = 1 };
};
In the list you can add the classes which you would like prevent to be passed as the template parameters.

template member function specialized on pointer-to-data-member

I would like to define a nullary static template member function which would be (explicitly) specialized on pointer-to-data-member and could have, for each specialization, different return type.
It should return some detailed information about each attribute, hence I will call this method trait. The trait object type returned will be inspected by other templates, so this whole machinery must be available at compile-time.
So far I have something like this (broken code, of course):
class Foo{
// some data members
int a; std::string b; int c;
// how to declare generic template here?
// compile-time error should ensue if none of the specializations below is matched
// specialization for a (aTraitExpr is expanded from macro, so it is OK to repeat it)
template auto trait<&Foo::a>()->decltype(aTraitExpr){ return aTraitExpr; }
// specialization for b; the return type will be different than for trait<&Foo::a>
template auto trait<&Foo::b>()->decltype(bTraitExpr){ return bTraitExpr; }
};
// some code which queries the trait at compile-time
// e.g. supposing all possible trait types declare isSerializable
// which happens to be True for a and False for b
Foo* foo;
template<bool isSerializable> void doSerialization(...);
template void doSerialization<true>(...){ ... };
template void doSerialization<false>(...){ /* no-op */ };
doSerialization<Foo::trait<&Foo::a>()::isSerializable>(...); // -> doSerialization<true>(foo)
doSerialization<Foo::trait<&Foo::b>()::isSerializable>(...); // -> doSerialization<False>(...)
doSerialization<Foo::trait<&Foo::c>()::isSerializable>(...); // -> compile error, specialization Foo::trait<&Foo::c> not defined
Could get some hint on how to achieve this? (I am not trying to invent a new serialization system, I already use boost::serialization; there will be more information in each trait, this is just for an example why it is needed at compile-time).
EDIT: I was able to get something nearing what I want, it is shown at ideone.com. I gave up having trait<Foo::a>() (for now), so there is static function getTrait_a() which returns reference to modifiable type-traits, which are however partially fixed at compile-time (so that Foo::TraitType_a::flags works, for instance). Thanks to everybody who replied, unfortunately I can only pick one of the answers as "answer".
It looks like you want several overloads instead of specializations. Unfortunately you don't detail on what xTraitExpr is, but it seems it's just a type that has a member isSerializable defined. I would probably go like this
class Foo {
// your members have been omitted to save space...
template<typename T, T Foo::*M>
struct W { };
static decltype(aTraitExpr) trait(W<int, &Foo::a>) {
return aTraitExpr;
}
static decltype(bTraitExpr) trait(W<std::string, &Foo::b>) {
return bTraitExpr;
}
// other overloads for other members...
public:
// overloads for each member type
template<int Foo::*M>
static decltype(trait(W<int, M>())) trait() {
return trait(W<int, M>());
}
template<std::string Foo::*M>
static decltype(trait(W<std::string, M>())) trait() {
return trait(W<std::string, M>());
}
};
trait(W<M>()) is a dependent call. A dependent call does ADL at definition and instantiation time and unqualified lookup only at definition time. That's why W and the additional trait overloads using it must be defined before the trait type overloads instead of after them, or the result of resolution in the return type and body of the functions will be different since they are parsed at different times (bodies are late parsed after the class definition, and return types are parsed immediately).
You can either make trait a constexpr function and make xTraitExpr be a literal class with a constexpr constructor initializing isSerializable appropriately, or you could apply decltype as follows
doSerialization<decltype(Foo::trait<&Foo::a>())::isSerializable>(...);
I think it doesn't make sense to use a function template here. That being said, using a class template in its stead isn't that convenient either: you have to account for the fact that the non-static data members can have different types and there can be several non-static data members with the same type. Here's a possibility:
template<typename T>
struct is_serializable: std::false_type {};
struct Foo {
int a; std::string b; int c;
// Primary template left undefined on purpose
// alternatively, could use a static_assert on a dependent
// std::false_type::value for better diagnostics
template<typename T, T t>
struct attribute_trait;
};
// Define explicit specializations outside of class
template<>
struct Foo::attribute_trait<int Foo::*, &Foo::a>
: is_serializable<int> {};
template<>
struct Foo::attribute_trait<std::string Foo::*, &Foo::b>
: is_serializable<std::string> {};
Which is usable as
doSerialization<Foo::attribute_trait<decltype(&Foo::a), &Foo::a>::value>(/* stuff */);
The usual way to define a traits class is by wrapping a struct/class around a compile-time constant expression (and not by wrapping a function returning such an expression). The syntax to take a class member function is like this:
template
<
SomeReturnType (SomeClass::*SomeMemberFunction)(SomeParameters)
>
class SomeTrait
{
static const value = SomeCompileTimeConstantExpression;
};
In your case, you would do it like that:
template
<
void (Foo::*f)()
>
class trait
{
static const value = fTraitExpr;
};
You then specialize this trait for all member functions of class Foo:
template<>
class trait<&Foo::a>
{
static const value = aTraitExpr;
};
// same for Foo::b and Foo::c
Furthermore, it is more idiomatic to overload function templates than to specialize them:
template<int V> struct Int2Type { enum { value = V }; };
Foo* foo;
template
<
void (Foo::*f)()
>
void doSerialization(...)
{
dispatch::doSerialization(Int2Type< trait<f>::value >(), ...);
}
namespace dispatch {
doSerialization(Int2Type< true >, ...) { ... };
doSerialization(Int2Type< false >, ...) { /* no-op */ };
} // namespace dispatch
You can then call it like this:
doSerialization<&Foo::a>(...);
doSerialization<&Foo::b>(...);
doSerialization<&Foo::c>(...);

Is there an easy way to check a fundamental type

In < Modern C++ Design >,it introduces a way to check if a type fundamental type by introducing the so called type list. but what if I don't want to include so many loki code and just want a simple function to implement that? What is the simplest way to do that?
don't re-invent the wheel use boost::type_traits
http://www.boost.org/doc/libs/1_42_0/libs/type_traits/doc/html/index.html
You can use template specialization to get what you want.
// General template
template<typename T>
struct IsFundamentalType { enum { result = false }; };
// Template specializations for each fundamental type
template<>
struct IsFundamentalType<char> { enum { result = true }; };
template<>
struct IsFundamentalType<int> { enum { result = true }; };
template<>
struct IsFundamentalType<short> { enum { result = true }; };
template<>
struct IsFundamentalType<float> { enum { result = true }; };
// And so on for other fundamental types ...
class NonFundamentalType
{
};
template<typename T>
void DoSomething(const T& var)
{
if(IsFundamentalType<T>::result)
{
printf("I'm fundamental type!\n");
}
else
{
printf("I'm not a fundamental type!\n");
}
}
int main()
{
int i = 42;
char c = 42;
short s = 42;
float f = 42.0f;
NonFundamentalType nft;
DoSomething(i);
DoSomething(c);
DoSomething(s);
DoSomething(f);
DoSomething(nft);
}
In this code, if you pass in a type such as int or char, the compiler will use the specialization of IsFundamentalType (given that you've defined the specializations for all fundamental types). Otherwise, the compiler will use the general template, as it is the case for the NonFundamentalType class. The important thing is that the specialized ones have a result member defined as true, while the general template also has a result member defined as false. You can then use the result member for the if statement. Optimizing compilers should be able to elide the if statement seeing that the expression reduces to a constant true/false value, so doing something like this should not impose a runtime penalty.
The simplest way is to create a type-traits object. Basically, you create an object (let's call it is_fundamental<T>) that is parameterized by the type and that inherits from boost::type_traits::no_type by default; then you specialize the object on all the fundamental types, making that specialization inherit from boost::type_traits::yes_type. So then you can use is_fundamental<T>::value as a boolean which will tell you if the type T is or is not a fundamental type. In most cases, you really don't need to know if a type is or is not fundamental, and when you do, it almost always involves templates, anyway, so might as well do it that way.
I should also point out that Boost already defines boost::type_traits::is_fundamental which does what you want. You can see in is_fundamental.hpp that they define it in terms of their other type-traits objects; a type is fundamental if it is a builtin arithmetic type or if it is the type "void" (which is also considered to be fundamental). Trying to figure things out from Boost can be kind of confusing but a simplification is:
template<typename T, T VAL> struct constant_value
{
static const T value = VAL;
};
typedef constant_value<bool,true> yes_type;
typedef constant_value<bool,false> no_type;
template<typename T> struct is_fundamental : public no_type{};
// Create a macro for convenience
#define DECLARE_FUNDAMENTAL(X) \
template<> struct is_fundamental<X> : public yes_type{}
// Specialize for all fundamental types
DECLARE_FUNDAMENTAL(void);
DECLARE_FUNDAMENTAL(bool);
DECLARE_FUNDAMENTAL(signed char);
DECLARE_FUNDAMENTAL(unsigned char);
// ... lots more similar specializations ...
DECLARE_FUNDAMENTAL(wchar_t);
DECLARE_FUNDAMENTAL(float);
DECLARE_FUNDAMENTAL(double);
DECLARE_FUNDAMENTAL(long double);
// Prevent this macro from polluting everything else...
#undef DECLARE_FUNDAMENTAL
That is essentially what it takes to create such a type-traits object. Note that one can maliciously specialize the type-trait to be true for a non-fundamental type, although that is the case for most things, anyway.
You can then use the above to create a more function-looking thing. For example, using the boost::type_traits::is_fundamental class, you could create the following:
template<typename T>
bool isFundametal(const T&)
{
return boost::type_traits::is_fundamental<T>::value;
}
Because the template specialization can be deduced from the parameters, you can invoke this isFundamental function without explicitly specifying the type. For example, if you write isFundamental(5) it will implicitly invoke isFundamental<int>(5), which will return true. Note, though, that if you create such a function, it won't allow you to test for void. You could create a function that took no parameters for such a case, but then the type wouldn't be deduced, and so it would be no prettier than simply using boost::type_traits::is_fundamenta<T>::value, and so one might as well just use it in that case.