![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> I don't know how it is today,
Usually a thousand or so, where such things are actually limited by
something other than the amount of memory available.
> 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...
Yep. That's exactly what was happening to me in my Tcl code. When I
could get the socket connection but it failed before it finished
flushing the first buffer, I failed to close the socket. After a couple
weeks of running, the program would bomb out with a file handle leak.
That was very annoying to debug. I probably should have just tossed that
whole function and started over.
> 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.
It could. That's what I like to recommend, but oddly few language
designers listen to me. >8)
> OTOH, file handles are just *one* possible resource which can leak.
> Java can't be prepared for all of them.
Well, it knows when something fails due to a lack of resources. It's
even not unreasonable that (for example) opening a file could fail from
lack of memory to put the stdio buffer in, or something, in which case a
GC and a retry could correct it.
>> 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.
Yeah. And a sufficiently smart compiler for Java or whatever could do
escape analysis, see that the stream isn't used outside the function,
and stack allocate it and explicitly clean it up afterwards. Not that
compilers quite do that yet.
> (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.
That's what I was talking about, yes. I thought Andrew was referring to
exiting Haskell with a core dump, basically, rather than simply an
exception caught at the top level.
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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. :-)
Basically, all you have to do is write a Haskell program that calls the
"error" function somewhere, and your program will exit without closing
anything behind it. Unless *you* remembered to take steps to prevent that.
That seems... a little unsafe to me.
Still, at least the code to do it isn't that hard.
bracket
(openFile "Foo.txt" ReadMode)
(hClose)
(\file_handle -> ...do stuff...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> Warp wrote:
>
>> I think that paper is a joke.
>
> I really, *really* hope you're right about that...
""
Because this project relies of the ability
to fool the brain into accepting a projected image as 3D and because we
don't take delivery of the 3D
projection device until next spring, this project is usually referred to
as "Project April Fool."
""
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> 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.
C++ supports pointers to member functions, yet using callback interfaces
is a rather common idiom.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> ""
> Because this project relies of the ability
> to fool the brain into accepting a projected image as 3D and because we
> don't take delivery of the 3D
> projection device until next spring, this project is usually referred to
> as "Project April Fool."
> ""
Oh thank *God*!
Damn, he writes so convincingly...
[...says the guy who mistakenly took HGTTG seriously! o_O ]
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> 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.
>
> C++ supports pointers to member functions, yet using callback interfaces
> is a rather common idiom.
How do you declare a pointer to a member function, then? I thought you
had to keep a pointer to the object and then somehow invoke the proper
member function, but I don't know the syntax for that latter part?
--
Darren New / San Diego, CA, USA (PST)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I
> am *so* not trying that out!)
You can overload the comma operator!
boost::assign does some nasty stuff with it, to let you add stuff to STL
containers like this:
std::vector<int> mylist;
mylist += 1,2,3,4; // uses overloaded += and , operators
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |