The ?: operator in C/C++ can be quite handy to express things more briefly, but should of course be used with care. The real fun begins when you start nesting ?: operators. It can get quite confusing quite soon. Even then, though, there are still situations where nesting ?: can be acceptable. For example, I consider this to be an acceptable usage:
bool Point::operator<(const Point& rhs)
{
return x != rhs.x ? x < rhs.x : y != rhs.y ? y < rhs.y : z < rhs.z;
}
Not that an if-elseif-else block wouldn't do the same, but it's more verbose.
Sounds like a good idea to me. Maybe also add a guideline for posting on those emulator forums: If your post is related to a specific emulator, your thread subject should start with "[<emulator>]". For example: "[gens] Some subject line here". Or something along those lines.
(Of course there will always be people who won't follow guidelines, but it could still help. And some admin could always rename threads if necessary.)
If I recall correctly, South Korea is locked into IE because they have a massive install base of ActiveX programs for banking and other vital infrastructure. Whoops.
I have always wondered about things like that. "Hey, let's tie tightly all of our vital financial systems, without which the entire country would go bankrupt and sink into chaos, to a piece of proprietary software owned by some private company in the US. This way we will be completely at the mercy of the whims and support of that company." "Yes, that sounds like an excellent idea. Go ahead!"
And then you wonder if politicians and CEOs are born idiots, or whether they grow to be.
Gecko and Opera just got @font-face support in their latest versions, IE has had it for 12 years now.
All the CSS3 stuff they're trying to implement is cool flashy stuff, but forget useful text features like text-justify which IE had since version 5, and is one of the most sensible things to add.
Yeah, seeing how CSS3 hasn't even been ratified yet, I really see how it makes sense for Firefox and Opera to implement CSS3 features 12 years ago.
Wake me up when Firefox, or Opera, or Safari or whoever finally support Arabic and Chinese CSS features which IE has had for years.
Say, does IE finally support alpha-channeled PNG images? Because Firefox and Opera have supported them out-of-the-box from year 0.
Would it be too hacker-ish to test for an odd integer with n&1, or to replace n%2 with (n>>1)<<1, or to pepper your functions with inline asm?
Those are good examples of the "null optimizations" I was talking about. Any compiler which is newer than about 15 years will be able to optimize such expressions.
(Actually, there's a fourth type of "hacker optimization" which I forgot to mention: The negative optimization. In other words, something which might look like an optimization but that causes the code to actually be slower than the straightforward solution. Sometimes trying too hard to optimize simple operations can cause negative optimization because the only thing you are achieving is confusing the compiler.)
It's also against the law (at least in germany). Customers have the right to re-sell pretty much everything they bought for personal purposes. You cannot buy large quantities and re-sell them for profit, buy you are allowed to re-sell used items you do not need any more. No amount of "Not for resale"-stickers on any product can void that right. And now there's software requiring activation, using technical measures to stop us from exercising our rights. Same with DRM and copy protection (as private copies are still legal here).
Don't worry. I'm sure music and movie companies will lobby your government to change those laws, as they have successfully done in so many other countries (including in Finland, which now has a copyright law so complicated that even half of the congressmen themselves don't understand fully). ;)
My stance on repetition:
* The first time you write something, do it in-line. That is, don't make a separate function for it; just incorporate it into your program.
* The second time you write something, recognize that you're duplicating functionality. Don't make a new function yet, but also don't copy and paste your previous implementation.
* The third time you write something, it's time to refactor. Make a new function, and look at the previous ways you accomplished your goal. Pick the best approaches from each.
I think that's an acceptable principle only for small pieces of code (a few lines, a dozen at the very most). If we are talking about large pieces of code, it may be a good idea to divide it logically into separate functions, even if those function are called only from one single place (and are not even visible outside of the current compilation unit) just so that you don't end up having one function with one thousand lines of code. Function naming in itself can often act as self-documenting code.
We can also apply your principles at a higher level:
* If you find yourself passing the same parameters to a group of functions from many places, that's usually a sign that the parameters and the functions are more or less closely related to each other. You should start considering if you could group both the data and those functions into a module or class.
This not only organizes the code better, it usually also simplifies the calling code (because now the calling code doesn't have to manage those parameters nor pass them to functions all around).
* Don't optimize until you need the speed. But when you're writing new code, be aware of its algorithmic complexity. When you do optimize, use a profiler to figure out what in your code is slowing you down. When you make changes, verify that they actually sped things up.
One should distinguish between two types of optimization: Low-level optimization ("hacker optimization") and high-level optimization. These two things should not be confused. (Very especially, the "optimize" in "don't optimize unless necessary" should not be confused with high-level optimization. It should only refer to the hacker optimization.)
One should be aware of computational complexities and have experience on which algorithms and data containers are best suited to solve which problems. Choosing the proper algorithm or data container to begin with will be a lot easier than using a naive solution and having to change it afterwards.
"Hacker optimization", on the other hand, should usually be avoided, especially because it tends to make the code more obfuscated and less readable, unless you know that a specific (preferably small) piece of code will need to be as fast as possible (for example because it will be called millions of times per second).
Even in these cases you should know the difference between null optimizations (optimizations which might look like they are doing something even though the aren't, because the compiler was making that optimization already anyways), micro-optimizations (optimizations which might have some minuscule effect, but which may get completely overwhelmed by the slowness of the surrounding code, making the optimization useless in practice) and real low-level optimization (such as reducing the amount of useless memory allocations in a C++ program, which can be a significant source of inefficiency).
I think that the program is too large to raise interest. A wall of code is rather daunting.
I'd say something like 15 lines of code is a good upper limit for such exercises.
Perhaps we should wait 6 months before publishing? Yes.
If the original point was "it's a great thing that submissions don't stay in the queue for months, but we shouldn't go to the other extreme either", why are you suggesting the original extreme as the "alternative"? Nobody has suggested that the submissions should be delayed for months, so why are you writing as if that was the implication?
What is it with extremes? When someone suggests not going to an extreme, the standard counter-argument seems to be to ask if what you want is to go to the opposite extreme. That doesn't make sense (especially when getting rid of that opposite extreme was a point raised to begin with).
I honestly can't understand why you are acting like judges waiting a few days for people to comment on a submission would be such an unreasonable suggestion. What exactly is the problem here?
1) No DRM. I didn't buy Red Alert 3 despite how much I love the series, because I can only install it 5 times, which is unacceptable.
As a matter of principle, ok, but as a practical matter, who cares how many times you can install it, really?
I own exactly one gaming PC, and when I buy a game I install it on it, play it through, and uninstall it. That's it. So what if the game allows itself to be installed only 5 times? Why should that bother me? (Besides, most such games free up such an installation registration when you uninstall the game. It's not like I would ever want to play the game on 5 different computers at the same time. I don't even own that many computers.)
As for the game installing some DRM rootkit or whatever nasty things... Well that doesn't bother me either because I use Windows exclusively for gaming and little else. I don't really care what copy protection software is installed as long as I can play the game I bought. My principal OS is Linux, and I don't really care about Windows, as long as it works. Besides, I believe that most attempts at breaching people's privacy with such software get caught quite quickly, causing controversy, and usually get changed pretty fast. I don't think most gaming companies even bother to try.
In more seriousness, in my opinion, real programmers do what is necessary to get the task accomplished in an elegant manner and no more. Elegance is defined by a number of meters, such as the ratio of "accomplishes" to "does" in the code (this is my favourite) and its ease to be understood at glance.
What both of your examples are actually telling is that real programmers avoid code repetition (a rather common beginner mistake).
Brevity in itself, when done wrong, can actually be extremely counter-productive.
"Don't do needless work when a shorter/simpler solution will do the same" yes. "Shorten the code just for the sake of making it shorter" no.
That first principle actually reminds me of some of the most horrible pieces of C++ code I have had to review as a teaching assistant at the University here. You wouldn't believe how complicated a function like "calculate the distance between two 2D points" can be (which is a simple 1-liner). I think that the worst examples spawned over 100 lines of code.
Because, hopefully, most people understand what is meant with "technical quality" (or at least what I meant when I implemented it and have tried to emphasize in numerous occasions): It does not mean "does it contain flaws or possible improvements?" At least not exclusively. While flaws may be considered when estimating the technical rating, IMO it should only be a relatively small part of it.
That's not actually what's happening.
You mean that most people do consider the technical rating to be a pure number which indicates the amount of flaws/possible improvements in the run? Considering how people have written about that rating in the past, that's probably (and sadly) the case. I would hope it wouldn't be so, but I can't stop people from having free will, I suppose. My quest for the rating to be more expressive and interesting than a boring flaw count is probably futile.
Warp wrote:
And as a side note, seemingly my argument of "if for nothing else, as a token of appreciation that some people still care to watch the submissions and comment on them" has fallen completely on deaf ears. Would showing some appreciation be too much to ask? It's not like it would be more laborious, tedious or technically difficult to do so. Although that's just my view.
It is appreciated.
I didn't want my text above to sound like an accusation (although it admittedly sounds like one). I was simply suggesting that it would be one way to show in practice that judges appreciate people's opinion by waiting for it and reading it.
Many acceptance/rejection notices by a judge do indeed contain a reference to the forum feedback, which is always nice. I'm just fearing that if some runs are rushed into publication, it may show that the judge wasn't even interested on people's opinions.
I think the converse needs to be spoken for.
Here we have judges spending their free time really thinking about a movie, and encoders using a lot of time and hard drive space, and effort to encode a movie, sometimes many times. Then they got to upload it and edit and all kinds of stuff, and in the end, we sometimes get "Hey? Why so fast?". It's ungrateful that people here are even fathoming using a term like "rushed publication". There will always be mistakes either way, but people helping out don't need to get their noses rubbed in it, which is what happens every time someone complains about a rush.
Well, one way of avoiding such situations is not to rush a publication, wouldn't it?-)
I do appreciate that judges/publishers are eager to publish new material, but sometimes it's good to use some diplomacy.
Even if we rejected all those, if you were correct, then why isn't every movie of at least of recent publication getting a perfect 10 in the technical ratings?
Because, hopefully, most people understand what is meant with "technical quality" (or at least what I meant when I implemented it and have tried to emphasize in numerous occasions): It does not mean "does it contain flaws or possible improvements?" At least not exclusively. While flaws may be considered when estimating the technical rating, IMO it should only be a relatively small part of it.
Not all runs can get an entertainment rating of 10 for the simple reason that not all games are suited to that rating, no matter how well you do the run on it. Such games simply are boring to watch (or at least not super-entertaining, which the rating of 10 would require). Likewise not all games lend themselves to a technical rating of 10 because not many (if any) superb TASing and running techniques can be used with them. That's (I hope) the answer why not all runs get a technical (nor entertainment) score of 10, no matter how "perfect" they might be.
And as a side note, seemingly my argument of "if for nothing else, as a token of appreciation that some people still care to watch the submissions and comment on them" has fallen completely on deaf ears. Would showing some appreciation be too much to ask? It's not like it would be more laborious, tedious or technically difficult to do so. Although that's just my view.
Generally speaking, if it's made by Square/Enix, I buy it. (They make so few games for the PC or the PSP that I'll take anything they have to offer.) Also anything set in the Half-Life universe is an automatic purchase for me (I think I have bought all of them during the years, unless there's some obscure official HL1 expansion I don't know of). Most modern games by Id Software also fall into this category (although the expansion to Doom3 was somewhat of a disappointment).
In other cases, I might buy a game if:
1) It's widely acclaimed as one of the best games in recent history.
2) It's a sequel to a game I already own, and it hasn't got completely crappy reviews.
3) It's extremely cheap, looks interesting, and I don't have any pending games in my games shelf.
IMO what should be avoided is having a submission stay in the queue for months even though everybody stopped talking about it a couple of days after it was submitted. I think that has been the problem with some submissions in the past, and it's good that something is actively done in order to avoid those cases.
However, going the other extreme and publishing something within hours of submitting it might be going a bit too far (even if it's crystal-clear to the judge that the submission is valid and publish-worthy). Let people comment and vote on it, if for nothing else, as a token of appreciation that some people still care to watch the submissions and comment on them. Also, as moozooh well put it, give the author a few days to possibly realize some last-minute optimization which he discovered after submitting.
I don't think submissions should be rushed because of newcomers. If they don't have a clue what to do with movie files nor can find pre-encodes, they probably won't be none the wiser about the fact that there were a few days between submission and publication either. I don't think anybody would complain about that.
While we're on this topic...
From IRC:
<Nach> if a judge watches a movie immediately after submission, and it kicks the old one in every way, and after watching it, he has to scrape his jaw off the floor and find where his eyeballs rolled to, I don't see what the problem is with him accepting it before anyone else weighed in
One could come up with scenarios where rushing even such a submission into publication can cause needless work later. Maybe the judge missed something, such as the submission breaking the rules, something which people commenting on the submission might point out. (I'm not saying that this precise scenario would be very likely, but you get the idea.)
If you're a web developer, there's also a couple of must have Firefox extensions, although they don't improve the general browsing experience.
You mean like firebug? Yes, a friend of mine who works in the web development industry says that it's an indispensable tool.
In fact, I'm assuming that such a tool is so indispensable that I have to wonder if Chrome doesn't have the equivalent already...
You are stirring up trouble here without even looking at the facts.
I can completely honestly say that I was not trying to criticize or attack anybody here. It was a legit and innocent question. I was just thinking that "getting the queue to 0" was some kind of ubiquitous goal that everyone is somehow taking for granted, and was wondering why this is so, when you think about it.
I apologize if I inadvertently sounded like attacking someone.
Warp:
At the end of the day it matters what the judges think. Votes and comments are only there to help a judge who isn't sure. If a judge feels it should or shouldn't be published, he has the power to mark the movie appropriately, irregardless of how long its been there.
You make it sound like judges don't really care or appreciate people's comments and votes (and only check them if they have some doubts about the movie). I'm not sure that's exactly what you meant.
The prejudice of programmers regarding Hungarian notation came about due to overuse of it.
True, but I'm not talking about overusing the notation. As I said, just the distinction between local, member and "global" variables helps readability a lot. IMO there's no much need to go further than that (eg. indicating the type of the variable in its name).
I had myself a prejudice against the prefixes for years, but some time ago I really started to consider it more seriously when I regularly had to go through old code of mine and was having trouble remembering what all the variables meant. I really have noticed an improvement now that I have started using those three prefixes.
Derakon wrote:
* Constants: in all caps. MAX_SPEED_X, NUM_COLUMNS, etc.
Many C++ (and C) programmers limit the usage of all-caps to preprocessor macros, as another distinguishing naming convention. (After all, a preprocessor macro can be a lot more than just an alias for a literal constant.)
Personally I also use all caps with enumerated constants (but not any other type of constants), but I have been considering changing that habit.
* Globals: referred to by their module name (e.g. map.minUniverseWidth, physicsobject.defaultGravity). Or, simply by being names that are not declared in the current scope -- most of my functions are short enough that such are easily recognizable.
In C++ you can have nameless namespaces, so obviously you can't use a "module name" with them (there is a radical difference between nameless and named namespaces; if you used a named namespace, all the identifiers inside it would become globally visible, while the visibility of identifiers in a nameless namespace are strictly restricted to the compilation unit where they reside.)
Of course you could prefix the usage of variables in a nameless namespace with a "::" (eg. "::value += 5;"), but the empty "::" prefix also has meanings other than just "the current global scope" so it may become confusing. (For example, "new" and "::new" are two very different things.)
DrJones wrote:
"What most C++ programmers (beginner and intermediate) don't seem to realize is that the "std::" prefixes actually make the code easier to read, not harder."
Yes, it also makes it a lot uglier, and I'm the one that has to read the code. Thank you.
This is precisely the kind of view that I don't understand anymore. As I said, to me the "std::" prefixes make the code easier to read and understand, not harder or "uglier". It's a clear visual clue that a standard library element is being used.
Honestly, I just can't understand where the "ugly" part is coming from. What do you mean "ugly"? It's three letters and two colons. What's so "ugly" about that?
Granted, if you had three nested namespaces, each one with a name which is 15 characters long, then one might consider some "using namespace" or a namespace alias to make the usage shorter. But this is just 5 characters, "std::".
Every time I defend the "std::" prefix, someone always comes up with the slippery slope argument. It's not very convincing. "std::" is just 5 characters, and it does make the code easier to read when you get used to it (which happens pretty quickly once you get over the prejudice).
We'll soon see if the number of submissions in workbench reaches 0.
Is that really something to aim for?
Movies are submitted on a more or less steady pace (which is a great thing), and optimally they would stay on the submission queue long enough for people to have time to vote and comment on them with enough detail. Rushing movies to publication or rejection for the sole reason of keeping the queue at 0 would only mean that people don't have that much time to comment and vote on them, which I don't see as such a good thing.
