Re: [Boost-users] [boost-users][Variant] Sequence instantiation

Subject: Re: [Boost-users] [boost-users][Variant] Sequence instantiation
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-08-28 01:24:35

On Thu, Aug 27, 2009 at 9:13 PM, Ryan McConnehey<mccorywork_at_[hidden]> wrote:
>
>> Ah, for something like that I personally would use Variant to hold it
>> all, Spirit2.1 (with stringtable > continued parsing trick, Spirit2.1
>> is in the boost trunk but it works on older boosts' too) to parse it,
>> would give the best speed and is easily extensible in the future while
>> being completely typesafe.
>>
>
> I'm assuming the Spirit 2.1 is just for parsing the xml file.  I still need
> to have a switch statement to determine what type I'm suppose to be storing.

You can use it for parsing the XML file, but I am not even talking
about that.  Spirit has a little ternary tree designed for fast
lookups, you could lookup the type in that, it will return a parser,
then you can run the string that inits that type through that parser
to create the type.  You could of course put it in a larger parser to
parse the whole xml file, but for just that purpose alone it would
still rule for this purpose.

On Thu, Aug 27, 2009 at 9:13 PM, Ryan McConnehey<mccorywork_at_[hidden]> wrote:
>  Lets suppose for a moment that I've determined the type to be stored
> (whether Spirit 2.1, tinyXML or some other parser).  I've tried making the
> Destination class a template based on type (see code at bottom of email).
>  Then I created a variant of all the Destination class with the types I
> wanted.  A map was used with a key for the parameter name and the value was
> a vector of the variants.  Matching the parameter name is simple in the get
> function.  I've had trouble comparing the type and then returning just a
> vector of that type and not a vector of the variant.  It seams that since
> the caller knows what type they want that I shouldn't have to return a
> variant.
>
> This approach seem to be complicating the return value.  The only reason to
> to make Destination a template was to keep track of the type.  Is there a
> way to keep track of the type in the key or something?  That way the
> Destination class can be simple and keep the return simple.  The caller
> knows what type they want and if it isn't there the return vector will be
> empty.  Can you provide some code on what you might suggest?

Since you are parsing something at runtime to figure out types, you
cannot really know what to return at compile time, hence the use of
the variant.  I'd might make something like this (pseudo-code):
struct someStruct {int i; float f;};
MAKE_FUSION_VECTOR_OVER_STRUCT(someStruct,(int,i)(float,f)); // or
whatever the name of the macro was...
typedef variant<int,float,someStruct> allPossibleTypesVariant;

template<typename Iterator>
struct TypeRegistrationAndParser
{
    typedef iteratorCharType<Iterator> Char; // or whatever the name
of the template is...
    typedef rule<Iterator,allPossibleTypesVariant()> ruleType;
    symbol<Char,ruleType> table;
    template <typename Iterator>
    bool ParseStringType(Iterator &iterType, Iterator endType,
Iterator &iterConstruct, Iterator endConstruct,
allPossibleTypesVariant &ret)
    {
        ruleType r = table.find(iterType,endType);
        if(iterType!=endType) return false;
        return parse(iterConstruct, endConstruct, r, ret);
    }
}

// Then use it somewhere:
TypeRegistrationAndParser typeParser;
typeParser.table["int"] = int_;
typeParser.table["float"] = int_;
typeParser.table["aStruct"] = int_>>':'>>float_;

std::string someTypeString("aStruct");
std::string someConstructString("42:3.14");
allPossibleTypesVariant value;
bool successful = typeParser.ParseStringType(
                      someTypeString.begin(),someTypeString.end(),
                      someConstructString.begin(),someConstructString.end(),
                      value
                      );
if(successful)
{
    // do something with value, which would be, in this case,
SomeStruct(i:42,f:3.14)
}

>
> Ryan
>
> Code:
> typedef boost::mpl::vector< Destination<long>, Destination<short>,
> Destination<std::string> > supported_types;
> typedef boost::variant::make_variant_over<supported_types>::type
>                  supported_variant;
> std::map< std::string, std::vector<supported_variant> >
>                   supported_list;
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>