I've been writing C++ code for about a decade. I consider myself competent with almost every weird nook in C++ - I have extensive template metaprogramming in some projects, I've used and abused multiple virtual inheritance, and about the only thing I avoid are exceptions because I feel they're a non-solution.
And I think you're dead right. C++ is a hideously complex bitch of a language. Anyone trying to use all the C++ features will quickly drive themselves insane. I rarely use inheritance, I rarely make my own templates, I never do operator overloading unless it's absolutely clear what the operators mean (number classes, geometry classes, and string classes, basically.) In many ways, my code looks like C code, albeit C code with obsessive typesafety and extensive use of the STL.
I've programmed in other languages quite a bit. I honestly feel C++ is the single best language out there. But it isn't for anyone, and it's certainly not for people who can't sit down and say "okay, we need to make this damn program simple."
Well, partially because I wrote an ODS->CSV converter, and it was 216 lines long - in C++:) I know just how simple the OpenOffice formats are - they're really, really simple.
And because I honestly don't believe Microsoft is trying to be open. Everything I've heard about the format says that it's technically an open format, once you figure out WTF they're talking about, assuming they're not using any weird non-open parts, assuming they don't extend it in a non-open way in the near future, assuming they even conform to their own spec. Considering that Microsoft has not been known for any of those - and are in fact known for violating essentially all of those points - I don't have much faith in the true openness and readability of OOXML.
If a standard is fully open, it's generally not particuarly hard to write a converter to convert to and from that standard. That means my SuperExpensiveProprietarySoftware which reads ODF can be easily modified to use OMG, the new open document standard, just by writing a little OMG->ODF converter and preprocessing files that are used as input.
It takes some work obviously, but it takes far less work than a proprietary closed format which you may not be able to build a working converter for. I don't really want to think about trying to write an OOXML->DOC converter, personally. Yes, it's possible Word will be able to automate that easily (in fact I suspect it will), but any bugs will just have to be accepted since it's not like the source is available.
I agree it's not easy to convert. But it's not all that hard either.
Honestly, I think even PAE and similar memory bank swapping techniques are cleaner than that would be;)
And yeah, I think you're spot-on with what Win64 is like right now. Generally things seem to work, which is probably why it's so frustrating when things don't.
PAE is a hack, and applications that need more than 4GB of RAM would have to jump through some ghastly hoops in order to do it. 64-bit really *is* the future - it lets applications easily and simply use more than 4GB of RAM.
Supreme Commander actually has some problems with running out of address space - right now it uses a 2gb address space, and in large skirmish games it can easily crash due to out-of-memory. Pushing the address space up to 3gb with command line switches fixes the problem. We're probably only a year or two out from games where 4gb isn't enough. 64 bit is the future, and considering that 99.9% of all applications work fine on XP 64, I can see why this person would be very annoyed that iPhone doesn't.
In WoW, most botters are, indeed, people who just downloaded an app. This is because the app works. If the app didn't work, they might go and do something more complicated, such as forking over $20 or $30 for a cheap hardware gizmo that does something like what the original poster is talking about.
"People are lazy, and therefore won't go any further effort" is a fallacy when people don't need to go to any further effort. Once that becomes necessary (I mean, if that ever becomes necessary, which I personally doubt) I would suspect that a lot of businesses would spring up.
It does have a way of doing that. It doesn't work with drivers, but it works with everything else, and in my experience it works nearly 100% flawlessly - the only problems I've had may not even have been problems with that.
The iPhone, apparently, requires a driver that they're too lazy to port over. I suspect that if the driver was ported, the software would Just Plain Work.
XP 64, and I assume Vista 64, does indeed run 32-bit applications just fine. I run XP 64 and the only issues I've had have been Defcon (which may have been a driver issue anyway) and a shareware registration program which was an ancient 16-bit program (which XP 64, unlike XP, does not support.)
This includes games and apps. Hell, this includes Cygwin, which installs flawlessly. I literally don't have to care about XP 64 99% of the time.
The GUI and data transfer parts don't have to be 64-bit compiled. XP 64 is perfectly capable of running 32-bit Windows code. The drivers are the only part that would need any sort of a modification.
I use WinXP 64 and I've had almost zero issues with it - I think Defcon might have had trouble with it, but that may have been a driver conflict anyway.
If I bought something which didn't work on WinXP 64 I'd be extremely disappointed. I mean, unless they're installing drivers, they don't even need to build anything differently - and if they are installing drivers, it's just a compiler flag for the driver. There's really no good excuse, especially with how many things Just Work on XP 64.
Actually, a lot of the geeks I know are libertarian, which puts them firmly against higher taxes (and, in fact, against large government.) And that said: even liberals don't want higher taxes for the sake of higher taxes. They generally feel that more should be paid into public works, like libraries, parks, medical care, etc, but I don't know of any liberal that would vote for a tax increase just because higher tax is good.
The fact that people use The Pirate Bay to post child porn instead of black panther stuff is a measure of how many sites allow posting child porn vs. how many sites allow posting black panther stuff.
If I want to go post equal-rights pictures, I don't need to resort to The Pirate Bay. I can use any one of a hundred image sites. Why would I use a new, untested site which is affiliated with (what a lot of Americans would consider) known criminals?
So they found away to accomplish the same thing, and the patent holder could do nothing? Thanks again for proving my point.
Approximately the same thing. Huffman encoding can be described as a special case of arithmetic encoding. However, unless you're in very special circumstances, arithmetic encoding gives better compression. Maybe not enormously better compression, but still better.
It's the "same thing" if you mean "it compresses data". It's a very different thing if you start paying attention to how much it compresses data. Consider how many megabytes may have been wasted through inferior algorithms, and consider how much that costs.
Switching to arithmetic encoding would be a very simple change that would have compression benefits across all sorts of fields. If the patents went away, we could do that. The only "workaround" is to use a less efficient algorithm.
I'd agree with you if that was the way they were used. Unfortunately, often it isn't. Riders are also used for political blackmail ("Bob voted against giving money to children! Clearly he hates America! I realize there was that little minor legalizing-torture thing attached, but really, it was called the Give Money To Children bill!") and for simple sneakiness ("What do you mean, you didn't realize torture was part of giving money to children? It was right there on page 1,943.")
This is where the whole line-item veto thing comes in - where people can say "well, I'm all for children, but I'm vetoing this torture section". Unfortunately, that has its own problems, as people have actually vetoed specific words out of a bill so it means something entirely different.
Personally, I'd like to see some requirement that bills divide their issues up in a sensible way, and provide an issue-level veto. But for some reason I don't think this will happen.
Everyone seems to be obsessed with data transfer. I'm going to go in a different direction. Install plugs. Lots and lots of plugs. I believe the house standard is two outlets every 3 feet - put in at least eight outlets every 3 feet. I don't know about you, but I'd *love* to be able to forget entirely about power strips.
If you want to be really cool, install some normal outlets and some UPS outlets, connected to a big honkin' UPS in the middle of your house somewhere. How many people have centralized battery-backed power?
There is, in fact, a difference between those cases.
Abortion is rarely chosen due to features of the baby. It's generally because of the mother's situation in one way or another.
Eugenics, on the other hand, is based entirely on the baby. It puts people in the position of being able to choose "good" features, and have a "proper" baby. This is dangerous on several levels, potential prejudices in both directions and gene pool reduction being two of the more important ones.
The fact that a fetus is being destroyed is not, in my opinion, the part that makes eugenics nasty. The part that makes eugenics nasty is what it means for the remaining children.
CDs and DVDs already contain error correction. If that error correction isn't enough, the first thing you'd need to do is figure out how much damage you expect to be able to recover from. If you're planning on keeping it in an armored container stored in a bank vault, you're probably fine - if you're planning on using it as a floor sander, you might have some trouble.
I use 'em all over the place. In the beginning of functions, in the middle of functions, at the end of functions. I actually have functions whose sole purpose is to double-check consistency after I've done something nasty (although I do try to avoid this.)
Internally, in my programs, I should never be calling a function with invalid input. Ever. So when I put an assert to check for that, it's an instant-crash assert, because it means I've done something horribly wrong. Obviously talking to an external API is potentially a different matter (although in that case you could still argue that "omg I have no idea what this means abort abort abort" is the right behavior) - but internally I shouldn't be passing error codes around because there shouldn't be errors.
I've written successful programs also, so I'm pretty sure I know what I'm talking about also. However I highly doubt either of us are going to convince the other.
I believe that assert()s should never, ever trigger, and should be used extensively to verify internal consistency and expected results.
(Also, there's no way to detect an invalid pointer in pure C++. NULL, sure. Invalid? Nope.)
Point 1: I disagree strongly. If you end up in a state that you don't understand it's entirely possible you've clobbered other parts of the code - perhaps data structures are no longer sane, perhaps you've overwritten random parts of memory, perhaps you're simply in a situation that nobody has ever conceived of. In any case, if you're in an unknown state, the function has failed in a way which could not have been foreseen, and therefore anything you do from there is just wandering around in the dark hoping that maybe somehow things work out.
Point 2: You're right, it is. That's why I have my own assert()like macro that doesn't get optimized out in release builds.
Point 3: The right thing to do is define "error" properly. Something going wrong in the function isn't an error. It's an expected case. It should be dealt with properly. Something utterly unexpected and impossible going wrong? That's an error.
If I get internal consistency faults in my program, it damn well should crash because nobody will be able to trust what it does next. Of course, that shouldn't be possible, but I've found by far the best way to keep internal consistency faults away is to make sure that they're detected ASAP and fixed. And that's where asserts come in.
There MUST be a place to put that 99. As C *LETS* you break the const semantic.
This is actually partially incorrect. In C++, at least, removing the const from a pointer is undefined behavior (at least in the case where the pointer actually points to a const object, I'm not sure what it does if the pointer points to an object which could theoretically be modified.) The compiler is well within its rights to store that value in a constant data segment, and it's well within its rights to make that code you posted do something horribly wrong.
However, just taking the pointer in the first place does, indeed, require that it has some existence in memory. So you're right that there must be a place to put the 99, but not because C++ lets you break the const semantic - especially because C++, in fact, doesn't let you.
const is two things. It's telling the local function "you're not allowed to change this", and it's telling the caller "it's not allowed to change this". Things might still get changed, but if they do, it's the sign of a hideously broken program.
Ah, fair enough. I don't actually use assert(), I have my own equivalent function that doesn't go away in release mode. So that isn't so much of a problem.
How would define have helped in that situation? I don't even see the token "xyz" existing anywhere in that code, besides in the const. Maybe Slashdot formatting broke it?
I believe that the linker pushes all those variables into the same section - a thousand 4-byte "blobs" will end up sitting end-to-end in a nice 4k memory area, taking not a lot of space. Globals are much nicer than dynamic allocation in that sense. That said, a true const int will likely not even exist in the program in the end - it'll be inlined into every function.
Yes, obviously using CString is going to take a significant amount of code and memory, because CString isn't a primitive, has a (very) nontrivial constructor and destructor, and therefore can't be inlined by the compiler. That's why you don't use it for a lot of global constants. You could argue that using char* strings is going to be a problem in some way due to the missing members, but the fact that the #define works indicates to me that it generally won't be - so the const char*const should work fine.
Personally, I leave assert()s in with final code. Why not? If there aren't bugs, they won't be hit anyway. If there are bugs, I'd rather the program crashed cleanly and quickly - far better than running wild with corrupt data and unknown state. I try to rig my assert-equivalent to emergency-save whatever it can, so, really, hitting an assert is the best possible result for a bug. Why remove that? That would just be dumb.
No, there are no universal rules. That's why I said 99%.
I disagree. Anything that you expect to happen shouldn't be caught by assert(), of course - hard drive out of space, timeout connecting to website, etc etc etc. But anything you don't expect to happen you obviously can't plan for, and that means you can't guarantee that your program will be in a consistent state. The best thing to do there is to save any user data you can and kill the program.
Obviously it's best if none of your asserts ever trigger, but I'd rather an assert trigger and save my work before crashing than have my document get increasingly corrupted until I can't even load it to save whatever is left.
Since the compiler knows that the int can't ever change, the compiler can easily inline it, giving you exactly the same performance as #define. I believe that most compilers only bother allocating space for the int if you try to take the address of it in some way.
I suspect they only do this in release mode, of course.
Slashdot Mirror
I've been writing C++ code for about a decade. I consider myself competent with almost every weird nook in C++ - I have extensive template metaprogramming in some projects, I've used and abused multiple virtual inheritance, and about the only thing I avoid are exceptions because I feel they're a non-solution.
And I think you're dead right. C++ is a hideously complex bitch of a language. Anyone trying to use all the C++ features will quickly drive themselves insane. I rarely use inheritance, I rarely make my own templates, I never do operator overloading unless it's absolutely clear what the operators mean (number classes, geometry classes, and string classes, basically.) In many ways, my code looks like C code, albeit C code with obsessive typesafety and extensive use of the STL.
I've programmed in other languages quite a bit. I honestly feel C++ is the single best language out there. But it isn't for anyone, and it's certainly not for people who can't sit down and say "okay, we need to make this damn program simple."
Well, partially because I wrote an ODS->CSV converter, and it was 216 lines long - in C++ :) I know just how simple the OpenOffice formats are - they're really, really simple.
And because I honestly don't believe Microsoft is trying to be open. Everything I've heard about the format says that it's technically an open format, once you figure out WTF they're talking about, assuming they're not using any weird non-open parts, assuming they don't extend it in a non-open way in the near future, assuming they even conform to their own spec. Considering that Microsoft has not been known for any of those - and are in fact known for violating essentially all of those points - I don't have much faith in the true openness and readability of OOXML.
Actually, you're kind of wrong there.
If a standard is fully open, it's generally not particuarly hard to write a converter to convert to and from that standard. That means my SuperExpensiveProprietarySoftware which reads ODF can be easily modified to use OMG, the new open document standard, just by writing a little OMG->ODF converter and preprocessing files that are used as input.
It takes some work obviously, but it takes far less work than a proprietary closed format which you may not be able to build a working converter for. I don't really want to think about trying to write an OOXML->DOC converter, personally. Yes, it's possible Word will be able to automate that easily (in fact I suspect it will), but any bugs will just have to be accepted since it's not like the source is available.
I agree it's not easy to convert. But it's not all that hard either.
While I don't have any ironclad evidence, I was able to find a designer quote talking about the beta being thoroughly tested on 64-bit systems and a thread on PlanetAMD64 discussing the demo with no major 64-bit issues.
So I'm guessing it does.
Battlefield 2 worked fine when I played it, if that helps at all.
Honestly, I think even PAE and similar memory bank swapping techniques are cleaner than that would be ;)
And yeah, I think you're spot-on with what Win64 is like right now. Generally things seem to work, which is probably why it's so frustrating when things don't.
PAE is a hack, and applications that need more than 4GB of RAM would have to jump through some ghastly hoops in order to do it. 64-bit really *is* the future - it lets applications easily and simply use more than 4GB of RAM.
Supreme Commander actually has some problems with running out of address space - right now it uses a 2gb address space, and in large skirmish games it can easily crash due to out-of-memory. Pushing the address space up to 3gb with command line switches fixes the problem. We're probably only a year or two out from games where 4gb isn't enough. 64 bit is the future, and considering that 99.9% of all applications work fine on XP 64, I can see why this person would be very annoyed that iPhone doesn't.
I'm not entirely sure I believe this.
In WoW, most botters are, indeed, people who just downloaded an app. This is because the app works. If the app didn't work, they might go and do something more complicated, such as forking over $20 or $30 for a cheap hardware gizmo that does something like what the original poster is talking about.
"People are lazy, and therefore won't go any further effort" is a fallacy when people don't need to go to any further effort. Once that becomes necessary (I mean, if that ever becomes necessary, which I personally doubt) I would suspect that a lot of businesses would spring up.
It does have a way of doing that. It doesn't work with drivers, but it works with everything else, and in my experience it works nearly 100% flawlessly - the only problems I've had may not even have been problems with that.
The iPhone, apparently, requires a driver that they're too lazy to port over. I suspect that if the driver was ported, the software would Just Plain Work.
XP 64, and I assume Vista 64, does indeed run 32-bit applications just fine. I run XP 64 and the only issues I've had have been Defcon (which may have been a driver issue anyway) and a shareware registration program which was an ancient 16-bit program (which XP 64, unlike XP, does not support.)
This includes games and apps. Hell, this includes Cygwin, which installs flawlessly. I literally don't have to care about XP 64 99% of the time.
The GUI and data transfer parts don't have to be 64-bit compiled. XP 64 is perfectly capable of running 32-bit Windows code. The drivers are the only part that would need any sort of a modification.
I use WinXP 64 and I've had almost zero issues with it - I think Defcon might have had trouble with it, but that may have been a driver conflict anyway.
If I bought something which didn't work on WinXP 64 I'd be extremely disappointed. I mean, unless they're installing drivers, they don't even need to build anything differently - and if they are installing drivers, it's just a compiler flag for the driver. There's really no good excuse, especially with how many things Just Work on XP 64.
Actually, a lot of the geeks I know are libertarian, which puts them firmly against higher taxes (and, in fact, against large government.) And that said: even liberals don't want higher taxes for the sake of higher taxes. They generally feel that more should be paid into public works, like libraries, parks, medical care, etc, but I don't know of any liberal that would vote for a tax increase just because higher tax is good.
No it's not.
The fact that people use The Pirate Bay to post child porn instead of black panther stuff is a measure of how many sites allow posting child porn vs. how many sites allow posting black panther stuff.
If I want to go post equal-rights pictures, I don't need to resort to The Pirate Bay. I can use any one of a hundred image sites. Why would I use a new, untested site which is affiliated with (what a lot of Americans would consider) known criminals?
So they found away to accomplish the same thing, and the patent holder could do nothing?
Thanks again for proving my point.
Approximately the same thing. Huffman encoding can be described as a special case of arithmetic encoding. However, unless you're in very special circumstances, arithmetic encoding gives better compression. Maybe not enormously better compression, but still better.
It's the "same thing" if you mean "it compresses data". It's a very different thing if you start paying attention to how much it compresses data. Consider how many megabytes may have been wasted through inferior algorithms, and consider how much that costs.
Switching to arithmetic encoding would be a very simple change that would have compression benefits across all sorts of fields. If the patents went away, we could do that. The only "workaround" is to use a less efficient algorithm.
I'd agree with you if that was the way they were used. Unfortunately, often it isn't. Riders are also used for political blackmail ("Bob voted against giving money to children! Clearly he hates America! I realize there was that little minor legalizing-torture thing attached, but really, it was called the Give Money To Children bill!") and for simple sneakiness ("What do you mean, you didn't realize torture was part of giving money to children? It was right there on page 1,943.")
This is where the whole line-item veto thing comes in - where people can say "well, I'm all for children, but I'm vetoing this torture section". Unfortunately, that has its own problems, as people have actually vetoed specific words out of a bill so it means something entirely different.
Personally, I'd like to see some requirement that bills divide their issues up in a sensible way, and provide an issue-level veto. But for some reason I don't think this will happen.
Everyone seems to be obsessed with data transfer. I'm going to go in a different direction. Install plugs. Lots and lots of plugs. I believe the house standard is two outlets every 3 feet - put in at least eight outlets every 3 feet. I don't know about you, but I'd *love* to be able to forget entirely about power strips.
If you want to be really cool, install some normal outlets and some UPS outlets, connected to a big honkin' UPS in the middle of your house somewhere. How many people have centralized battery-backed power?
There is, in fact, a difference between those cases.
Abortion is rarely chosen due to features of the baby. It's generally because of the mother's situation in one way or another.
Eugenics, on the other hand, is based entirely on the baby. It puts people in the position of being able to choose "good" features, and have a "proper" baby. This is dangerous on several levels, potential prejudices in both directions and gene pool reduction being two of the more important ones.
The fact that a fetus is being destroyed is not, in my opinion, the part that makes eugenics nasty. The part that makes eugenics nasty is what it means for the remaining children.
CDs and DVDs already contain error correction. If that error correction isn't enough, the first thing you'd need to do is figure out how much damage you expect to be able to recover from. If you're planning on keeping it in an armored container stored in a bank vault, you're probably fine - if you're planning on using it as a floor sander, you might have some trouble.
"How much" depends entirely on your needs.
I use 'em all over the place. In the beginning of functions, in the middle of functions, at the end of functions. I actually have functions whose sole purpose is to double-check consistency after I've done something nasty (although I do try to avoid this.)
Internally, in my programs, I should never be calling a function with invalid input. Ever. So when I put an assert to check for that, it's an instant-crash assert, because it means I've done something horribly wrong. Obviously talking to an external API is potentially a different matter (although in that case you could still argue that "omg I have no idea what this means abort abort abort" is the right behavior) - but internally I shouldn't be passing error codes around because there shouldn't be errors.
I've written successful programs also, so I'm pretty sure I know what I'm talking about also. However I highly doubt either of us are going to convince the other.
I believe that assert()s should never, ever trigger, and should be used extensively to verify internal consistency and expected results.
(Also, there's no way to detect an invalid pointer in pure C++. NULL, sure. Invalid? Nope.)
Point 1: I disagree strongly. If you end up in a state that you don't understand it's entirely possible you've clobbered other parts of the code - perhaps data structures are no longer sane, perhaps you've overwritten random parts of memory, perhaps you're simply in a situation that nobody has ever conceived of. In any case, if you're in an unknown state, the function has failed in a way which could not have been foreseen, and therefore anything you do from there is just wandering around in the dark hoping that maybe somehow things work out.
Point 2: You're right, it is. That's why I have my own assert()like macro that doesn't get optimized out in release builds.
Point 3: The right thing to do is define "error" properly. Something going wrong in the function isn't an error. It's an expected case. It should be dealt with properly. Something utterly unexpected and impossible going wrong? That's an error.
If I get internal consistency faults in my program, it damn well should crash because nobody will be able to trust what it does next. Of course, that shouldn't be possible, but I've found by far the best way to keep internal consistency faults away is to make sure that they're detected ASAP and fixed. And that's where asserts come in.
This is actually partially incorrect. In C++, at least, removing the const from a pointer is undefined behavior (at least in the case where the pointer actually points to a const object, I'm not sure what it does if the pointer points to an object which could theoretically be modified.) The compiler is well within its rights to store that value in a constant data segment, and it's well within its rights to make that code you posted do something horribly wrong.
However, just taking the pointer in the first place does, indeed, require that it has some existence in memory. So you're right that there must be a place to put the 99, but not because C++ lets you break the const semantic - especially because C++, in fact, doesn't let you.
const is two things. It's telling the local function "you're not allowed to change this", and it's telling the caller "it's not allowed to change this". Things might still get changed, but if they do, it's the sign of a hideously broken program.
Ah, fair enough. I don't actually use assert(), I have my own equivalent function that doesn't go away in release mode. So that isn't so much of a problem.
How would define have helped in that situation? I don't even see the token "xyz" existing anywhere in that code, besides in the const. Maybe Slashdot formatting broke it?
I believe that the linker pushes all those variables into the same section - a thousand 4-byte "blobs" will end up sitting end-to-end in a nice 4k memory area, taking not a lot of space. Globals are much nicer than dynamic allocation in that sense. That said, a true const int will likely not even exist in the program in the end - it'll be inlined into every function.
const char *const blah = "somestring";
Yes, obviously using CString is going to take a significant amount of code and memory, because CString isn't a primitive, has a (very) nontrivial constructor and destructor, and therefore can't be inlined by the compiler. That's why you don't use it for a lot of global constants. You could argue that using char* strings is going to be a problem in some way due to the missing members, but the fact that the #define works indicates to me that it generally won't be - so the const char*const should work fine.
Personally, I leave assert()s in with final code. Why not? If there aren't bugs, they won't be hit anyway. If there are bugs, I'd rather the program crashed cleanly and quickly - far better than running wild with corrupt data and unknown state. I try to rig my assert-equivalent to emergency-save whatever it can, so, really, hitting an assert is the best possible result for a bug. Why remove that? That would just be dumb.
No, there are no universal rules. That's why I said 99%.
I disagree. Anything that you expect to happen shouldn't be caught by assert(), of course - hard drive out of space, timeout connecting to website, etc etc etc. But anything you don't expect to happen you obviously can't plan for, and that means you can't guarantee that your program will be in a consistent state. The best thing to do there is to save any user data you can and kill the program.
Obviously it's best if none of your asserts ever trigger, but I'd rather an assert trigger and save my work before crashing than have my document get increasingly corrupted until I can't even load it to save whatever is left.
Since the compiler knows that the int can't ever change, the compiler can easily inline it, giving you exactly the same performance as #define. I believe that most compilers only bother allocating space for the int if you try to take the address of it in some way.
I suspect they only do this in release mode, of course.