Don't be stupid. Anyone with half a brain can see the potentials of this kind of system, and the people pushing for it are very aware of the fact that it's not just about taxing road use. If it were, they'd just raise gasoline taxes, which would have the mutliple benefits of raising more money and providing more incentive for energy-efficent cars, which incidently tend to be lighter and thus cause less road wear.
Dunno about AIX, but the HPUX vendor supplied compiler has long been known to be crap. If you're really forced to use it instead of GCC, my sympathies.
IE is not integrated into explorer, or vice versa. Rather, they're both simple wrappers around components. Pretty much the only common code is decoding URIs and deciding which component to load in the client area. If your taskbar locks up, look at hard drive failures/inefficencies, mapped network drives on unreliable network connections, and Explorer (not IE) shell extensions.
You said "whats the fuss". The fuss is that people don't like it because it's immoral and ruins their enjoyment of the game. You were implying that there should be no fuss because there's no law against it.
Blizzards stance is that anything you can do through the UI mod API is fine. That's very reasonable, because the UI modding is a documented, supported aspect of the client that Blizzard controls and can expose as much or as little functionality as they desire. Mods such as the ones that were popular with Asherons Call, which do binary patching, or work as a proxy to intercept data, are against the TOS.
Ah, I was confused by the 2 year period under part 1. My knowledge dates to within that period. As for telling them how, that's section 2 - this is the section that was used to forbid linking to the DeCSS code, for example.
If he's satisfied with what he's doing, then he wouldn't be asking questions. Moreover, anyone who is doing anything of any complexity who is satisfied with using global variables and serializing via memory dumps isn't someone who's doing anything I would want to be associated with. It's bad code. I suppose as long as he keeps it to himself without asking anyone else to run it there's no harm.
That's just an accounting trick - the question is whether or not you're paying more money to the DVD group and Macrovision than you're saving. I can't answer that question, but when the numbers presented by a party with a vested interest in inflating the amount gives a number thats a pretty low percentage of total sales, I have to wonder.
If the guy had asked me how to serialize *one* global variable I wouldn't have said anything. But it's never just one, as I'm sure you know. I wouldn't write this in anything like the way you describe - I'd create a GameState object with accessors for all of the variables that would normally be flat global vars. I might spend 5 minutes making it a real singleton. Access to global state would be through the GameState object only (and I might make that state object global) and I'd be done with it. Complicated scaffolding would come later, if I needed it. I see no need for delegates. I think you're misrepresenting the OO proponents here, as well as the "no global vars" dictate. It's not (at least as I use it) an absolute. There's very little difference between a singleton and a global - it's a matter of code cleanliness, style, and semantics. I would use a Singleton here for a) the encapsulation benefits of using an object to store state and b) the ability to control initialization granted by using a singleton rather than a global static object. No delegates. No days worth of scaffolding. I can write this kind of object in my sleep.
Now, granted, all this presumes a game simple enough that it's reasonable to store all of the game state in a single global object. That certainly may not be the case, or it may not remain the case, and I might need to create a more complicated object hierarchy and serialization tools to deal with that, but the global vars solution is going to fall down a hell of a lot faster.
As regards to your understanding of OO, I was responding to the content of your post, not trying to make predictions about your knowledge. Regardless, if you actually do spend a day writing scaffolding every time you create an object system you might want to re-think your methodology.
Slight correction: The DMCA doesn't say you can't circumvent the protections. It just says that you can't tell anyone how you did it, or give them tools to let them do it.
Here's an intersting question. So piracy costs a bit less than 4% of annual income each year. What kind of royalties do you have to pay for a CSS license? And how much will Macrovision charge for licensing? Is the total more than 4% of sales (and thats assuming that the 1 billion in lost sales is legit, which is questionable).
An amusing aside is the Google ads at the bottom of that article.
There was a lot of spin. The guys really good. He wriggled out of the TCO thing by pointing out that the TCO studies only address a specific scenario, which is true, but it's hardly how they're presented in the literature. He came very close to admitting that the marketing literature is crap and shouldn't be taken seriously, which we all know, but would be interesting to hear.
He squirmed a lot on the disclaimer of fitness thing, too. He's totally correct that pretty much all software (OSS included) makes this disclaimer, but he didn't really adress the issue that the barrier of responsibility is much lower for something thats provided gratis than for a commercial product.
VA will also add autocompletion for words near your current location in the source code. You can manually add arbitrary words to it as well. It sounds very similiar to the emacs feature you describe (not a big emacs fan). This is in addition to the code insight features. It's also aware of scope, so (for example) it offers auto-complete for local variables first. It makes errors due to typoing variable names much more rare.
I just realized I'm coming off as a total fanboy in my posts:P I'm not associated with VA or whole tomato in any way. VA also has it's share of warts - it's a hog for ram (continually updated syntax tree of your entire C++ program....) and there have been any number of bugs, minor and otherwise. It's an amazingly functional tool, though, and the Whole Tomato guys are very supportive.
It also learns from the patterns you use more often in your code and sorts the suggestions in a way that the probability that you'd need to scroll down the list of the suggestions becomes lower and lower.
"Patterns you use" indicates it's just doing pattern matching, not understanding the language.
To clear up any misconceptions:
There is more than one definition of the word pattern. The OP was talking about VAs heuristic behavior, where (for example) if you call Foo.Bar() a whole lot, the method Bar will be moved upward in the autocomplete list. Note that you don't need to use a mouse to interact with these lists, VA provides keyboard access to all it's features.
Anjuta provides functionality similiar to that found in the (stock) version of Visual Studio. VA is head and shoulders above that in quality and functionality. It's the right concept, VA just does it better.
The VA stuff is a lot more advanced than (at least whats built into) vim. Many of the features aren't directly comparable, because they're things you'd want in a GUI environment rather than a terminal-based editor like vim. VA parses all your source files, including supporting libraries and dependencies (pulled from the Visual Studio project files). It does this in real time, as you work. The syntax highlighting is actually context-sensitive, not simple keyword highlighting.
You could probably implement much of this in vim with sufficent work, but as far as I know there's nothing out of the box for it. You aren't going to get the same quality of context sensitivity without an IDE that does project management, though.
All the general advantages of OO. Encapsulation - all of your access to the global data goes through one object and in one manner. This makes extending behavior (for example, adding journaling) much simpler as well as drastically reducing the chance of errors. The object provides a namespace wrapping around the variables to prevent pollution of the global namespace. And don't underestimate the benefit of cleaner code, which is easier to maintain and easier to fix.
I can translate your post as "I don't know OO very well, so using it takes me longer than doing things my way". This is all well and good but not a very helpful way of teaching. It doesn't take any longer to write an object than it does to write a whole slew of global variables, and you don't need to add any special amounts of scaffolding. Incidently, the OO technique often (but not always, although it generally depends on the skill of the programmer) makes it easier to leverage the fancy scaffolding into place after the fact.
Personally, I have never seen a functional or procedural technique which could not easily be translated into OO. I've seen lots of OO features that can't be translated into functional or procedural, if only because the lack of language support makes using them that way awkward. So in my (admittedly limited) experience, OO is objectively better. I wouldn't make that as a general claim, of course, but I will make a general claim that encapsulating something like global state as an object is superior to using it as a bunch of global variables. Even making a single global struct would be better.
"Too old to be fashionable, suitable, or useful; outmoded." -- From dictionary.com
By definition, calling something antiquted is calling it inferior. In the context of software development, it's reasonable to call something antiquted if it's been superceded by a better technology or method - punch card programming is antiquated. Don't turn your brain off on buzzwords. There's a good reason people preach against global variables. It's not just dogmatic.
A C++ environment which does not call constructors on global objects is non-standard and broken. This is sort of like saying that you shouldn't use malloc in C programs because you can't rely on it working. If you are in such an environment, my condolences, and I suggest to talk to your vendors and ask them why they shipped such a non-conforming pile of crap. And then stop using C++, because your tools don't work.
This is the largest load of crap I've heard in a long time, especially directed to someone who's a student. The whole point of being a student is that you learn something, not that you just do whatever until you run into all the problems. Sure, what he has works. But he wants to know if there's a better way. He's been introduced to something that he doesn't understand, and doesn't see how it can make his programs better. So he's asking for some examples. This makes him an intelligent person (unless he's just got an axe to grind against OO and is trying to troll, but I'm assuming good faith and even if he is, this is a lousy example to pick), as opposed to being a reactionary turd who'll refuse to better himself.
Unfortunately, the OP does not have one single object that they can serialize, and they surely don't want to serialise the whole content of the memory...
Then he should have one. Encapsulate the (global) game state into an object. OP says he uses global vars for this stuff. That's fine for simple cases but it rapidly gets unweildy as complexity grows. If it helps, think of the GameState object as a namespace, and think about how that can reduce the chances of mistakes and errors. If you embrace the OO design methods, then you start seeing other things you can do, like adding support for journalling of game state (easy when all access to the game state is encapsulated in an object, much harder when it's done directly via global vars).
Slashdot Mirror
Don't be stupid. Anyone with half a brain can see the potentials of this kind of system, and the people pushing for it are very aware of the fact that it's not just about taxing road use. If it were, they'd just raise gasoline taxes, which would have the mutliple benefits of raising more money and providing more incentive for energy-efficent cars, which incidently tend to be lighter and thus cause less road wear.
Why are you putting dual Athlon 64s into a file server? That's 20% of your cost right there.
Dunno about AIX, but the HPUX vendor supplied compiler has long been known to be crap. If you're really forced to use it instead of GCC, my sympathies.
IE is not integrated into explorer, or vice versa. Rather, they're both simple wrappers around components. Pretty much the only common code is decoding URIs and deciding which component to load in the client area. If your taskbar locks up, look at hard drive failures/inefficencies, mapped network drives on unreliable network connections, and Explorer (not IE) shell extensions.
Not a damn thing. Maybe you meant KHTML.
Pretend for a moment that you live in Japan, or Russia, and you actually use websites that use these IDN characters.
You said "whats the fuss". The fuss is that people don't like it because it's immoral and ruins their enjoyment of the game. You were implying that there should be no fuss because there's no law against it.
Blizzards stance is that anything you can do through the UI mod API is fine. That's very reasonable, because the UI modding is a documented, supported aspect of the client that Blizzard controls and can expose as much or as little functionality as they desire. Mods such as the ones that were popular with Asherons Call, which do binary patching, or work as a proxy to intercept data, are against the TOS.
Ah, I was confused by the 2 year period under part 1. My knowledge dates to within that period. As for telling them how, that's section 2 - this is the section that was used to forbid linking to the DeCSS code, for example.
If he's satisfied with what he's doing, then he wouldn't be asking questions. Moreover, anyone who is doing anything of any complexity who is satisfied with using global variables and serializing via memory dumps isn't someone who's doing anything I would want to be associated with. It's bad code. I suppose as long as he keeps it to himself without asking anyone else to run it there's no harm.
That's just an accounting trick - the question is whether or not you're paying more money to the DVD group and Macrovision than you're saving. I can't answer that question, but when the numbers presented by a party with a vested interest in inflating the amount gives a number thats a pretty low percentage of total sales, I have to wonder.
Now, granted, all this presumes a game simple enough that it's reasonable to store all of the game state in a single global object. That certainly may not be the case, or it may not remain the case, and I might need to create a more complicated object hierarchy and serialization tools to deal with that, but the global vars solution is going to fall down a hell of a lot faster.
As regards to your understanding of OO, I was responding to the content of your post, not trying to make predictions about your knowledge. Regardless, if you actually do spend a day writing scaffolding every time you create an object system you might want to re-think your methodology.
Slight correction: The DMCA doesn't say you can't circumvent the protections. It just says that you can't tell anyone how you did it, or give them tools to let them do it.
An amusing aside is the Google ads at the bottom of that article.
He squirmed a lot on the disclaimer of fitness thing, too. He's totally correct that pretty much all software (OSS included) makes this disclaimer, but he didn't really adress the issue that the barrier of responsibility is much lower for something thats provided gratis than for a commercial product.
I just realized I'm coming off as a total fanboy in my posts :P I'm not associated with VA or whole tomato in any way. VA also has it's share of warts - it's a hog for ram (continually updated syntax tree of your entire C++ program....) and there have been any number of bugs, minor and otherwise. It's an amazingly functional tool, though, and the Whole Tomato guys are very supportive.
To clear up any misconceptions: There is more than one definition of the word pattern. The OP was talking about VAs heuristic behavior, where (for example) if you call Foo.Bar() a whole lot, the method Bar will be moved upward in the autocomplete list. Note that you don't need to use a mouse to interact with these lists, VA provides keyboard access to all it's features.
Anjuta provides functionality similiar to that found in the (stock) version of Visual Studio. VA is head and shoulders above that in quality and functionality. It's the right concept, VA just does it better.
You could probably implement much of this in vim with sufficent work, but as far as I know there's nothing out of the box for it. You aren't going to get the same quality of context sensitivity without an IDE that does project management, though.
All the general advantages of OO. Encapsulation - all of your access to the global data goes through one object and in one manner. This makes extending behavior (for example, adding journaling) much simpler as well as drastically reducing the chance of errors. The object provides a namespace wrapping around the variables to prevent pollution of the global namespace. And don't underestimate the benefit of cleaner code, which is easier to maintain and easier to fix.
Personally, I have never seen a functional or procedural technique which could not easily be translated into OO. I've seen lots of OO features that can't be translated into functional or procedural, if only because the lack of language support makes using them that way awkward. So in my (admittedly limited) experience, OO is objectively better. I wouldn't make that as a general claim, of course, but I will make a general claim that encapsulating something like global state as an object is superior to using it as a bunch of global variables. Even making a single global struct would be better.
By definition, calling something antiquted is calling it inferior. In the context of software development, it's reasonable to call something antiquted if it's been superceded by a better technology or method - punch card programming is antiquated. Don't turn your brain off on buzzwords. There's a good reason people preach against global variables. It's not just dogmatic.
A C++ environment which does not call constructors on global objects is non-standard and broken. This is sort of like saying that you shouldn't use malloc in C programs because you can't rely on it working. If you are in such an environment, my condolences, and I suggest to talk to your vendors and ask them why they shipped such a non-conforming pile of crap. And then stop using C++, because your tools don't work.
This is the largest load of crap I've heard in a long time, especially directed to someone who's a student. The whole point of being a student is that you learn something, not that you just do whatever until you run into all the problems. Sure, what he has works. But he wants to know if there's a better way. He's been introduced to something that he doesn't understand, and doesn't see how it can make his programs better. So he's asking for some examples. This makes him an intelligent person (unless he's just got an axe to grind against OO and is trying to troll, but I'm assuming good faith and even if he is, this is a lousy example to pick), as opposed to being a reactionary turd who'll refuse to better himself.
Then he should have one. Encapsulate the (global) game state into an object. OP says he uses global vars for this stuff. That's fine for simple cases but it rapidly gets unweildy as complexity grows. If it helps, think of the GameState object as a namespace, and think about how that can reduce the chances of mistakes and errors. If you embrace the OO design methods, then you start seeing other things you can do, like adding support for journalling of game state (easy when all access to the game state is encapsulated in an object, much harder when it's done directly via global vars).