Tell me what section says "oh, but if you didn't have a user-defined destructor, don't worry about 5.3.5".
How can I show you a section that doesn't exist? It's not pertinent information. When you call destroy on a pointer to a base class which actually points to memory held by a derived class, and neither of the two classes have a destructor, it's a non-issue. Where is the section on how to grow your own tea leaves? It's not in the specification because it's non-pertinent. When you don't have destructors, the issue of a base not having a virtual destructor is a NON-issue.
No they don't. Structs without any virtual methods are just like old C structs in many (most? all?) implementations.
That was my point; structs and classes are the same, except for the default visibility of its members. You made a statement indicating you thought structs didn't have vtables, and I was saying they certainly do ("when needed" I admit was omitted). They operate no differently from classes.
So far you made very strong statements about what keywords you didn't think C++ has, and implementation dependant assumptions about the existance of vtables.
It's good you are redundantly attacking me for mistakes I've already admitted; if you actually talked about that dumb-ass test you mentioned, you'd have nothing in your favor.
Question for you, genius. Don't bother answering me, because I will never believe you didn't look this up, but answer it to yourself nonetheless so you know how clueless you are. What is the byte size of the char date type and is it signed or unsigned, as defined by either the C or C++ specification? I know the answer without looking. Do you?
Now, a suggestion. Such questions are moronic. Don't ask your programmers IDIOTIC things like whether void main(void) is valid or not. You might have the worlds greatest Java programmer sitting in front of you, and they're a few months worth of C++ experience away from being a FANTASTIC C++ programmer, and such a DUMB ASS question would cause you to reject that person in favor of some neophyte with a penchant for falling asleep at the keyboard who just took a C++ class and knew the answer. Instead, ask them to write code, even if breaks down into pseudocode, to determine how smart they are, and how they think. Ask them to write a quick text encryption tool that uses a password to encode/decode text, and give them 15 minutes to code some basic functions up.
The problem with that dumbass test you showed us is twofold: one, it doesn't really say ANYTHING about if they are a good programmer or not and two, the guy was just plain wrong. If you've been impressed by anyone after quizzing them that way, you must have a hell of a team there. Oh man, Microsoft watch out! THEY HAVE GUYS THAT KNOW NOT TO WRITE VOID MAIN(VOID). Holy crap!
Seriously though. You made me think of the boss in "Office Space." That test is wrong from the get-go, and you're using it to measure interviewees? Sweet.
I agree...Descent was a truly revolutionary game. Humans probably need to evolve a little more though before you can expect such freedom of movement in an FPS to be widely accepted. I LOVED playing that game online, but it could be really disorienting, and I can understand how lots of people couldn't get into it.
But the object *has no destructors* in the example, so it's perfectly safe. If the base or derived object had destructors that were not marked as virtual then yes, there could be a problem because the derived destructor would not be called.
You're mis-reading that description (5.3.5). Classes don't have to have destructors at all. That description is misleading because it makes the assumption that there is a destructor in the dynamic type that won't get called when delete is called on the static type. The behavior is undefined ONLY if the dynamic type has a destructor. If neither the base nor derived object have destructors, delete's job amounts to nothing more than a simple free call.
Don't insinuate I'm a bad programmer. I consider you to have intellectual shortcomings yourself for using that guy's "test" on your potential programmers. You don't seem to see the kernel of truths in his statements and how they are twisted into something completely nonsensical. They're nonsensical nonetheless.
Consider this hypothetical case: If an implementation wants to allocate small structs (things with no vtable) in one memory area (say, on-chip) and large ones in another (say, an external dram); in my understanding it is possible to have a valid compiler that does so. In your case you might be deleting from the wrong pool of memeory.
This has nothing to do with anything. For starters, structs all have vtables. For another, the constructors/destructors don't decide which memory manager their objects are stored in, you have to override new and delete to do that. Overriding new and delete are not related to the issue of virtual destructors at all.
What torture it must be for programmers you interview to have to endure such a mountain of misinformed superiority. I really feel for them.
It means nothing, that article is pure crap. I was dead serious about all my points (except "using"), and my summary.
Go back to my first post point by point and comment. Calling destroy to a base pointer which points to a derived object is SAFE. C++ destroys objects in two steps: first, it calls the destructor, which presumably performs cleanup operatings, then it frees the memory. The amount of memory it frees is determined by a looking based on the memory the pointer points to, not the size of the object. There were no destructors defined at all for either the base nor the derived object, so there's nothing wrong with calling destroy on a base pointer. In fact, LOTS of class APIs do exactly this, and unless a derived class is destroyed this way which defines a non-virtual destructor, and that destructor needs to free up resources, this results in absolutely NO harm.
Discuss my points, don't keep throwing that guy's credentials at me. Is that why you value that article? Think for yourself. It's 100% garbage.
I just found out "using" *is* a C++ keyword, so I was wrong there, but it's new and the rest of it is garbage.
Listen, have you looked at the complete C++ specification? It's 80% useless crap. The multiple inheritance model is more problem than solution. That this guy chaired on the C++ committee means nothing...he's perfectly capable of spewing utter nonsense as much as anyone else.
#1: Worry about problems that matter. At worst, when using a different compiler that doesn't support void main(), you will see an error.
#2: Another non-problem. There were no destructors at all, so deleting a pointer to a base class is fine.
#3: What the hell is "using!?" There's no such keyword in C++. To make base functions visible, first mark them as virtual in the base, then to call them, use the syntax BaseClass::function.
#4: I see no reason why a derived function can't change the value of default parameters. It's a different class, albeit inherited.
Also, deleting pb won't leave anything corrupted. delete works exactly like free, it releases memory by looking up a pointer, so it doesn't matter if you cast it to a (char*) and called delete...the memory will still be freed. The only potential problem is if Derived had a non-virtual destructor, it wouldn't be called. But there are no destructors, so there is no clean-up work to perform, so there are no other resources to be left hanging.
The guy that wrote that doesn't know squat about C++, and you ought to NOT quiz your programmers based on THAT garbage.
Now if they'll just redo the english dubbing of Castle in the Sky and get some voice actors that don't make you try to scratch your skin off, and get rid of that uber-cheesy non-stop TADADA! music that drones ENDLESSLY, I'll be set.
The question doesn't have an answer; farming out the load means, by definition, using other servers to balance the load out.
But assuming you can afford to set up a couple dedicated servers on short notice, how about:
1) get your basic servers up with apache and whatever else you need to serve the pages 2) mirror your content with rsync, both the web pages and any SQL databases it uses 3) set up your DNS to rotate the IPs for each new server
I really love the one about the sysadmin whose server got slammed by Slashdot and absolutely could NOT figure out how to farm the load, so instead they just put up a page with basically nothing on it. That one's my favorite.
Also never work for anyone without getting periodic payments. Once a week is now my standard. If someone doesn't like it, they're probably planning to withhold payment at some point and are just using your work in an exploratory fashion, to see if they like it or will actually use it; paying later if they green-light it, of course, if they can even afford it...after you've done the work.
But what if I say: "Today I don't volunteer. Today you pay me or no more service."
That's essentially what he did. He let them ride free to a point, then asked that they begin paying for service. They refused, so he shut them down. That's 100% legal and within his rights, and I think if that guy gets himself half a clueful lawyer, that Sherrif's office is going to be seeing a handful of both criminal and civil charges against them.
The man did it out of his own pocket and asked to be paid back. The Sherrif's weren't FORCED to become dependent on the web site; they CHOSE to use it and they CHOSE to allow Pat Richard to continue to pay out of his own pocket, despite repeated attempts to negotiate payment.
It's Pat Richard's property, and if the Sherrif's office wants control of it, they need to compensate the man for the time and money he spent on it. The "priviledge" of developing a web site for a Sherrif's office such as one that would arrest a man after abusing his resources for so long must be quite an honor!
Macomb County Sheriff's Office: FUCK YOU. Freeloading losers.
Spam is a hot issue...but just because it's hot and the issue bugging you now, don't let that make you forget how important free speech is, and accessibility to the internet is probably the greatest free speech engine since Gutenberg's printing press.
Yes, but all things being equal, the ratio should not be expected to scale evenly. How well-known an ISP is to their potential market influences the make-up of their market. That is to say, the percentages of "types of customers" doesn't stay the same as an ISP grows/shrinks. If a small ISP with a customer base of 50% geeks and 50% non-geeks grows to 100,000, that 50% geek rate is going to drop dramatically.
Basically, the ratio you're talking about is, itself, affected by UUnet's size and age.
Any ISP of sufficient size is going to be accused of being spam-friendly because there's simply no way to ensure that any given new customer is NOT going to spam. There's simply no way to ensure such a thing.
It's a numbers game. The only way to NOT host a spammer is to close your doors and go out of business. EVERY ISP has to close their doors, because as soon as UUnet and Rackspace do, all their customers are going to host at your favorite ISP that you think is responsible and doesn't host spammers. You will find, soon enough, that they indeed DO host spammers when they show up using fake credit cards and sign up for new accounts and start pumping spam. When you suddenly can't deliver email anymore because SPEWS has decided that your favorite ISP is spammer-friendly, don't come crying to me...you have to be tough on those spammer-friendly ISP's after all!
Spammers can sneak into even the most STRINGENT anti-spam ISP network. A stolen credit card that works only once gets a spammer an account that can deliver many thousands of letters before they're shut down. UUnet isn't spam-friendly anymore than Rackspace is spam-friendly. Spam is going nowhere until good authentication techniques are implemented internet-wide.
He didn't say that because there's a cause to the effect of spamming, it should be legal. He simply said that so long as spam paid off, there will be spam, legal or not, and that if you want to solve the problem you need to look at making it not pay off.
Too many of you sit around with arguments in your mouth waiting for someone to come along and trigger your spewage. Shut the fuck up and THINK about what's being said before you open your pie-holes.
You idiots need remedial moderation classes. This isn't flamebait.
Flamebait is "This sounds like something only Nazis would use." Saying it belongs last on the list of things to give a shit about isn't flamebait, it's an opinion containing profanity.
But the funny thing is, I have far, far, far LESS trouble keeping my system updated and running smoothly with Gentoo than I ever had with Mandrake, RedHat or Debian.
Who really cares if athletes artificially buff themselves up? It's not the end of the world. It's an issue somewhere BELOW the last item on the list of things to give a shit about when looking at the uses for a technology like this.
Sometimes people say things at just the right time to make it stinking hilarious. I have been compiling Gentoo+KDE on an older computer here since Saturday afternoon.
I agree everyone should try it. Rather than argue about whether it saves time or wastes time, everyone should start writing unit tests for every project before you begin coding it, give it a couple years, then decide whether it's worth it or not.
Code robots to test interfaces in large systems is as ancient as programming itself; it's probably the grandfather of unit testing, but not unit testing itself. Also, good design makes features easy to add later on, not unit testing. Ascribing "new features were easy to add later on" to unit testing is disingenuous; that's something every project I've ever worked on strove for, and save for perhaps my first few years as a programmer, achieved, and generally early on in the project, not later.
Slashdot Mirror
Tell me what section says "oh, but if you didn't have a user-defined destructor, don't worry about 5.3.5".
How can I show you a section that doesn't exist? It's not pertinent information. When you call destroy on a pointer to a base class which actually points to memory held by a derived class, and neither of the two classes have a destructor, it's a non-issue. Where is the section on how to grow your own tea leaves? It's not in the specification because it's non-pertinent. When you don't have destructors, the issue of a base not having a virtual destructor is a NON-issue.
No they don't. Structs without any virtual methods are just like old C structs in many (most? all?) implementations.
That was my point; structs and classes are the same, except for the default visibility of its members. You made a statement indicating you thought structs didn't have vtables, and I was saying they certainly do ("when needed" I admit was omitted). They operate no differently from classes.
So far you made very strong statements about what keywords you didn't think C++ has, and implementation dependant assumptions about the existance of vtables.
It's good you are redundantly attacking me for mistakes I've already admitted; if you actually talked about that dumb-ass test you mentioned, you'd have nothing in your favor.
Question for you, genius. Don't bother answering me, because I will never believe you didn't look this up, but answer it to yourself nonetheless so you know how clueless you are. What is the byte size of the char date type and is it signed or unsigned, as defined by either the C or C++ specification? I know the answer without looking. Do you?
Now, a suggestion. Such questions are moronic. Don't ask your programmers IDIOTIC things like whether void main(void) is valid or not. You might have the worlds greatest Java programmer sitting in front of you, and they're a few months worth of C++ experience away from being a FANTASTIC C++ programmer, and such a DUMB ASS question would cause you to reject that person in favor of some neophyte with a penchant for falling asleep at the keyboard who just took a C++ class and knew the answer. Instead, ask them to write code, even if breaks down into pseudocode, to determine how smart they are, and how they think. Ask them to write a quick text encryption tool that uses a password to encode/decode text, and give them 15 minutes to code some basic functions up.
The problem with that dumbass test you showed us is twofold: one, it doesn't really say ANYTHING about if they are a good programmer or not and two, the guy was just plain wrong. If you've been impressed by anyone after quizzing them that way, you must have a hell of a team there. Oh man, Microsoft watch out! THEY HAVE GUYS THAT KNOW NOT TO WRITE VOID MAIN(VOID). Holy crap!
Seriously though. You made me think of the boss in "Office Space." That test is wrong from the get-go, and you're using it to measure interviewees? Sweet.
Unreal Tournament
Descent
Shogo
I agree...Descent was a truly revolutionary game. Humans probably need to evolve a little more though before you can expect such freedom of movement in an FPS to be widely accepted. I LOVED playing that game online, but it could be really disorienting, and I can understand how lots of people couldn't get into it.
But the object *has no destructors* in the example, so it's perfectly safe. If the base or derived object had destructors that were not marked as virtual then yes, there could be a problem because the derived destructor would not be called.
You're mis-reading that description (5.3.5). Classes don't have to have destructors at all. That description is misleading because it makes the assumption that there is a destructor in the dynamic type that won't get called when delete is called on the static type. The behavior is undefined ONLY if the dynamic type has a destructor. If neither the base nor derived object have destructors, delete's job amounts to nothing more than a simple free call.
Don't insinuate I'm a bad programmer. I consider you to have intellectual shortcomings yourself for using that guy's "test" on your potential programmers. You don't seem to see the kernel of truths in his statements and how they are twisted into something completely nonsensical. They're nonsensical nonetheless.
Consider this hypothetical case: If an implementation wants to allocate small structs (things with no vtable) in one memory area (say, on-chip) and large ones in another (say, an external dram); in my understanding it is possible to have a valid compiler that does so. In your case you might be deleting from the wrong pool of memeory.
This has nothing to do with anything. For starters, structs all have vtables. For another, the constructors/destructors don't decide which memory manager their objects are stored in, you have to override new and delete to do that. Overriding new and delete are not related to the issue of virtual destructors at all.
What torture it must be for programmers you interview to have to endure such a mountain of misinformed superiority. I really feel for them.
When was it adopted into the ANSI standard? 8 years ago you say? Somehow I doubt that.
It means nothing, that article is pure crap. I was dead serious about all my points (except "using"), and my summary.
Go back to my first post point by point and comment. Calling destroy to a base pointer which points to a derived object is SAFE. C++ destroys objects in two steps: first, it calls the destructor, which presumably performs cleanup operatings, then it frees the memory. The amount of memory it frees is determined by a looking based on the memory the pointer points to, not the size of the object. There were no destructors defined at all for either the base nor the derived object, so there's nothing wrong with calling destroy on a base pointer. In fact, LOTS of class APIs do exactly this, and unless a derived class is destroyed this way which defines a non-virtual destructor, and that destructor needs to free up resources, this results in absolutely NO harm.
Discuss my points, don't keep throwing that guy's credentials at me. Is that why you value that article? Think for yourself. It's 100% garbage.
I just found out "using" *is* a C++ keyword, so I was wrong there, but it's new and the rest of it is garbage.
Listen, have you looked at the complete C++ specification? It's 80% useless crap. The multiple inheritance model is more problem than solution. That this guy chaired on the C++ committee means nothing...he's perfectly capable of spewing utter nonsense as much as anyone else.
#1: Worry about problems that matter. At worst, when using a different compiler that doesn't support void main(), you will see an error.
#2: Another non-problem. There were no destructors at all, so deleting a pointer to a base class is fine.
#3: What the hell is "using!?" There's no such keyword in C++. To make base functions visible, first mark them as virtual in the base, then to call them, use the syntax BaseClass::function.
#4: I see no reason why a derived function can't change the value of default parameters. It's a different class, albeit inherited.
Also, deleting pb won't leave anything corrupted. delete works exactly like free, it releases memory by looking up a pointer, so it doesn't matter if you cast it to a (char*) and called delete...the memory will still be freed. The only potential problem is if Derived had a non-virtual destructor, it wouldn't be called. But there are no destructors, so there is no clean-up work to perform, so there are no other resources to be left hanging.
The guy that wrote that doesn't know squat about C++, and you ought to NOT quiz your programmers based on THAT garbage.
Now if they'll just redo the english dubbing of Castle in the Sky and get some voice actors that don't make you try to scratch your skin off, and get rid of that uber-cheesy non-stop TADADA! music that drones ENDLESSLY, I'll be set.
The question doesn't have an answer; farming out the load means, by definition, using other servers to balance the load out.
But assuming you can afford to set up a couple dedicated servers on short notice, how about:
1) get your basic servers up with apache and whatever else you need to serve the pages
2) mirror your content with rsync, both the web pages and any SQL databases it uses
3) set up your DNS to rotate the IPs for each new server
I really love the one about the sysadmin whose server got slammed by Slashdot and absolutely could NOT figure out how to farm the load, so instead they just put up a page with basically nothing on it. That one's my favorite.
Also never work for anyone without getting periodic payments. Once a week is now my standard. If someone doesn't like it, they're probably planning to withhold payment at some point and are just using your work in an exploratory fashion, to see if they like it or will actually use it; paying later if they green-light it, of course, if they can even afford it...after you've done the work.
But what if I say: "Today I don't volunteer. Today you pay me or no more service."
That's essentially what he did. He let them ride free to a point, then asked that they begin paying for service. They refused, so he shut them down. That's 100% legal and within his rights, and I think if that guy gets himself half a clueful lawyer, that Sherrif's office is going to be seeing a handful of both criminal and civil charges against them.
The man did it out of his own pocket and asked to be paid back. The Sherrif's weren't FORCED to become dependent on the web site; they CHOSE to use it and they CHOSE to allow Pat Richard to continue to pay out of his own pocket, despite repeated attempts to negotiate payment.
It's Pat Richard's property, and if the Sherrif's office wants control of it, they need to compensate the man for the time and money he spent on it. The "priviledge" of developing a web site for a Sherrif's office such as one that would arrest a man after abusing his resources for so long must be quite an honor!
Macomb County Sheriff's Office: FUCK YOU. Freeloading losers.
I think because Free Speech > Spam Death.
Spam is a hot issue...but just because it's hot and the issue bugging you now, don't let that make you forget how important free speech is, and accessibility to the internet is probably the greatest free speech engine since Gutenberg's printing press.
Yes, but all things being equal, the ratio should not be expected to scale evenly. How well-known an ISP is to their potential market influences the make-up of their market. That is to say, the percentages of "types of customers" doesn't stay the same as an ISP grows/shrinks. If a small ISP with a customer base of 50% geeks and 50% non-geeks grows to 100,000, that 50% geek rate is going to drop dramatically.
Basically, the ratio you're talking about is, itself, affected by UUnet's size and age.
Any ISP of sufficient size is going to be accused of being spam-friendly because there's simply no way to ensure that any given new customer is NOT going to spam. There's simply no way to ensure such a thing.
It's a numbers game. The only way to NOT host a spammer is to close your doors and go out of business. EVERY ISP has to close their doors, because as soon as UUnet and Rackspace do, all their customers are going to host at your favorite ISP that you think is responsible and doesn't host spammers. You will find, soon enough, that they indeed DO host spammers when they show up using fake credit cards and sign up for new accounts and start pumping spam. When you suddenly can't deliver email anymore because SPEWS has decided that your favorite ISP is spammer-friendly, don't come crying to me...you have to be tough on those spammer-friendly ISP's after all!
Spammers can sneak into even the most STRINGENT anti-spam ISP network. A stolen credit card that works only once gets a spammer an account that can deliver many thousands of letters before they're shut down. UUnet isn't spam-friendly anymore than Rackspace is spam-friendly. Spam is going nowhere until good authentication techniques are implemented internet-wide.
He didn't say that because there's a cause to the effect of spamming, it should be legal. He simply said that so long as spam paid off, there will be spam, legal or not, and that if you want to solve the problem you need to look at making it not pay off.
Too many of you sit around with arguments in your mouth waiting for someone to come along and trigger your spewage. Shut the fuck up and THINK about what's being said before you open your pie-holes.
You idiots need remedial moderation classes. This isn't flamebait.
Flamebait is "This sounds like something only Nazis would use." Saying it belongs last on the list of things to give a shit about isn't flamebait, it's an opinion containing profanity.
Get a clue.
But the funny thing is, I have far, far, far LESS trouble keeping my system updated and running smoothly with Gentoo than I ever had with Mandrake, RedHat or Debian.
Who really cares if athletes artificially buff themselves up? It's not the end of the world. It's an issue somewhere BELOW the last item on the list of things to give a shit about when looking at the uses for a technology like this.
Sometimes people say things at just the right time to make it stinking hilarious. I have been compiling Gentoo+KDE on an older computer here since Saturday afternoon.
I agree everyone should try it. Rather than argue about whether it saves time or wastes time, everyone should start writing unit tests for every project before you begin coding it, give it a couple years, then decide whether it's worth it or not.
Code robots to test interfaces in large systems is as ancient as programming itself; it's probably the grandfather of unit testing, but not unit testing itself. Also, good design makes features easy to add later on, not unit testing. Ascribing "new features were easy to add later on" to unit testing is disingenuous; that's something every project I've ever worked on strove for, and save for perhaps my first few years as a programmer, achieved, and generally early on in the project, not later.