Ah yes, the famously undefined "shift by 32." I can't see which direction you're shifting (your << or >> got eaten). On one of the DSPs I work with (TI's C6000 family), it has a 40-bit shifter and so looks at the lower 6 bits of the shift amount. Most other architectures only look at the lower 5 bits of the shift amount. This occasionally leads to amusing bugs.
As for the idiom above that generates the warning... I really don't know what circumstance it's warning about, except perhaps if "len" is less than 0—say, INT_MIN or something. But still, since it's an equals comparison, overflow shouldn't matter on the target architecture. Maybe it matters on machines with saturating arithmetic, but then perhaps the optimizer shouldn't make those kinds of optimizations on those architectures.
Unfortunately, there are [rare] times when it is necessary to write code which generates compiler warnings.
These get MUCH less rare when you crank up the warning and optimization levels. For example, the following idiom generates a warning in recent GCC versions if you turn -Wstrict-overflow on:
for (i = 0; i < len; i++) . . if (foo[i] == blah) . . . . break; if (i == len) . . return -1;/* not found */
This tends to generate the following warning:
warning: assuming signed overflow does not occur when simplifying conditional to constant
The first C compilers were written in assembly. What's GCC written in? C. More interestingly, what's Gnat (GNU Ada) written in? That's right. Ada.
How's that you ask? It's the very bootstrapping process you refer to.
As long as you can compile to machine code, there's no reason you ever need to write it. If you have a new machine, just make a cross-compiler in a high level language. Sure you need to have a native code generator at some level to createe the lowest level code that runs on the new machine, but that native code can be generated from as high a level language as you like once you have a sufficient software stack.
Yeah, using the laptop on the plane usually sucks. I'm more likely to use it before getting on the plane, or on really, really long plane rides. I wait until it's pretty likely the person in front of me won't recline.
For most flights, I take Southwest. What's this "first class" you speak of?
Meh. I'm no road warrior. I take maybe 3 to 6 business trips a year. But when I do, I typically need to get something together on the plane, or I'm at a conference full of people that are likely to understand what's on my screen. If I fly for a day trip and manage to get everything done in my already disrupted morning, I can take the rest of the day off when I'm done. And if I can leave work early and wrap up business over a couple beers, even better.
Huh? The local physics computations are only being used for presentation and local extrapolation. The server recomputes the relevant physics anyway, and can re-sync everyone periodically. That's how FPSes work to reduce lag--they do local extrapolation, and the server periodically snaps everyone back in line. It sometimes leads to what John Carmack calls "paradoxes" where locally displayed events get undone, but it works.
So, if some portion of your local physics calculation is purely for local presentation (e.g. game outcome doesn't depend on exactly how dirt particles fly around or boobs bounce, but you want it to look realistic), the server doesn't need to reproduce any of that to model the game correctly. Your screen might look different than someone else's, but in an immaterial way. For the super-soaker example, the server will still compute actual "wetness," possibly with a simplified model that skips computing the goosebumps and most of the dripping water.
Reading is about edge detection and shape discrimination. If you can set an ambient light floor without edges and shapes, it'll be easier to pick text out of it than if you have a bright spot and patterns you have to visually filter out to get to the text.
Tell that to the banks of fluorescent lighting that hang over many peoples' heads. Sure, it's indirect lighting and it's not shining on the screen, but it makes my face bright enough to see over most of my text. Also tell that to the folks that paint most of the walls white, or install white boards in peoples' offices.
It's maybe less of a problem for folks that like black text on white backgrounds. In my case, I'm a light text on dark type of guy, and so glossy just loses horribly in that environment. Sure, I can tilt my display up some and wear a dark shirt, but doesn't that sound an awful lot like the human bending to fit the machine rather than vice versa?
Well, given that all my web browsing goes through a proxy that can tie the traffic back to my employee number, I think you can appreciate that that's not my concern. Surfing pr0n at work means losing my job, and so is a rather expensive proposition regardless of the display device.:-)
Keep in mind, privacy filters slide out, so when I want a wide viewing angle, I can have one. I'm more concerned about airports, airplanes, coffee shops, etc. since there are actual professional reasons for why I really don't want to be shoulder-surfed by a person sitting across the aisle from me. Those also tend to be some of the worst lighting conditions, too, depending on whether the bozo across the way leaves his window open. I can at least control the lighting in my office most of the time.
I've always found these inscrutable, personally, and they also don't seem to always be exactly set in concrete. Wikipedia has a secret decoder ring, thankfully, and points out some of the inconsistencies on individual pages where different resolutions have been referred to by the same name.
This is worse than the HD folks mixing 2^10 and 10^3 units in the drive capacity computation.
Ah yes. As I recall, the Sun Trinitrons have an antiglare coat that can scratch relatively easily compared to straight up glass. It also tended to make fingerprints glow practically neon under certain fluorescent lighting conditions.
(And people wonder why half the fluorescent bulbs are turned off in my office.)
As for the glossy laptop screens, I'm thinking about getting one of those 3-M privacy filters. Those have a matte finish, and should hide the glossy from the glare. I'm hoping that's the one saving grace of glossy--less light loss before getting to the privacy filter.
Am I the only person who keeps having this page redirected to "USA Survey Group" after about 20 - 30 seconds?
Looks like it's not just stolen content, but stolen content wrapped around dubious revenue generation.
I believe the notion of "middle" Shatrat was referring to was "peak of the response curve." Human auditory response does not peak anywhere near 10kHz, but human visual response does peak in the center of green.
It's weird, but I do better with light text on a dark background when coding, and vice versa with documents and technical web pages most of the time. Casual content is more flexible. That said, it also matters what sort of display you're using as to what has the best fatigue properties, and that can bring other factors into play such as refresh rate and font.
Regardless of whether you prefer dark on light vs. light on dark, CRTs really want nice, thick fonts, particularly if you're at high resolution. This probably is a function of the shadow mask dot pitch, the "glowing spot" aspect of phosphor, and limitations of display bandwidth in the cable and in the electron guns. Large regions of bright colors really send a lot of light at your eyes. At too low of a refresh rate, this can be very fatiguing. I'd say that gives the edge to light text on dark backgrounds for many purposes, especially coding. Still, dark on light has a special place for me for documents that will mostly be printed. I think I tend to stare intently at screen more when I code than when I read/scan prose, which may explain the difference.
With projectors, I think it depends on the projector and the environment. I've noticed our DLP-based projectors at work are tuned for dark text on a light background. It shows up pretty well and is readable throughout the room. Bring up an xterm with light on dark and it's just a muddled morass. Thus, for these projectors, there really is Only One Way. Also, said projectors seem fairly sensitive to matching their desired refresh rate and resolution if you don't want synchronization noise. (At least in our case, where we're using analog VGA connections 99% of the time when passing the ol' VGA cable around the room to laptops of various ages.)
With an LCD, particularly with a DVI cable, you have neither cable bandwidth nor scanning bandwidth issues to deal with. You also don't have the flicker problems of a CRT. Now the choice of light vs. dark background is much more dependent on personal taste. Here, I cleave to my own bias I stated at the beginning.
In all cases, contrast is king. I use white or bright green on black for my xterms, and prefer black on white for things like documents (such as the many technical PDFs I might download and print). For casual content, such as my home page or blog, I don't mind going light on dark though. Actually, my Intellivision page picked a "bright neons on dark" theme mainly for the retro aspect more than the readability. It's still fairly readable though, IMHO.
Isn't a good part of C++0x's 1200 pages the boost^H^H^H^H^Hstandard library? Saying you need to learn all of that to effectively learn the language is like saying you need to learn all of CPAN to learn Perl, or all the gobs of standardized Java class libraries to learn Java. The fact of the matter is that large portions of any huge library are very domain specific, and are safely ignored by those outside the domain. For example, our compiler guys at work know the Boost Graph Library pretty well. I can't imagine someone writing payroll software cares too much about it though.
How much is GCC's autovectorization actually kicking in though? SSE has all sorts of alignment constraints as I recall, and if the compiler can't prove alignment or minimum trip counts, it will often punt.
Slashdot Mirror
Repeating what ILikeRed said:
Heck, I see this happen at work all the time, to older engineers that aren't well versed in the wiley ways of Windows.
Ah yes, the famously undefined "shift by 32." I can't see which direction you're shifting (your << or >> got eaten). On one of the DSPs I work with (TI's C6000 family), it has a 40-bit shifter and so looks at the lower 6 bits of the shift amount. Most other architectures only look at the lower 5 bits of the shift amount. This occasionally leads to amusing bugs.
As for the idiom above that generates the warning... I really don't know what circumstance it's warning about, except perhaps if "len" is less than 0—say, INT_MIN or something. But still, since it's an equals comparison, overflow shouldn't matter on the target architecture. Maybe it matters on machines with saturating arithmetic, but then perhaps the optimizer shouldn't make those kinds of optimizations on those architectures.
--Joe01010111 01101000 01100001 01110100 00100000 01101001 01100110 00100000 01001001 00100000 01101010 01110101 01110011 01110100 00100000 01101110 01111001 01100010 01100010 01101100 01100101 00100000 01100001 00100000 01100010 01101001 01110100 00111111
These get MUCH less rare when you crank up the warning and optimization levels. For example, the following idiom generates a warning in recent GCC versions if you turn -Wstrict-overflow on:
This tends to generate the following warning:
warning: assuming signed overflow does not occur when simplifying conditional to constant
*sigh*
The first C compilers were written in assembly. What's GCC written in? C. More interestingly, what's Gnat (GNU Ada) written in? That's right. Ada.
How's that you ask? It's the very bootstrapping process you refer to.
As long as you can compile to machine code, there's no reason you ever need to write it. If you have a new machine, just make a cross-compiler in a high level language. Sure you need to have a native code generator at some level to createe the lowest level code that runs on the new machine, but that native code can be generated from as high a level language as you like once you have a sufficient software stack.
Of course, such bootstrapping has its own problems.
One hacked ad server and you've pwn3d thousands upon thousands of users. And they'd be none the wiser.
Yeah, using the laptop on the plane usually sucks. I'm more likely to use it before getting on the plane, or on really, really long plane rides. I wait until it's pretty likely the person in front of me won't recline.
For most flights, I take Southwest. What's this "first class" you speak of?
Meh. I'm no road warrior. I take maybe 3 to 6 business trips a year. But when I do, I typically need to get something together on the plane, or I'm at a conference full of people that are likely to understand what's on my screen. If I fly for a day trip and manage to get everything done in my already disrupted morning, I can take the rest of the day off when I'm done. And if I can leave work early and wrap up business over a couple beers, even better.
Huh? The local physics computations are only being used for presentation and local extrapolation. The server recomputes the relevant physics anyway, and can re-sync everyone periodically. That's how FPSes work to reduce lag--they do local extrapolation, and the server periodically snaps everyone back in line. It sometimes leads to what John Carmack calls "paradoxes" where locally displayed events get undone, but it works.
So, if some portion of your local physics calculation is purely for local presentation (e.g. game outcome doesn't depend on exactly how dirt particles fly around or boobs bounce, but you want it to look realistic), the server doesn't need to reproduce any of that to model the game correctly. Your screen might look different than someone else's, but in an immaterial way. For the super-soaker example, the server will still compute actual "wetness," possibly with a simplified model that skips computing the goosebumps and most of the dripping water.
--JoeReading is about edge detection and shape discrimination. If you can set an ambient light floor without edges and shapes, it'll be easier to pick text out of it than if you have a bright spot and patterns you have to visually filter out to get to the text.
Tell that to the banks of fluorescent lighting that hang over many peoples' heads. Sure, it's indirect lighting and it's not shining on the screen, but it makes my face bright enough to see over most of my text. Also tell that to the folks that paint most of the walls white, or install white boards in peoples' offices.
It's maybe less of a problem for folks that like black text on white backgrounds. In my case, I'm a light text on dark type of guy, and so glossy just loses horribly in that environment. Sure, I can tilt my display up some and wear a dark shirt, but doesn't that sound an awful lot like the human bending to fit the machine rather than vice versa?
--JoeWell, given that all my web browsing goes through a proxy that can tie the traffic back to my employee number, I think you can appreciate that that's not my concern. Surfing pr0n at work means losing my job, and so is a rather expensive proposition regardless of the display device. :-)
Keep in mind, privacy filters slide out, so when I want a wide viewing angle, I can have one. I'm more concerned about airports, airplanes, coffee shops, etc. since there are actual professional reasons for why I really don't want to be shoulder-surfed by a person sitting across the aisle from me. Those also tend to be some of the worst lighting conditions, too, depending on whether the bozo across the way leaves his window open. I can at least control the lighting in my office most of the time.
I've always found these inscrutable, personally, and they also don't seem to always be exactly set in concrete. Wikipedia has a secret decoder ring, thankfully, and points out some of the inconsistencies on individual pages where different resolutions have been referred to by the same name.
This is worse than the HD folks mixing 2^10 and 10^3 units in the drive capacity computation.
Ah yes. As I recall, the Sun Trinitrons have an antiglare coat that can scratch relatively easily compared to straight up glass. It also tended to make fingerprints glow practically neon under certain fluorescent lighting conditions. (And people wonder why half the fluorescent bulbs are turned off in my office.) As for the glossy laptop screens, I'm thinking about getting one of those 3-M privacy filters. Those have a matte finish, and should hide the glossy from the glare. I'm hoping that's the one saving grace of glossy--less light loss before getting to the privacy filter.
Am I the only person who keeps having this page redirected to "USA Survey Group" after about 20 - 30 seconds? Looks like it's not just stolen content, but stolen content wrapped around dubious revenue generation.
Now that doesn't surprise me too much.
I believe the notion of "middle" Shatrat was referring to was "peak of the response curve." Human auditory response does not peak anywhere near 10kHz, but human visual response does peak in the center of green.
Which segment of /. are you addressing when you say "console"? The xterm / text frame buffer crowd or the PlayStation / Xbox crowd?
It's weird, but I do better with light text on a dark background when coding, and vice versa with documents and technical web pages most of the time. Casual content is more flexible. That said, it also matters what sort of display you're using as to what has the best fatigue properties, and that can bring other factors into play such as refresh rate and font.
Regardless of whether you prefer dark on light vs. light on dark, CRTs really want nice, thick fonts, particularly if you're at high resolution. This probably is a function of the shadow mask dot pitch, the "glowing spot" aspect of phosphor, and limitations of display bandwidth in the cable and in the electron guns. Large regions of bright colors really send a lot of light at your eyes. At too low of a refresh rate, this can be very fatiguing. I'd say that gives the edge to light text on dark backgrounds for many purposes, especially coding. Still, dark on light has a special place for me for documents that will mostly be printed. I think I tend to stare intently at screen more when I code than when I read/scan prose, which may explain the difference.
With projectors, I think it depends on the projector and the environment. I've noticed our DLP-based projectors at work are tuned for dark text on a light background. It shows up pretty well and is readable throughout the room. Bring up an xterm with light on dark and it's just a muddled morass. Thus, for these projectors, there really is Only One Way. Also, said projectors seem fairly sensitive to matching their desired refresh rate and resolution if you don't want synchronization noise. (At least in our case, where we're using analog VGA connections 99% of the time when passing the ol' VGA cable around the room to laptops of various ages.)
With an LCD, particularly with a DVI cable, you have neither cable bandwidth nor scanning bandwidth issues to deal with. You also don't have the flicker problems of a CRT. Now the choice of light vs. dark background is much more dependent on personal taste. Here, I cleave to my own bias I stated at the beginning.
In all cases, contrast is king. I use white or bright green on black for my xterms, and prefer black on white for things like documents (such as the many technical PDFs I might download and print). For casual content, such as my home page or blog, I don't mind going light on dark though. Actually, my Intellivision page picked a "bright neons on dark" theme mainly for the retro aspect more than the readability. It's still fairly readable though, IMHO.
--JoeMy ID may not be 3 digits, but it is prime and lower than yours. :-D Interestingly enough, though, your ID also happens to be prime.
--JoeYou misspelled "few." ;-)
Signed,
--One of the Punny Ones.
Slashdot seems disappointingly sane today.
Isn't a good part of C++0x's 1200 pages the boost^H^H^H^H^Hstandard library? Saying you need to learn all of that to effectively learn the language is like saying you need to learn all of CPAN to learn Perl, or all the gobs of standardized Java class libraries to learn Java. The fact of the matter is that large portions of any huge library are very domain specific, and are safely ignored by those outside the domain. For example, our compiler guys at work know the Boost Graph Library pretty well. I can't imagine someone writing payroll software cares too much about it though.
--JoeI do waaaay more integer divisions than floating point divisions.
How much is GCC's autovectorization actually kicking in though? SSE has all sorts of alignment constraints as I recall, and if the compiler can't prove alignment or minimum trip counts, it will often punt.