>> or dot

Dec 16, 2013 at 1:32 AM
Hi there

Sounds like a good idea to make the library extensible, though does using the >> operator work for intellisense on your average IDE, in a similar way you would get the benefit of a "." which gives relevant methods.
Dec 16, 2013 at 8:33 PM
mmalcolm wrote:
Hi there

Sounds like a good idea to make the library extensible, though does using the >> operator work for intellisense on your average IDE, in a similar way you would get the benefit of a "." which gives relevant methods.
I've been following the extensions for a little while now. I'm not sure, was this a statement or a question? Can't speak to the IDE's or code-completion / Intellisense part, per se, but I do like the idea of overloading the >> operator in order to extend the library. Taking a step backwards, anything that allows "extension"-style look-and-feel, in the same way as C# .NET extension methods, per se, also avoiding the "wrappers" approach, where things are generally wrapped in "()" operators, that gets to be very unwieldy very quickly.
Dec 16, 2013 at 10:10 PM
Sorry for the confusion - just wondering what people thought on this issue.
Thanks for your thoughts.
More recently I've been thinking just having a separate fork for a library to make your own addiations might be enough these days, rather than needing "full extensibility".
The dot notation is desirable for the people I work with mainly because of the intellisense benefits.
I've been weighing up different c++ linq libraries trying to work out which is better,
on basis of things like robustness, completeness, correctness (in terms of references, constness etc) and popularity.
Dec 17, 2013 at 2:03 AM
Of course, no problem. Can the dot (".") operator even be overloaded? I'm not sure it can, or necessarily when you would. At least in C++ parlance as concerns LINQ-style extensions. I suppose you could overload the "->" operator, but then you start getting into pointer weirdness. My personal opinion is, the >> is perfectly fine; it lends itself to C++ syntax and "extends" operation in a more or less fluent manner. I've taken to using that style in strategic AST's, DSL's, etc, for instance. Anywho, that's my two cents.
Dec 17, 2013 at 3:23 PM
I might also add, in C++ IDE's that I know about, while you can specify the "using namespace" statement, you can also be very clear in what you specify, i.e. cpplinq::such_and_such. Which most IDE's will code-complete or "Intellisense" at that point.
Coordinator
Dec 17, 2013 at 5:43 PM
Hi there.

The whole inspiration of cpplinq is to allow extensibility through >>. The reason that I find this important is that when using LINQ in C# I constantly make my own extension methods. It might seem strange but to me extensibility is more important than intellisense.

If C++ supported like C# does:
  1. partial classes
  2. Extension metods
it would be possible to allow extensions using methods and thus easier for the intellisense to work out what options you have.

One way to get intellisense somewhat is typing cpplinq:: + ctrl-space (if you are in VS, used to show intellisense alternatives, other IDE has other shortcuts). This would show all members of cpplinq namespace.

There are alternatives to cpplinq though that takes the approach OP is asking for, such as lx++ in https://rx.codeplex.com/

Mårten

PS. When you have compared the different versions of c++ linq libraries I would be interested in seeing the feature matrix regardless whether you choose cpplinq or not.
PS. If it's some help to you I listed some alternatives to cpplinq on the front page
Dec 17, 2013 at 9:41 PM
Yes - thanks Marten.

I am aware of the inspiration of your library, and trying to work out which one to go with.
Yes. I have looked at a few you refer to.

I was considering whether having my own fork and contributing my own code is a way around the otherwise lack of extensibility in other libraries, since it has become easier to do that in recent days. (with git , github/codeplex etc)

Ix++ seems like the one I would like (since it goes with Rx++), but is not yet feature complete (in terms of matching C# Linq Enumerable etc)
Also tried boolinq.
Haven't tried others.
Another one relies on boost - which would be good if it came with boost,
Coordinator
Dec 18, 2013 at 5:00 PM
There's also boost::ranges (http://www.boost.org/doc/libs/1_55_0/libs/range/doc/html/range/introduction.html) but it builds on overloading of operator | so it's shares cpplinqs strengths and weaknesses.

Mårten
May 27, 2014 at 7:03 AM
Edited May 27, 2014 at 7:07 AM
I would propose using , instead of >>. You can overload comma in, and it actually reads pretty nice:

auto result = from_array (ints),
                     where ([](int i) {return i%2 ==0;}), 
                     sum ();       

(EDIT: Okay, I give up trying to get this code formatted nicely. You get the idea)
Coordinator
May 28, 2014 at 6:19 AM
The comma operator is a possibility but I personally I prefer operator >> over comma as >> implies the motion of data through the pipe line.
auto x = from (x) >> where (...) >> select (...) >> to_array ();
data flows from x to where to select and finally into to_array.

In PowerShell and Linux shells | is used as the piping operator. IMO if cpplinq wouldn't use >> it probably would have settled on |.
auto x = from (x) | where (...) | select (...) | to_array ();
As far as I can tell the main benefit of comma operator is that it looks a bit like '.' and has the lowest precedence but that IMHO isn't enough to motivate breaking changes to cpplinq

Mårten
May 28, 2014 at 8:05 AM
IMO comma is in some ways better than period because it reads like normal prose. Like if you were to write down a "comprehension" to another human in pseudo code you'd probably use a comma because that's how English works. Probably the best case for overloading comma I've ever seen.

Doesn't have to be a breaking change. You could have both (or a user could add it separately), where comma just calls >> in a generic way (C++ 11 type traits help do this without boiler plate)..