Author Topic: cbVariant class - update: discarded  (Read 39525 times)

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
cbVariant class - update: discarded
« on: December 30, 2005, 01:23:36 am »
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;
};

Is there anything like this on the net?
« Last Edit: January 02, 2006, 08:30:39 pm by rickg22 »

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: cbVariant class - REQUIRED! Need implementation
« Reply #1 on: December 30, 2005, 01:26:54 am »
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)?
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: cbVariant class - REQUIRED! Need implementation
« Reply #2 on: December 30, 2005, 01:31:03 am »
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. :)
« Last Edit: December 30, 2005, 01:34:56 am by 280Z28 »
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: cbVariant class - REQUIRED! Need implementation
« Reply #3 on: December 30, 2005, 01:37:32 am »
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)
« Last Edit: December 30, 2005, 01:39:47 am by rickg22 »

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: cbVariant class - REQUIRED! Need implementation
« Reply #4 on: December 30, 2005, 01:44:44 am »
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.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: cbVariant class - REQUIRED! Need implementation
« Reply #5 on: December 30, 2005, 01:47:49 am »
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?

Offline byo

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 837

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: cbVariant class - REQUIRED! Need implementation
« Reply #7 on: December 30, 2005, 04:24:31 am »
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.

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: cbVariant class - REQUIRED! Need implementation
« Reply #8 on: December 30, 2005, 04:25:55 am »
OK, before we reinvent the wheel here...
  :)

takeshimiya

  • Guest
Re: cbVariant class - REQUIRED! Need implementation
« Reply #9 on: December 30, 2005, 04:35:33 am »
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

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: cbVariant class - REQUIRED! Need implementation
« Reply #10 on: December 30, 2005, 06:44:41 am »
Hmmm....

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

takeshimiya

  • Guest
Re: cbVariant class - REQUIRED! Need implementation
« Reply #11 on: December 30, 2005, 06:49:46 am »
Good enough for the purpose I think.
If you have any design concerns look at the boost.any.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: cbVariant class - REQUIRED! Need implementation
« Reply #12 on: December 30, 2005, 09:41:45 am »
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

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: cbVariant class - REQUIRED! Need implementation
« Reply #13 on: December 30, 2005, 10:27:43 am »
to quote Thomas ...
Hey, don't use my name in the same thread as the word variant... I am not involved in this :P
But yes, you are right, Lieven.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline TDragon

  • Lives here!
  • ****
  • Posts: 943
    • TDM-GCC
Re: cbVariant class - REQUIRED! Need implementation
« Reply #14 on: December 30, 2005, 03:46:40 pm »
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.)
https://jmeubank.github.io/tdm-gcc/ - TDM-GCC compiler suite for Windows (GCC 9.2.0 2020-03-08, 32/64-bit, no extra DLLs)