$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: [boost] C# LINQ-like library: Boost.Qlang.
From: Germán Diago (germandiago_at_[hidden])
Date: 2009-10-18 07:48:18
From: 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.