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

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...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> >   Unless I'm completely mistaken, this is not something you can achieve
> > in Java. (In Java you have to close files explicitly and catch all
> > possible exceptions which might otherwise bypass that closing.)

> The destructor will close the file when the GC collects the object, but 
> that might be several seconds later.

  I don't know how it is today, but at least in the past the amount of
file handles one single program could keep open at the same time was
ridiculously limited (IIRC to a few dozens or so). If the program tried
to open more than that, it would fail.

  If a program is constantly opening files, doing something to them, and
then closing them, a file handle leak (which would happen if it fails to
close them for some reason, eg. because of a bug or a suprising exception)
can cause the program to malfunction. And this might not be caught on
testing, if the testing fails to stress the program in the same way as
it happens in actual usage...

  OTOH, I could imagine that if Java detects that a file cannot be opened
because of too many file handles being open, it could automatically try
to run the GC and then try again.

  OTOH, file handles are just *one* possible resource which can leak.
Java can't be prepared for all of them.

> And it might not run if you exit 
> the program before the GC runs, but that's true of C++ also.

  It's true of C++ only if your stream has been allocated dynamically
(directly or indirectly). If it's stack-allocated then there's no way
its destructor won't be called.

  (Ok, there is a way: If you call abort() the program is immediately
terminated without any stack unwinding, in which case no destructors
are called at all. However, abort() is such a harsh way of terminating
the program that it shouldn't happen in normal code.
  Incidentally a failed assert() calls abort(), which is the reason why
assert() should only be used to catch programming errors, not to exit
the program normally.)

-- 
                                                          - Warp

Post a reply to this message

On Fri, 26 Sep 2008 19:44:56 +0200, Orchid XP v8 <voi### [at] devnull> wrote:
>
> I bet you can't overload ";", can you?

';' is not an operator. It is a statement terminator. It would make no  
sense for a C++ program to redefine the meaning of ';'.


> In Haskell, you can. >:-D

Can you overload/redefine '->' in Haskell? What about '()'?



-- 
FE

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> 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