Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign

cbVariant class - update: discarded

(1/4) > >>

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: ---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;
};

--- End code ---

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.

Navigation

[0] Message Index

[#] Next page