 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] dev null> wrote:
> Warp wrote:
> > Isn't this usually handled with callback interfaces (in OO languages)
> > rather than function pointers?
> Speaking of which... apparently you can overload "()", thus creating an
> object that looks like a function... How far-out is that? o_O
So-called functors are a common idiom in C++ template programming.
For example many STL data containers and algorithms accept functors
as parameters.
A functor is something which acts like a function. In other words, it
can be called like a function can be called, and it will return a value
like a function returns a value.
Obviously a regular function is a valid functor (and a common way to
pass functors to the STL).
Another way of creating a functor is, as you point out, to create a
struct or class which has the operator() overloaded. This way an instance
of that class can be used exactly like it was a function.
The advantage of the latter method is that the struct/class can have
member variables (and member functions) which the operator() can use.
This way you can have different values for those member variables for
different instances of the functor. (If I'm not completely mistaken,
this starts get closer to so-called closures.)
In the next C++ standard there will be a third type of functor: Lambda
functions.
> I'm almost tempted to try just to see if I can implement curried
> functions with it in C++. You know, just to be totally perverse...
C++ might not be the best language for that... ;)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> I bet you can't overload ";", can you? In Haskell, you can. >:-D
; is not an operator in the first place.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I bet you can't overload ";", can you?
>
> ';' is not an operator. It is a statement terminator.
Yes, I know that. ;-) I was just being silly...
>> In Haskell, you can. >:-D
>
> Can you overload/redefine '->' in Haskell?
No. But then, it means something different in Haskell anyway.
> What about '()'?
No.
But then, in Haskell, a function *is* a data value, so there's not so
much need...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I bet you can't overload ";", can you? In Haskell, you can. >:-D
>
> ; is not an operator in the first place.
Yeah, I know that. ;-) I'm just teasing.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> So-called functors are a common idiom in C++ template programming.
> For example many STL data containers and algorithms accept functors
> as parameters.
>
> A functor is something which acts like a function. In other words, it
> can be called like a function can be called, and it will return a value
> like a function returns a value.
>
> Obviously a regular function is a valid functor (and a common way to
> pass functors to the STL).
I see...
> Another way of creating a functor is, as you point out, to create a
> struct or class which has the operator() overloaded. This way an instance
> of that class can be used exactly like it was a function.
>
> The advantage of the latter method is that the struct/class can have
> member variables (and member functions) which the operator() can use.
> This way you can have different values for those member variables for
> different instances of the functor. (If I'm not completely mistaken,
> this starts get closer to so-called closures.)
Yes, indeed. It looks like that means you could do something like write
a struct that contains a number, and make it into a functor that adds
that number when called. OTOH, if your function really had to be a
*function*, you'd have to write a seperate function for every value you
might want to add... which would be, uh, silly.
In Haskell, you can just say "map (*2)" and it'll work. It looks like
what you're describing enables you to achieve something very similar in C++.
(Presumably the *other* thing about a C++ functor is that it could
change some internal state each time you call it - say, to generate
unique IDs or something...?)
> In the next C++ standard there will be a third type of functor: Lambda
> functions.
Knowing what I now know about C++ (constructors, copy constructors,
assignment constructors, pointers, references, etc.), I suspect this is
going to be... uh... "interesting". :-}
I wonder what the scoping rules would be like?
>> I'm almost tempted to try just to see if I can implement curried
>> functions with it in C++. You know, just to be totally perverse...
>
> C++ might not be the best language for that... ;)
Heh. It could probably work... but no, I'm sure it'll be pretty ugly.
;-) [Not to mention being abnormal C++ style.]
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I bet you can't overload ";", can you? In Haskell, you can. >:-D
>>
>> ; is not an operator in the first place.
>
> Yeah, I know that. ;-) I'm just teasing.
Wow, wait a sec...
http://www.research.att.com/~bs/whitespace98.pdf
WTF?! O_O
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 <voi### [at] devnull> wrote:
> Wow, wait a sec...
> http://www.research.att.com/~bs/whitespace98.pdf
> WTF?! O_O
I think that paper is a joke.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I think that paper is a joke.
I really, *really* hope you're right about that...
Especially the use of multicoloured identifiers, and the use of dingbats
as names!
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Isn't this usually handled with callback interfaces (in OO languages)
> rather than function pointers?
Only in languages that don't support pointers to member functions. In
languages with closures or pointers to member functions, no. Just like
in a language without pointers at all, the way you do callbacks is to
redefine the function at link-time and then do a big switch statement.
C#, for example, has the "observer" design pattern built into the
language as "delegates" or "events", accepting multiple pointers to
member functions and letting the owner "invoke" all the methods pointed to.
Ruby and Smalltalk and all those pass around "blocks" for this
functionality. Python passes around lambdas. LISP passes around
closures. They're all essentially the same sort of thing, with ever so
slightly different implementations, but all basically "a block of code
with a pointer to an object's context".
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Yeah, but if the Haskell runtime has code to handle printing out a
> human-readable error message on an unhandled exception, why can't it
> also run some finalisers? This is pretty basic stuff!
Yep, true. I didn't realize you meant "exited cleanly due to an
unhandled exception." I thought you meant "crashed out due to a signal,
or running out of memory, or some such."
I suppose you could theoretically do a final GC and finalize before you
exited (but perhaps before you printed the exception stack?), but I
think at that point you're already pretty screwed. :-)
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
