constructor initialisation order when Base constructor depends on reference from Derived - c++

I have a base class which writes objects to a std::ostream with buffering. I want to call this with
Obj obj;
flat_file_stream_writer<Obj> writer(std::cout);
writer.write(obj);
writer.flush();
but also with
Obj obj;
flat_file_writer<Obj> writer("filename.bin");
writer.write(obj);
writer.flush();
The latter call must establish a std::ofstream instance, and hold that for the duration of writing, and can then call the former version.
I thought simple non-virtual inheritance would be fine here. But I have constructor initialization order issues.
warning: field 'ofstream_' will be initialized after base
'flat_file_stream_writer<hibp::pawned_pw>' [-Wreorder-ctor]
Because the base class depends on a reference to the object held by the derived this seems like chicken and egg and can't be solved?
Is inheritance just the wrong abstraction here? A clean alternative?
template <typename ValueType>
class flat_file_stream_writer {
public:
explicit flat_file_stream_writer(std::ostream& os, std::size_t buf_size = 100)
: db_(os), buf_(buf_size) {}
void write(const ValueType& value) {
if (buf_pos_ == buf_.size()) flush();
std::memcpy(&buf_[buf_pos_], &value, sizeof(ValueType));
++buf_pos_;
}
void flush() { // could also be called in destructor?
if (buf_pos_ != 0) {
db_.write(reinterpret_cast<char*>(buf_.data()), // NOLINT reincast
static_cast<std::streamsize>(sizeof(ValueType) * buf_pos_));
buf_pos_ = 0;
}
}
private:
std::ostream& db_;
std::size_t buf_pos_ = 0;
std::vector<ValueType> buf_;
};
template <typename ValueType>
class flat_file_writer : public flat_file_stream_writer<ValueType> {
public:
explicit flat_file_writer(std::string dbfilename)
: dbfilename_(std::move(dbfilename)), dbpath_(dbfilename_),
ofstream_(dbpath_, std::ios::binary), flat_file_stream_writer<ValueType>(ofstream_) {
if (!ofstream_.is_open())
throw std::domain_error("cannot open db: " + std::string(dbpath_));
}
private:
std::string dbfilename_;
std::filesystem::path dbpath_;
std::ofstream ofstream_;
};

You can put std::ofstream ofstream_; in a separate struct, then have flat_file_writer inherit from that struct using private. Base classes are initialized in the order they are declared, so make sure to inherit from that struct before flat_file_stream_writer. You can now initialize that ofstream_ before the base class flat_file_stream_writer.
On closer inspection, I think you'll probably want to put all 3 of those members in the struct.
See below for updated code.
So this in effect means that the 3 members in ofstream_holder now come before the flat_file_stream_writer in the layout of flat_file_writer.
This seems like the right solution, not just because it "squashes the compiler warning", but because now we are really getting the correct initialization order, ie construct the std::ofstream first and then pass a reference to it to flat_file_stream_writer. And during destruct the std::ofstream will be destroyed last.
The original code above had this exactly the wrong way around, because the order we write in the derived constructor initializer is ignored and the actual order implemented is layout order, ie the order the members are declared.
(despite the flaws of the original code, it "ran fine" for me with sanitizers etc... but was probably UB?).
template <typename ValueType>
class flat_file_stream_writer {
public:
explicit flat_file_stream_writer(std::ostream& os, std::size_t buf_size = 100)
: db_(os), buf_(buf_size) {}
void write(const ValueType& value) {
if (buf_pos_ == buf_.size()) flush();
std::memcpy(&buf_[buf_pos_], &value, sizeof(ValueType));
++buf_pos_;
}
void flush() {
if (buf_pos_ != 0) {
db_.write(reinterpret_cast<char*>(buf_.data()), // NOLINT reincast
static_cast<std::streamsize>(sizeof(ValueType) * buf_pos_));
buf_pos_ = 0;
}
}
private:
std::ostream& db_;
std::size_t buf_pos_ = 0;
std::vector<ValueType> buf_;
};
struct ofstream_holder {
explicit ofstream_holder(std::string dbfilename)
: dbfilename_(std::move(dbfilename)), dbpath_(dbfilename_),
ofstream_(dbpath_, std::ios::binary) {}
std::string dbfilename_;
std::filesystem::path dbpath_;
std::ofstream ofstream_;
};
template <typename ValueType>
class flat_file_writer : private ofstream_holder, public flat_file_stream_writer<ValueType> {
public:
explicit flat_file_writer(std::string dbfilename)
: ofstream_holder(std::move(dbfilename)), flat_file_stream_writer<ValueType>(ofstream_) {
if (!ofstream_.is_open())
throw std::domain_error("cannot open db: " + std::string(dbpath_));
}
};

Related

QList of a polymorphic class with copy-on-write?

I am trying to create a QList of a polymorphic type that still uses Qt's implicit sharing.
My specific use case is passing items held in a QList to QtConcurrent::mapped. The items all descend from a base class which defines a virtual function that QtConcurrent::mapped will call. The majority of the stored data will be child class specific. These items may be edited after the threading begins, leaving me with two main options, locks or copy the data. I do not want to stick locks in, because that would eliminate most of the purpose of using extra threads. Also making full copies of my data also seems quite undesirable. Instead I would like use Qt's implicit sharing to only make copies of the data items that I change, however I can't seem to make a QList of a polymorphic type that still uses implicit sharing.
QList by default uses implicit sharing, so at first glance it would seem that we are already done.
QList<Base> list;
Derived derived_obj;
list.append(derived_obj); // this fails
However appending a child class to a QList of the parent class will not work and the standard answer is to instead use a QList of QSharedPointers to the base class, which will accept appending a pointer to the child class.
QList<QSharedPointer<Base> > pointer_list;
QSharedPointer<Derived> derived_pointer;
pointer_list.append(derived_pointer); // this works but there is no copy-on-write
If I use a QList of QSharedPointers, it is the QSharedPointer that will be be copied rather than my polymorphic class, meaning that I have lost the copy-on-write functionality that I would like.
I have also looked at using a QList of QSharedDataPointers.
QList<QSharedDataPointer<Base> > data_pointer_list;
QSharedDataPointer<Derived> derived_data_pointer;
list.append(derived_data_pointer); // this fails
However like QList itself, QSharedDataPointers do not seem to accept polymorphic types.
This fails:
QList<QSharedDataPointer<Base>> list;
QSharedDataPointer<Derived> derived(new Derived);
list.append(derived);
Note An alternative approach to the below would be to merge the PolymorphicShared and PolymorphicSharedBase to add polymorphism support directly to QSharedDataPointer, without placing special requirements on the QSharedData-derived type (e.g. it wouldn't need to explicitly support clone). This requires a bit more work. The below is just one working approach.
QSharedDataPointer is indeed the answer you seek and can definitely hold polymorphic QSharedData. You need to separate the type into a hierarchy based on QSharedData, and another parallel hierarchy wrapping the QSharedDataPointer. The QSharedDataPointer is not usually meant to be used directly by the end user of a class. It's an implementation detail useful in implementing an implicitly shared class.
For efficiency's sake, a QSharedDataPointer is a small type that can be moved at the bit level. It's quite efficient when stored in containers of all sorts - especially in Qt containers that can utilize the type traits to be aware of this property. The size of a class using a QSharedDataPointer will usually double if we make it polymorphic itself, thus it helps not to do it. The pointed-to data type can be polymorphic, of course.
First, let's define a rather univeral base class PIMPL that you'll build the hierarchy on. The PIMPL class can be dumped into the debug stream, and cloned.
// https://github.com/KubaO/stackoverflown/tree/master/questions/implicit-list-44593216
#include <QtCore>
#include <type_traits>
class PolymorphicSharedData : public QSharedData {
public:
virtual PolymorphicSharedData * clone() const = 0;
virtual QDebug dump(QDebug) const = 0;
virtual ~PolymorphicSharedData() {}
};
The xxxData types are PIMPLs and are not meant for use by the end-user. The user is meant to use the xxx type itself. This shared type then wraps the polymorphic PIMPL and uses the QSharedDataPointer for storage of the PIMPL. It exposes the methods of the PIMPL.
The type itself is not polymorphic, to save on the size of the virtual table pointer. The as() function acts as dynamic_cast() would, by redirecting polymorphism to the PIMPL.
class PolymorphicShared {
protected:
QSharedDataPointer<PolymorphicSharedData> d_ptr;
PolymorphicShared(PolymorphicSharedData * d) : d_ptr(d) {}
public:
PolymorphicShared() = default;
PolymorphicShared(const PolymorphicShared & o) = default;
PolymorphicShared & operator=(const PolymorphicShared &) = default;
QDebug dump(QDebug dbg) const { return d_ptr->dump(dbg); }
template <class T> typename
std::enable_if<std::is_pointer<T>::value, typename
std::enable_if<!std::is_const<typename std::remove_pointer<T>::type>::value, T>::type>
::type as() {
if (dynamic_cast<typename std::remove_pointer<T>::type::PIMPL*>(d_ptr.data()))
return static_cast<T>(this);
return {};
}
template <class T> typename
std::enable_if<std::is_pointer<T>::value, typename
std::enable_if<std::is_const<typename std::remove_pointer<T>::type>::value, T>::type>
::type as() const {
if (dynamic_cast<const typename std::remove_pointer<T>::type::PIMPL*>(d_ptr.data()))
return static_cast<T>(this);
return {};
}
template <class T> typename
std::enable_if<std::is_reference<T>::value, typename
std::enable_if<!std::is_const<typename std::remove_reference<T>::type>::value, T>::type>
::type as() {
Q_UNUSED(dynamic_cast<typename std::remove_reference<T>::type::PIMPL&>(*d_ptr));
return static_cast<T>(*this);
}
template <class T> typename
std::enable_if<std::is_reference<T>::value, typename
std::enable_if<std::is_const<typename std::remove_reference<T>::type>::value, T>::type>
::type as() const {
Q_UNUSED(dynamic_cast<const typename std::remove_reference<T>::type::PIMPL&>(*d_ptr));
return static_cast<T>(*this);
}
int ref() const { return d_ptr ? d_ptr->ref.load() : 0; }
};
QDebug operator<<(QDebug dbg, const PolymorphicShared & val) {
return val.dump(dbg);
}
Q_DECLARE_TYPEINFO(PolymorphicShared, Q_MOVABLE_TYPE);
#define DECLARE_TYPEINFO(concreteType) Q_DECLARE_TYPEINFO(concreteType, Q_MOVABLE_TYPE)
template <> PolymorphicSharedData * QSharedDataPointer<PolymorphicSharedData>::clone() {
return d->clone();
}
A helper to makes it easy to use the abstract base class with derived data types. It casts the d-ptr to a proper derived PIMPL type, and forwards the constructor arguments to the PIMPL's constructor.
template <class Data, class Base = PolymorphicShared> class PolymorphicSharedBase : public Base {
friend class PolymorphicShared;
protected:
using PIMPL = typename std::enable_if<std::is_base_of<PolymorphicSharedData, Data>::value, Data>::type;
PIMPL * d() { return static_cast<PIMPL*>(&*this->d_ptr); }
const PIMPL * d() const { return static_cast<const PIMPL*>(&*this->d_ptr); }
PolymorphicSharedBase(PolymorphicSharedData * d) : Base(d) {}
template <typename T> static typename std::enable_if<std::is_constructible<T>::value, T*>::type
construct() { return new T(); }
template <typename T> static typename std::enable_if<!std::is_constructible<T>::value, T*>::type
construct() { return nullptr; }
public:
using Base::Base;
template<typename ...Args,
typename = typename std::enable_if<std::is_constructible<Data, Args...>::value>::type
> PolymorphicSharedBase(Args&&... args) :
Base(static_cast<PolymorphicSharedData*>(new Data(std::forward<Args>(args)...))) {}
PolymorphicSharedBase() : Base(construct<Data>()) {}
};
It's now a simple matter to have the parallel hierarchy of PIMPL types and their carriers. First, a basic abstract type in our hierarchy that adds two methods. Note how PolymorphicSharedBase adds the d() accessor of the correct type.
class MyAbstractTypeData : public PolymorphicSharedData {
public:
virtual void gurgle() = 0;
virtual int gargle() const = 0;
};
class MyAbstractType : public PolymorphicSharedBase<MyAbstractTypeData> {
public:
using PolymorphicSharedBase::PolymorphicSharedBase;
void gurgle() { d()->gurgle(); }
int gargle() const { return d()->gargle(); }
};
DECLARE_TYPEINFO(MyAbstractType);
Then, a concrete type that adds no new methods:
class FooTypeData : public MyAbstractTypeData {
protected:
int m_foo = 0;
public:
FooTypeData() = default;
FooTypeData(int data) : m_foo(data) {}
void gurgle() override { m_foo++; }
int gargle() const override { return m_foo; }
MyAbstractTypeData * clone() const override { return new FooTypeData(*this); }
QDebug dump(QDebug dbg) const override {
return dbg << "FooType-" << ref << ":" << m_foo;
}
};
using FooType = PolymorphicSharedBase<FooTypeData, MyAbstractType>;
DECLARE_TYPEINFO(FooType);
And another type that adds methods.
class BarTypeData : public FooTypeData {
protected:
int m_bar = 0;
public:
BarTypeData() = default;
BarTypeData(int data) : m_bar(data) {}
MyAbstractTypeData * clone() const override { return new BarTypeData(*this); }
QDebug dump(QDebug dbg) const override {
return dbg << "BarType-" << ref << ":" << m_foo << "," << m_bar;
}
virtual void murgle() { m_bar++; }
};
class BarType : public PolymorphicSharedBase<BarTypeData, FooType> {
public:
using PolymorphicSharedBase::PolymorphicSharedBase;
void murgle() { d()->murgle(); }
};
DECLARE_TYPEINFO(BarType);
We'll want to verify that the as() method throws as needed:
template <typename F> bool is_bad_cast(F && fun) {
try { fun(); } catch (std::bad_cast) { return true; }
return false;
}
The use of the implicitly shared types is no different than the use of Qt's own such types. We can also cast using as instead of dynamic_cast.
int main() {
Q_ASSERT(sizeof(FooType) == sizeof(void*));
MyAbstractType a;
Q_ASSERT(!a.as<FooType*>());
FooType foo;
Q_ASSERT(foo.as<FooType*>());
a = foo;
Q_ASSERT(a.ref() == 2);
Q_ASSERT(a.as<const FooType*>());
Q_ASSERT(a.ref() == 2);
Q_ASSERT(a.as<FooType*>());
Q_ASSERT(a.ref() == 1);
MyAbstractType a2(foo);
Q_ASSERT(a2.ref() == 2);
QList<MyAbstractType> list1{FooType(3), BarType(8)};
auto list2 = list1;
qDebug() << "After copy: " << list1 << list2;
list2.detach();
qDebug() << "After detach: " << list1 << list2;
list1[0].gurgle();
qDebug() << "After list1[0] mod: " << list1 << list2;
Q_ASSERT(list2[1].as<BarType*>());
list2[1].as<BarType&>().murgle();
qDebug() << "After list2[1] mod: " << list1 << list2;
Q_ASSERT(!list2[0].as<BarType*>());
Q_ASSERT(is_bad_cast([&]{ list2[0].as<BarType&>(); }));
auto const list3 = list1;
Q_ASSERT(!list3[0].as<const BarType*>());
Q_ASSERT(is_bad_cast([&]{ list3[0].as<const BarType&>(); }));
}
Output:
After copy: (FooType-1:3, BarType-1:0,8) (FooType-1:3, BarType-1:0,8)
After detach: (FooType-2:3, BarType-2:0,8) (FooType-2:3, BarType-2:0,8)
After list1[0] mod: (FooType-1:4, BarType-2:0,8) (FooType-1:3, BarType-2:0,8)
After list2[1] mod: (FooType-1:4, BarType-1:0,8) (FooType-1:3, BarType-1:0,9)
The list copy was shallow and the items themselves weren't copied: the reference counts are all 1. After the detach, all data items were copied but because they are implicitly shared, they only incremented their reference counts. Finally, after an item is was modified, it is automatically detached, and the reference counts drop back to 1.

C++ BigIntegers and the Curiously Recurring Template Pattern Issue

I'm implementing a Big Integer library where the user can choose between fixed precision or arbitrary precision integers. Since great part of the code is shared between the two entities I've decided to use the CRTP to implement the Integer operations just once.
In short there is a base class named UInteger and two derived classes named UIntegerFP (fixed precision) and UIntegerAP (arbitrary precision).
Follows a skeleton of the implementation:
template <typename Derived>
class UInteger
{
public:
UInteger<Derived> &operator +=(const UInteger<Derived> &rhs);
...
};
template <int blocks>
class UIntegerFP : public UInteger<UIntegerFP>
{
public:
int get_size() { return m_len; }
void set_size(int size) { m_len = len; }
private:
std::array<uint32_t, blocks> m_data;
int m_len;
};
class UIntegerAP : public UInteger<UIntegerAP>
{
public:
int get_size() { return m_data.size(); }
void set_size(int size) { m_data.resize(len); }
private:
std::vector<uint32_t> m_data;
};
The base class uses a couple of methods exposed by the derived classes to interact with implementation dependent aspects (ie like get_size/set_size).
My problem:
I want to implement a global binary operator+() that returns the result of the operation by value in the UInteger "generic" header file in this way:
template <typename Derived>
UInteger<Derived> operator+(const UInteger<Derived> &x0,
const UInteger<Derived> &x1)
{
Derived res = static_cast<Derived>(x0);
x0 += x1;
return x0;
}
The problem is that, since the result is returned by value, it is casted to the base class type loosing the implementation details (e.g. the m_data vector destructor is called).
Obviously I do not get this problem if I define the function to return a Derived type by value:
template <typename Derived>
Derived operator+(const UInteger<Derived> &x0,
const UInteger<Derived> &x1)
{
Derived res = static_cast<Derived>(x0);
x0 += x1;
return x0;
}
But I don't like too much this approach, epecially from a design point of view.
Is there a better solution to such problem? Maybe I should define such operators directly just for the derived classes?
Is there someone thinking that the CRTP is not very appropriate here and maybe is better to directly implement just one UInteger class in this way:
template <bool dynamic = true>
class UInteger
{
...
private:
std::array<uint32_t> m_data;
int m_len; <- how much of m_data array is actually in use
}
and if the bool "dynamic" value is false I never reallocate the vector obtaining something similar to the UIntegerFP template class. Maybe (if the compiler is smart enough) , since the boolean is a const template parameter, I also abtain something like conditional code compilation?!
Suggestions of any type are very welcome,
Thanks,
Davide
I don't quite understand why you want to use CRTP here in this way.
CRTP is the natural way to implement the actual details of the = and += operations, when only the memory management is done via the derived methods. Such design clearly separates the two task of arithmetic and memory management to different classes. The + (binary) operator is then best implemented as stand-alone function template.
Something like this:
namespace biginteger_details {
template<typename UInteger>
class UIntegerBase // CRTP base, implementing the arithmetics
{
using uint32_t = std::uint32_t;
using size_t = std::size_t;
// access to data: all functionality is implemented through these methods
uint32_t&block(size_t i) { return static_cast< UInteger*>(this)->m_data[i]; }
uint32_t block(size_t i) const { return static_cast<const UInteger*>(this)->m_data[i]; }
size_t size() const { return static_cast<const UInteger*>(this)->size(); }
void resize(size_t n) { static_cast<UInteger*>(this)->resize(n); }
public:
// assignment operator: allow assignment from any UInteger type
template<typename UI>
UInteger&operator=(UIntegerBase<UI> const&other)
{
resize(other.size());
for(size_t i=0; i!=size(); ++i)
block(i) = other.block(i);
return static_cast<UInteger&>(*this);
}
// add and assign: allow adding any UInteger type
template<typename UI>
UInteger&operator+=(UIntegerBase<UI> const&other)
{
// your code here using block(), size(), and resize()
return static_cast<UInteger&>(*this);
}
};
template<std::size_t nblock=8>
struct UIntegerFP
: UIntegerBase<UIntegerFP<nblock>>
{
static constexpr std::size_t max_blocks=nblock;
// 1 data
std::array<std::uint32_t,nblock> m_data;
std::size_t m_size=0;
// 2 interface to base
std::size_t size() const { return m_size; }
void resize(std::size_t n)
{
if(n>nblock) throw std::out_of_range("exceeding capacity");
m_size = n;
}
// 3 constructors
// copy constructor from any UInteger type
template<typename UI>
UIntegerFP(UIntegerBase<UI> const&other)
{ this->operator=(other); }
};
struct UIntegerAP
: UIntegerBase<UIntegerAP>
{
static constexpr std::size_t max_blocks=~(std::size_t(0));
// 1 data,
std::vector<std::uint32_t> m_data;
// 2 interface to base
std::size_t size() const { return m_data.size(); }
void resize(std::size_t n)
{ m_data.resize(n); }
// 3 constructors
// copy constructor from any UInteger type
template<typename UI>
UIntegerAP(UIntegerBase<UI> const&other)
{ this->operator=(other); }
};
// functions best take UIntegerBase<UI> arguments, for example:
// operator + as stand alone function template
template<typename Ulhs, typename Urhs>
inline std::conditional_t<(Ulhs::max_blocks > Urhs::max_blocks), Ulhs, Urhs>
operator+(UIntegerBase<Ulhs> const&lhs, UIntegerBase<Urhs> const&rhs)
{
std::conditional_t<(Ulhs::max_blocks > Urhs::max_blocks), Ulhs, Urhs>
result=lhs;
return result+=rhs;
}
} // namespace biginteger_details;
using biginteger_details::UIntegerFP;
using biginteger_details::UIntegerAP;
// note: biginteger_details::operator+ will be found by ADL (argument dependent look-up)
In your operator+ implementation, in practice, you are setting the function return type as:
UIntegerAP if one of the template types is an UIntegerAP.
Ulhs, otherwise (here I suppose you intend UIntegerFP).
Is that right?
Now... what if the UIntegerAP is a template as well? For example defined like this:
template <typename block_type>
class UIntegerAP
{
....
private:
std::vector<block_type> m_data;
}
I cannot use UIntegerAP type in the operator+ declaration anymore.

C++ Push Multiple Types onto Vector

Note: I know similar questions to this have been asked on SO before, but I did not find them helpful or very clear.
Second note: For the scope of this project/assignment, I'm trying to avoid third party libraries, such as Boost.
I am trying to see if there is a way I can have a single vector hold multiple types, in each of its indices. For example, say I have the following code sample:
vector<something magical to hold various types> vec;
int x = 3;
string hi = "Hello World";
MyStruct s = {3, "Hi", 4.01};
vec.push_back(x);
vec.push_back(hi);
vec.push_back(s);
I've heard vector<void*> could work, but then it gets tricky with memory allocation and then there is always the possibility that certain portions in nearby memory could be unintentionally overridden if a value inserted into a certain index is larger than expected.
In my actual application, I know what possible types may be inserted into a vector, but these types do not all derive from the same super class, and there is no guarantee that all of these types will be pushed onto the vector or in what order.
Is there a way that I can safely accomplish the objective I demonstrated in my code sample?
Thank you for your time.
The objects hold by the std::vector<T> need to be of a homogenous type. If you need to put objects of different type into one vector you need somehow erase their type and make them all look similar. You could use the moral equivalent of boost::any or boost::variant<...>. The idea of boost::any is to encapsulate a type hierarchy, storing a pointer to the base but pointing to a templatized derived. A very rough and incomplete outline looks something like this:
#include <algorithm>
#include <iostream>
class any
{
private:
struct base {
virtual ~base() {}
virtual base* clone() const = 0;
};
template <typename T>
struct data: base {
data(T const& value): value_(value) {}
base* clone() const { return new data<T>(*this); }
T value_;
};
base* ptr_;
public:
template <typename T> any(T const& value): ptr_(new data<T>(value)) {}
any(any const& other): ptr_(other.ptr_->clone()) {}
any& operator= (any const& other) {
any(other).swap(*this);
return *this;
}
~any() { delete this->ptr_; }
void swap(any& other) { std::swap(this->ptr_, other.ptr_); }
template <typename T>
T& get() {
return dynamic_cast<data<T>&>(*this->ptr_).value_;
}
};
int main()
{
any a0(17);
any a1(3.14);
try { a0.get<double>(); } catch (...) {}
a0 = a1;
std::cout << a0.get<double>() << "\n";
}
As suggested you can use various forms of unions, variants, etc. Depending on what you want to do with your stored objects, external polymorphism could do exactly what you want, if you can define all necessary operations in a base class interface.
Here's an example if all we want to do is print the objects to the console:
#include <iostream>
#include <string>
#include <vector>
#include <memory>
class any_type
{
public:
virtual ~any_type() {}
virtual void print() = 0;
};
template <class T>
class concrete_type : public any_type
{
public:
concrete_type(const T& value) : value_(value)
{}
virtual void print()
{
std::cout << value_ << '\n';
}
private:
T value_;
};
int main()
{
std::vector<std::unique_ptr<any_type>> v(2);
v[0].reset(new concrete_type<int>(99));
v[1].reset(new concrete_type<std::string>("Bottles of Beer"));
for(size_t x = 0; x < 2; ++x)
{
v[x]->print();
}
return 0;
}
In order to do that, you'll definitely need a wrapper class to somehow conceal the type information of your objects from the vector.
It's probably also good to have this class throw an exception when you try to get Type-A back when you have previously stored a Type-B into it.
Here is part of the Holder class from one of my projects. You can probably start from here.
Note: due to the use of unrestricted unions, this only works in C++11. More information about this can be found here: What are Unrestricted Unions proposed in C++11?
class Holder {
public:
enum Type {
BOOL,
INT,
STRING,
// Other types you want to store into vector.
};
template<typename T>
Holder (Type type, T val);
~Holder () {
// You want to properly destroy
// union members below that have non-trivial constructors
}
operator bool () const {
if (type_ != BOOL) {
throw SomeException();
}
return impl_.bool_;
}
// Do the same for other operators
// Or maybe use templates?
private:
union Impl {
bool bool_;
int int_;
string string_;
Impl() { new(&string_) string; }
} impl_;
Type type_;
// Other stuff.
};

Building boost::options from a string/boost::any map

I have a map which represents a configuration. It's a map of std::string and boost::any.
This map is initialized at the start and I'd like the user to be able to override these options on the command line.
What I'd love to do is build the program options from this map using the options_description::add_option() method. However, it takes a template argument po::value<> whereas all I have is boost::any.
So far, I just have the shell of the code. m_Config represents my configuration class, and getTuples() returns a std::map<std::string, Tuple>. TuplePair is a typedef of std::pair<std::string, Tuple> and the Tuple contains the boost::any I am interested in.
po::options_description desc;
std::for_each(m_Config.getTuples().begin(),
m_Config.getTuples().end(),
[&desc](const TuplePair& _pair)
{
// what goes here? :)
// desc.add_options() ( _pair.first, po::value<???>, "");
});
Is there a way to build it this way, or do I need to resort to doing it myself?
Thanks in advance!
boost::any is not applicable to your problem. It performs the most basic form of type erasure: storage and (type-safe) retrieval, and that's it. As you've seen, no other operations can be performed. As jhasse points out, you could just test every type you want to support, but this is a maintenance nightmare.
Better would be to expand upon the idea boost::any uses. Unfortunately this requires a bit of boiler-plate code. If you'd like to try it, there's a new Boost library being discussed right now on the mailing list (titled "[boost] RFC: type erasure") that is essentially a generalized type erasure utility: you define the operations you'd like your erased type to support, and it generates the proper utility type. (It can simulate boost::any, for example, by requiring the erased type be copy-constructible and type-safe, and can simulate boost::function<> by additionally requiring the type be callable.)
Aside from that, though, your best option is probably to write such a type yourself. I'll do it for you:
#include <boost/program_options.hpp>
#include <typeinfo>
#include <stdexcept>
namespace po = boost::program_options;
class any_option
{
public:
any_option() :
mContent(0) // no content
{}
template <typename T>
any_option(const T& value) :
mContent(new holder<T>(value))
{
// above is where the erasure happens,
// holder<T> inherits from our non-template
// base class, which will make virtual calls
// to the actual implementation; see below
}
any_option(const any_option& other) :
mContent(other.empty() ? 0 : other.mContent->clone())
{
// note we need an explicit clone method to copy,
// since with an erased type it's impossible
}
any_option& operator=(any_option other)
{
// copy-and-swap idiom is short and sweet
swap(*this, other);
return *this;
}
~any_option()
{
// delete our content when we're done
delete mContent;
}
bool empty() const
{
return !mContent;
}
friend void swap(any_option& first, any_option& second)
{
std::swap(first.mContent, second.mContent);
}
// now we define the interface we'd like to support through erasure:
// getting the data out if we know the type will be useful,
// just like boost::any. (defined as friend free-function)
template <typename T>
friend T* any_option_cast(any_option*);
// and the ability to query the type
const std::type_info& type() const
{
return mContent->type(); // call actual function
}
// we also want to be able to call options_description::add_option(),
// so we add a function that will do so (through a virtual call)
void add_option(po::options_description desc, const char* name)
{
mContent->add_option(desc, name); // call actual function
}
private:
// done with the interface, now we define the non-template base class,
// which has virtual functions where we need type-erased functionality
class placeholder
{
public:
virtual ~placeholder()
{
// allow deletion through base with virtual destructor
}
// the interface needed to support any_option operations:
// need to be able to clone the stored value
virtual placeholder* clone() const = 0;
// need to be able to test the stored type, for safe casts
virtual const std::type_info& type() const = 0;
// and need to be able to perform add_option with type info
virtual void add_option(po::options_description desc,
const char* name) = 0;
};
// and the template derived class, which will support the interface
template <typename T>
class holder : public placeholder
{
public:
holder(const T& value) :
mValue(value)
{}
// implement the required interface:
placeholder* clone() const
{
return new holder<T>(mValue);
}
const std::type_info& type() const
{
return typeid(mValue);
}
void add_option(po::options_description desc, const char* name)
{
desc.add_options()(name, po::value<T>(), "");
}
// finally, we have a direct value accessor
T& value()
{
return mValue;
}
private:
T mValue;
// noncopyable, use cloning interface
holder(const holder&);
holder& operator=(const holder&);
};
// finally, we store a pointer to the base class
placeholder* mContent;
};
class bad_any_option_cast :
public std::bad_cast
{
public:
const char* what() const throw()
{
return "bad_any_option_cast: failed conversion";
}
};
template <typename T>
T* any_option_cast(any_option* anyOption)
{
typedef any_option::holder<T> holder;
return anyOption.type() == typeid(T) ?
&static_cast<holder*>(anyOption.mContent)->value() : 0;
}
template <typename T>
const T* any_option_cast(const any_option* anyOption)
{
// none of the operations in non-const any_option_cast
// are mutating, so this is safe and simple (constness
// is restored to the return value automatically)
return any_option_cast<T>(const_cast<any_option*>(anyOption));
}
template <typename T>
T& any_option_cast(any_option& anyOption)
{
T* result = any_option_cast(&anyOption);
if (!result)
throw bad_any_option_cast();
return *result;
}
template <typename T>
const T& any_option_cast(const any_option& anyOption)
{
return any_option_cast<T>(const_cast<any_option&>(anyOption));
}
// NOTE: My casting operator has slightly different use than
// that of boost::any. Namely, it automatically returns a reference
// to the stored value, so you don't need to (and cannot) specify it.
// If you liked the old way, feel free to peek into their source.
#include <boost/foreach.hpp>
#include <map>
int main()
{
// (it's a good exercise to step through this with
// a debugger to see how it all comes together)
typedef std::map<std::string, any_option> map_type;
typedef map_type::value_type pair_type;
map_type m;
m.insert(std::make_pair("int", any_option(5)));
m.insert(std::make_pair("double", any_option(3.14)));
po::options_description desc;
BOOST_FOREACH(pair_type& pair, m)
{
pair.second.add_option(desc, pair.first.c_str());
}
// etc.
}
Let me know if something is unclear. :)
template<class T>
bool any_is(const boost::any& a)
{
try
{
boost::any_cast<const T&>(a);
return true;
}
catch(boost::bad_any_cast&)
{
return false;
}
}
// ...
po::options_description desc;
std::for_each(m_Config.getTuples().begin(),
m_Config.getTuples().end(),
[&desc](const TuplePair& _pair)
{
if(any_is<int>(_pair.first))
{
desc.add_options() { _pair.first, po::value<int>, ""};
}
else if(any_is<std::string>(_pair.first))
{
desc.add_options() { _pair.first, po::value<std::string>, ""};
}
else
{
// ...
}
});
// ...
If you have more than a handful of types consider using typelists.

Template type deduction with a non-copyable class

Suppose I have an autolocker class which looks something like this:
template <T>
class autolocker {
public:
autolocker(T *l) : lock(l) {
lock->lock();
}
~autolocker() {
lock->unlock();
}
private:
autolocker(const autolocker&);
autolocker& operator=(const autolocker&);
private:
T *lock;
};
Obviously the goal is to be able to use this autolocker with anything that has a lock/unlock method without resorting to virtual functions.
Currently, it's simple enough to use like this:
autolocker<some_lock_t> lock(&my_lock); // my_lock is of type "some_lock_t"
but it is illegal to do:
autolocker lock(&my_lock); // this would be ideal
Is there anyway to get template type deduction to play nice with this (keep in my autolocker is non-copyable). Or is it just easiest to just specify the type?
Yes you can use the scope-guard technique
struct autolocker_base {
autolocker_base() { }
protected:
// ensure users can't copy-as it
autolocker_base(autolocker_base const&)
{ }
autolocker_base &operator=(autolocker_base const&)
{ return *this; }
};
template <T>
class autolocker : public autolocker_base {
public:
autolocker(T *l) : lock(l) {
lock->lock();
}
autolocker(const autolocker& o)
:autolocker_base(o), lock(o.lock)
{ o.lock = 0; }
~autolocker() {
if(lock)
lock->unlock();
}
private:
autolocker& operator=(const autolocker&);
private:
mutable T *lock;
};
Then write a function creating the autolocker
template<typename T>
autolocker<T> makelocker(T *l) {
return autolocker<T>(l);
}
typedef autolocker_base const& autolocker_t;
You can then write it like this:
autolocker_t lock = makelocker(&my_lock);
Once the const reference goes out of scope, the destructor is called. It doesn't need to be virtual. At least GCC optimizes this quite well.
Sadly, this means you have to make your locker-object copyable since you need to return it from the maker function. But the old object won't try to unlock twice, because its pointer is set to 0 when it's copied, so it's safe.
Obviously you can't get away with autolocker being a template, because you want to use it as a type, and templates must be instantiated in order to obtain types.
But type-erasure might be used to do what you want. You turn the class template into a class and its constructor into a member template. But then you'd have to dynamically allocate an inner implementation object.
Better, store a pointer to a function that performs the unlock and let that function be an instance of a template chosen by the templatized constructor. Something along these lines:
// Comeau compiles this, but I haven't tested it.
class autolocker {
public:
template< typename T >
autolocker(T *l) : lock_(l), unlock_(&unlock<T>) { l->lock(); }
~autolocker() { unlock_(lock_); }
private:
autolocker(const autolocker&);
autolocker& operator=(const autolocker&);
private:
typedef void (*unlocker_func_)(void*);
void *lock_;
unlocker_func_ unlock_;
template <typename T>
static void unlock(void* lock) { ((T*)lock)->unlock(); }
};
I haven't actually tried this and the syntax might be wrong (I'm not sure how to take the address of a specific function template instance), but I think this should be doable in principle. Maybe someone comes along and fixes what I got wrong.
I like this a lot more than the scope guard, which, for some reason, I never really liked at all.
I think jwismar is correct and what you want is not possible with C++. However, a similar (not direct analogue) construct is possible with C++0x, using several new features (rvalues/moving and auto variable type):
#include <iostream>
template <typename T>
class autolocker_impl
{
public:
autolocker_impl(T *l) : lock(l) {
lock->lock();
}
autolocker_impl (autolocker_impl&& that)
: lock (that.lock)
{
that.lock = 0;
}
~autolocker_impl() {
if (lock)
lock->unlock();
}
private:
autolocker_impl(const autolocker_impl&);
autolocker_impl& operator=(const autolocker_impl&);
private:
T *lock;
};
template <typename T>
autolocker_impl <T>
autolocker (T* lock)
{
return autolocker_impl <T> (lock);
}
struct lock_type
{
void lock ()
{ std::cout << "locked\n"; }
void unlock ()
{ std::cout << "unlocked\n"; }
};
int
main ()
{
lock_type l;
auto x = autolocker (&l);
}
autolocker is a class template, not a class. Your "this would be ideal" is showing something that doesn't make sense in C++.