How do I inherit static data members ?

I can't get the syntax right.
Suppose, the base class has a (static) string called foo.
I want the derived classes to maintain their own (constant) values of foo individually and have the same values for same types of objects created.
How do I do it ?
Is it better to make them non static and set constant values by the respective constructors ?

Override a virtual function to return the desired string for each derived class.

That would work, thanks.

The only scenario I can think of that failing is when I need, to make objects of the base class directly from stored/shared data.
What I'm trying to do is to, set up a 'sort of' dynamic typing thing where all types of objects will be derived from a C++ class or direct instances of the base, but the class name, data member names and values will be available as strings. The derived ones will define their C++ functions for operating on the data.
I want to keep the option of making objects of the base as the data can be made up by a script running somewhere else.

Following the idea of virtual functions , if I do not make the function purely virtual, but have the base's function return from a private field of the base, is that a good solution ?

Some proof of concept code; but I think I didn't get the OOP up to the mark.

Code:

---

#include<string>
#include<vector>
#include<stdexcept>
#include<iostream>

class SObject
{
    const std::string className;
    const std::vector<std::string> mNames;
    std::vector<std::string> mValues;
public:
    SObject(const std::string& cn, const std::vector<std::string>& mn, const std::vector<std::string>& mv)
        :className(cn), mNames(mn), mValues(mv)
        {};
    virtual std::string& memValue(const std::string& m)
    {
        //Do a better search later
        int i;
        for(i=0;i<mNames.size();++i)
            if(m==mNames[i])return mValues[i];
        throw(std::runtime_error("no_such_member"));
    };
    virtual std::string getClassName(){return className;};   
};

class derived : public SObject
{
    static std::string className;
    static std::vector<std::string> mNames;
public:
    derived(const std::vector<std::string>& mv)
        :SObject(className,mNames,mv){};
    std::string& operator[](const std::string& m){return memValue(m);}
   
};
std::string derived::className = "derived";
std::vector<std::string> derived::mNames = {"mA","mB","mC"};

int main()
{
    derived foo({"Value_of_mA","b","c"});
    std::cout<<foo["mA"];
}

---

map might be easier instead of the 2 vector approach.

looks like you're trying for a reflection scheme of sorts, yes?

Quote:

---

Originally Posted by m37h0d

map might be easier instead of the 2 vector approach.

---

If I implement binary search for this, it'll (afaik) be the same.
I'll also probably replace vectors of strings by plain 2d arrays if I need to share the objects between the program and a vm running scripts.

Quote:

---

looks like you're trying for a reflection scheme of sorts, yes?

---

You could say so.... but giving a lot less freedom. (like Qt does with QObject, but without mangling the code, and fitting the design I thought of)
My main goal is to make some sort of 'generic' interface between a program and a script(as of now.. lisp).

implementing your own binary search is certainly not equally easy. if you're doing it as an academic exercise, then more power to you, but it's generally better to use a prefabricated container that does what you're after.

Quote:

---

Originally Posted by m37h0d

implementing your own binary search is certainly not equally easy. if you're doing it as an academic exercise, then more power to you, but it's generally better to use a prefabricated container that does what you're after.

---

Not academic, but trying to enjoy making wheels as a hobby.

The problems I'll face with maps is that I can't be sure of their orientation in memory without writing a lot of template code.

i don't get it. do you want to marshal them as contiguous blocks or something?

Quote:

---

Originally Posted by m37h0d

i don't get it. do you want to marshal them as contiguous blocks or something?

---

Yes, (after some compromises, limiting maximum size of a field.)
That would take away the necessity of serializing and reconstructing objects every now and then and also a lot of stream parsing.

As those 'ugly' changes will be internal to the base class, I left those out of the above code.

the need to restrict your member types to POD will likely prove too big a compromise to make this really useful.

difficulties with stream parsing can be avoided if you put the onus on the objects to know the order their members appear in the stream. it's less work, and it simplifies the problem.

look at boost's implementation. i used it as a design guide for something similar a few years back to great effect.

Quote:

---

Originally Posted by m37h0d

the need to restrict your member types to POD will likely prove too big a compromise to make this really useful.

---

True, but unless I can magically instantiate templates at runtime, that seems to be the most efficient design to me.

Quote:

---

difficulties with stream parsing can be avoided if you put the onus on the objects to know the order their members appear in the stream. it's less work, and it simplifies the problem.

---

I was aiming for more simple.
If I have 64 bits space for each field, I can skip the stream operations totally and have random access I/O with pointer arithmetic(and some cheating by casting).
Bigger Objects can request numerous such blocks. That would help storing arrays of PODs or serialized representations of objects in other data atructures.

Quote:

---

look at boost's implementation. i used it as a design guide for something similar a few years back to great effect.

---

Thanks for that tip. I'll look into it and possibly replicate some of it.

you don't need to instantiate templates at runtime. the objects themselves know their layout.

i'm just jotting this down in here, so this is likely not correct; it's just to illustrate the concept.

consider:

Code:

---

class Serializable
{
    virtual void serialize(Serializer& s)=0;
}

class Serializer
{
private:
    std::vector<char>buffer;
public:
    template<typename T> void pack(const T& instance)
    {
        int oldSize = buffer.size();
        buffer.resize(buffer.length()+sizeof(T));
        char* start = &buffer[oldSize];
        memcpy(start,&instance,sizeof(T));
    }

    template<typename T> void pack(const std::vector<T>& v)
    {
        for(unsigned int i=0;i<v.size();++i)
        {
              pack(v[i]);
        }
    }

    void pack(const std::string& s)
    {
    //you get the idea here
    }

    void pack(Serializable& instance)
    {
      s.serialize(*this);
    }
};

---

i actually got really clever and worked it out so the serialize function did both serialization and deserialization based on the const-ness of the objects; this was crucial, as it made it impossible to jumble the order of the objects in the memory stream. i'll leave that for you to work out if you decide you like this approach.

This serializer is very broken in that it treats any type as just a sequence of bytes. Obviously this doesn't work too well with many containers.
Actually, boost has a serializer library. Worth a look at.

don't be so quick to judge. you'll note there are overloads for containers. i didn't provide the overloads for every conceivable one, only 2 as examples just to illustrate the idea.

I would probably use the generic overload for primitive types, then provide a Serializable& overload, but no more, causing compile errors instead of silent "failure."
Anyway, I put that out there not just as a "lecture," but also as information to whomever else may be reading and to point out boost, of course.

that wouldn't cause compile errors.

Having a non-appropriate overload would cause a compile error.

you can't overload your way into compile errors, the template always picks up the 'miscellaneous'. you can only overload your way into alternate paths. the only way that could possibly work would be with something like this:

Code:

---

template<class T,class U>
class Conversion
{
    typedef char Small;
    class Big{char arr[2];};
    static Small Test(U);
    static Big Test(...);
    static T& MakeT();
public:
    enum
    {
        exists = sizeof(Test(MakeT()))==sizeof(Small)
    };
};

template<typename T> void Serializer::pack(T& t)
{
    static_assert(Conversion<T,int>::exists,"packed types must be POD");
}

---

My point was to remove the generic overload to cause compile errors on purpose.

you said you'd use it for POD.

the generic overload is extremely powerful. it lets you serialize containers recursively, which allows you to handle containers-of-containers, and the like with no additional effort.

providing overloads for the standard containers plus a serializeable interface, along with the POD-check above in the ultimate call that packs the data members into the byte buffer works very well.

Quote:

---

Originally Posted by m37h0d

you said you'd use it for POD.

---

Not POD. Primitive types.
Although, even primitive types are dangerous.
Although then again, think about it, providing overloads for the fixed-size types in C++11 and doing checks for endianess, it wouldn't be so bad.
POD types are still dangerous since we cannot predict padding.

Quote:

---

providing overloads for the standard containers plus a serializeable interface, along with the POD-check above in the ultimate call that packs the data members into the byte buffer works very well.

---

For primitive types, but yes, I am inclined to agree. You may wish to extend it somehow to make it easy to write some code to allow for easily writing code to handle custom containers. Although I suppose one might be able to derive from Serializable or perhaps the class exposes some interface that can easily be overloaded. I digress.

darth vader is riding a unicycle playing a bagpipe.

your argument is invalid.

Darth Vader bagpipe unicycle - YouTube





happy monday ;)