|
Bonus posted:Ultimate variable naming scheme Similarly, back when C# first came out, I couldn't resist the urge to use full Unicode in my identifier names. code:
On the one hand, I think having the ability to use Unicode identifiers is awesome and long overdue. On the other hand, it would permit sweet revenge and job security for those outsourced overseas programmers to write all their code in Hindi or Urdu character sets
|
# ¿ Mar 31, 2008 15:32 |
|
|
# ¿ May 6, 2024 14:40 |
|
rotor posted:We're gonna need bigger keyboards. APL was ahead of its time! It was a language without a mainstream character set large enough to hold it... but now things are different! It's ripe to make a comeback, I say!
|
# ¿ Mar 31, 2008 17:10 |
|
rotor posted:I don't understand how this is supposed to be especially awful for what is, I assume, supposed to be an in-class example or something. The horror is obviously Swing itself
|
# ¿ Apr 14, 2008 19:25 |
|
zootm posted:The great thing about the prime factorisation solution is that you can have counted flags. It's like the flag equivalent of turning your amp up to 11. I'm surprised nobody has mentioned this advantage yet. If I remember my Win32 API correctly, there's a window style called WS_EX_THICKFRAME. But it doesn't let me control the degree of thickness. code:
code:
|
# ¿ Apr 25, 2008 13:53 |
|
bcrules82 posted:[code] FUN FACT: 0xFFFFFFFFFFFFFFFFULL is a special constant in C named as such because it's the only machine word that is just chock-FFFFFFFFFFULL of set bits.
|
# ¿ Apr 26, 2008 23:16 |
|
JoeNotCharles posted:Can't speak for Java, but in C++ length() would almost certainly be simple enough to inline. That's not the whole story, though, since I don't believe inlining works when length() is in a shared library, which it probably is. (I think you can get inlining to work across library boundaries, but you have to do extra work? I dunno, I should read up on this.) string is a template, so it would never be compiled into a shared library anyway. The compiler is pretty much going to inline it all the time unless you explicitly tell it not to inline anything. Then it just becomes an issue of the following: is this, code:
code:
Anyone who would complain about this who isn't working entirely on tiny embedded micro-architectures needs to quit stroking their e-penis and focus on the problem domain instead of premature optimization. The OP said he didn't care about it, and rightly so. But drat does it piss me off when I get into a conversation with someone -- usually it was one of my "advanced" students -- who thinks they're just oh-so-clever and thinks they're smarter than a tried-and-tested professional compiler. And to stroke my e-penis a little, code like what I just wrote above pisses me off. It should be code:
|
# ¿ May 6, 2008 20:29 |
|
more falafel please posted:++i damnit! FWIW, I do use pre-increment when I'm dealing with iterators, so that I don't have to worry about the cost of a temporary copy. But for integral values, it's a wash. Speaking of, has anyone ever examined the optimized assembly code for using ++iterator vs. iterator++ in a for-loop (or anywhere for that matter)? I wonder if the compiler is smart enough to optimize post- to pre- if it sees that the result isn't used as part of a larger expression.
|
# ¿ May 6, 2008 22:15 |
|
Standish posted:I'd be surprised if it could optimize that for std::iterators, remember the STL is just another library as far as the compiler is concerned -- from the compiler's point of view, it doesn't know anything about iterator semantics and std::iterator::operator++() (the prefix overload) and std::iterator::operator++(int) (the postfix overload) are completely distinct functions which could have completely different sideeffects. Good point, it hadn't occurred to me that some rear end in a top hat could overload operator++() to do the correct thing and operator++(int) to do while(1) printf("Penus\n");. Chin Strap posted:Wait, could someone explain what iter++ is doing different than ++iter in a loop? I've never heard this before. Semantically, for(...; iter++) and for(...; ++iter) do the same thing, since the increment stands alone in the expression. The difference is in the lower-level implementation -- ++iter is more efficient since it increments the operand before evaluating the rest of the expression, if any. iter++, on the other hand, requires that a copy be made, since it increments the operand and then uses its old value in the remainder of the expression. So, in a tight loop, post-increment does O(n) unnecessary copy operations. In most cases it's not going to be that much of a penalty, but why do it if you can avoid it? Flobbster fucked around with this message at 05:25 on May 7, 2008 |
# ¿ May 7, 2008 05:18 |
|
PrBacterio posted:Well I don't necessarily know about those, but I would very much welcome being able to use the proper glyphs, i.e. ≠, ≤ and ≥, for comparisons, instead of !=, <= and >=. Sounds like you'd like Applescript! quote:(I'm also one of those people who'd prefer the Pascal-style syntax of = as the comparison operator with := being used for assignments, instead of the C-style == for a comparison operator...) The one true assignment operator is ← code:
|
# ¿ Jul 4, 2008 23:54 |
|
^^ Not before I make this post that I've already been typing Objective-C has had this so-called "monkeypatching"/extension methods for about 100 years now in the form of categories, and it's about time other languages like C# have decided that it's a feature worth having. I often hear self-proclaimed "OO purists" complain that attaching methods to a class you didn't write is a violation of OO design, but I would argue that forcing the user to put unrelated methods statically into some kind of "StringUtils" class or whatever is an even more egregious violation. There's no "object" there -- it's a workaround for an implementation detail and has nothing to do with the component design of the project. And as long as the language doesn't permit extension methods/categories to access private data in the class, then there's no violation of encapsulation either. I use categories all the time when I do Cocoa programming and I can't imagine living without them. I wrote a method once that escaped XML entities (ampersand, quotes, greater/less-than signs) and returned the new string, and it makes a lot more sense to write (I'll use C#-style syntax here for those unfamiliar with Obj-C) x = the_string.escapeXMLEntities() than it is to write x = HurfDurfXMLEscaper.escapeXMLEntities(the_string). It's no loving contest.
|
# ¿ Aug 27, 2008 19:00 |
|
Mustach posted:Maybe, but it's an unnecessary source of potential overhead for a negligible readability improvement. I haven't had an opportunity to play around with variadic templates yet in the upcoming C++0x, but I bet something like this could be thrown together: code:
This is also CRAZY and going way out of one's way to implement what amounts to syntactic sugar for a sequence of OR comparisons
|
# ¿ Aug 27, 2008 22:12 |
|
Vanadium posted:I would still prefer to have the 'a == any_of(b, c, d)" syntax because it is easier to read and probably makes it easy to overload other operators than == as well. I did not bother with the whole "taking template arguments by const reference" thing because you probably need to use boost.call_traits to do it correctly, and I have no idea how to apply that to variadic templates. After thinking about it, 'a == any_of(b, c, d)' might be easier than I first thought. Instead of doing the comparison inside 'any_of' like above, just have it return an instance of a class, say, AnyOfComparator. Then define global operators, template <typename T> bool operator==(const T& lhs, const AnyOfComparator<???>& rhs) and template <typename T> bool operator==(const AnyOfComparator<???>& lhs, const T& rhs) (I can't visualize what the template args for this class would be without playing around with it). These operators would just delegate to a helper function in the comparator class to do the actual comparison. This way, you could extend it to other relops by just overloading them. I may just have to download the latest gcc to play with this, just for my own curiosity. I really just want to see if code like this would get inlined into a similar sequence of comparison/branches that the raw conditional statement would. Things like this is why I can't wait for C++0x to be official. I rarely do any serious C++ programming anymore, but this would be like a fun new Christmas toy for me. vvv Except what we're talking about is syntax like: string s; s.myOwnExtensionFunction();, in which no conversion, implicit or otherwise, will downcast "s" from a string to some arbitrary subclass that I write. Nor should it. Flobbster fucked around with this message at 22:48 on Aug 27, 2008 |
# ¿ Aug 27, 2008 22:45 |
|
Holy poo poo, I made 'any_of' with variadic templates work. (g++ 4.3.0) I suppose the code below definitely qualifies as a "horror".code:
So the original question was, how efficient is this compared to a chain of if-statements? With -O3 enabled, the compiler does a phenomenal job of inlining this and it turns out it's exactly the same: code:
EDIT: removed an extra not in the != operator Flobbster fucked around with this message at 00:55 on Aug 28, 2008 |
# ¿ Aug 28, 2008 00:24 |
|
Scaevolus posted:What about -O2? -O2 comes out the same as -O3, compiled into to an inlined sequence of cmp/branch instructions. Under -O/-O1 though, the class, instantiated object, and method calls remain.
|
# ¿ Aug 28, 2008 01:44 |
|
JoeNotCharles posted:Nothing wrong with that (except the doubled ; ). It's future-proofing. If you want to add more tests to that method, you put them between the two return statements. If you left out the first one, whoever extends it next might forget to check if pObj is set. Then there should be a comment indicating exactly what you just said
|
# ¿ Aug 28, 2008 19:21 |
|
Everyone in this thread right now should shut up and use C#, since it has an explicit distinction between ref and out parameters. Problem solved.
|
# ¿ Sep 2, 2008 02:00 |
|
Karanth posted:
int num = big_number(5,010,000); printf("num = %d\n", num); quote:num = 5008000
|
# ¿ Sep 4, 2008 20:20 |
|
Victor posted:The real WTF is in several online tutorials that teach you to use a StringBuilder for instances such as the above, instead of letting the compiler automatically combine all the string constants into one. It's pretty sad. Not only that, but even in the case of appending a bunch of string constants and string variables together, the Java compiler is smart enough (that's a phrase you don't hear too often!) to compile that into a StringBuilder construction and sequence of append() calls. I never knew this until I had to decompile a class for something and saw that. I wonder under what conditions this transformation occurs -- without compiling an example, I bet it only applies to a single statement at a time. Still, it really cuts down on the number of times that you actually need to use StringBuilder explicitly. vvv Fair enough, I suppose my beef with Java is with the design of the core language and not the compiler. It's just hard to be nice when Java's the topic of conversation Flobbster fucked around with this message at 22:11 on Nov 19, 2008 |
# ¿ Nov 19, 2008 21:17 |
|
rjmccall posted:Actually, this (1) is mandated by the language specification and has nothing to do with the quality of the compiler, (2) applies to any value that you concatenate into a string, not just string values, and (3) works only within a single expression. Well yeah, anything that's not a string would get toString()'d first so that's a non-issue. That's cool though, I didn't know it was part of the language spec itself -- I just assumed it was an optimization in the compiler for large expressions. quote:Also, weren't we talking about JavaScript, not Java? JavaScript code that was being generated on the server (in, as it turns out though, C# and not Java). It's a code horror that generates another code horror In the interest of full disclosure, I've done the very same thing in two of my projects (generating JS code with a StringBuilder in one, generating C++ in the other). I replaced the whole thing with Velocity templates (for the JS) and StringTemplate (for the C++ -- this code needed to be generable in both Eclipse and VS.NET plugins, so I needed a library with both Java and .NET versions), and I can't believe I didn't do that from the outset.
|
# ¿ Nov 20, 2008 01:03 |
|
TSDK posted:... and why is a function for reading called 'write' at one point? Clearly he's programming in lower-level terms than our puny little minds can handle, since obviously every operation on a computing machine is a "write" -- even if you're reading from a file, you have to WRITE those bits to memory or a register to use them
|
# ¿ Nov 20, 2008 21:06 |
|
Zakalwe posted:Wait isn't that a correct fix for erasing based on an iterator so you don't invalidate the iterator itself? forgive me if I'm wrong here as it's nearly 2am The code is unnecessarily complicated and shows that the developer doesn't understand how the return value of erase can be used in a situation like this. The correct idiom is (with some syntax liberties because gently caress I'm lazy): code:
Pitfalls like this are why STL algorithms like remove_if exist and hopefully the improved lambda syntax in C++0x will encourage people to start using them more instead of writing their own flawed loops.
|
# ¿ Jan 17, 2009 03:05 |
|
awesmoe posted:Hm. Thanks. Smackbilly is correct, but at the same time erase is still guaranteed to return a valid iterator to the element after the one being erased, regardless of whether the container's semantics invalidate other iterators on erasure. So if you try to do a trick like the guy in the code fragment posted above where you create a temp, increment it past the element you want to delete, and then delete, that temp iterator might be undefined. STL algorithms. Use 'em, motherfuckers
|
# ¿ Jan 17, 2009 14:04 |
|
julyJones posted:As far as "least-surprise" goes, as an example, I don't think an iterator should be invalidated by a change in the state of the collection. When you're iterating over a vector and push_back() makes your iterator wild, instead of, say, throwing an exception, it comes as a surprise (unless you were patient and actually read the entire documentation, but who does that? ) I don't mean to presume it's wrong- it's just not something you'd expect, hence the "surprise". The problem with this is, some of what you're asking would have a substantial negative effect on performance, when C++'s iterators are implemented with specifically that goal in mind. For instance, in your vector example, vector<T>::iterator (in most release builds) is nothing more than T*, so there isn't even a mechanism there to deal with exception handling if you dereference or increment an invalidated iterator. I can't really see where the "surprise" is in your use case. If you're doing something during an iteration that makes your iterator go invalid, you know you're doing it and that you will have to readjust in some way, so an exception adds complexity with zero benefit. Let's say you catch the exception, then what? You have either this: code:
code:
|
# ¿ Jan 19, 2009 00:05 |
|
duck monster posted:I think they are great, because it lets you have resources that really really should be singular , like data base connections, but you just loving know dipshit junior developers will be re-instantiating over and over against. (They should be re-instantiating the cursor, but the cursors just hang off the connection. I never understood the hate for singletons either. I always get the feeling that some self-proclaimed expert blogger wrote an entry once that "SINGLETONS ARE BAD!!" and then everyone hopped on the and parroted it as The New Wisdom. Just use the right design pattern for the right job. Are singletons the solution to every problem? Of course not -- some of the concerns and drawbacks are well-founded. But at the same time, the code contortions that some people suggest or use to avoid them can be just as ridiculous when a simple singleton would be just fine in that particular context. I should start up a joke programming blog where I write posts like "Functions with multiple arguments are bad!" and rationalize it with horrible advice just to see how many people hop on board. Things like: "It doesn't scale; if you want to add arguments later, you have changed the entire signature of the function. Instead, all of your functions should return void and take an array of key/value pairs. This array should be used to return multiple values from the function as well, where the user supplies the keys representing the return values of interest with NULL value placeholders." (As I was typing this, I realized I was describing AmigaOS 2.0+ tag lists. )
|
# ¿ Mar 16, 2009 23:31 |
|
Gazpacho posted:So what if it is? The code you posted apparently works; it's the broken code you should worry about first. People shouldn't feel obligated to use every redundant feature of a language. The "not" operator is a redundant feature?
|
# ¿ Apr 12, 2009 13:37 |
|
Every operation on a computer except for "Subtract and Branch if Less Than or Equal to Zero" is redundant, so it seems arbitrary beyond that to say "well this operation isn't redundant but this one is".
|
# ¿ Apr 12, 2009 19:59 |
|
Unparagoned posted:1. There should be comments on what it actually does. Not to mention the use of NSArray to store integers makes me want to scratch my eyes out, since it means you have to wrap them in NSNumbers and make everything even more verbose by boxing/unboxing them. I refuse to actually look too closely at the code, but there's the potential for NSIndexSet to be a better fit here for a collection of integers.
|
# ¿ May 11, 2009 19:34 |
|
rjmccall posted:2. The import system lacks shortened qualified import, which turns name collisions into minor catastrophes (because everyone uses prolix package names), which means you see some really silly workarounds like Swing's J prefix on every single class in the library. We like to complain about the long typenames in Java, but it's sad that Sun gets it wrong even when they try to use short names too: java.util.List java.awt.List The only saving grace is that no method in java.awt.List seems to manipulate a java.util.List. But still, if you wanted to use both in the same compilation unit (something that could be quite likely), you're stuck fully qualifying at least one of them everywhere. Was this moronic naming (instead of something like ListBox or ListView for the UI component) just Java puffing up their chest and saying "look, packages are cool "? Fake edit: Oh god! Since it subclasses java.awt.Component, it has a list() method that does the incredibly useless task of printing a debugging description of the component to a stream! code:
|
# ¿ May 14, 2009 04:04 |
|
As much as we love to rage about long-rear end type names, the unfortunate reality is that if we're using a language like Java for a project, we're stuck with them, since the chucklefucks at Sun refuse to actually improve the language in any meaningful way. So I'd at least like it if we could get people behind the idea of bumping up the obsolete 80-character limitation to something a little more reasonable but still legible, like say 100. There's no reasons it should take me two lines to do a simple object allocation like: code:
|
# ¿ May 15, 2009 13:56 |
|
Otto Skorzeny posted:to get you to complain to Sun or Oracle or the Java Community Process or whoever to get some type inference up in this bitch I don't believe the action in the first part of that sentence has ever achieved the consequence in the second part. And even when Sun does add something people have been asking for, they manage to cock it up in the worst way possible to the point of making it only a fraction as useful as it could be (cf. generics). I think auto(un)boxing is the only thing they've added recently that I've actually been 100% grateful for. Watching Microsoft continue to develop and grow C# in a ton of ways makes me wish someone would just fire the entire Java language team and get new people in there who listen to feedback and care about turning it into a real modern programming language.
|
# ¿ May 15, 2009 14:09 |
|
king_kilr posted:5) It has various DOM helper classes, basically so you can write html in python with stuff like HTML(HEAD(TITLE("my title")), BODY(DIV(A))) etc.... I hate this poo poo in any language that does it. When I started writing my first Rails app, I'm just writing the usual <% %> templates, and everyone in all the Rails forums/blogs that I read to learn was like "You've gotta use haml, haml haml haml, I love to stick my dick in haml and then when I'm done I flip over so haml can top me too, oh godddddd haml". Do we really need a completely different markup language that obfuscates the HTML that most people doing web development would already know? It gets translated into HTML anyway, so what's the point of introducing yet another tier of crap for a user to have to learn when regular ol' template substitution suffices? Anyone who tells me that the box on the left is better or more legible than the box on the right can suck it. I like Rails from the couple projects I've been involved with that use it, but it's the reinvent-the-wheel-for-no-reason mentality of these edge projects (and the flamingly pretentious copy on their websites) that ruin it for the rest of us. Janin posted:The fact that that guy uses "I te[a]ch computer science at the Ph.D. level" as an indicator that he knows a thing or two about software development makes me wonder if he's ever interacted with any other computer science professors, ever. Out of my entire department, I can name about two or three who can actually write kick-rear end code. The others either just manage to get by, or avoid it altogether. Flobbster fucked around with this message at 19:17 on Jun 4, 2009 |
# ¿ Jun 4, 2009 19:13 |
|
tef posted:[cobol setTitle:self];
|
# ¿ Jun 9, 2009 21:12 |
|
Mercator posted:Seriously? I don't think I've ever seen more obvious proof that Larry Wall is just trolling the entire programming language community with Perl. There's no other explanation for the poo poo that goes on there.
|
# ¿ Jun 12, 2009 14:00 |
|
sonic bed head posted:From my very own keyboard with my very own brain. It took me at least a minute to re-understand what I was doing. I caught it in a few hours when I was looking over everything, but I had written this quickly to fix a error if there is no element with id "anywhere". I actually kinda like this. It's better than $("anywhere") && $("anywhere").checked because you're not resolving it twice (unless $() does some caching; it's been a while since I've used any of those JS libraries), and it saves valuable keystrokes in declaring a temp variable. It was obvious to me right away what the intent was, but yeah, I can see it being somewhat cryptic to someone, and probably best avoided in general.
|
# ¿ Jul 16, 2009 00:59 |
|
Avenging Dentist posted:People have an unhealthy obsession with switch statements though (especially in languages like C# or Java). I mean ok, sure, in C/C++ with a sub-optimal compiler, a switch statement might be faster than if/elses by implementing it as a jump table (a smart compiler should be able to figure this out too for if/elses), but that sort of thing isn't going to work with string comparisons. I went to search Google for some statistics on when C#'s compile-string-switches-to-a-hashtable approach becomes more/less efficient than a chain of if/elses, and I found something else that belongs in this thread: shoehorning in a functional lambda-based switch construct that accomplishes the same thing as a bunch of ifs, but uglier! code:
The best part is that you would think that you could say "Oh that's almost kinda cool, I could create this switch object and pass it around", but you can't because it abuses collection initializers and executes each case immediately in the IEnumerable.Add method.
|
# ¿ Jul 24, 2009 20:48 |
|
Can we quit calling regular expressions "regular"? Because most of the implementations in common use now are not.
|
# ¿ Aug 1, 2009 18:32 |
|
I like that the helper function they wrote to handle the null string case requires about twice as much typing as the expression itself.code:
code:
|
# ¿ Aug 17, 2009 16:52 |
|
Plorkyeran posted:Does using COM to run a program via WScript.Shell count as a horror? I don't really want to know why both that and exec are used about two lines apart. COM is always a horror.
|
# ¿ Sep 22, 2009 14:38 |
|
floWenoL posted:Honestly if I were a professor and I found out my student went through the effort of decompiling my reference program and then rewriting it sensibly in the original language, I'd let it go because he probably did learn whatever he was supposed to, and then some. Eh, it depends. If a student manually inspected bytecode or assembly language code and rewrote it in the original language, then yes, I'd be impressed by that and would congratulate the student instead of punishing them. But if he's just running Jad or Reflector.NET, those generate reasonable enough code automatically that it's not worthy of any kind of praise.
|
# ¿ Oct 2, 2009 00:54 |
|
|
# ¿ May 6, 2024 14:40 |
|
SwimNurd posted:I only have experience with Jad, but yes variables names are preserved if debugging is turned on. This has been my experience as well, in just about every class file I've had to decompile -- the main project I've been working on for the past couple years is a Frankenstein-like beast built on Apple WebObjects and we've had to resort to using Jad from time to time to hack into WO classes that we need to fix bugs in or change the functionality of where just subclassing isn't an option. The code that Jad dumps out is usually quite usable, and in many cases, without needing any manual repair. The only times I've seen it fail were in some heavy try/catch situations, or occasionally with complex nested conditionals where it can't figure out the structure and just dumps out labels. I haven't used Reflector.NET in several years since I don't do .NET anymore, but I seem to remember it generating pretty good C# code too (never bothered with other languages). Since MSIL can be generated by a handful of source languages, there's probably some cases where it gets tricker (like I don't know how good VB (compile) --> MSIL (decompile) --> C# would look), but if you stick to the same source and destination language it's probably on the same level as Jad.
|
# ¿ Oct 2, 2009 03:57 |