It isn't done by default, because a failing IO-operation is hardly a big surprise...
Well, not really... it isn't done by default because the original iostream library was created before exceptions were added to C++, and changing the interface would have broken legacy code.
(And potentially it's undefined behavior. Now that I think about it again, evaluating '++c-c*2' may provoke undefined behavior. I'm pretty sure it at least will add a few new axes to the possible outcomes.)
Yes, but C++ has the same problem. The code you gives compiles with C++.
And even if you buy that this is the reason they don't let it be used for array bounds, there are still plenty of other constants that you could screw up with equally devastating results.
Does the use of const int vs #define compile any differently? I work mostly with small embedded projects where every byte counts...
If you're doing embedded stuff, you would be well served to check it out. My feeling is that any compiler worth its salt would be able to optimize away at least almost all occurrences, and probably all occurrences, of a const. I suspect it would then get rid of the constant from the executable, but I'm not sure. You would have to test it with your compiler. (It almost certainly would NOT remove the constant if you ever take the address of it though.)
But, if you're working on embedded stuff, you're probably using C instead of C++, which means you're subject to the broken const int I mentioned in a previous post (where you can't use it for array bounds) so you'll have to use #define some of the time anyway.
the few things that won't (generally involving implicit casts to void*, as I understand it)
It's not *hard* fixes, but it's a LOT of fixes. Every call to malloc for instance.
There are a number of other things. "blah blah" has type char* in C, but const char* in C++. (There is a hack in C++ for this, but it's limited in scope.) C++ defines a ton of new keywords. 'a' has a different type, so any code that relies on the size will break. Same with enumerations. Functions with no parameters have type (...) in C but (void) in C++. C allows implicit conversions from int to an enumeration type. C structs are in a different namespace than variables and such, so you can have a struct S and a variable S and still refer to both.
If you get into C99, things get much worse, because there are a lot of extensions it implements to C89 that are not in C++ (yet).
I got into a debate on another site when I said that you could compile most decent C code as C++ with very few changes if only C++ allowed implicit conversion to void* for malloc purposes, and got reasonably schooled in that debate. There are a lot more differences than you might think, and they show up in most C code.
That is bad in a way because the const ints are being stored in memory instead of hardcoded at compile time.
Not necessarily. That's implementation dependent, and as long as you're compiling with optimization, you're probably wrong most of the time.
Neither offer any advantage over the other since changing either will only affect the program after its been recompiled
#defines have a number of well-known drawbacks that consts don't.
1. CPP macros stomp all over your namespace. For instance, Linux defines a macro "current". At one point I tried to make a local variable in a function named "current". I spent the next 15 minutes swearing at GCC for not compiling my code and giving error messages that made no sense. You can reduce this problem by naming conventions (for instance all caps), but consts don't have this problem at all.
2. consts don't suffer from order of operation issues, so you can define them without regards to those thoughts. The classic example is
#define SIX 1 + 5
#define NINE 8 + 1
printf("%d", SIX * NINE)
Which helpfully prints "42" instead of 54. Again, there are ways to work around this (put parens around the expressions), but you don't NEED to work around it if you use consts.
3. consts are typesafe
Of course, you can't always use 'const' in C. For instance, you can't use a const int as an array bound. But if you don't have to worry about C compatibility, I can't think of a reason to use #define instead of const for defining constant expressions.
I should say that I'm not trying to be argumentative, just that overall "use this" rules (both use #define a lot and never use #define) are dumb.
CPP macros are very useful even in C++ as a code generation technique for instance. Using them as constants or inline functions is bad practice, but there are uses.
And in both languages, keep them distinct from names people might use independently. For instance, don't name a macro "current", lest you cause a newbie 15 minutes of frustration and swearing at GCC for nonsensical error messages. (I have to work that gripe into any discussion of CPP macros.;-) )
Don't use #define. Avoid it as best as you can. Use const int. That's what it's for. It will be typechecked by the compiler, it's much harder to produce bizarre errors, and 99% of the time it's better.
With the caveat that you're not working in C. Unfortunately, even in C99 consts are broken in that they can't be used as array bounds:
const int S = 10; int i[S];
Comeau C/C++ 4.3.9 (Mar 27 2007 17:24:47) for ONLINE_EVALUATION_BETA1 Copyright 1988-2007 Comeau Computing. All rights reserved. MODE:strict errors C99 noC++0x_extensions
"ComeauTest.c", line 2: error: expression must have a constant value
int i[S];
^
Despite the fact that neither of these games requires the use of the mouth or vocalizations, I am completely unable to speak while playing them. My mind is entirely occupied by the rhythm and counting involved in playing.
I'm the same way! I played cello for a number of years in the school orchestra, and if someone asked me a question while I was playing, it would get internally queued and I'd answer it a minute or two later when I was stopped. Or else I would slowly form the answer in my head (if it was short enough, like your yes/no), and say it on beat.
I've made programs, specifically, spiders, that can run 200-1,000 simultaneous threads usefully on a PC. They work ok, as long as the inter-thread coupling is minimized
That's data parallelism. That's easy. I posted in another comment about how in 11th grade I had a (not well working) data parallel fractal generator (n threads, each rendering 1/n of the view) within six months of my first Win32 program, a couple months after learning about threads, and after a mostly-rewrite of the program. (The first version wasn't really parallelized; the worker thread ran separate from the GUI thread, but there was only one worker. That's not why I rewrote it.)
But there are a lot of programs that would be nice to parallelize, but aren't trivially parallel problems. For instance, my research involves static analysis of programs. The algorithms used in program analysis are very possibly not parallelizable. Formally, they probably don't belong to the NC complexity class, which is probably a proper subset of P.
I can eat, talk and think at the same time, all are pretty conscious actions
True, but can you talk (perhaps reciting something from memory) at the same time you are listening to something? Even if it's not a volume issue; you're wearing headphones say.
Feynman has a chapter in "What do you care what other people think" where he talks about some informal experimentation he did where he tried to figure out what he could do at the same time as accurately timing out a minute. Essentially, the same time as counting. He found that (1) he could be very consistent about timing out a given time, and that (2) he could do most things while counting. But what he couldn't do is talk. On discussion with other people in his dorm/frat/house/whatever, there was another person who could talk, but couldn't read while timing things out. Turns out that the reason it differed was because they counted differently; Feynman was hearing "one, two, three,..." while this other guy was watching the numbers pass in front of his eyes.
Activities are localized in the brain; it seems that these areas are largely independent, but try two tasks that use the same area and you're SOL.
Yes, but that's an easy sort of parallelism. Heck, I wrote a fractal generator that did the generation in a separate thread in 11th grade after writing my first Win32 program 4 or 5 months previous. It was also my first experience with threads. I'm not even sure I really knew what they were before that. This isn't *really* paralleling the application in the sense TFA means.
Closer is this: After some more work and a rewrite (for other reasons), I had "Fracked" running n threads, each rendering 1/n of the display. Data parallelism == easy parallelism.
But a lot of problems don't fit these models, and need a LOT of thought put into how to parallelize them. It's likely that some problems in P are not efficiently parallelizable.
Dunno where locokamil is, but here in the states, this isn't uncommon. Two summers ago I paid $30/mth for just Internet, and that was a probably slower cable connection than what you have, no TV, no phone. The only reason it was that cheap is because Time Warner was having an introductory sale for new customers.
Our blue jeans may be cheaper, but my impression is that our internet/phone/tv/media/whatever is rather more expensive and worse than what's available in most of the rest of the developed world.
In the world of user design foolishness, the worst by far are programs that interrupt you while typing with error windows, pop-ups or windows suddenly gaining focus. Internet Explorer, I am talking to you here, as well as every other program that pops up a brain-dead window demanding me to hit cancel or OK while I'm busy with more important things
Oooo, that was one of the things I liked best with the Firefox 1.0 -> 1.5 transition, it moving from dialogs to inform you about connection failures to just a bad page. (Actually wasn't IE ahead in this? At least in that exact respect?)
What's worse is when you're tying along, a dialog pops up, and you hit space or enter before you can stop typing, thus making the dialog go away and doing who-knows-what. AIM used to do that a fair amount, and it was one of the reasons I started using Gaim even on Windows.
Whoever modded the parent redundant is wrong. Nobody has made a comment similar to this in this discussion.
You mean, except for phalse phace saying "Cancel or Allow" at 4:27, Leroy Brown saying Vista itself at 4:50, flyingfsck saying all versions of Windows at 5:19? (For the record, the post in question was at 5:31, which means that a post saying specifically Windows Vista was posted over 40 minutes before.)
At the risk of being sued by Viacom and/or having my hosting plan overrun... Stephen Colbert did an amusing segment on that awful packaging and, yes, the people who have injured themselves. (5.6 MB XviD download; sorry the audio and video are ever so slightly out of sync.)
Mmmm... not really, at least not in XP. You can turn OFF automatic updates, but you can't disable that dialog from there. The same dialog *I think* appears if you do manual updates, though maybe not through IE. (If you have auto updates set to just inform you or download and inform it definitely still brings it up.)
This is the link you really want to turn off the dialog if you still want auto updates on.
"I used to look forward to the time when my computer was as easy to use as my phone. Now it's come true - I no longer know how to use my phone." -- perhaps Donald Norman The Design of Everyday Things (which should be required reading for anyone doing product design and is just flat out interesting even if you're not)
(This quote was really hard to search for, and I only found it without attribution. If anyone can provide attribution or a for-sure correct quote, that'd be wonderful.)
You could do the same thing better with a rotary encoder though.
Agreed that analog dials suck. My dorm came with a microwave (and fridge!) in each room, but many of them had analog dials and they were obnoxious. I eventually gave up with them and just rotated them to about 15 minutes and timed them out-of-band with the countdown timer on my watch.
I wish someone had the sense to build one with just a big knob to set the time, a small knob to set the power level (clicking to an off position if you just want to use the timer), and a big start/stop button. Put the timer on a logarithmic scale up to whatever the maximum sane length of time you might run a microwave for is (or use a continuous encoder with some acceleration programmed in the software), and read the value out on the display as you spin it.
My oven has this. It goes up by 5 seconds to 2:00, by 10 seconds to 10:00, by 1 minute to 1:00:00, and 5 minutes thereafter. (It might go up again after that, I don't know. I've only used it to about 30 minutes, and just tested after an hour now.)
This is in part because the actual rotary encoder sucks and it will occasionally go in the opposite direction you turn it, but I find it really obnoxious, in part because higher times take a while to get to. This is probably far less of a problem in a microwave where things are often less than a minute, but to get to the 7 minutes I cook pizzas for typically takes 2 "resets" of my hand position and getting to the 25 minutes for mac&cheese takes 3. Still, I don't think I'd like that interface for the microwave.
I kind of like my microwave's interface. The button I press most frequently is "+30" which adds 30 seconds to the time and starts cooking if it's not already. This is pretty darn convenient; a lot of the time, what I do is just one key press away. Less nice is that the 1-9 buttons do the same with 1-9 minutes. To get to where you actually enter the time in the traditional sense, you have to press another button first. By contrast, my parents' microwave you just started typing then hit start. I'm not sure how I feel about that. Probably a combination of the two is best; work like my parents' microwave, but add a +30 button.
If you want drive-through ATMs to not have braille keypads, then now you have two items in your catalog, you need a mold for the non-braille keys and a mold for the braille keys, you need to stock both, you need to worry about banks that request the wrong kind, etc.
It makes far more sense to just have the one kind that has braille keys. Those bumps probably add an extra 0.0001 cents to the manufacturing cost.
Slashdot Mirror
It isn't done by default, because a failing IO-operation is hardly a big surprise...
Well, not really... it isn't done by default because the original iostream library was created before exceptions were added to C++, and changing the interface would have broken legacy code.
Expressions are like sex: they're better without side-effects.
I think this should be the slogan of Haskell or something like that. I think I have to steal it for something.
(And potentially it's undefined behavior. Now that I think about it again, evaluating '++c-c*2' may provoke undefined behavior. I'm pretty sure it at least will add a few new axes to the possible outcomes.)
// and the result is...
The result is... implementation dependent!
Any one of 24 potentially different outcomes may occur.
Yes, but C++ has the same problem. The code you gives compiles with C++.
And even if you buy that this is the reason they don't let it be used for array bounds, there are still plenty of other constants that you could screw up with equally devastating results.
Does the use of const int vs #define compile any differently? I work mostly with small embedded projects where every byte counts...
If you're doing embedded stuff, you would be well served to check it out. My feeling is that any compiler worth its salt would be able to optimize away at least almost all occurrences, and probably all occurrences, of a const. I suspect it would then get rid of the constant from the executable, but I'm not sure. You would have to test it with your compiler. (It almost certainly would NOT remove the constant if you ever take the address of it though.)
But, if you're working on embedded stuff, you're probably using C instead of C++, which means you're subject to the broken const int I mentioned in a previous post (where you can't use it for array bounds) so you'll have to use #define some of the time anyway.
the few things that won't (generally involving implicit casts to void*, as I understand it)
It's not *hard* fixes, but it's a LOT of fixes. Every call to malloc for instance.
There are a number of other things. "blah blah" has type char* in C, but const char* in C++. (There is a hack in C++ for this, but it's limited in scope.) C++ defines a ton of new keywords. 'a' has a different type, so any code that relies on the size will break. Same with enumerations. Functions with no parameters have type (...) in C but (void) in C++. C allows implicit conversions from int to an enumeration type. C structs are in a different namespace than variables and such, so you can have a struct S and a variable S and still refer to both.
If you get into C99, things get much worse, because there are a lot of extensions it implements to C89 that are not in C++ (yet).
I got into a debate on another site when I said that you could compile most decent C code as C++ with very few changes if only C++ allowed implicit conversion to void* for malloc purposes, and got reasonably schooled in that debate. There are a lot more differences than you might think, and they show up in most C code.
Not necessarily. That's implementation dependent, and as long as you're compiling with optimization, you're probably wrong most of the time.
Neither offer any advantage over the other since changing either will only affect the program after its been recompiled
#defines have a number of well-known drawbacks that consts don't.
1. CPP macros stomp all over your namespace. For instance, Linux defines a macro "current". At one point I tried to make a local variable in a function named "current". I spent the next 15 minutes swearing at GCC for not compiling my code and giving error messages that made no sense. You can reduce this problem by naming conventions (for instance all caps), but consts don't have this problem at all.
2. consts don't suffer from order of operation issues, so you can define them without regards to those thoughts. The classic example is Which helpfully prints "42" instead of 54. Again, there are ways to work around this (put parens around the expressions), but you don't NEED to work around it if you use consts.
3. consts are typesafe
Of course, you can't always use 'const' in C. For instance, you can't use a const int as an array bound. But if you don't have to worry about C compatibility, I can't think of a reason to use #define instead of const for defining constant expressions.
I should say that I'm not trying to be argumentative, just that overall "use this" rules (both use #define a lot and never use #define) are dumb.
;-) )
CPP macros are very useful even in C++ as a code generation technique for instance. Using them as constants or inline functions is bad practice, but there are uses.
And in both languages, keep them distinct from names people might use independently. For instance, don't name a macro "current", lest you cause a newbie 15 minutes of frustration and swearing at GCC for nonsensical error messages. (I have to work that gripe into any discussion of CPP macros.
...I would personally just compile it as C++ (remember, you don't have to use all the C++ features if you don't want to.)
This doesn't work if you're working on legacy code that must be compiled as C.
With the caveat that you're not working in C. Unfortunately, even in C99 consts are broken in that they can't be used as array bounds: Anyone have an explanation for this?
Despite the fact that neither of these games requires the use of the mouth or vocalizations, I am completely unable to speak while playing them. My mind is entirely occupied by the rhythm and counting involved in playing.
I'm the same way! I played cello for a number of years in the school orchestra, and if someone asked me a question while I was playing, it would get internally queued and I'd answer it a minute or two later when I was stopped. Or else I would slowly form the answer in my head (if it was short enough, like your yes/no), and say it on beat.
I've made programs, specifically, spiders, that can run 200-1,000 simultaneous threads usefully on a PC. They work ok, as long as the inter-thread coupling is minimized
That's data parallelism. That's easy. I posted in another comment about how in 11th grade I had a (not well working) data parallel fractal generator (n threads, each rendering 1/n of the view) within six months of my first Win32 program, a couple months after learning about threads, and after a mostly-rewrite of the program. (The first version wasn't really parallelized; the worker thread ran separate from the GUI thread, but there was only one worker. That's not why I rewrote it.)
But there are a lot of programs that would be nice to parallelize, but aren't trivially parallel problems. For instance, my research involves static analysis of programs. The algorithms used in program analysis are very possibly not parallelizable. Formally, they probably don't belong to the NC complexity class, which is probably a proper subset of P.
I can eat, talk and think at the same time, all are pretty conscious actions
..." while this other guy was watching the numbers pass in front of his eyes.
True, but can you talk (perhaps reciting something from memory) at the same time you are listening to something? Even if it's not a volume issue; you're wearing headphones say.
Feynman has a chapter in "What do you care what other people think" where he talks about some informal experimentation he did where he tried to figure out what he could do at the same time as accurately timing out a minute. Essentially, the same time as counting. He found that (1) he could be very consistent about timing out a given time, and that (2) he could do most things while counting. But what he couldn't do is talk. On discussion with other people in his dorm/frat/house/whatever, there was another person who could talk, but couldn't read while timing things out. Turns out that the reason it differed was because they counted differently; Feynman was hearing "one, two, three,
Activities are localized in the brain; it seems that these areas are largely independent, but try two tasks that use the same area and you're SOL.
Yes, but that's an easy sort of parallelism. Heck, I wrote a fractal generator that did the generation in a separate thread in 11th grade after writing my first Win32 program 4 or 5 months previous. It was also my first experience with threads. I'm not even sure I really knew what they were before that. This isn't *really* paralleling the application in the sense TFA means.
Closer is this: After some more work and a rewrite (for other reasons), I had "Fracked" running n threads, each rendering 1/n of the display. Data parallelism == easy parallelism.
But a lot of problems don't fit these models, and need a LOT of thought put into how to parallelize them. It's likely that some problems in P are not efficiently parallelizable.
Dunno where locokamil is, but here in the states, this isn't uncommon. Two summers ago I paid $30/mth for just Internet, and that was a probably slower cable connection than what you have, no TV, no phone. The only reason it was that cheap is because Time Warner was having an introductory sale for new customers.
Our blue jeans may be cheaper, but my impression is that our internet/phone/tv/media/whatever is rather more expensive and worse than what's available in most of the rest of the developed world.
American Icon, Survivor, etc!
House, Daily Show, Colbert Report, Mythbusters, Star Trek reruns...
In the world of user design foolishness, the worst by far are programs that interrupt you while typing with error windows, pop-ups or windows suddenly gaining focus. Internet Explorer, I am talking to you here, as well as every other program that pops up a brain-dead window demanding me to hit cancel or OK while I'm busy with more important things
Oooo, that was one of the things I liked best with the Firefox 1.0 -> 1.5 transition, it moving from dialogs to inform you about connection failures to just a bad page. (Actually wasn't IE ahead in this? At least in that exact respect?)
What's worse is when you're tying along, a dialog pops up, and you hit space or enter before you can stop typing, thus making the dialog go away and doing who-knows-what. AIM used to do that a fair amount, and it was one of the reasons I started using Gaim even on Windows.
Whoever modded the parent redundant is wrong. Nobody has made a comment similar to this in this discussion.
You mean, except for phalse phace saying "Cancel or Allow" at 4:27, Leroy Brown saying Vista itself at 4:50, flyingfsck saying all versions of Windows at 5:19? (For the record, the post in question was at 5:31, which means that a post saying specifically Windows Vista was posted over 40 minutes before.)
At the risk of being sued by Viacom and/or having my hosting plan overrun... Stephen Colbert did an amusing segment on that awful packaging and, yes, the people who have injured themselves. (5.6 MB XviD download; sorry the audio and video are ever so slightly out of sync.)
Mmmm... not really, at least not in XP. You can turn OFF automatic updates, but you can't disable that dialog from there. The same dialog *I think* appears if you do manual updates, though maybe not through IE. (If you have auto updates set to just inform you or download and inform it definitely still brings it up.)
This is the link you really want to turn off the dialog if you still want auto updates on.
"I used to look forward to the time when my computer was as easy to use as my phone. Now it's come true - I no longer know how to use my phone."
-- perhaps Donald Norman The Design of Everyday Things (which should be required reading for anyone doing product design and is just flat out interesting even if you're not)
(This quote was really hard to search for, and I only found it without attribution. If anyone can provide attribution or a for-sure correct quote, that'd be wonderful.)
You could do the same thing better with a rotary encoder though.
Agreed that analog dials suck. My dorm came with a microwave (and fridge!) in each room, but many of them had analog dials and they were obnoxious. I eventually gave up with them and just rotated them to about 15 minutes and timed them out-of-band with the countdown timer on my watch.
I wish someone had the sense to build one with just a big knob to set the time, a small knob to set the power level (clicking to an off position if you just want to use the timer), and a big start/stop button. Put the timer on a logarithmic scale up to whatever the maximum sane length of time you might run a microwave for is (or use a continuous encoder with some acceleration programmed in the software), and read the value out on the display as you spin it.
My oven has this. It goes up by 5 seconds to 2:00, by 10 seconds to 10:00, by 1 minute to 1:00:00, and 5 minutes thereafter. (It might go up again after that, I don't know. I've only used it to about 30 minutes, and just tested after an hour now.)
This is in part because the actual rotary encoder sucks and it will occasionally go in the opposite direction you turn it, but I find it really obnoxious, in part because higher times take a while to get to. This is probably far less of a problem in a microwave where things are often less than a minute, but to get to the 7 minutes I cook pizzas for typically takes 2 "resets" of my hand position and getting to the 25 minutes for mac&cheese takes 3. Still, I don't think I'd like that interface for the microwave.
I kind of like my microwave's interface. The button I press most frequently is "+30" which adds 30 seconds to the time and starts cooking if it's not already. This is pretty darn convenient; a lot of the time, what I do is just one key press away. Less nice is that the 1-9 buttons do the same with 1-9 minutes. To get to where you actually enter the time in the traditional sense, you have to press another button first. By contrast, my parents' microwave you just started typing then hit start. I'm not sure how I feel about that. Probably a combination of the two is best; work like my parents' microwave, but add a +30 button.
Why make two versions?
If you want drive-through ATMs to not have braille keypads, then now you have two items in your catalog, you need a mold for the non-braille keys and a mold for the braille keys, you need to stock both, you need to worry about banks that request the wrong kind, etc.
It makes far more sense to just have the one kind that has braille keys. Those bumps probably add an extra 0.0001 cents to the manufacturing cost.