For the most part the public doesn't actually know what is good for them.
This is the arrogance which has led to the stagnation in current gaming, coupled with the lack of compelling new game mechanics. Watch a five year old kid for an hour and you've got two new games.
For the most part the public may not know what's good for them, but neither do you. You may make your borderline ecumenical diatribes about the ignorance of the public on your way out the door, please; for all the complaining you're doing about the book's author, you've done a hell of a lot less.
Armchair quarterbacks can't throw. When you release three new game mechanics, you may speak about the public's general ignorance. For now, all you're doing is displaying your own.
Oh, don't be ridiculous. That's like saying that nobody can sit down and start plotting a rocket path after reading a book on physics, because first they have to find out what air is, and then how to use a pencil, and then what direction up goes. The book isn't "every step you've ever fucking needed to write a game starting from learning to breathe." A calculus book doesn't cover arithmetic, an engineering book doesn't cover mechanics, a pointillism book doesn't cover paint blending, and there's no reason on earth that a book about game design should have to think about programming or APIs.
After that string of jabs, I almost expected to see the new Quaker rebranded Princess Amidala microwavable breakfast line, available in sizes ranging from single serving to 38" waist.
Hey, shut up, I've never made a NPHG joke. I get to. It's been long enough.
For being much more cerebral than most games, you sure have a fantastic control of the English language. On the front page alone I count twenty seven grammar errors, three conjugational errors, two spelling errors, and seven misused words. Don't trumpet yourself until you've learned the song, please; you're no more cerebral than the other ten dozen slashdotters which think themselves the gaming world's next Thomas Pynchon.
Oh, and a hint: PUTTING some various WORDS in all CAPITALS for no APPARENT reason is TACKY. Stop doing IT.
You predicted that graphical MUDs would be successful after years of successful text-based MUDs
Actually, his prediction postdates the first successful graphic MMOs, too. Have a look at the early histories of GEnie, Delphi and Compuserve; they offered massive online games whose game mechanics, if not whose quality of graphics, frequently rivalled or bettered those available today.
I have never promoted someone whose skillset was artistic and tool-use oriented into a software development position. In fact, going through the people I know, I can't think of almost anyone which has come into game design this way; it is my opinion that this is the "farm boy makes good" myth of our profession.
If you want a software development job, get a junior software development position. You'll be paid and treated like any other entry job, but at least it'll be in the right market. Also, don't follow these myths that small houses are easier to climb up the ranks through; it's the big houses like EA and Take Two which have the resources to hire unknowns and take risks on individuals. A five man operation which is hiring a sixth person will not risk 16% of their workforce on an unknown. EA, however, sees cheap labor; if you can do well there for a year, then the small houses will snap you up like gold.
Ask a lawyer, a surgeon, an architect. What you have to do is break your back with ridiculous hours for no pay for a year as a faceless minion of some gigundous corporation, because in those places you can make your name. Once you have the ability to say something like "yeah, I did the physics system on FIFA 2006, and I have a game design I'd like to implement," you will be taken far more seriously than if you just said "Hi, I have this GDD, hire me please."
Tester is a maybe-in; they're semi-code-oriented. If I were you, though, I would be sure to attempt the junior positions.
I, like many others, have been thrilled with Enterprise in its entirety.
Please take off the blinders. Enterprise has the smallest following of any of the Treks, including the original, despite having the largest advertising budget and the broadest installed fanbase from prior series.
And people like you, arrogant sci-fi tasters of the finest, could do the least bit to admit that Enterprise is better than 2/3 of the complete filth that is television today.
For someone which opened with the phrase "fuck off," to accuse others of arrogance seems a bit presumptuous. That said, look, what you just said is roughly equivalent to "You could at least admit that Scientology is better than two thirds of the other new religions out there."
Just because the genre is dying and has nothing good doesn't make Enterprise any better. I will begrudgingly admit that this latest season has been pretty good; that said, don't kid yourself, seasons one through three were just awful. Even Voyager fans turned their noses up in disgust.
they were saddled with berman and Braga - the "ren and stimpy" of the star trek world.
Please get a clue. Rick Berman is brilliant; he's the motive impulse behind ST:TNG existing in the first place. Brannon Braga is the problem. Don't bang the drum until you know the music, poser fanboy.
Thats the thing, I know games so well I'm overlooked.
I'm only telling you this because I hope you'll listen. You're not being overlooked because you're really good at playing video games. You're being overlooked because playing video games has absolutely zero bearing on software development, and because nobody starts in game design.
What you're doing is saying "I have this neat idea for a jet engine that eats peroxide to keep itself clean, put me in the cutting edge lab at SkunkWorks," and all the while, your resume shows no experience in aeronautics, physics, materials engineering, mechanics or math.
If you want to be a game designer, first you have to become a programmer; no successful artist can work in ignorance of their tools. I say this with firmament having read your web page; not to be rude, but some of the things written there seem to be an indication of total ignorance of machine limitations.
You suggest things like that once we get machine vision going, suddenly AI will just jump into our laps, with neither any fortifying argument nor any evidence, and seemingly without realizing that many non-intelligent creatures can see. Belay any discussion of the watershed level of the intelligence level of a deer, please; we're well past the level of the intelligence of cockroaches already, and many far simpler creatures than cockroaches have sight.
Your progress in AI page contains things like logs of the crashes of MS Windows, frustration with image blending algorithms and compilers, photographs of rooms, but nothing actually about artificial intelligence beyond a rant filled with points like "okay, so, we need it to imprint like a duck, that'll be good, that way our computer will trust us and obey us; one way to teach it would be to put stuff on disk, but better would be voice recognition; you can use verbal commands to teach it, as long as they're in terms of objects and actions it's already familiar with." Maybe this'll be a shock to you: we don't have any computers which even have the concept of familiarity yet.
Making a list of loosely-related speculations about what might work well is not research, and it is most certainly not invention. If you want to be taken seriously, get rid of the list that says "my best invention is potential AI, the reason Cyc fails blah blah blah." Nobody's interested in bare speculation; it's useless.
Write functioning code, or stop pretending to be more than you are. This is hardly even up to the level of armchair quarterbacking.
From my position in the trenches I feel qualified to suggest that maybe four times in five or so, the fad following is by management, not the developers. Yes, it happens, but usually the developers have to play their own games; they figure it out in time, even if they got started on the wrong track.
Management, on the other hand, gets to say "I want a racing game, but set it fifty years in the future, make the hero grim and gritty, or maybe a girl, and um, I guess it's in... Morocco." More often than not, they never see the game running on screen.
As a world class game designer, I trust you're able to point out one game which you have implemented, or even designed in more depth than "oh you know what'd be cool is tenchu except you can fire poison darts from your shoes i should be a millionaire pass the bong."
To be quite frank, I don't consider myself a world class game designer, and many of the games I think of as my biggest failures carry both more invention and novelty than anything discussed on that site of yours. I should hope that it's just a teaser, and that you've got your code secretly hidden away.
Please do edify us: what makes you better than ten year olds which write lists of neato rad things they want to be millionaires from on the insides of their trapper keepers? There's quite a big gap between talking about and implementing, which you may discover if you actually attempt to implement something.
Maybe the reason you've never had an interview is that your cover letter for a software job lists how good you are at NES games and Angband, rather than work skills, accomplishments, goals or concrete mechanisms. There's more to making a video game than saying "i made a new comic book character; he has two swords and he can FLY AROUND ON THEM."
And yet somehow you still manage to take yourself seriously. By now I'd think even Geocities would have pulled your site in disgust.
Yeah, because a bigger network would never take over a failing network just to get a few strong series and gut the rest in favor of novel programming. Why, you'd have to be NBC looking at Sci-Fi to do something like that; Sci-Fi would never be involved in such a... hey, wait a minute.
Man, you know nothing about media convergence, do you?
That would be the joke, y'know. NBC bought Sci-Fi, hence my saying that... aw, nevermind.
Speaking of Sci-Fi, maybe they should take it over. They've done it before.
Both UPN and the Star Trek franchise are owned by the same company. So it will never go to a competing network.
Yeah, because a bigger network would never take over a failing network just to get a few strong series and gut the rest in favor of novel programming. Why, you'd have to be NBC looking at Sci-Fi to do something like that; Sci-Fi would never be involved in such a... hey, wait a minute.
It's like saying that the next Mario game should be on PS2.
Yeah, or like Sonic should be on the... hey, waitaminute again...
See the problem, both threads can now continue on to the new. If Instance has not been called at least once before multiple threads are running then two singleton objects can be created.
Read the code again. This is accounted for.
My statement that "we disagree about the meaning and I will leave it at that" was an attempt to slow down your hostility
The hostility wasn't there until you spent three generations of message ignoring the same question over and over again, like you've done yete again here.
Look it up, Brainiac. That's how it's spelled. You know, the noun conjugation of condescend.
That's okay, the condescention[sic] was lagniappe.
Lagniappe is a noun. Why are you attempting to use it as an adjective? (I won't even bother explaining to you what a Lagniappe is; you wouldn't believe me. Just take it on faith that even if you had used correct grammar, you'd still be out in left field.)
I note that you're still totally unable to answer my simple question: can you or can you not provide me an example of a c89 compiler which strips comments in the lexer? GotW is smarter than either of us; they're quite correct, and until you show me a c89 or better compiler which behaves otherwise, you're remaining on the clueless peg.
That's three messages in a row you've written a whole tirade without answering the question. Doesn't it embarrass you to be this pathetically obviously evasive?
If we're talking about the business about the TEXT and DATA segments, since standards are your big deal here, can you cite anything in the ANSI standard that says the TEXT segments must be combined as you suggest?
I never suggested any such thing, and TEXT and DATA have nothing do do with at what point in the compilation the comments are removed. You're just making things up.
By the way, C doesn't actually specify that there are TEXT and DATA segments at all; that's a Unix convention. C doesn't even require a lnkscript. When you get into embedded programming you'll maybe find this out. This reminds me of those people which insist bytes are eight bits, etc.
Some years ago, I did some work for DARPA on trustworthy C compilation
I don't believe you. Luckily, since I actually do have such ties, it's relatively easy for me to look people up. What was the project number, and what was your project UID? It won't give me your name; the entire purpose of a UID is to allow you to safely identify your work without identifying yourself.
You really shouldn't lie about things like this; eventually you'll bump into somoene which really does secure government contracting, and they'll ask you for procedural details which you cannot provide. I'm sure, though, that you'll either ignore the question or pretend there's no such thing as a work UID.
and one of the things we discovered was that there are LOTS of places where you can't make assumptions about the standard just because it was what you were used to.
Oh man, this makes my head hurt. You can't make any assumptions about a document which puts things into concrete terms? That doesn't make any sense. How could you possibly assume a part of a standards document? Either it's there or it isn't.
I haven't made any assumptions; you've made dozens, and ignored my requests for reference. Make this sort of handwavery all you want; you're transparently clueless.
As far as "significant faults in standards compliance", look at the dates I'm talking about, son. C89 was a 1989 standard, and I'm talking about 1979. Those compilers didn't fail to comply with the standard in 1979-84 because it would be five years before the standard was promulgated.
(sigh)
As any experienced C programmer knows, there were virtually no standards-compiliant C compilers before c89. The issue is not whether the C compiler adheres to the 1989 standard; the issue is whether the C compiler is new enough to be standards compliant at all. Again, I remind you that the standard is in strict defiance of your claims, and that all you have to do is either show me a passage in the standard which supports you or a compiler which supports you.
Make all the excuses about the examples I'm requesting being ill targeted that you like; the burden of proof is on you, not me, and you've been evading that burden as hard as you can.
you can push things called factors around; that has nothing to do with Fowlerian refactoring
I have never heard of anyone named Fowler
What a surprise. He both coined the term and codified the field as its own seperate entity. Doesn't it embarrass you to argue things you don't know about?
When I tell you to encapsulate your class, I imply that you would also reconsider the design of the other code that uses it to reduce coupling.
You keep saying "oh yeah, I meant this other thing." No, you didn't. If that's what you meant, you've not the faintest idea what encapsulation is. Quit playing the "and by car I meant hovercraft" game. It's childish.
To do this, you must define an interface and rewrite all the other code to make proper use of it.
That's called rewriting, not encapsulation. "And to overhaul your car, first you have to buy a new set of doors, and paint the body." No, it just doesn't work that way. Read a book.
I can't see how you can do this (source rewrite) without decoupling.
Actually, it's intensely difficult to decouple and encapsulate at the same time, because the two are contrarian interests, as I explained to you two posts ago.
I'm curious: are you able to explain what decoupling is? (braces self for something entirely random)
Well, there we are splitting linguistic hairs again. Human language is not that precise
No, but programming languages are. Maybe you didn't realize this, but a static is a very specific very concrete thing. We're not discussing english. If you like, you can crack the standard open and read it, since it's fairly plain that you don't know what you're on about (again.)
As for threaded code, I never write any Obviously. You also clearly don't write libraries, where you cannot guess about the nature of outside code.
On the contrary, I write little but libraries. I just write libraries for non-threaded code
There's no such thing. It's really a shame to watch an amateur flail about, insisting they're not an amateur, when instead they could be learning from others.
Big static local arrays are most definitely slower because they are built at runtime:
I'd love to know where you picked up this curious little myth. If you compile the following code to assembly, you will be disbused of this false belief:
int main() {
static const int foo[5] = {0};// lives in.RODATA
static int foo[5] = {0};// Compile-time allocated like any other base type }
Try compiling this to assembly. My gcc 3.4.3 generates c_Strings at runtime on the stack, even with optimization turned on.
Bwahahaha. This is awesome: you're telling me that statics are generated at runtime, and the example codce you give isn't even making statics. The reason those are generated at runtime is specifically because they're not static. Try making them static; suddenly you'll have a giant cluebulb.
Of course, had you bothered to read TC++PL or the standard, you'd already know that statics are allocated at compile-time.
I just write libraries for non-threaded code, and I don't "guess" the nature of the outside code
Attempting to decide whether the user's software may be threaded is a guess. God, you contradicted yourself within a single sentence.
I define it by telling the user exactly what the library is for. And it is usually not for threaded applications.
Mature library authors know better than to make asinine limitations like this, and also than to expect users to notice ridiculous caveats in documentation. This is the sort of totally unnessecary restriction that makes libaries useless in real applications. Welcome to/dev/null; enjoy your stay.
You do realize that the event mechanism in essentially e
There is a race condition you ignore that can only be avoided by assuming that AtomicSingleton::Instance is called at least once before any additional threads are created.
What the hell are you talking about? It doesn't matter if threads are created before a singleton. Could you be any more random?
That is the "non-sequitur" I made about library initialization.
Again, I know this is difficult for you, but try to keep up: library initializatin has nothing to do with class constructors.
we disagree about the meaning and spirt of it and I'll leave it at that.
Maybe you should read TC++PL or the standard, where it's clearly defined. I really don't care what you want to believe: the word has a concrete meaning, and whereas you can ramble on using it to mean any random thing that pops into your mind, you're still wrong. There's nothing more to it than that: if you use a term in regards to C++ in a way contrarian to the standard, you are wrong.
Make all the childish "I meant something else and you don't agree so it's a nonissue" arguemnts you want; you're not correct, and you're not going to become correct by making ridiculous seperations from the real meaning of terms. This is one of the primary signs of a rank amateur.
In fact, since you've shown a remarkable tendency to ignore things named for the specific purpose of looking things up, let me just save us both some trouble.
class AtomicSingleton {
public:
AtomicSingleton* Instance();
protected:
AtomicSingleton();
private:
AtomicSingleton* instance;
};
AtomicSingleton::Instance() {
if (!instance) {
AtomicSingleton* workspace = new AtomicSingleton;
if (!instance) {
instance = workspace;
} else {
delete workspace;
}
}
return instance; }
And what is the handle pattern but an application of information hiding?
I have explained this twice already. Decoupling is not encapsulation, even though the two go together quite frequently. Pimpl applies to pure-private classes, POD, and in situations where encapsulation simply does not factor into play. Before you ask me that a fourth time, please read my first three answers. Repeating myself is getting quite annoying.
pimpl gives the benefit of vtbl isolation, but that arises as an additional benefit - not the sole purpose.
If you would take the time to read the book from which pimpl comes, you would realize that the two reasons I lsited are in fact the reasons it was created.
You need a mutex for singleton to avoid a possible race condition at creation.
Not for things with atomic creation. I'm sure you'll point out that you discussed atomic creation, except that what I said was predicated on creation being atomic; therefore this is a non-argument.
Atomic class creation can only be achieved by creating the instance yourself
This is simply false. There are many techniques for achieving atomization. Take a look into non-mutexed threadsafe containers; they're not running on magic, and they work just fine with any UDT you want to throw at them.
you can not be guaranteed client programmers will do so correctly
Non-sequitor. Client programmers have nothing to do with the constructor of an object in a library they did not write.
(library init functions which can enforce this often seem to cause more trouble than they are worth)
What do library init functions have to do with atomic construction of an object? Hint: nothing.
I didn't ask you for a chronology, nor in fact for the condescention, only an example of a compiler which exhibits the behavior you suggest. Given that you're not certain of what compiler it was, and given that both VAX C and TinyC were known to have significant faults in standards compliance, I fear that you're confusing personal experience with low quality software for standard behavior, or perhaps even just misremembering.
I will ask you again. This is not a request for a chronology, nor is it a request for you to tell me you've been programming for 40 years in a question regarding a language which isn't yet 30 years old. This is a simple, straightforward question.
Can you provide an example of a c89 or better compiler which exhibits the behavior you suggest?
pimpl is very much a separation of implementation from interface - information hiding is essential to encapsulation.
pimpl has nothing to do with information hiding. This is a non-sequitor. Pimpl is in effect a c-focussed version of the Handle pattern. It is used to prevent long copy times on large objects and to prevent vtbl change from breaking dependant code. Before you get in a fit about how isolation from vtbl change is somehow an encapsulation issue, please take the time to consider that adding a single private member enacts this fault; this is not about information hiding, no matter how badly you may want for it to be.
You mention the most common legitimate use of class variables, the singleton. Obviously that requires some form of mutex.
Amusingly, no, it doesn't - the typical singleton is almost the only place wherein a member static is safe against race conditions without a mutex, assuming that you have a safe cleanup pattern and can make class creation atomic.
mutable does nothing to dig you deeper into a const trap,
It does when you use it to undo an existing overconst block of code, as you suggested.
I've just tested. GCC, BCC, ICC, Arm ADS, Arm SDT, CodeWarrior, MSVC 7.1 and GHOC don't. I don't have my copy of MetaWare High C anymore, but I bet it doesn't either. Can you provide an example of a compiler which is c89 or later which does?
I am reluctant to believe that GotW tricks are based on things which cannot be relied upon.
Slashdot Mirror
For the most part the public doesn't actually know what is good for them.
This is the arrogance which has led to the stagnation in current gaming, coupled with the lack of compelling new game mechanics. Watch a five year old kid for an hour and you've got two new games.
For the most part the public may not know what's good for them, but neither do you. You may make your borderline ecumenical diatribes about the ignorance of the public on your way out the door, please; for all the complaining you're doing about the book's author, you've done a hell of a lot less.
Armchair quarterbacks can't throw. When you release three new game mechanics, you may speak about the public's general ignorance. For now, all you're doing is displaying your own.
Oh, don't be ridiculous. That's like saying that nobody can sit down and start plotting a rocket path after reading a book on physics, because first they have to find out what air is, and then how to use a pencil, and then what direction up goes. The book isn't "every step you've ever fucking needed to write a game starting from learning to breathe." A calculus book doesn't cover arithmetic, an engineering book doesn't cover mechanics, a pointillism book doesn't cover paint blending, and there's no reason on earth that a book about game design should have to think about programming or APIs.
After that string of jabs, I almost expected to see the new Quaker rebranded Princess Amidala microwavable breakfast line, available in sizes ranging from single serving to 38" waist.
Hey, shut up, I've never made a NPHG joke. I get to. It's been long enough.
For being much more cerebral than most games, you sure have a fantastic control of the English language. On the front page alone I count twenty seven grammar errors, three conjugational errors, two spelling errors, and seven misused words. Don't trumpet yourself until you've learned the song, please; you're no more cerebral than the other ten dozen slashdotters which think themselves the gaming world's next Thomas Pynchon.
Oh, and a hint: PUTTING some various WORDS in all CAPITALS for no APPARENT reason is TACKY. Stop doing IT.
The line down in the middle of the m clearly being the user's head bent so far down in vomiting that all you can see are their neck and shoulders.
You predicted that graphical MUDs would be successful after years of successful text-based MUDs
Actually, his prediction postdates the first successful graphic MMOs, too. Have a look at the early histories of GEnie, Delphi and Compuserve; they offered massive online games whose game mechanics, if not whose quality of graphics, frequently rivalled or bettered those available today.
I have never promoted someone whose skillset was artistic and tool-use oriented into a software development position. In fact, going through the people I know, I can't think of almost anyone which has come into game design this way; it is my opinion that this is the "farm boy makes good" myth of our profession.
If you want a software development job, get a junior software development position. You'll be paid and treated like any other entry job, but at least it'll be in the right market. Also, don't follow these myths that small houses are easier to climb up the ranks through; it's the big houses like EA and Take Two which have the resources to hire unknowns and take risks on individuals. A five man operation which is hiring a sixth person will not risk 16% of their workforce on an unknown. EA, however, sees cheap labor; if you can do well there for a year, then the small houses will snap you up like gold.
Ask a lawyer, a surgeon, an architect. What you have to do is break your back with ridiculous hours for no pay for a year as a faceless minion of some gigundous corporation, because in those places you can make your name. Once you have the ability to say something like "yeah, I did the physics system on FIFA 2006, and I have a game design I'd like to implement," you will be taken far more seriously than if you just said "Hi, I have this GDD, hire me please."
Tester is a maybe-in; they're semi-code-oriented. If I were you, though, I would be sure to attempt the junior positions.
I, like many others, have been thrilled with Enterprise in its entirety.
Please take off the blinders. Enterprise has the smallest following of any of the Treks, including the original, despite having the largest advertising budget and the broadest installed fanbase from prior series.
And people like you, arrogant sci-fi tasters of the finest, could do the least bit to admit that Enterprise is better than 2/3 of the complete filth that is television today.
For someone which opened with the phrase "fuck off," to accuse others of arrogance seems a bit presumptuous. That said, look, what you just said is roughly equivalent to "You could at least admit that Scientology is better than two thirds of the other new religions out there."
Just because the genre is dying and has nothing good doesn't make Enterprise any better. I will begrudgingly admit that this latest season has been pretty good; that said, don't kid yourself, seasons one through three were just awful. Even Voyager fans turned their noses up in disgust.
they were saddled with berman and Braga - the "ren and stimpy" of the star trek world.
Please get a clue. Rick Berman is brilliant; he's the motive impulse behind ST:TNG existing in the first place. Brannon Braga is the problem. Don't bang the drum until you know the music, poser fanboy.
In comparison with Time Travel Janeway, my septic tank contains pure gold, too.
Thats the thing, I know games so well I'm overlooked.
I'm only telling you this because I hope you'll listen. You're not being overlooked because you're really good at playing video games. You're being overlooked because playing video games has absolutely zero bearing on software development, and because nobody starts in game design.
What you're doing is saying "I have this neat idea for a jet engine that eats peroxide to keep itself clean, put me in the cutting edge lab at SkunkWorks," and all the while, your resume shows no experience in aeronautics, physics, materials engineering, mechanics or math.
If you want to be a game designer, first you have to become a programmer; no successful artist can work in ignorance of their tools. I say this with firmament having read your web page; not to be rude, but some of the things written there seem to be an indication of total ignorance of machine limitations.
You suggest things like that once we get machine vision going, suddenly AI will just jump into our laps, with neither any fortifying argument nor any evidence, and seemingly without realizing that many non-intelligent creatures can see. Belay any discussion of the watershed level of the intelligence level of a deer, please; we're well past the level of the intelligence of cockroaches already, and many far simpler creatures than cockroaches have sight.
Your progress in AI page contains things like logs of the crashes of MS Windows, frustration with image blending algorithms and compilers, photographs of rooms, but nothing actually about artificial intelligence beyond a rant filled with points like "okay, so, we need it to imprint like a duck, that'll be good, that way our computer will trust us and obey us; one way to teach it would be to put stuff on disk, but better would be voice recognition; you can use verbal commands to teach it, as long as they're in terms of objects and actions it's already familiar with." Maybe this'll be a shock to you: we don't have any computers which even have the concept of familiarity yet.
Making a list of loosely-related speculations about what might work well is not research, and it is most certainly not invention. If you want to be taken seriously, get rid of the list that says "my best invention is potential AI, the reason Cyc fails blah blah blah." Nobody's interested in bare speculation; it's useless.
Write functioning code, or stop pretending to be more than you are. This is hardly even up to the level of armchair quarterbacking.
From my position in the trenches I feel qualified to suggest that maybe four times in five or so, the fad following is by management, not the developers. Yes, it happens, but usually the developers have to play their own games; they figure it out in time, even if they got started on the wrong track.
... Morocco." More often than not, they never see the game running on screen.
Management, on the other hand, gets to say "I want a racing game, but set it fifty years in the future, make the hero grim and gritty, or maybe a girl, and um, I guess it's in
As a world class game designer, I trust you're able to point out one game which you have implemented, or even designed in more depth than "oh you know what'd be cool is tenchu except you can fire poison darts from your shoes i should be a millionaire pass the bong."
To be quite frank, I don't consider myself a world class game designer, and many of the games I think of as my biggest failures carry both more invention and novelty than anything discussed on that site of yours. I should hope that it's just a teaser, and that you've got your code secretly hidden away.
Please do edify us: what makes you better than ten year olds which write lists of neato rad things they want to be millionaires from on the insides of their trapper keepers? There's quite a big gap between talking about and implementing, which you may discover if you actually attempt to implement something.
Maybe the reason you've never had an interview is that your cover letter for a software job lists how good you are at NES games and Angband, rather than work skills, accomplishments, goals or concrete mechanisms. There's more to making a video game than saying "i made a new comic book character; he has two swords and he can FLY AROUND ON THEM."
And yet somehow you still manage to take yourself seriously. By now I'd think even Geocities would have pulled your site in disgust.
Yeah, because a bigger network would never take over a failing network just to get a few strong series and gut the rest in favor of novel programming. Why, you'd have to be NBC looking at Sci-Fi to do something like that; Sci-Fi would never be involved in such a ... hey, wait a minute.
... aw, nevermind.
Man, you know nothing about media convergence, do you?
That would be the joke, y'know. NBC bought Sci-Fi, hence my saying that
Speaking of Sci-Fi, maybe they should take it over. They've done it before.
... hey, wait a minute.
... hey, waitaminute again...
Both UPN and the Star Trek franchise are owned by the same company. So it will never go to a competing network.
Yeah, because a bigger network would never take over a failing network just to get a few strong series and gut the rest in favor of novel programming. Why, you'd have to be NBC looking at Sci-Fi to do something like that; Sci-Fi would never be involved in such a
It's like saying that the next Mario game should be on PS2.
Yeah, or like Sonic should be on the
See the problem, both threads can now continue on to the new. If Instance has not been called at least once before multiple threads are running then two singleton objects can be created.
Read the code again. This is accounted for.
My statement that "we disagree about the meaning and I will leave it at that" was an attempt to slow down your hostility
The hostility wasn't there until you spent three generations of message ignoring the same question over and over again, like you've done yete again here.
condescention[sic]
Look it up, Brainiac. That's how it's spelled. You know, the noun conjugation of condescend.
That's okay, the condescention[sic] was lagniappe.
Lagniappe is a noun. Why are you attempting to use it as an adjective? (I won't even bother explaining to you what a Lagniappe is; you wouldn't believe me. Just take it on faith that even if you had used correct grammar, you'd still be out in left field.)
I note that you're still totally unable to answer my simple question: can you or can you not provide me an example of a c89 compiler which strips comments in the lexer? GotW is smarter than either of us; they're quite correct, and until you show me a c89 or better compiler which behaves otherwise, you're remaining on the clueless peg.
That's three messages in a row you've written a whole tirade without answering the question. Doesn't it embarrass you to be this pathetically obviously evasive?
If we're talking about the business about the TEXT and DATA segments, since standards are your big deal here, can you cite anything in the ANSI standard that says the TEXT segments must be combined as you suggest?
I never suggested any such thing, and TEXT and DATA have nothing do do with at what point in the compilation the comments are removed. You're just making things up.
By the way, C doesn't actually specify that there are TEXT and DATA segments at all; that's a Unix convention. C doesn't even require a lnkscript. When you get into embedded programming you'll maybe find this out. This reminds me of those people which insist bytes are eight bits, etc.
Some years ago, I did some work for DARPA on trustworthy C compilation
I don't believe you. Luckily, since I actually do have such ties, it's relatively easy for me to look people up. What was the project number, and what was your project UID? It won't give me your name; the entire purpose of a UID is to allow you to safely identify your work without identifying yourself.
You really shouldn't lie about things like this; eventually you'll bump into somoene which really does secure government contracting, and they'll ask you for procedural details which you cannot provide. I'm sure, though, that you'll either ignore the question or pretend there's no such thing as a work UID.
and one of the things we discovered was that there are LOTS of places where you can't make assumptions about the standard just because it was what you were used to.
Oh man, this makes my head hurt. You can't make any assumptions about a document which puts things into concrete terms? That doesn't make any sense. How could you possibly assume a part of a standards document? Either it's there or it isn't.
I haven't made any assumptions; you've made dozens, and ignored my requests for reference. Make this sort of handwavery all you want; you're transparently clueless.
As far as "significant faults in standards compliance", look at the dates I'm talking about, son. C89 was a 1989 standard, and I'm talking about 1979. Those compilers didn't fail to comply with the standard in 1979-84 because it would be five years before the standard was promulgated.
(sigh)
As any experienced C programmer knows, there were virtually no standards-compiliant C compilers before c89. The issue is not whether the C compiler adheres to the 1989 standard; the issue is whether the C compiler is new enough to be standards compliant at all. Again, I remind you that the standard is in strict defiance of your claims, and that all you have to do is either show me a passage in the standard which supports you or a compiler which supports you.
Make all the excuses about the examples I'm requesting being ill targeted that you like; the burden of proof is on you, not me, and you've been evading that burden as hard as you can.
Even one example would do. Do you have one?
In this business, 1979
This is too stupid to mock.
you can push things called factors around; that has nothing to do with Fowlerian refactoring
// lives in .RODATA // Compile-time allocated like any other base type
/dev/null; enjoy your stay.
I have never heard of anyone named Fowler
What a surprise. He both coined the term and codified the field as its own seperate entity. Doesn't it embarrass you to argue things you don't know about?
When I tell you to encapsulate your class, I imply that you would also reconsider the design of the other code that uses it to reduce coupling.
You keep saying "oh yeah, I meant this other thing." No, you didn't. If that's what you meant, you've not the faintest idea what encapsulation is. Quit playing the "and by car I meant hovercraft" game. It's childish.
To do this, you must define an interface and rewrite all the other code to make proper use of it.
That's called rewriting, not encapsulation. "And to overhaul your car, first you have to buy a new set of doors, and paint the body." No, it just doesn't work that way. Read a book.
I can't see how you can do this (source rewrite) without decoupling.
Actually, it's intensely difficult to decouple and encapsulate at the same time, because the two are contrarian interests, as I explained to you two posts ago.
I'm curious: are you able to explain what decoupling is? (braces self for something entirely random)
Well, there we are splitting linguistic hairs again. Human language is not that precise
No, but programming languages are. Maybe you didn't realize this, but a static is a very specific very concrete thing. We're not discussing english. If you like, you can crack the standard open and read it, since it's fairly plain that you don't know what you're on about (again.)
As for threaded code, I never write any Obviously. You also clearly don't write libraries, where you cannot guess about the nature of outside code.
On the contrary, I write little but libraries. I just write libraries for non-threaded code
There's no such thing. It's really a shame to watch an amateur flail about, insisting they're not an amateur, when instead they could be learning from others.
Big static local arrays are most definitely slower because they are built at runtime:
I'd love to know where you picked up this curious little myth. If you compile the following code to assembly, you will be disbused of this false belief:
int main() {
static const int foo[5] = {0};
static int foo[5] = {0};
}
Try compiling this to assembly. My gcc 3.4.3 generates c_Strings at runtime on the stack, even with optimization turned on.
Bwahahaha. This is awesome: you're telling me that statics are generated at runtime, and the example codce you give isn't even making statics. The reason those are generated at runtime is specifically because they're not static. Try making them static; suddenly you'll have a giant cluebulb.
Of course, had you bothered to read TC++PL or the standard, you'd already know that statics are allocated at compile-time.
I just write libraries for non-threaded code, and I don't "guess" the nature of the outside code
Attempting to decide whether the user's software may be threaded is a guess. God, you contradicted yourself within a single sentence.
I define it by telling the user exactly what the library is for. And it is usually not for threaded applications.
Mature library authors know better than to make asinine limitations like this, and also than to expect users to notice ridiculous caveats in documentation. This is the sort of totally unnessecary restriction that makes libaries useless in real applications. Welcome to
You do realize that the event mechanism in essentially e
There is a race condition you ignore that can only be avoided by assuming that AtomicSingleton::Instance is called at least once before any additional threads are created.
What the hell are you talking about? It doesn't matter if threads are created before a singleton. Could you be any more random?
That is the "non-sequitur" I made about library initialization.
Again, I know this is difficult for you, but try to keep up: library initializatin has nothing to do with class constructors.
we disagree about the meaning and spirt of it and I'll leave it at that.
Maybe you should read TC++PL or the standard, where it's clearly defined. I really don't care what you want to believe: the word has a concrete meaning, and whereas you can ramble on using it to mean any random thing that pops into your mind, you're still wrong. There's nothing more to it than that: if you use a term in regards to C++ in a way contrarian to the standard, you are wrong.
Make all the childish "I meant something else and you don't agree so it's a nonissue" arguemnts you want; you're not correct, and you're not going to become correct by making ridiculous seperations from the real meaning of terms. This is one of the primary signs of a rank amateur.
In fact, since you've shown a remarkable tendency to ignore things named for the specific purpose of looking things up, let me just save us both some trouble.
class AtomicSingleton {
public:
AtomicSingleton* Instance();
protected:
AtomicSingleton();
private:
AtomicSingleton* instance;
};
AtomicSingleton::Instance() {
if (!instance) {
AtomicSingleton* workspace = new AtomicSingleton;
if (!instance) {
instance = workspace;
} else {
delete workspace;
}
}
return instance;
}
Gee, that was hard. *cough*
And what is the handle pattern but an application of information hiding?
I have explained this twice already. Decoupling is not encapsulation, even though the two go together quite frequently. Pimpl applies to pure-private classes, POD, and in situations where encapsulation simply does not factor into play. Before you ask me that a fourth time, please read my first three answers. Repeating myself is getting quite annoying.
pimpl gives the benefit of vtbl isolation, but that arises as an additional benefit - not the sole purpose.
If you would take the time to read the book from which pimpl comes, you would realize that the two reasons I lsited are in fact the reasons it was created.
You need a mutex for singleton to avoid a possible race condition at creation.
Not for things with atomic creation. I'm sure you'll point out that you discussed atomic creation, except that what I said was predicated on creation being atomic; therefore this is a non-argument.
Atomic class creation can only be achieved by creating the instance yourself
This is simply false. There are many techniques for achieving atomization. Take a look into non-mutexed threadsafe containers; they're not running on magic, and they work just fine with any UDT you want to throw at them.
you can not be guaranteed client programmers will do so correctly
Non-sequitor. Client programmers have nothing to do with the constructor of an object in a library they did not write.
(library init functions which can enforce this often seem to cause more trouble than they are worth)
What do library init functions have to do with atomic construction of an object? Hint: nothing.
I didn't ask you for a chronology, nor in fact for the condescention, only an example of a compiler which exhibits the behavior you suggest. Given that you're not certain of what compiler it was, and given that both VAX C and TinyC were known to have significant faults in standards compliance, I fear that you're confusing personal experience with low quality software for standard behavior, or perhaps even just misremembering.
I will ask you again. This is not a request for a chronology, nor is it a request for you to tell me you've been programming for 40 years in a question regarding a language which isn't yet 30 years old. This is a simple, straightforward question.
Can you provide an example of a c89 or better compiler which exhibits the behavior you suggest?
pimpl is very much a separation of implementation from interface - information hiding is essential to encapsulation.
pimpl has nothing to do with information hiding. This is a non-sequitor. Pimpl is in effect a c-focussed version of the Handle pattern. It is used to prevent long copy times on large objects and to prevent vtbl change from breaking dependant code. Before you get in a fit about how isolation from vtbl change is somehow an encapsulation issue, please take the time to consider that adding a single private member enacts this fault; this is not about information hiding, no matter how badly you may want for it to be.
You mention the most common legitimate use of class variables, the singleton. Obviously that requires some form of mutex.
Amusingly, no, it doesn't - the typical singleton is almost the only place wherein a member static is safe against race conditions without a mutex, assuming that you have a safe cleanup pattern and can make class creation atomic.
mutable does nothing to dig you deeper into a const trap,
It does when you use it to undo an existing overconst block of code, as you suggested.
Oh, my. I apologize: the way that was phrased, I had taken it as sarcasm.
I've just tested. GCC, BCC, ICC, Arm ADS, Arm SDT, CodeWarrior, MSVC 7.1 and GHOC don't. I don't have my copy of MetaWare High C anymore, but I bet it doesn't either. Can you provide an example of a compiler which is c89 or later which does?
I am reluctant to believe that GotW tricks are based on things which cannot be relied upon.