| --- Log opened Wed Dec 23 00:00:30 2009 |
| 00:53 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 01:15 | | AgentIchiro [Smith@Nightstar-e2478917.cable.rogers.com] has joined #code |
| 01:15 | | AgentIchiro [Smith@Nightstar-e2478917.cable.rogers.com] has quit [[NS] Quit: Leaving] |
| 02:50 | | Vornicus-Latens is now known as Vornicus |
| 02:53 | | Vornicus is now known as Phas |
| 04:00 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 04:12 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: *hums* Can't stay now!] |
| 05:08 | | * ToxicFrog has an epiphany: he doesn't actually need seperate classes for viewing, he just needs modules that add :draw methods to the model. |
| 06:11 | | SmithKurosaki [Smith@Nightstar-f933638e.dsl.teksavvy.com] has left #code ["Leaving"] |
| 06:11 | | SmithKurosaki [Smith@Nightstar-f933638e.dsl.teksavvy.com] has joined #code |
| 06:11 | < SmithKurosaki> | TF: Working on vstruct |
| 06:11 | < SmithKurosaki> | ? |
| 06:12 | <@ToxicFrog> | map, actually. |
| 06:12 | <@ToxicFrog> | Which I don't have a good name for yet. |
| 06:13 | < SmithKurosaki> | The one for La Mulana? |
| 06:21 | | Tarinaky [Tarinaky@Nightstar-f349ca6d.plus.com] has joined #code |
| 06:36 | <@Phas> | I think this is for ss1, actually |
| 06:43 | <@ToxicFrog> | Nope, it's for la-mulana. |
| 06:43 | <@ToxicFrog> | The ss1 map generator depends on the res library, which I can only now start work on with the completion of vstruct 1.1 |
| 06:44 | <@ToxicFrog> | this however is a utility that will permit me to draw my own annotated maps and bring my army of robots to bear upon the puzzles of la-mulana |
| 07:15 | | Tarinaky [Tarinaky@Nightstar-f349ca6d.plus.com] has quit [Connection closed] |
| 07:17 | | Phas is now known as Vornicus-Latens |
| 08:50 | | Tarinaky [Tarinaky@Nightstar-f349ca6d.plus.com] has joined #code |
| 09:07 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has quit [Client exited] |
| 09:18 | | You're now known as TheWatcher |
| 09:24 | | Attilla [The.Attilla@FBC920.173C5E.100391.58795F] has joined #code |
| 09:24 | | mode/#code [+o Attilla] by Reiver |
| 09:55 | | Attilla [The.Attilla@FBC920.173C5E.100391.58795F] has quit [Ping timeout: 121 seconds] |
| 09:56 | | Attilla [The.Attilla@FBC920.173C5E.100391.58795F] has joined #code |
| 09:56 | | mode/#code [+o Attilla] by Reiver |
| 10:15 | | AnnoDomini [annodomini@Nightstar-86df5d63.adsl.tpnet.pl] has joined #code |
| 10:15 | | mode/#code [+o AnnoDomini] by Reiver |
| 10:44 | | Attilla [The.Attilla@FBC920.173C5E.100391.58795F] has quit [Connection reset by peer] |
| 10:44 | | Attilla_ [The.Attilla@FBC920.173C5E.100391.58795F] has joined #code |
| 10:45 | | Attilla_ is now known as Attilla |
| 11:03 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Client closed the connection] |
| 13:17 | | MyCatSchemes [mycatverbs@Nightstar-3b2c2db2.bethere.co.uk] has joined #code |
| 13:22 | | MyCatSchemes [mycatverbs@Nightstar-3b2c2db2.bethere.co.uk] has quit [Ping timeout: 121 seconds] |
| 14:17 | | ASCII [none@Nightstar-a7d2ccfd.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 14:32 | | MyCatSchemes [mycatverbs@Nightstar-3b2c2db2.bethere.co.uk] has joined #code |
| 14:39 | | MyCatSchemes [mycatverbs@Nightstar-3b2c2db2.bethere.co.uk] has quit [Ping timeout: 121 seconds] |
| 14:54 | | MyCatSchemes [mycatverbs@Nightstar-3b2c2db2.bethere.co.uk] has joined #code |
| 15:12 | | Tarinaky [Tarinaky@Nightstar-f349ca6d.plus.com] has quit [Connection closed] |
| 15:22 | | * TheWatcher stabs javascript frameworks |
| 15:23 | <@TheWatcher> | Hell, *stabs HTML DOM* while I'm at it |
| 15:40 | <@TheWatcher> | Aha, fixed you, you wee bastard |
| 16:03 | | AbuDhabi [annodomini@Nightstar-250ff829.adsl.tpnet.pl] has joined #code |
| 16:05 | | AnnoDomini [annodomini@Nightstar-86df5d63.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 16:39 | <@simon`> | in java, inherited classes don't inherit constructors, right? |
| 17:45 | < SmithKurosaki> | simon`: As far as I know, the subclasses inherit the constructor |
| 17:47 | <@simon`> | apparently, they don't. if no constructors are specified, a dummy one is created that looks like: public Foo() { super(); } |
| 18:30 | | MyCatSchemes [mycatverbs@Nightstar-3b2c2db2.bethere.co.uk] has quit [[NS] Quit: Leaving] |
| 19:06 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has joined #code |
| 19:07 | <@jerith> | There are some Very Good Reasons for that, having to do with type safety and stuff. |
| 19:07 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 19:07 | <@simon`> | alright. |
| 19:12 | <@jerith> | (I'm very cynical about such things, though, because reflection lets you bypass all the safeties if you don't mind the ugliness.) |
| 19:53 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: *hums* Can't stay now!] |
| 20:09 | <@McMartin> | jerith: I don't believe those apply to Constructors. |
| 20:10 | <@McMartin> | You can, however, get around it, sort of, by calling virtual functions as arguments to the super(...) call. |
| 20:10 | <@McMartin> | You will probably end up accessing uninitialized arguments. |
| 20:10 | <@McMartin> | The JVM pre-initializes everything to sensible NULL values as a defensive measure. |
| 20:10 | <@jerith> | McMartin: What doesn't apply to constructors? |
| 20:11 | <@jerith> | In a fit of pique a few months ago, I read up all about this stuff to figure out exactly why it wasn't letting me do what I wanted. I've forgotten all the detail now, though. :-/ |
| 20:12 | < NamegSecondary> | Java's type safety work is all kinda hilarious once you consider how its containers work. |
| 20:12 | | NamegSecondary is now known as Namegduf |
| 20:13 | <@McMartin> | You can't defeat the type safety that Java provides via reflection on constructors, because breaking memory via constructors is intercepted at the sub-instruction level at the JVM. |
| 20:13 | <@jerith> | Oh, right. |
| 20:14 | < Namegduf> | I'm really amazed that "this" appears to be of the ending type, not the type in that constructor, while it's being constructed. |
| 20:14 | < Namegduf> | (In Java) |
| 20:15 | <@jerith> | I ended up making empty objects that had to be initialised after creation. |
| 20:16 | <@McMartin> | Namegduf: Its containers don't break type safety, but it does rely on RTTI. |
| 20:16 | <@McMartin> | Still, you can't do the things like in C++ where you cast an object to void** and then overwrite its vtable pointer. Intentionally. |
| 20:16 | <@McMartin> | To turn it into a different class with the same object layout. |
| 20:16 | <@McMartin> | Yes, I've not only seen this done, I've had people recommend it as a serious development technique. |
| 20:17 | < Namegduf> | Wow. |
| 20:17 | < Namegduf> | I was going to comment that if you really want to crash it on purpose you can do it in both. |
| 20:17 | < Namegduf> | And Object Oriented crap will always win for how badly wrong you can do anything. |
| 20:19 | < Namegduf> | Java doesn't suffer from it quite so bad as C++, but you can still do horrible wrong things in it. |
| 20:20 | <@McMartin> | Outside of a tiny handful of applications, C++ is almost always the worst of all possible worlds. |
| 20:20 | < Namegduf> | C++ is quite fine. |
| 20:20 | <@McMartin> | My favorite C++ fact is that casting a pointer can change its value. |
| 20:20 | < Namegduf> | Quite. |
| 20:20 | < Namegduf> | Did you know that casting integers can change their representation, too? |
| 20:21 | <@McMartin> | Not when it's to an integer of the same size. |
| 20:21 | < Namegduf> | If it's an integer of the same size, it's changing signness or having no change at all |
| 20:21 | < Namegduf> | In the former, it will |
| 20:21 | < Namegduf> | In the latter, it won't, but that's because it's a noop |
| 20:22 | <@Vornicus-Latens> | well if you cast a negative integer to unsigned you're asking for trouble anyway. |
| 20:22 | < Namegduf> | Yes, but even positive integers (can) change representation. |
| 20:22 | <@McMartin> | However, if you take the resulting signed and cast it back, or if you do an == check, it will be representation preserving. |
| 20:22 | <@McMartin> | Maybe not value preserving at time of use |
| 20:23 | < Namegduf> | McMartin: I believe the same applies with classes. |
| 20:23 | <@McMartin> | Pointer casts are value preserving but not representation preserving. |
| 20:23 | < Namegduf> | And why would anyone care? |
| 20:23 | < Namegduf> | Basically everything at that level of operation is "implementation defined" |
| 20:23 | < Namegduf> | And illegal to touch |
| 20:23 | < Namegduf> | It makes perfect technical sense for actually implementing things |
| 20:23 | <@McMartin> | It means that you cannot implement object identity via intptr_t. |
| 20:24 | < Namegduf> | ...you mean it means you can't cast to and from a completely unrelated pointer type (potentially illegal, I believe) and have things stay unbroken? |
| 20:25 | < Namegduf> | My questions are mostly "Why the hell would I want to?" |
| 20:25 | <@McMartin> | No, I mean that you can't cast to and from a *legal* pointer type to static_cast<> to and still have == work. |
| 20:25 | <@McMartin> | I mean that if you inherit from A and B, then one of "(A*) this == this" and "(B*) this == this" will be false. |
| 20:25 | < Namegduf> | That sentence was missing some words |
| 20:25 | <@McMartin> | *at least one of |
| 20:26 | < Namegduf> | Oh, yes, it will. |
| 20:26 | < Namegduf> | I'm surprised it allows comparison of pointers between different classes. |
| 20:26 | < Namegduf> | (For equality) |
| 20:26 | <@McMartin> | That's a pretty fundamental operation if you allow pointer arithmetic of any kind |
| 20:27 | <@McMartin> | And arguably even if you don't, since eq has been a core primitive in LISP for 50 years. |
| 20:27 | < Namegduf> | Yes, and == has been one in C++ |
| 20:27 | < Namegduf> | Since... C++ existed. |
| 20:27 | < Namegduf> | That doesn't say much. |
| 20:27 | < Namegduf> | And I don't think you *are* allowed to use pointer arithmetic to tinker with object representation |
| 20:28 | <@McMartin> | Yeah, except you have to if you have an array of them. |
| 20:28 | < Namegduf> | Which is... the only thing I can see that relating to. |
| 20:28 | < Namegduf> | I don't see how that would require your example, though. |
| 20:28 | <@McMartin> | Basically, you still have to write your own version of Java's System.identityHashCode(). You can't just take what you think is an address. |
| 20:29 | <@McMartin> | Because you're not guaranteed to keep getting the same one. |
| 20:29 | < Namegduf> | Er, what? |
| 20:29 | < Namegduf> | You'll always get the same address for the same pointer type of the same object. |
| 20:29 | <@McMartin> | Yes, but that's rarely what you want in a collection of generic objects. |
| 20:30 | < Namegduf> | So you'll need to clarify what you mean by "keep getting" |
| 20:30 | <@McMartin> | Different points in the code, possibly thinking the pointer is a different (but castable-to) type |
| 20:30 | <@McMartin> | You need a virtual function to get its pointer-hash, because the pointer itself won't stay stable through casts. |
| 20:30 | < Namegduf> | Nope, but I don't see why it needs to. |
| 20:30 | <@McMartin> | Helps for implementing a lot of generic template methods. |
| 20:31 | <@McMartin> | I first ran into it for a Singleton mixin. |
| 20:31 | < Namegduf> | You could use templates. |
| 20:31 | < Namegduf> | It's kinda what they're there for. |
| 20:31 | <@McMartin> | Yeah, there's an idiom for it. |
| 20:31 | < Namegduf> | They're also a lot more... sensible than that, and that's saying something. |
| 20:31 | <@McMartin> | You cast to the template mixin, and subtract that from this. |
| 20:31 | <@McMartin> | You need that offset later when doing memory management. |
| 20:32 | <@McMartin> | That fact that you're using templates for this generally is what means you have to account for this. |
| 20:32 | < Namegduf> | I'm really confused about your use case. |
| 20:32 | < Namegduf> | It doesn't sound impossible to account for, given you know it's not guaranteed by the language. |
| 20:33 | <@McMartin> | "Implementing a library for other people to use so that it works no matter how they use multiple inheritance." |
| 20:33 | <@McMartin> | I don't have the actual code in front of me; it's in a book in my closet at home. |
| 20:33 | <@McMartin> | But at least one implementation of Singleton needs this in order to actually return valid pointers, as part of its template code. |
| 20:33 | < Namegduf> | Then it's invalid code? |
| 20:34 | < Namegduf> | And whoever wrote it should be sent to the C++ FAQ until they can actually write C++? |
| 20:34 | <@McMartin> | No, the code was perfectly valid. |
| 20:34 | <@McMartin> | I remember working through it. |
| 20:34 | < Namegduf> | Because the language straightforwardly says it's not guaranteed and in fact is explicitly not true in basically all implementations, assuming that casting pointers doesn't change the value is unsafe. |
| 20:35 | <@McMartin> | The worst direct sin it committed was casting a constant to a pointer for use in computing a ptr_diff_t, and this is explicitly permitted by the language as something that is unspecified by useful. |
| 20:35 | <@McMartin> | It *doesn't* assume that. |
| 20:35 | < Namegduf> | Okay. |
| 20:35 | <@McMartin> | It *explicitly compensates for that* |
| 20:35 | <@McMartin> | I am complaining about the fact that *you need to explicitly compensate for this ever*. |
| 20:35 | < Namegduf> | Then I suggest Python, or possibly Visual Basic. |
| 20:35 | <@McMartin> | I thought you were asking "when would need to compensate for this?", and the answer is "when doing mixing templates involving multiple inheritance" |
| 20:35 | < Namegduf> | C++ exposes implementation detail where necessary in the guarantees it makes in order to support a decent speed of operation. |
| 20:36 | <@McMartin> | "Then I suggest C". |
| 20:36 | < Namegduf> | ...I'm actually not sure how a language could allow pointer arithmetic and multiple inheritance and NOT be implemented that way. |
| 20:36 | < Namegduf> | I'm sure it'd be quite slow. |
| 20:37 | <@McMartin> | My preferred solution is to not actually permit multiple inheritance, using C++'s incredibly complicated "and now we'll try to do it six different ways all at once" as proof that there is no actual scheme that gets it right. |
| 20:37 | < Namegduf> | It'd have to, instead of adjusting pointer values, compensate at *every time a pointer was dereferenced* using RTTI |
| 20:37 | < Namegduf> | Or something similar, I think. |
| 20:37 | <@McMartin> | In other words, it would have to act like every other Object-Oriented language in the world except Java and C#, both of which are its children, yes. |
| 20:37 | < Namegduf> | Yeah, it'd have to be slow. |
| 20:38 | <@McMartin> | Objective-C is not particularly slow, tbh. |
| 20:38 | < Namegduf> | What I'm saying is that if you're criticising C *or* C++ for restricting the guarantees they offer based on what's efficient to do, you're probably using the wrong language |
| 20:38 | | * Vornicus-Latens dislikes obj-c because it feels like two or three languages glommed together. |
| 20:38 | < Namegduf> | That's basically what they do |
| 20:39 | <@McMartin> | I'm claiming that C++ cared in this case more about being able to express everything, and in so doing reduced itself to babbling incoherence. |
| 20:39 | < Namegduf> | I'd hardly call it babbling incoherence. |
| 20:39 | <@McMartin> | Compared to C? |
| 20:39 | < Namegduf> | *in this case* |
| 20:39 | <@McMartin> | Oh, there's a reason for it, yes. |
| 20:39 | <@McMartin> | There's a reason for virtual vs. nonvirtual inheritance too. |
| 20:39 | < Namegduf> | This specific lack of a guarantee doesn't matter except in really weirdass fringe corners of the language, and isn't really hard to note. |
| 20:39 | <@McMartin> | That doesn't mean it isn't hideously ugly. |
| 20:40 | < Namegduf> | These are all the same kinda reasons why I've heard people say C is ugly. |
| 20:40 | < Namegduf> | "There's a reason why you can't resize char arrays. This doesn't mean it isn't hideously annoying." |
| 20:40 | <@McMartin> | You aren't remotely listening to me here. |
| 20:40 | < Namegduf> | I am, I'm just seeing you complaining about things done based on what's efficient to actually implement |
| 20:40 | <@McMartin> | virtual vs. nonvirtual inheritance isn'ta bout efficiency. |
| 20:40 | <@McMartin> | It's about correctness. |
| 20:41 | < Namegduf> | I thought it was about nonvirtual being cheaper due to lack of a vtable. |
| 20:41 | <@McMartin> | No |
| 20:41 | <@McMartin> | This is "what happens when C inherits from B and C, but B and C both inherit from A" |
| 20:41 | < Namegduf> | But... virtual and non-virtual doesn't (as a matter of basic definition) relate to multiple inheritance. |
| 20:41 | <@McMartin> | And it has to do with whether or not B's private methods can modify protected data that C's private methods can see. |
| 20:41 | <@McMartin> | Yes it does |
| 20:42 | < Namegduf> | I mean, there's obviously the interaction of the two features |
| 20:42 | <@McMartin> | No, I mean, the "virtual" keyword is overloaded. |
| 20:42 | <@McMartin> | This is using it up in the class def a la "class a : public virtual B {" |
| 20:42 | < Namegduf> | Ah. |
| 20:43 | <@McMartin> | And I'm not complaining about the use of the word, but the problem it solves. |
| 20:43 | <@McMartin> | Which more or less is a demonstration of why "multiple inheritance" is actually a poorly-posed problem to begin with. |
| 20:43 | < Namegduf> | Pretty much, yes |
| 20:43 | < Namegduf> | I hate objects and I especially hate inheritance |
| 20:43 | < Namegduf> | So I would agree. |
| 20:43 | <@McMartin> | Then why are you defending C++~ |
| 20:44 | <@McMartin> | Especially when I'm not attacking it on efficiency grounds |
| 20:44 | < Namegduf> | Because it's a perfectly good implementation of them, and I *like* the fact that it doesn't slow itself down by orders of magnitude just to hide me from some damn pointers changing value |
| 20:44 | < Namegduf> | When I have to use it. |
| 20:44 | <@McMartin> | You know full well that's not actually where the cost is coming in. |
| 20:45 | < Namegduf> | It pretty much would, given the overhead it'd have to apply to every function call into the class. |
| 20:45 | < Namegduf> | Not orders of magnitude, but it'd be significant. |
| 20:46 | <@McMartin> | One extra arithmetic operation and one extra pointer lookup, basically, and you're already trashing your instruction pipeline with the indirect jump. That latter should be dominating. |
| 20:47 | < Namegduf> | I hope the second one isn't true, because the second one is a memory access |
| 20:47 | <@McMartin> | (Assuming a sensible hash function implementation here) |
| 20:47 | < Namegduf> | And memory access is slowass |
| 20:47 | < Namegduf> | I don't know how it compares to breaking the pipeline, exactly, but it's overhead. |
| 20:47 | <@McMartin> | So is a vtable call. |
| 20:47 | < Namegduf> | Yeah, it is. |
| 20:48 | <@McMartin> | Basically, you use a hash function on the method ID instead of an array offset. |
| 20:48 | <@McMartin> | It doesn't even have to be a good hash function because you get to pick the values. |
| 20:49 | < Namegduf> | vtables are overhead, yeah. |
| 20:51 | <@McMartin> | And if you aren't using vtables, you may as well be using C because nonvirtual functions are really just regular functions with hidden arguments. |
| 20:51 | < Namegduf> | Yep. |
| 20:51 | < Namegduf> | This just adds another layer rather than merging into, thuogh. |
| 20:51 | <@McMartin> | C++ is only actually useful when you need C's speed but for some reason also need the OO ontology, and this is more or less "GUI code and nothing else". |
| 20:52 | < Namegduf> | Abstraction is a useful tool. |
| 20:52 | <@McMartin> | Everything else needs runtime support that C++ philosophically refuses to grant in order to do right, though you can occasionally get template abuse to poorly simulate them. |
| 20:52 | <@McMartin> | A lot of that template abuse is now part of the standard and quasi-standard libraries. |
| 20:52 | < Namegduf> | No, everything else works fine, it just has to work with the limited guarantees given in order to have minimal (but still present) overhead. |
| 20:53 | < Namegduf> | You said yourself they were able to explicitly handle it and move on. |
| 20:53 | <@McMartin> | In the name of no overhead, there is no pervasive RTTI. In the name of no overhead, it is fundamentally impossible to do proper garbage collection even if you want to. In the name of no overhead, exceptions cannot be implemented efficiently. |
| 20:54 | < Namegduf> | C++ is pretty decent at not forcing a programming style, I think it's fair to let them have "You shouldn't be throwing exceptions in normal operation." |
| 20:54 | <@McMartin> | Even entering try blocks is pretty significant. |
| 20:54 | < Namegduf> | Hmm, that's ow. |
| 20:55 | <@McMartin> | Once you start using all of Boost and the STL, your throughput (though not your total running time) ends up dropping to around Java's. |
| 20:55 | <@McMartin> | With a couple of exceptions where C++ and Java both will beat "idiomatic" C. |
| 20:56 | <@McMartin> | Like those nonresizable char arrays. Java and C++ drop contiguity requirements on strings and can do a lot of string processing much faster than C can. |
| 20:56 | < Namegduf> | That's because "all of Boost" is crap and STL, well, yeah, STL is slow as hell unless used very carefully, because it's designed to provide the ease that languages higher level typically do. |
| 20:57 | < Namegduf> | So it has the "will do anything, even slow things, and it's all okay because we waste RAM to let you do it in constant time on average. |
| 20:57 | <@McMartin> | Exceptions are also a weird case (and on non-x86 machines, C's direct version of them are slower than C++'s!) because really doing them right demands designing not only the language but the ABI around them. |
| 20:57 | <@McMartin> | I've seen implementations where throw/catch was two instructions. |
| 20:57 | | You're now known as TheWatcher[afk] |
| 20:57 | < Namegduf> | I hate exceptions, so... yeah. |
| 20:58 | <@McMartin> | But you can't do that with the normal ABI because this obviously trashes your registers. |
| 20:58 | < Namegduf> | Right. |
| 20:58 | < Namegduf> | Well, actually, I kinda like Java's checked exceptions. |
| 20:58 | < Namegduf> | They seem halfway sane and designed to be actually maintainable. |
| 20:59 | <@McMartin> | I'd prefer it if it could do "throws inference" for you, though for all I know Eclipse does that for you now. |
| 20:59 | < Namegduf> | As opposed to unchecked exceptions, which seem to be designed so that everyone has to very carefully memorise everything everything in their program can throw, so they know what everything above it throws, so they know what everything above that throws... |
| 20:59 | <@McMartin> | It's more that there are too many of them. |
| 20:59 | < Namegduf> | ...or so that people just catch exception superclasses at higher levels and make no real effort to prroperly do error handling. |
| 20:59 | <@McMartin> | It doesn't offend me that OutOfMemoryError is unchecked, for instance. |
| 21:00 | < Namegduf> | It would offend me if I actually expected to check and handle it. |
| 21:00 | <@McMartin> | The Error tree you basically can't, except for logging. |
| 21:00 | < Namegduf> | Because then it's an invisible, must-be-manually-documented thing that has to be tracked. |
| 21:01 | <@McMartin> | (Which is the one place where the 'catch the superclass' thing comes in.) |
| 21:01 | < Namegduf> | I'm not a big fan of exceptions anyway bcause they're pretty useless except where things are abortable (that is, you can handle "something" going wrong in there) and there are better constructs people could make to handle that. |
| 21:01 | <@McMartin> | The usual alternative has been error codes, which have historically not ended well. |
| 21:02 | <@McMartin> | I'm aware that your position on this is that it means every programmer in the world needs to man up. |
| 21:02 | < Namegduf> | Not really. |
| 21:02 | < Namegduf> | I'm kinda happy with checked exceptions. |
| 21:02 | <@McMartin> | I'd trade them for reasonably usable multiple return values. |
| 21:02 | < Namegduf> | Oh, yeah. |
| 21:02 | <@McMartin> | Except for the languages where it's a two-instruction op |
| 21:03 | < Namegduf> | Lack of multiple return values is why it's bad in C/C++ |
| 21:03 | < Namegduf> | To use error codes, I mean. |
| 21:03 | < Namegduf> | Java's error type is sort of fine, I think, I just wish there was a way for a program/part of one to say "I want to handle this, make it checked" |
| 21:03 | <@McMartin> | C++'s need for destructor stack unwinding will always make it "worse" there, but, again, needed for correctness, and it's one of the things that C++ lets you use as a core part of the design. |
| 21:04 | < Namegduf> | So unchecked errors were ones which you never ever had any interest in handling except as a "SOMETHING happened, log it generically, possibly restart whatever died/move on and ignore anyway." |
| 21:05 | <@McMartin> | Yeah. Making Error a subclass of Throwable and exposed was a mistake. |
| 21:05 | <@McMartin> | Hrm. I have two hours to finish packing. I'll have to pick this up again tonight. |
| 21:05 | < Namegduf> | Okay. |
| 21:06 | < Namegduf> | I might go to sleep soonish, perhaps after a meal or I finish wrapping stuff. Tomorrow is going to be a lot of delivering. |
| 22:01 | | You're now known as TheWatcher |
| 22:41 | | Alek [omegaboot@Nightstar-940c10c3.emhril.sbcglobal.net] has quit [Ping timeout: 121 seconds] |
| 22:45 | | Alek [omegaboot@Nightstar-454bb9c3.emhril.sbcglobal.net] has joined #code |
| 23:18 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 23:25 | <@Vornicus-Latens> | I really hate error codes. |
| 23:29 | <@Vornicus-Latens> | Every way I've seen them done, they get in the way: in C you have to either check an external thing (usually imported in yet another library) or pass a pointer for the function to place the error code or pass a pointer for the function to place /the actual result/; in langauges with multireturn you have to split out the error code from the other returned data. |
| 23:31 | < Namegduf> | No, in languages with multireturn, it comes split out out. |
| 23:31 | < Namegduf> | Which is... a good thing? |
| 23:31 | < Namegduf> | Do you really want it merged in? |
| 23:32 | | You're now known as TheWatcher[T-2] |
| 23:39 | | You're now known as TheWatcher[zZzZ] |
| 23:39 | <@Vornicus-Latens> | 'course I also hate exceptions. |
| 23:44 | <@simon`> | hating is easy! |
| 23:44 | < Namegduf> | I hate hate. |
| 23:46 | <@Vornicus-Latens> | Actually my main issue is really I don't like the way error-handling looks in text at all. |
| 23:50 | < AbuDhabi> | I just had a thought that I should write my own variant of a Civ/Col game. Given that my experience is limited to things like Snake, that doesn't seem too easy. |
| 23:51 | < Namegduf> | They're totally the same kind of game |
| 23:51 | < Namegduf> | Get in there and start coding |
| 23:51 | < Namegduf> | XD |
| 23:53 | <@simon`> | are any of you going to 26C3? |
| 23:53 | <@simon`> | (the 26th Chaos Communication Conference) |
| --- Log closed Thu Dec 24 00:00:31 2009 |