Prev: Detecting pointer on the heap
Next: warning: dereferencing pointer does break strict-aliasing rules
From: Kumar Anurag on 2 Apr 2010 00:58
On Apr 2, 2:54 am, Seungbeom Kim <musip...(a)bawi.org> wrote:
> On 2010-04-01 07:08, Mathias Gaunard wrote:
>
> > On Mar 31, 11:36 pm, "Thiago A."<thiago.ad...(a)gmail.com> wrote:
>
> >> For instance, we could write:
>
> >> matrix.Rotate(pi).ReflectHor().Inverse();
>
> > This works fine, but the main problem is that it is intrusive: you
> > need to have such functions declared as members of the returned types.
> > Using operator overloading, you can avoid this issue.
>
> This is a valid concern. Then how about defining one function
> that can call arbitrary operations:
>
> matrix.apply(Rotate, pi).apply(ReflectHor).apply(Inverse);
>
> > Consider matrix | Rotate(pi) | ReflectHor() | Inverse()
> > Such syntax is used by the new extension to Boost.Range.
>
> I like this syntax, too!

{ edits: quoted sig & banner removed. please keep readers in mind when you
quote. -mod }

I have read that .(dot) operator can't be overloaded. Is it false??


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Mark Zaytsev on 9 Apr 2010 06:16
On Mar 31, 6:36 pm, "Thiago A." <thiago.ad...(a)gmail.com> wrote:
> Using function notation we have expressions like that:
>
> F(G(H(X)))
>
> Where we have to read from inside to outside. It is not so bad; this
> is the normal mathematical notation.
>
> However in some cases, I would prefer to read expression from left to
> right applying the next function in the previous result.
>
> H(x) G() F()

Why not to overload 'operator ,' ?
x, H(), G(), F()


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2 3
Prev: Detecting pointer on the heap
Next: warning: dereferencing pointer does break strict-aliasing rules