rvalue References and Template parameters - c++

Why is this syntax not allowed:
template<float&& value>
struct MyStruct{
float GetValue() { return value; }
};
MyStruct<12.1f> myFloat;
And we have to instead do this:
template<const float& value>
struct MyStruct{
float GetValue() { return value; }
};
extern constexpr float param = 12.1f;
MyStruct<param> myFloat;
I don't see any reason why the first should be forbidden.
The first syntax is far less clunky and the second syntax just makes it seem like the creators of c++ are just trying to make things difficult....So why is it like this?

Because template processing is hugely complicated, I assume that the designers rightly rejected features that could be easily done using other means. Template parameters exist to customize the behavior of the code, not merely to insert constants. That's why int template parameters are supported, so you can do things like:
template <int SIZE> struct X {
char buffer[SIZE];
};
If you just want a constant in your instance of the class, add it to the constructor:
class X {
public:
X(float value_) {
value = value_;
}
float value;
};
If you really want a customized class that uses that constant, how about:
class X71 : public X {
public:
X71() : X(7.1f) {}
};

Related

Why can't I check for a constraints on a type using requires?

I'm trying to understand how to use Concepts to do interface checks on a type (duck typing?), and produce the most readable code. I have the following concept:
template <typename T>
concept Shape = requires(const T& t)
{
{ t.area() } -> std::convertible_to<float>;
};
And then use it as follows
template <typename T>
struct shape_checker_check_in_ctor
{
shape_checker_check_in_ctor()
{static_assert(Shape<T>);}
};
struct Circle : shape_checker_check_in_ctor<Circle>
{
float r;
float area() const
{return 22*r*r/7;}
};
Which works fine, but I think having the static_assert in the constructor of the constraint checker makes its role a tad less obvious. What I'd like instead is the following, which involves less boilerplate:
template <typename T> requires Shape<T>
struct shape_checker_with_constraint
{};
And then
struct Square : shape_checker_with_constraint<Square>
{
double side;
float area() const
{return side*side;}
};
But it doesn't work. Full code here: https://godbolt.org/z/GzEq54P8Y
Can anyone figure out why please?
CRTP is amazing, but doesn't solve every problem. CRTP is not the right tool here.
The test you need to do has to happen after the type is fully defined.
You have hacked it by putting a static assert in the constructor.
Here I simply put the static assert right after the class definition, when it is complete.
struct Circle
{
float r;
float area() const
{return 22*r*r/7;}
};
static_assert( Shape<Circle> );
struct Square
{
double side;
float area() const
{return side*side;}
};
static_assert( Shape<Square> );
now in a future version of C++, we expect to get reflection and eventually (maybe) metaclasses.
With metaclasses, you'd be able to do something like
class(Shape) Circle {
float r;
float area() const
{return 22*r*r/7;}
};
and the metaclass Shape would perform checks and manipulation of the struct. This proposal is in its early steps and won't show up until after we have reflection (which was delayed from c++23 by the pandemic).

C++ Runtime variable in templates

template <int ns, int id>
class Bar
{
public:
static int value;
};
template <int ns, int id>
int Bar<ns, id>::value = 0;
class Foo
{
public:
template <int ns, int id>
static int GetNextValue()
{
++Bar<ns, id>::value;
return Bar<ns, id>::value;
}
};
class Baz
{
public:
Baz(int value)
: value(value)
{
}
void PrintBaz();
private:
int value;
};
This works fine when called like:
Baz baz(Foo::GetNextValue<1, 1>());
I need this code to support the following.
int ns = 1;
int id = 5;
Baz baz(Foo::GetNextValue<ns, id>());
Compilation for this code fails understandably. Is there a way to have template meta-programming support runtime variable values?
Pointer to solution for this problem by any other method will also be helpful.
The simple answer is no, templates are a compile time construct. You might want to consider constexpr functions if you need code that can be evaluated at compile time or runtime.
A template meta programm "runs" during compilation. So every input into it must be known at compile time.
Think of this:
template<int N>
int get(void) {
return N;
}
This creates a completely new function on each instantiation with a different value for N. So if the passed value of some instantiation isn't known at compile time, this would mean that the new function had to be generated during runtime. For this to work you'd need the compiler to be part of your final application. It might seem simple in this case, but there are pretty complex meta programms out there.
Moreover, even the syntax of C++ depends on the results of some meta programms:
template<bool = true>
struct switch {
template<int>
using thing = int;
};
template<>
struct switch<false> {
int thing = 21;
}
switch<META>::thing<42>(21);
// bool result of comparisons: 21 < 42 > 21
// or int result from cast: 21

Recursive template definition

I have a recursive template definition (I just made up that term). I think code explains it better.
template<typename X>
class Domain
{
public:
X begin;
X end;
Domain(
X _begin,
X _end)
: begin(_begin)
, end(_end)
{
// ...
}
bool Contains(
const X& t) const
{
// ...
}
};
template<typename X, typename Y>
class IFunction
{
public:
Domain<X> myDomain;
public:
IFunction(
const Domain<X>& dom)
: myDomain(dom)
{
}
virtual Y
Calc(
const X& IV) const = 0;
virtual IFunction<X, Y>*
GetDerivative() const = 0;
};
template<typename X, typename Y, int n>
class NthOrderFunction
: public IFunction<X, Y>
{
public:
double coeffs[n+1];
public:
NthOrderFunction(
const Domain<X>& dom,
... )
: IFunction(dom)
{
}
virtual Y
Calc(
const X& IV) const
{
// temporary compile solution
return Y();
}
virtual IFunction<X, Y>*
GetDerivative() const
{
if ( n > 1 )
{
return new NthOrderFunction<X, Y, n-1>(dom, ...);
}
return new FlatLine<X, Y>(dom);
}
};
I took out a lot of inheritance and other relations to keep it readable, simple and mysterious. So a new typo might have snuck in while editing the code, but please ignore it. The code has worked fine for years, the only problem I have is the one I'm going to point out.
I recently added a "GetDerivative" function, and it's implementation in the NthOrderFunction class is giving me problems. I know that template classes are defined before compilation but after the preprocessing. As such, I can't see how to bring this functionality ever to work. Every NthOrderFunction with template parameter n, requires a NthOrderFunction with template parameter n-1. You can see that this is a problem. The thing is, even though n will never be negative in use, no amount of coding I do, will convince the "template definition engine" to not bother with instances of n < 1;
has anyone ever had any problems with this? And what solutions did you come up with?
This is the same as the template metaprogramming 101 example- factorial, just the content is somewhat more complex.
template<int N> struct factorial { enum { value = N * factorial<N-1>::value }; };
And you need the same solution- a specialization for the base case.
template<> struct factorial<1> { enum { value = 1 }; };
Yours would be partial rather than full, but it would still work.
Add something like:
template<typename X, typename Y>
class NthOrderFunction<X, Y, 1>
: public IFunction<X, Y>
{
public:
double coeffs[n+1];
public:
NthOrderFunction(
const Domain<X>& dom,
... )
: IFunction(dom)
{
}
virtual Y
Calc(
const X& IV) const
{
// temporary compile solution
return Y();
}
virtual IFunction<X, Y>*
GetDerivative() const
{
return new FlatLine<X, Y>(dom);
}
};
and remove the n==1 case from your recursion case.
As an advice, get some book or tutorial or such on template metaprogramming. One of the base techniques is using recursion in templates in this fashion. This strictly speaking isn't metaprogramming yet, it's just recursive templates. The book/tutorial will explain how more advanced tricks work which you can use to your benefit when expanding on this.
The reason this works is that the original would still expand the compile-time "if" to runtime code (that would just never be executed). This code replaces the one case where it could be compiled out with one where it isn't present, so there's no option for infinite recursion.

How not to compile casting into enum type in C++?

I have this "better" enum class that
cannot contain invalid values, and
cannot be used until enum value is not set explicitly,
as follows:
class Symmetry
{
public:
enum Type {
GENERAL, SYMMETRIC, HERMITIAN,
SKEW_SYMMETRIC, SKEW_HERMITIAN, UNINITIALIZED
};
Symmetry() { t_ = UNINITIALIZED }
explicit Symmetry(Type t) : t_(t) { checkArg(t); }
Symmetry& operator=(Type t) { checkArg(t); t_ = t; return *this; }
operator Type() const {
if (t_ == UNINITIALIZED) throw runtime_error("error");
return t_;
}
private:
Type t_;
void checkArg(Type t) {
if ((unsigned)t >= (unsigned)UNINITIALIZED)
throw runtime_error("error");
}
};
This allows me to write the following code:
Symmetry s1(Symmetry::SYMMETRIC);
Symmetry s2;
s2 = Symmetry::HERMITIAN;
Symmetry s3;
if (Symmetry::GENERAL == s3) // throws
My problem is that a compiler allows constructs such as:
Symmetry s1((Symmetry::Type)18); // throws
Symmetry s2;
s2 = (Symmetry::Type)18; // throws
I solved this problem by throwing exceptions, but I would prefer such a code not to compile at all (a compile time error). Is there a way how to manage this?
Potentially a crummy solution, but it would solve your immediate problem. Rather than having an inner enum type, define a little helper class with a private constructor, and make the outer class a friend. Then the "enum" values can be static const members in your outer class. Something like this:
(DISCLAIMER: untested, so there may be various compilation issues, but you should get the idea)
class Symmetry
{
public:
class Type
{
private:
Type() {};
friend class Symmetry;
};
static const Type GENERAL;
static const Type SYMMETRIC;
static const Type HERMITIAN;
};
You will need some way of determining equality, but this should be fairly easy.
My attempt using templates: (tested. However, this can be further improved!)
template<int N>
struct Symmetry
{
enum Type
{
GENERAL, SYMMETRIC, HERMITIAN,
SKEW_SYMMETRIC, SKEW_HERMITIAN
};
template<Type e> struct allowed;
template<> struct allowed<GENERAL> { static const int value = GENERAL; };
template<> struct allowed<SYMMETRIC> { static const int value = SYMMETRIC; };
template<> struct allowed<HERMITIAN> { static const int value = HERMITIAN; };
template<> struct allowed<SKEW_SYMMETRIC> { static const int value = SKEW_SYMMETRIC; };
template<> struct allowed<SKEW_HERMITIAN> { static const int value = SKEW_HERMITIAN; };
allowed<(Type)N> m_allowed;
operator int()
{
return N;
}
};
Symmetry<0> e0; //okay
Symmetry<1> e1; //okay
Symmetry<100> e4; //compilation error!
Symmetry<e0.SKEW_HERMITIAN> e3; //okay
Symmetry<e0.SKEW_SYMMETRIC> e3; //okay
Usage:
int main()
{
Symmetry<0> e0;
Symmetry<e0.HERMITIAN> e1;
switch (e1)
{
case e0.HERMITIAN:
{
cout << "It's working" << endl;
}
break;
}
}
No. If you allow any cast to be used, as your last example does, then there will always be some cast that can be used to subvert your type.
The solution is to not be in the habit of using these casts and to very suspiciously consider any code that uses these casts indiscriminately. View this type of casting as the nuclear bomb in your arsenal: it's important to have, but you always handle it with care and never want to deploy it more than rarely.
What warning options does your compiler have for casting? What lint tools are you using which may detect this misuse of casts?
That said, it appears you really want to hide the inner Type so users are less tempted to even use it. Realizing that, it's straight-forward to make that type name private, even while not preventing all cast misuse, by slightly tweaking your original:
struct Symmetry {
enum {
UNINITIALIZED,
GENERAL, SYMMETRIC, HERMITIAN,
SKEW_SYMMETRIC, SKEW_HERMITIAN
};
private:
typedef decltype(UNINITIALIZED) Hidden;
Hidden _value;
public:
Symmetry(Hidden value = UNINITIALIZED) : _value (value) {}
Symmetry& operator=(Hidden value) { _value = value; return *this; }
operator Hidden() const {
if (_value == UNINITIALIZED) {
throw std::logic_error("uninitialized Symmetry");
}
return _value;
}
bool initialized() const { return _value != UNINITIALIZED; }
// required if you want to check for UNINITIALIZED without throwing in
// the above conversion
};
This is a complete implementation, no details omitted or unknown, or issues with initialization order. The only caveat is decltype – with a pre-C++0x compiler, you'll have to use something implementation-specific or a library which wraps something implementation-specific.
And a smaller issue: change from runtime_error to logic_error, as using uninitialized values should be preventable beforehand and thus falls in the latter category.

C++ creating variations of classes with different combinations of fields

templates allow in c++ to automatically create a lot of classes with the same interface, but different data stored.
i'm looking for something similar (i don't know whether it exists, that's why I ask here) that automatically creates for me variations of an object storing only a subset of the datamembers.
let's say i have a
class FullClass
{
public:
bool A;
int B;
float C;
double D;
};
then i would like to have all possible combinations of those fields like for example:
class BDClass
{
public:
int B;
double D;
};
or
class BCDClass
{
public:
int B;
float C;
double D;
};
and i want to be able to cast from any of the variation classes to FullClass such that the defined fields will be copied, and the missing fields are set to defaultvalues:
FullClass foo;
BDClass bar = BDClass(3, 5.0);
foo = (FullClass) bar;
Is there any mechanism that let's the compiler create those variations for me, or do I have to define all possible combinations myself?
thanks!
edit:
why am I looking for this?
I have a software construct that follows the strategy pattern. thus, i have a bunch of different algorithms (more than 30) using the same interface. the client shall be able to use this interface without knowing what exact algorithm currently is running behind. the client calculates such a 'FullClass' object and passes it through the interface - however, each algorithm uses only a subset of the fields provided in this object (and each algorithm uses different ones).
This strategy-pattern construct is fixed and i cannot change it.
Now i want to 'record' the sequence of such generated 'FullClass' objects, such that the complete flow of the usage of this construct can be repeated without having to recalculate those 'FullClass' objects. However, this is a lot of data (which i'd like to keep in mainmemory for performance reasons) and since most of the algorithms only use a small subset of the fields, i only want to store the fields which are effectively used
I cannot even imagine why do you need this, but you can try use mixins:
class Dummy
{
};
<template Base>
class AClass : public Base
{
public:
bool A;
};
<template Base>
class BClass : public Base
{
public:
int B;
};
... //( etc)
BClass< AClass<Dummy>> abClass;
abClass.B = 4;
abClass.A = false;
And if you will keep going you will be able to do:
DClass< CCLass< BClass< AClass<Dummy>>>> abcdClass;
I might be wrong or it might be an non-efficient solution to your problem, but maybe using tuple will solve it : http://www.boost.org/doc/libs/1_41_0/libs/tuple/doc/tuple_users_guide.html
That said, you should explain the problem you're trying to solve, as Neil said. Why would you need this.
First, you can define four classes for each data type, then declare templae class for type pairs, then for three-type combinations, then for four ones. You can't get it any simpler than that.
I think you could do something using the private class data pattern, and then some terrible memcopy tricks:
class Full
{
private:
struct fullData
{
a;
b;
c;
d;
e;
...
z;
} * m_pData;
public:
Stuff!
}
class Partial
{
private:
struct partialData
{
a;
b;
c_filler; //This is an issue
d;
}
public:
Different Stuff!;
}
Then, when you copy, just literally copy the memory of partialData into fullData, filling the rest of fullData with zeros.
The issues are that this only works with datatypes that don't need you to use their constructors (so, there's no safety checks in here), and you have to put in padding (as above) to make sure your data lines up properly.
But your copy-constructor gets to be a memcopy then a memfill;
(note, I almost certainly have the memcopy and fill syntax wrong)
template<class T>
Full(T& t)
{
m_pData = new fullData;
memcopy(/*to*/m_pData, /*from*/Partial->getData(), /*how much to copy*/ sizeof(T));
memfill(/*tp*/m_pData, /*how much to copy*/ sizeof(fullData) - sizeof(T), /*with*/ 0);
}
May work for your particular situation, but it's not particularly safe or pretty.
Have you considered just writing a preprocessor to codegen what you need?
I personally really appreciate Boost.Fusion ;)
Here, I would use boost::fusion::map since it allows to mix types quite easily.
You need to use a combination of tags types (types only used for compilation purpose) and of real types, used to store data.
Let's define our tags:
class a_tag { typedef bool type; };
class b_tag { typedef int type; };
class c_tag { typedef float type; };
class d_tag { typedef double type; };
Then you can write a macro using Boost.Preprocessor which takes the list of tags and generates the appropriate boost::fusion::map
GENERATE_MY_TYPE(TypeName, (a_tag)(b_tag)(c_tag)(d_tag));
// For information: (a_tag)(b_tag)(c_tag)(d_tag) is called a sequence in PP
The type shall be something like:
typedef boost::fusion::map<
std::pair<a_tag, a_tag::type>,
std::pair<b_tag, b_tag::type>,
std::pair<c_tag, c_tag::type>,
std::pair<d_tag, d_tag::type>
> TypeName;
Or more likely a wrapper using the boost::fusion::map as an implementation detail, say:
// defined once
template <class Vector>
struct TemplateType
{
typedef Vector tags_type;
typedef detail::deduce<Vector>::type data_type
// which for Vector = boost::mpl::vector<a_tag, b_tag, c_tag, d_tag> should be
// typedef boost::fusion::map<
// std::pair<a_tag, a_tag::type>,
// std::pair<b_tag, b_tag::type>,
// std::pair<c_tag, c_tag::type>,
// std::pair<d_tag, d_tag::type>
// > data_type;
data_type m_data;
template <class T>
boost::fusion::result_of::at<T, data_type> at()
{
return boost::fusion::at<T>(m_data);
}
};
// Generated by the macro, filling boost::mpl::vector by iteration
// the sequence
typedef TemplateType< boost::mpl::vector<a_tag, b_tag, c_tag, d_tag> > TypeName;
And then you only need the type defined to provide a conversion trick from a subset of tags. This might be defined only once if you need only have the full subset.
template <class Vector>
TypeName toTypeName(TemplateType<Vector> const& arg)
{
TypeName result;
result.fill(arg);
return result;
}
With fill being defined as:
namespace detail
{
class NoAssign
{
template <class Pair, class TT> static Do(Pair const&, TTconst&) { }
};
class Assign
{
template <class Pair, class TT>
static Do(Pair& p, TTconst& tt)
{
p.second = tt.at<typename Pair::first_type>();
};
};
template <class Vector>
class Filler
{
public:
Filler(TemplateType<Vector> const& ref): m_ref(ref) {}
template <class T, class U>
void operator()(std::pair<T,U>& p) const
{
typedef typename boost::mpl::find<T,Vector>::type it;
typedef typename boost::mpl::end<Vector>::type end;
typedef typename boost::mpl::if< boost::same_type<it,end>, NoAssign, Assign> assign;
assign::Do(p, m_ref);
}
private:
TemplateType<Vector> const& m_ref;
};
}
template <class Vector>
template <class OV>
void TemplateType<Vector>::fill<OV>(TemplateType<OV> const& rhs)
{
boost::fusion::for_each(m_data, detail::Filler<OV>(rhs));
}
I love those problems, but of course being forced to use both Meta Template Progamming AND Preprocessing to generate some template classes / methods... means some lengthy solutions and some headaches. Once done however the syntax can be really neat (for the user).