 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> Warp wrote:
> > The benefit is that, at least in theory, the member function can be
> > dynamically bound, while the regular function can't.
> But not on an object that only occupies four bytes, which is your usual
> example. :-)
Ok, if it takes 8 bytes, then it could have virtual functions. ;)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
> In other words, you simply can write the same thing with a slightly
> different syntax, but otherwise there's no difference. I really fail
> to see the usefulness of this.
You're terribly correct, there is no use to this at all. After all, the
following are all identical:
VectorAdd(v1, v2, &v3);
v3 = VectorAdd(v1,v2);
v3 = v1+v2;
Since there's no difference between them, the second two should just be
taken out completely, don't you think?
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> But yeah, it's syntax sugar, like overloading operators is.
And if anyone cares, here's a fairly complex query written in LINQ, in C#
with extension methods, and in C# without extension methods.
http://www.interact-sw.co.uk/iangblog/2005/09/30/expressiontrees
about 3/4ths the way down, after the text "A little further into the demo"
Pretty cool. Especially since there's an Expression.Compile() instance
method that will generate actual CIL code for a parse tree you created at
runtime. (A la http://www.jot.fm/issues/issue_2008_03/column4.pdf ). But
AFAIK, once you've created CIL code, you can't unload it, at least not
without dumping the whole assembly context, so it winds up being a sort of
resource leak if you do this dynamically too much. I've seen libraries to
manage this, tho, starting with multiple assemblies and dumping them when
they get full, restarting with new ones. Seems kind of kludgey.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> > -----Original Message-----
> > From: Warp [mailto:war### [at] tagpovrayorg]
> > In other words, you simply can write the same thing with a slightly
> > different syntax, but otherwise there's no difference. I really fail
> > to see the usefulness of this.
> You're terribly correct, there is no use to this at all. After all, the
> following are all identical:
> VectorAdd(v1, v2, &v3);
> v3 = VectorAdd(v1,v2);
> v3 = v1+v2;
> Since there's no difference between them, the second two should just be
> taken out completely, don't you think?
Ah, so this extension can be used for operator overloading in C#?
Nobody told me that before.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Ah, so this extension can be used for operator overloading in C#?
> Nobody told me that before.
Operator overloading has existed since C# 1.0
I think the poster was trying to demonstrate a syntatic sugar feature
you may be familiar with and might like.
Rather than using, for example:
GraphicsExtensions.DrawButton(g, rcArea, caption);
You could define it so you simply type
g.DrawButton(rcArea, caption);
It just simplifies things a bit.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Warp wrote:
> > Ah, so this extension can be used for operator overloading in C#?
> > Nobody told me that before.
> Operator overloading has existed since C# 1.0
I was being sarcastic.
> I think the poster was trying to demonstrate a syntatic sugar feature
> you may be familiar with and might like.
And the demonstration was invalid.
We are talking about "object.function()" vs. "function(object)", not
about "a+b+c" vs. "add(a, add(b, c))".
> Rather than using, for example:
> GraphicsExtensions.DrawButton(g, rcArea, caption);
> You could define it so you simply type
> g.DrawButton(rcArea, caption);
I see no relevant difference to making a function so that you can write
"DrawButton(g, rcArea, caption)".
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> I see no relevant difference to making a function so that you can write
> "DrawButton(g, rcArea, caption)".
>
Except that in C# everything is defined in a class. So, if the function
is part of a library, you'd have to either define static methods or
instance methods. The Graphics class is sealed, so there's no means of
defining a sub class, such as GraphicEx ...so your choices are define a
bunch of static methods, or define a class whose constructor takes a
pointer to a Graphics object, and offers the extended functions.
C# 3.0 offers the extension methods to get around this. It may seem like
a pointless feature to you, but for some it is a minor convenience.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
> Ah, so this extension can be used for operator overloading in C#?
> Nobody told me that before.
Actually, it can't, but that's irrelevant.
You said:
"In other words, you simply can write the same thing with a slightly
different syntax, but otherwise there's no difference. I really fail to
see the usefulness of this."
In other words, you see no usefulness in having syntactic sugar. I
think it's useful.
...Ben Chambers
www.pacificwebguy.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers wrote:
> In other words, you see no usefulness in having syntactic sugar. I
> think it's useful.
Especially when you want to chain methods together to make things work.
Writing
myCollection.Select(...).Group(...).Transform(...).Sort(...).Output()
is a lot more clear than
Sort(Group(myCollection.Select(...)).Transform(...)).Output()
just like writing
cout << 123 << endl << mystuff.xyz() << endl
is more clear than
cout.write(cout.write(123).endl(), mystuff.xyz()).endl()
or something like that.
Plus, it interacts with other syntax of the language that the compiler turns
into syntax like this. When your C++ sorting template has to know whether
the right call is myThing.compare(otherThing) or
MyUtil.compare(myThing,otherThing), it gets messy. That's exactly what this
is for, so it's pretty much just like what operator overloading is for.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> Actually, it can't, but that's irrelevant.
> You said:
> "In other words, you simply can write the same thing with a slightly
> different syntax, but otherwise there's no difference. I really fail to
> see the usefulness of this."
> In other words, you see no usefulness in having syntactic sugar. I
> think it's useful.
No. What I said was that I don't see usefulness IN THIS CASE. The
difference is practically nonexistent. It's only in reordering of
names.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
