I want to declare member variables in a class template if some condition from template parameters is true. I could use nested class as container, but it is impossible to do explicite specializations in that case.
I'm trying someting like this:
enum class VarPolice { Declare, DontDeclare };
template<VarPolice vp = VarPolice::Declare>
class MyClass
{
struct EmptyStruct {};
struct VarSaverStruct { int MyVar; };
using VarSaver = typename std::conditional<vp == VarPolice::Declare, VarSaverStruct, EmptyStruct>::type;
VarSaver saver;
}
So, I can use MyVar as saver.MyVar
Is there any way to do optional variable declaration without using EmptyStruct that has a size overhead?
C++17 can be used.
Yes, you can have your cake and eat it too. Just inherit from correct type instead, and rely on the empty base optimization.
enum class VarPolice { Declare, DontDeclare };
struct EmptyStruct {};
struct VarSaverStruct { int MyVar; };
template<VarPolice vp = VarPolice::Declare>
class MyClass : std::conditional_t<vp == VarPolice::Declare,
VarSaverStruct, EmptyStruct>
{
};
Standard library implementations rely on it themselves to "store" allocators without taking up space if they are stateless.
Related
Consider
template<class Base> struct ChildT : Base
{
};
struct NoBase{};
typedef ChildT<NoBase> Child;
Is there a way of writing this typedef so you don't need to define NoBase? I'm thinking of something like the following:
typedef ChildT<class {}> Child;
There's std::monostate, which is defined just like your NoBase.
As you can see from the link it is not been thought for your use case, but essentially it can. After all, it's just a unit type.
I'm not sure whether std::monostate is the only empty struct in the STL. Nothing comes to mind, except std::nullptr_t, which however is not defined as struct nullptr_t {} but as decltype(nullptr), so it is not an alternative to std::monostate.
I would do it like this :
namespace details
{
struct none
{
};
}
template<typename Base = details::none>
struct ChildT :
public Base // be sure to use the correct inheritance, private is default
{
void do_something() {}
};
using Child = ChildT<>;
int main()
{
Child c;
c.do_something();
}
Note : after reading the other answers std::monostate does the same as details::none :)
Is it possible to do something like:
template <unsigned majorVer, unsigned minorVer>
class Object
{
public:
if constexpr ((majorVer == 1) && (minorVer > 10))
bool newField;
else
int newInt
};
or
template <unsigned majorVer, unsigned minorVer>
class Object
{
public:
if constexpr ((majorVer == 1) && (minorVer > 10))
bool newField;
// Nothing other wise
};
using c++17?
I would like to change the structure of a class based on some condition that can be checked at compile time. Is there any way to achieve this?
You can't use if constexpr for this. You would have to collapse them into one member using something like std::conditional:
std::conditional_t<(majorVer == 1) && (minorVer > 10), bool, int> newField;
Alternatively, you can wrap each of the two kinds of the fields in their own type:
struct A { bool newField; };
struct B { int newInt; };
And either inherit from std::conditional_t<???, A, B> or have one of those as a member.
For the case where you want either a member or nothing, the other case just needs to be an empty type. In C++20, that's:
struct E { };
[[no_unique_address]] std::conditional_t<some_condition(), bool, E> newField;
In C++17 and earlier, you'll want to inherit from this to ensure that the empty base optimization kicks in:
struct B { bool field; };
struct E { };
template <unsigned majorVer, unsigned minorVer>
class Object : private std::conditional_t<some_condition(), B, E>
{ ... };
if-constexpr is about control flow, not about memory layout. Maybe the reflection TS could be a good fit for this. However, untill that is available, you'll need other techniques.
constexpr bool useLegacyInt(unsigned major, unsigned minor)
{
return (majorVer <= 1) && (minorVer <= 10));
}
template<bool>
class ObjectBase
{
book newField;
};
template<>
class ObjectBase<true>
{
int newInt;
};
template <unsigned majorVer, unsigned minorVer>
class Object : public ObjectBase<useLegacyInt (majorVer, minorVer)>
{};
Based on this, you could do some refinements. You don't only influence the members, also the methods. So also setters and getters ... could have a different signature. Protected helper functions could provide a bool API to Object to separate the implementation.
Finally, I would not recommend using a bool, I rather expect an enumeration as this can have multiple values.
Inheriting from an earlier version could also be possible if a new version only extends. And with some default template arguments, you can even do more fancy things.
Be warned, this kind of backwards compatibility could become complex really quickly. Sometimes it's better to just copy the complete code in a legacy version and keep it as is, without interference of the new API. This at the cost of duplicated code.
Something like:
template<bool HOLD_MANUFACTURER>
class Computer {
int memory;
int storage;
#if HOLD_MANUFACTURER
char *manufacturer;
#endif
};
I need this to create two variations of the almost-same class, when one variation is a lighter one for performance reasons. I don't want to use a separate class that will wrap the lighter one.
If yes, is it possible to any type (not just bool from the sample code above)? Maybe primitive types only? What about enums?
This code don't work for me, but I hope that I've just missed some little thing.
You can creatively use the empty base optimization in a policy approach to achieve almost what you want:
struct NO_MANUFACTURER {};
struct HOLD_MANUFACTURER { char *manufacturer; };
template <typename ManufacturerPolicy>
class Computer : public ManufacturerPolicy
{
int memory;
int storage;
}
Then instantiate as Computer<HOLD_MANUFACTURER> computer_with_manufacturer;
Not possible, but you can use template specialization and inheritance:
template <bool HoldManufacturer>
class ComputerAdditions
{};
template <>
class ComputerAdditions<true>
{
protected:
char *manufacturer;
public:
// Methods using this additional member
};
template <bool HoldManufacturer = false>
class Computer
: public ComputerAdditions<HoldManufacturer>
{
int memory;
int storage;
public:
// Methods of Computer
}
This question is somewhat a continuation of this one I've posted.
What I was trying to do: my point was to allow access to private members of a base class A in a derived class B, with the following restraints:
what I want to access is a structure -- an std::map<>, actually --, not a method;
I cannot modified the base class;
base class A has no templated method I may overload as a backdoor alternative -- and I would not add such method, as it would be going against the second restraint.
As a possible solution, I have been pointed to litb's solution (post / blog), but, for the life of me, I haven't been able to reach an understanding on what is done in these posts, and, therefore, I could not derive a solution to my problem.
What I am trying to do: The following code, from litb's solution, presents an approach on how to access private members from a class/struct, and it happens to cover the restrictions I've mentioned.
So, I'm trying to rearrange this one code:
template<typename Tag, typename Tag::type M>
struct Rob {
friend typename Tag::type get(Tag) {
return M;
}
};
// use
struct A {
A(int a):a(a) { }
private:
int a;
};
// tag used to access A::a
struct A_f {
typedef int A::*type;
friend type get(A_f);
};
template struct Rob<A_f, &A::a>;
int main() {
A a(42);
std::cout << "proof: " << a.*get(A_f()) << std::endl;
}
To something that would allow me to do the following -- note I'm about to inherit the class, as the entries in the std::map<> are added right after the initialization of the derived class B, i.e., the std::map<> isn't simply a static member of class A with a default value, so I need to access it from a particular instance of B:
// NOT MY CODE -- library <a.h>
class A {
private:
std::map<int, int> A_map;
};
// MY CODE -- module "b.h"
# include <a.h>
class B : private A {
public:
inline void uncover() {
for (auto it(A_map.begin()); it != A_map.end(); ++it) {
std::cout << it->first << " - " << it->second << std::endl;
}
}
};
What I'd like as an answer: I'd really love to have the above code working -- after the appropriate modifications --, but I'd be very content with an explanation on what is done in the first code block -- the one from litb's solution.
The blog post and its code is unfortunately a bit unclear. The concept is simple: an explicit template instantiation gets a free backstage pass to any class, because
An explicit instantiation of a library class may be an implementation detail of a client class, and
Explicit instantiations may only be declared at namespace scope.
The natural way to distribute this backstage pass is as a pointer to member. If you have a pointer to a given class member, you can access it in any object of that class regardless of the access qualification. Fortunately, pointer-to-members can be compile-time constants even in C++03.
So, we want a class which generates a pointer to member when it's explicitly instantiated.
Explicit instantiation is just a way of defining a class. How can merely generating a class do something? There are two alternatives:
Define a friend function, which is not a member of the class. This is what litb does.
Define a static data member, which gets initialized at startup. This is my style.
I'll present my style first, then discuss its shortcoming, and then modify it to match litb's mechanism. The end result is still simpler than the code from the blog.
Simple version.
The class takes three template arguments: the type of the restricted member, its actual name, and a reference to a global variable to receive a pointer to it. The class schedules a static object to be initialized, whose constructor initializes the global.
template< typename type, type value, type & receiver >
class access_bypass {
static struct mover {
mover()
{ receiver = value; }
} m;
};
template< typename type, type value, type & receiver >
typename access_bypass< type, value, receiver >::mover
access_bypass< type, value, receiver >::m;
Usage:
type_of_private_member target::* backstage_pass;
template class access_bypass <
type_of_private_member target::*,
& target::member_name,
backstage_pass
>;
target t;
t.* backstage_pass = blah;
See it work.
Unfortunately, you can't rely on results from this being available for global-object constructors in other source files before the program enters main, because there's no standard way to tell the compiler which order to initialize files in. But globals are initialized in the order they're declared, so you can just put your bypasses at the top and you'll be fine as long as static object constructors don't make function calls into other files.
Robust version.
This borrows an element from litb's code by adding a tag structure and a friend function, but it's a minor modification and I think it remains pretty clear, not terribly worse than the above.
template< typename type, type value, typename tag >
class access_bypass {
friend type get( tag )
{ return value; }
};
Usage:
struct backstage_pass {}; // now this is a dummy structure, not an object!
type_of_private_member target::* get( backstage_pass ); // declare fn to call
// Explicitly instantiating the class generates the fn declared above.
template class access_bypass <
type_of_private_member target::*,
& target::member_name,
backstage_pass
>;
target t;
t.* get( backstage_pass() ) = blah;
See it work.
The main difference between this robust version and litb's blog post is that I've collected all the parameters into one place and made the tag structure empty. It's just a cleaner interface to the same mechanism. But you do have to declare the get function, which the blog code does automatically.
OK, so you asked about how to make that weird "Rob" code work with your use case, so here it is.
// the magic robber
template<typename Tag, typename Tag::type M>
struct Rob {
friend typename Tag::type get(Tag) {
return M;
}
};
// the class you can't modify
class A {
private:
std::map<int, int> A_map;
};
struct A_f {
typedef std::map<int, int> A::*type;
friend type get(A_f);
};
template struct Rob<A_f, &A::A_map>;
class B : private A {
public:
inline void uncover() {
std::map<int, int>::iterator it = (this->*get(A_f())).begin();
}
};
Now, I personally think the cure here may be worse than the disease, despite that I'm usually the last one you'll see claiming that abusing C++ is OK. You can decide for yourself, so I've posted this as a separate answer from my one using the preprocessor to do it the old-school way.
Edit:
How It Works
Here I will replicate the code above, but with the types simplified and the code drawn out more, with copious comments. Mind you, I did not understand the code very well before I went through this exercise, I don't understand it completely now, and I certainly won't remember how it works tomorrow. Caveat maintainer.
Here's the code we aren't allowed to change, with the private member:
// we can use any type of value, but int is simple
typedef int value_type;
// this structure holds value securely. we think.
struct FortKnox {
FortKnox() : value(0) {}
private:
value_type value;
};
Now for the heist:
// define a type which is a pointer to the member we want to steal
typedef value_type FortKnox::* stolen_mem_ptr;
// this guy is sort of dumb, but he knows a backdoor in the standard
template<typename AccompliceTag, stolen_mem_ptr MemPtr>
struct Robber {
friend stolen_mem_ptr steal(AccompliceTag) {
return MemPtr; // the only reason we exist: to expose the goods
}
};
// this guy doesn't know how to get the value, but he has a friend who does
struct Accomplice {
friend stolen_mem_ptr steal(Accomplice);
};
// explicit instantiation ignores private access specifier on value
// we cannot create an object of this type, because the value is inaccessible
// but we can, thanks to the C++ standard, use this value in this specific way
template struct Robber<Accomplice, &FortKnox::value>;
// here we create something based on secure principles, but which is not secure
class FortKnoxFacade : private FortKnox {
public:
value_type get_value() const {
// prepare to steal the value
// this theft can only be perpetrated by using an accomplice
stolen_mem_ptr accessor = steal(Accomplice()); // it's over now
// dereference the pointer-to-member, using this as the target
return this->*accessor;
}
};
int main() {
FortKnoxFacade fort;
return fort.get_value();
}
How about something more brutal?
// MY CODE -- module "b.h"
# define private protected
# include <a.h>
# undef private
class B : private A {
// now you can access "private" members and methods in A
The best-packaged version I know of this idiom is as follows:
template<class Tag,typename Tag::type MemberPtr>
struct access_cast{
friend typename Tag::type get(Tag){return MemberPtr;};
};
template<class Tag,class MemberPtr>
struct access_tag{
typedef MemberPtr type;
friend type get(Tag);
};
class A {
public:
auto x() const {return x_;};
private:
int x_ = 9;
};
#include <iostream>
struct AMemTag: access_tag<AMemTag,int A::*>{}; //declare tag
template struct access_cast<AMemTag,&A::x_>; //define friend get function
int main() {
A a;
std::cout<<a.x()<<"\n";
a.*get(AMemTag()) = 4; //dereference returned member pointer and modify value
std::cout<<a.x()<<"\n";
}
See it work.
I'm currently writing a class which allows getting and setting interal program options and it should be quite flexible and easy to use.
Specifically, an option is identified by an enum type and a value type, which have a one-on-one relationship. For example, an enum IntType will contains options which have an int type.
I had in mind the following code, but have no idea how to get it working or whether I'm trying to use templates in a way i shouldn't.
enum IntType {OPTION1, OPTION2}
enum StringType { OPTION3, OPTION4}
template<class T, class T2>
class Policy{
public:
T2 getValue(const T& a);
void setValue(const std::string& name, const T2& a);
...
}
class A: public Policy<IntType, int>, public Policy<Stringtype, std::string>, ...{
...
}
Each enum constant has one associated string representation, which is constant, but options are also taken as string input into the program, so I have to be able to deduce from a string which option I should change.
But obviously, this code cannot be used to directly call set or get values without qualifying its full template specialization. So
A* a = ...
a->setValue("intoption", 5);
will not work.
Any pointers on what I should use to get this working?
A partial answer on how to derive at compile time that OPTION1 maps to int and IntType, ... would also be great.
Thanks in advance,
Broes
It is not necessary to pass both the Enum and the type. You can deduce the enum value from the type itself thanks to a traits class:
template <typename T>
struct PolicyTraits;
template <>
struct PolicyTraits<int> { static Enum const value = IntType; }
// ... and so on ...
Your selection is obviously a bit more difficult. For templates to work correctly you need selection based on compile constants, be they constants or types. This requires the names of your options to be constants.
A revised implementation would thus be:
template<class Name, class Type>
class Policy{
public:
Type getValue(Name);
void setValue(Name, Type const&);
...
}
This can be used as:
struct IntOption {};
class A: public Policy<IntOption, int> {};
int main() {
A a;
a.setValue(IntOption(), 3);
}
Also, you might be interested in looking up How Boost does it and perhaps use their library.
Since you are filling the data at runtime, templates are not viable for this design. Runtime polymorphism with virtual function will be a good choice. For example,
class Options; // Say this is the class of interest
class DataType {
public:
virtual Options& getOptions () = 0;
};
class IntType : public DataType {
public:
Options& getOptions (); // implement for 'int' type
};
class StringType : public DataType {
public:
Options& getOptions (); // implement for 'std::string' type
};
Now, class A should contain a pointer to DataType;
class A {
DataType *pData;
public:
void setValue (DataType *p) { pData = p; }
...
};
Usage:
A *a = ...;
a->setValue(new IntType); // take care of heap allocation / stack allocation