|
dwazegek posted:Wouldn't compile though, you can't reference the current instance during initialization. You sure about that? In Java, at least, instance variables are initialized from top to bottom as they appear in the source.
|
# ? May 26, 2011 13:22 |
|
|
# ? May 14, 2024 21:12 |
|
Internet Janitor posted:You sure about that? In Java, at least, instance variables are initialized from top to bottom as they appear in the source. Yes, but C# is a good language.
|
# ? May 26, 2011 13:31 |
|
Broken Knees Club posted:Yes, but C# is a good language. boosh
|
# ? May 26, 2011 13:57 |
|
dwazegek posted:Wouldn't compile though, you can't reference the current instance during initialization. Looks like Terraria was written in VB then?
|
# ? May 26, 2011 15:02 |
|
Geekner posted:I could only imagine some variables refer to previous variables, and rely on the specific initialization order. Wouldn't the reflector just name those in alphabetical order since that's the way they're initialized? IE: One becomes int aInt, TWO becomes int bInt or however reflector names it's variables?
|
# ? May 26, 2011 15:28 |
|
Mustach posted:http://prog21.dadgum.com/87.html For an example like that I can see where the author's coming from, but in the case of Terraria it's a game where the coders still want to add more content patches and such. To go with the example from the article, if the author wanted to add in the ability to draw sheep, he'd just have to write a DrawSheep subroutine, but the other guy would have a lot more work ahead of him. If you know you're not expanding or maintaining your code then by all means write terrible code if it works, but if you're trying to release code to the public now that you want to keep updating, you need to make it easy to update.
|
# ? May 26, 2011 16:03 |
|
Hughlander posted:Wouldn't the reflector just name those in alphabetical order since that's the way they're initialized? IE: One becomes int aInt, TWO becomes int bInt or however reflector names it's variables? No, the names of class members, even private ones, are preserved in the MSIL, so reflector can just show them as they're named. I guess it should also be possible to see in which order they're initialized, and order them based on that, but I guess reflector never implemented that feature.
|
# ? May 26, 2011 16:04 |
|
YeOldeButchere posted:Someday I hope we'll get to crack open Dwarf Fortress and get something even worse. I imagine it will be like opening the Ark of the Covenant. I've done a fair bit of DF memory hacking and reversing. The greater difficulty of decompiling C++ of course means I didn't see nearly as much of it as people get with Minecraft or Terraria, but I never saw anything I really felt would be worthy of this thread. It's definitely not awesome code; there are some huge monolithic functions, particularly for things like generating text for displays. The code page 437 stuff is a bit weird; strings are stored in cp-437, but in all the cases I came across they were converted to cp-1252 before use; I'm not sure that it's anything more than vestigial weirdness at this point. The creature class is ridiculously huge; if I remember correctly, last I looked at it each instance took 2000 bytes of memory with something like 70-100 vectors in it. In a number of cases there were pairs or triplets of vectors rather than a single vector of a struct or class (of course, those pairs or triplets could have been part of a struct themselves). It's clearly not unmaintainably convoluted though, since substantial changes have been made to it in several releases.
|
# ? May 26, 2011 16:15 |
|
dwazegek posted:No, the names of class members, even private ones, are preserved in the MSIL, so reflector can just show them as they're named. I still don't see how this is possible. Code that initializes variables won't be reordered, it's just the declarations that are reordered - variable initialization is code, declarations are just syntax. And you can't make auto-initializers depend on other instance variables, as previously stated. I'm pretty sure that auto-initializers are just syntactic sugar that the compiler writes into the constructor anyway, so Reflector would just see the constructor code, not the fact that they're auto-initializers. It shouldn't matter where you declare the instance variables in the class file, because the C# compiler does multiple passes. I declare instance variables all the time in random places when I'm writing parts of a class that really should be their own class, and you can forward-reference fine. So I'm not sure how this feat is achieved. I don't have a copy of Terraria to decompile myself, but I'm sure that Reflector isn't giving us the full story...
|
# ? May 26, 2011 18:01 |
|
Posting a horror made by me, since it also happens to be slightly on topic. It's from my short-lived C# Minecraft library, networking API to be exact. Around that time I was experimenting with the fun parts of C#, like reflection, to see how much I could automate. Some packet definition first... code:
code:
Most importantly, it was fun as hell to write and it cut the redundant manual read/write code from packets significantly. Although I'm surprised that it worked without problems.
|
# ? May 26, 2011 18:39 |
|
Ryouga Inverse posted:I still don't see how this is possible. code:
|
# ? May 26, 2011 18:51 |
|
Well, I learned something new and horrible about C# today. ed: Pollyzoid posted:So yes, I made the declaration order matter, thanks to ordering by MetadataToken which (supposedly) guarantees the order on all computers. In addition, it uses plenty of dynamic method invocation to read and write to the stream. Actually I can't tell whether this is horrible or awesome. It kind of walks a fine line between elegance and insanity. Dessert Rose fucked around with this message at 19:25 on May 26, 2011 |
# ? May 26, 2011 19:20 |
|
It appears that field ordering in C# source is 'reflected' (heh heh heh) in the field ordering returned by reflection calls. http://dotnetpad.net/ViewPaste/pnR8rOileUWDyUHNWOHMjQ I don't know if that's coincidental or guaranteed, though.
|
# ? May 26, 2011 19:40 |
|
Ryouga Inverse posted:I'm pretty sure that auto-initializers are just syntactic sugar that the compiler writes into the constructor anyway, so Reflector would just see the constructor code, not the fact that they're auto-initializers. It's not entirely syntactic sugar. Initializers of derived types run in the reverse order that the constructors run in, so there is a difference between initializing a member in the declaration or initializing it in the constructor. Of course, if you actually write code that depends on this behavior, it's most likely also a horror. Say you have a class C that derives from B, that derives from A. If you instantiate C, then the initializers run in the order C, B, A, followed by the constructors in the order A, B, C. You're right that this is achieved by sticking all the code in the constructor though, just not in a way that reflector can translate back to C#. Class C's constructor would look like 1. C's initializers 2. Call B's Constructor 3. C's constructor code
|
# ? May 26, 2011 19:47 |
|
Smugdog Millionaire posted:It appears that field ordering in C# source is 'reflected' (heh heh heh) in the field ordering returned by reflection calls. This is what MSDN says: quote:The GetFields method does not return fields in a particular order, such as alphabetical or declaration order. Your code must not depend on the order in which fields are returned, because that order varies. However, when I was playing around with reflection, I stumbled upon this: David M Morton posted:what it does is order the fields by the MetaDataToken, so they're guaranteed to be in the same order as you wrote them into the code The guy is a moderator and an MVP on MSDN, so I trusted him on that.
|
# ? May 26, 2011 19:48 |
|
Pollyzoid posted:The guy is a moderator and an MVP on MSDN, so I trusted him on that. Does that mean 'guaranteed by the current implementation' or 'guaranteed as part of the software contract'?
|
# ? May 26, 2011 19:58 |
|
Smugdog Millionaire posted:Does that mean 'guaranteed by the current implementation' or 'guaranteed as part of the software contract'? According to MSDN, the former. Depending on an implementation detail is a bad idea.
|
# ? May 26, 2011 21:55 |
|
Not to mention that reflection is very slow, so it's not the kind of thing you'd want to be doing in your networking code.
|
# ? May 27, 2011 02:20 |
|
Scaevolus posted:Not to mention that reflection is very slow, so it's not the kind of thing you'd want to be doing in your networking code. Reflection's not as terribly slow if you cache what it was you were looking for. Still not a good idea for anything requiring low latency/overhead.
|
# ? May 27, 2011 02:40 |
|
An anonymous person sends a type-level Fizzbuzz complete with an example run.
Opinion Haver fucked around with this message at 07:57 on May 27, 2011 |
# ? May 27, 2011 07:49 |
|
PhonyMcRingRing posted:Reflection's not as terribly slow if you cache what it was you were looking for. Still not a good idea for anything requiring low latency/overhead. If performance is a problem, you can use the System.Linq.Expressions stuff to generate a bunch delegates that do the real work. The initial cost could be pretty high, but even that can be mitigated by compiling it to an assembly and saving that to disk. If you're on an older version of .NET that doesn't have Expressions, you could use System.Reflection.Emit to do the same thing, but that's a quite a bit more work.
|
# ? May 27, 2011 08:40 |
|
yaoi prophet posted:An anonymous person sends a type-level Fizzbuzz complete with an example run. Mine is better. You have to compile it with -fcontext-stack=105 for it to work. Yes, I am a monster. code:
Volte fucked around with this message at 10:52 on May 27, 2011 |
# ? May 27, 2011 10:25 |
|
code:
|
# ? May 27, 2011 17:44 |
|
course you cancode:
|
# ? May 27, 2011 18:12 |
|
FizzBuzz is very important, therefore it deserves its own language primitive: http://code.google.com/p/hq9pf/
|
# ? May 27, 2011 19:10 |
|
Found this at work a while agocode:
|
# ? May 27, 2011 21:23 |
|
http://thedailywtf.com/Comments/The-Disgruntled-Bomb.aspx?pg=2#340740pre:C#: static SomeCtor() { typeof(string).GetField("Empty").SetValue(null, " "); } //Sets string.Empty to a space character
|
# ? May 28, 2011 10:16 |
|
Anyone who actually uses string.Empty deserves it.
|
# ? May 28, 2011 11:30 |
|
Plorkyeran posted:Anyone who actually uses string.Empty deserves it. Also, this is what String.Empty looks like on the inside: public static readonly string Empty = ""; Static readonly?
|
# ? May 28, 2011 11:50 |
|
Broken Knees Club posted:Also, this is what String.Empty looks like on the inside: public static readonly string Empty = ""; Which is weird because you can't change non-static readonly members through reflection, only static ones.
|
# ? May 28, 2011 12:29 |
|
http://forums.somethingawful.com/showthread.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 php. Works on any PHP script. Zend logo: PHPE9568F35-D428-11d2-A769-00AA001ACF42 PHP credits: PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000
|
# ? May 28, 2011 13:26 |
|
What the hell is going on there? That a bizarre dark corner of PHP I haven't seen yet.
|
# ? May 28, 2011 16:05 |
|
NotShadowStar posted:What the hell is going on there? That a bizarre dark corner of PHP I haven't seen yet. http://phpsadness.com/?page=sad/11 I don't know if it's been linked here before but that entire site is full of things well worthy for the coding horrors thread. Some of them are obvious (like inconsistencies in function names/arguments) but some of them are just bizarre. I like this one: quote:E_ALL doesn't actually mean "E_ALL"; it means E_ACTUALLY_ALL & ~E_STRICT. Shouldn't it be named E_ALMOST_ALL instead? Why isn't there a real E_ALL named constant? Meat Beat Agent fucked around with this message at 16:38 on May 28, 2011 |
# ? May 28, 2011 16:35 |
|
I'm fond of "exception thrown without stack frame" myself.
|
# ? May 28, 2011 16:48 |
|
My favorite: Can point a variable into raw memory with array_walk and debug_backtrace.
|
# ? May 28, 2011 16:53 |
|
daft punk railroad posted:http://phpsadness.com/?page=sad/11 quote:Static variables in methods are bound to the class, not instances of the class.
|
# ? May 28, 2011 17:30 |
|
php programmers can't even whine about the language right, let alone use it well
|
# ? May 28, 2011 17:56 |
|
Holy poo poo they are literally using goto: in the C code of PHP http://phpsadness.com/?page=sad/36
|
# ? May 28, 2011 18:03 |
|
Using goto isn't a horror in itself. It's nice when you need to do cleanup on the way out of a function when aborting, like in that snippet.
|
# ? May 28, 2011 18:09 |
|
|
# ? May 14, 2024 21:12 |
|
That #if for the first argument's type probably has some monstrous consequences elsewhere.
|
# ? May 28, 2011 18:45 |