Re: [boost] C# LINQ-like library: Boost.Qlang.

Subject: Re: [boost] C# LINQ-like library: Boost.Qlang.
From: Germán Diago (germandiago_at_[hidden])
Date: 2009-10-17 21:32:25

2009/10/18 Germán Diago <germandiago_at_[hidden]>

>
>
>
>
>> Hi,
>> I read you mail on boost concerning QLang. I just wanted to say I was
>> wondering (not very seriously) how to do such system, and you come with a
>> very clean first try.
>>
>
> Basically it's done with some metaprogramming to get the exact return type
> of a query. For example, if I put as an argument in a select a pointer to
> member data, I extract that  pointer to member's
> type and put it in a tuple, without const, volatile and removing the
> reference. I also use filter_iterator and transform_iterator from boost to
> filter sequences based on the where lambda.
> Thanks for the "clean first try". Anyway, it must improve quite a bit
> before being a serious candidate for boost. Just now it just works with
> c++0x, which I think is a serious problem for
>
   inclusion.

> .
>
>  Just a suggestion : it would be great if the user of the qlang could
>> select a tuple of value as a return value. (let's say I want to select the
>> string member "_name", a copy of the pointeur "this", and an int "_age" for
>> example from a set of objects. I suppose returning a tuple for example (or
>> some other type than those of the members) could be very interesting.
>>
>
> I don't know very well what you mean by returning a tuple of value as a
> return value. For now, what the libraries does is, if you write:
>
> from(somerange).select(full_object);
>
> it will return a select_ object which will generate a copy of the full
> object.
>
> if you write:
>
> from(somerange).select(&MyStruct::a_, &MyStruct::b_);
>
> it will return a select_ object which will return a std::tuple<type of a_
> without const and without reference, type of b_ without const and without
> reference>.
>
> Boost.Qlang allows you to return tuples right now, the problem is that
> those tuples (for now) are just 1-element tuples. But in the future they
> will be arbitrary tuples.
> A copy of the this pointer does not make sense I think. Since every piece
> of data is immutable (data is always generated based on the select
> arguments), if you want the this pointer, you will have
> to return full_object (a copy). So you cannot get the this pointer
> directly. You can manipulate that query and write it back where it belongs
> if you want to modify some object.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>