cbVariant class - update: discarded

[rickg22]

OK, before we reinvent the wheel here, I'm asking:

How many c++ "variant" classes are out there? Has anyone used them? (They MUST NOT use templates)

This is a basic draft of what I came up with:

Code Select Expand


union cbtypes_t {
  char c;
  int i;
  bool b;
  float f;
} cbtypes;

class cbVariant
{
  public:
    bool is_undefined() { return m_type=='u'; }
    char QueryType();
    operator==(int intval);
    operator==(bool bool);
    ...
    operator_the_last_operator_used(last_type_used blah);
  private:
    char m_type;
    cbtypes m_v;
    wxString m_s;
};


Is there anything like this on the net?

[280Z28]

Can you add a brief explanation to the first post that explains 1) how such a class relates compiler framework and 2) why templates are bad. It'll stop some off-topic questions before they are asked.

Also, are you sure this should be in the compiler framework and not a part of the Code::Blocks SDK (where we just use it in the compiler framework)?

[280Z28]

Actually, if you think this is more of an SDK concept than a compiler framework concept (I'm thinking it probably is), then the way it relates to the compiler framework is unrelated to the discussion of implementation, but you might want to move this thread to the Development forum in that case. But you still might include why templates are bad. I'll remove these posts once you edit and/or move the thread.

Edit: Actually I'm going to dinner now. You can definitely delete them yourself once you read them.

[rickg22]

OK...

1) this variant class is required because:

The most important part of the framework consists of a map of variants. Actually, a class which holds a map of variants. *ALL* the configurations will be stored in a tree, where the nodes hold these.

2) And it needs to be template-free, because:

I don't want to impose the burden of templates for a simple thing which can be defined with a union of POD (plain-old-data) types and a string.

3) Finally, this belongs in the compiler framework forum, because:

The compiler framework is ALREADY in the SDK. The compiler plugin is based on this framework (see CompilerOptionsBase, CompilerTargetBase classes defined in the SDK)

[280Z28]

The idea of a cbVariant seems useful (to me) as a global C::B SDK general utility class so any CB plugin can make use of it for storing preferences or internal data. Having it as a compiler plugin specific class could unnecessarily limit its use to other plugin developers.

[rickg22]

The idea of a cbVariant seems useful (to me) as a global C::B SDK general utility class so any CB plugin can make use of it for storing preferences or internal data. Having it as a compiler plugin specific class could unnecessarily limit its use to other plugin developers.

Yes, the cbVariant and cbProperty (to be defined elsewhere in this forum) will be part of the SDK, but the new compiler framework REQUIRES these classes.

So, *ahem* hello? Anyone?

[byo]

How about wxVariant ? http://www.wxwidgets.org/manuals/2.6.2/wx_wxvariant.html#wxvariant

[rickg22]

How about wxVariant ? http://www.wxwidgets.org/manuals/2.6.2/wx_wxvariant.html#wxvariant

Um... eew?

(I read the docs). I don't think we'll be needing all those types... Anyway, I researched more, and the Microsoft VARIANT type is even worse  :shock: . I think it'll be cheaper to implement it ourselves.

[tiwag]

OK, before we reinvent the wheel here...

[takeshimiya]

I know you said no templates, but you can still look at boost.variant.

But, a version with little (almost none) templatization, very simmilar class is boost.any.
Perhaps that's what you're looking for. 

http://boost.org/doc/html/variant/misc.html#variant.versus-any

[rickg22]

Hmmm....

Interesting. Anyway I think i made up my mind, we'll use a very basic version (mine ) of variant. For storing the configs we shouldn't use advanced types other than wxString. Arrays should be handled with cbProperty classes.

[takeshimiya]

Good enough for the purpose I think.
If you have any design concerns look at the boost.any.

[killerbot]

to quote Thomas ... ***shudders***
Storing a type in the class and using unions.
Last month in Vegas several Gurus were flaming against those kind of things.
I'd say templates (I don't consider them a burden), leave the work up to the compiler.

Just another 'little' remark, when talking about the new features, maybe it's better to not think about implementation details yet (like using a tree) ??

Anyway, time to think and think ... ;-)

Lieven

[thomas]

to quote Thomas ...

Hey, don't use my name in the same thread as the word variant... I am not involved in this
But yes, you are right, Lieven.

[TDragon]

Personall, I'm not clear on what exactly your map/tree of variants does in the compiler framework. The only things I can envision requiring something like that would be handled more gracefully by inheritance and polymorphism. (But then, I've never sat down and designed a compiler framework before, so I'm probably missing something.)