I do linux kernel programming. Casting pointers is pretty much the only way to do what is essentially object-oriented template programming in C. The only real alternative is using unions, which have their own set of difficulties.
Personally I *like* having wired connections for charging, plugging in video out, plugging in headphones, etc.
There are basically no high-quality bluetooth headphones for listening to music, and can you imagine how long it'll take before every single monitor/tv out there can accept wireless video signals? Also, if you have inductive charging as your only option it immediately makes all of the aftermarket usb chargers useless.
Now I *would* appreciate ports with waterproof covers/plugs.
The application says that USB/SD is one example but that it could apply to many others as well:
"The foregoing description has broad application. For example, while examples disclosed herein may focus on an input port for receiving a USB plug and a SD card, it should be appreciated that the concepts disclosed herein may equally apply to connectors and plugs. Similarly, although the input port may be discussed with respect to a computer, the devices and techniques disclosed herein are equally applicable to any type of device including an external connector for transferring data and/or power."
While I'm generally on the check-for-errors case, I find that I generally don't have the time to test for every single documented error code and handle each one differently. I usually test for a few that I know I can deal with, and then bail out with loud log messages if the others happen.
Something as simple as open() can spit out something like 22 separate errors. I generally don't check for each one separately.
I work on highly-available systems (telecom equipment, core network stuff). Even there, some parts of the system can be less robust and some parts need to be as robust as possible.
The design for a given component needs to take into account how robust that component needs to be. Do you check EVERY POSSIBLE error condition and figure out intelligent ways to handle them (can be quite difficult and very time-consuming) or can you just panic the system if you detect something has gone wrong and you don't know how to handle it?
In some cases, you need to trade off between reliability and performance. In other cases you need to ship a product so it goes out with known corner cases that aren't handled because in the real world that condition should never happen.
It's also good for breaking out of multiply-nested loops, for checking a bunch of possible error conditions before starting the meat of a procedure, etc.
LCD displays with CCFL backlights are less susceptible to the problem than ones with LED backlights. And some monitors use non-pulsed backlights or at least smooth it out with a filter circuit or something.
According to this article (http://www.tftcentral.co.uk/articles/pulse_width_modulation.htm) LED backlights generally pulse between 90-420Hz, not in the KHz or MHz range.
With CCFL backlights flicker was less of an issue because the backlight itself smoothed out the flickering. With LED backlights the on/off cycle is sharp and immediate and therefore more noticeable.
Also, some LED backlights drive the PWM as low as 90Hz, which can be visible when the *whole screen* is flickering at that rate.
I have a Dell 2407 and I run at 25% brightness. It also doesn't use PWM since it's old enough to use CCFL. At 100% brightness it is uncomfortable to look at for any length of time.
Go check out the HardOCP display forums. There are lots of people sensitive to PWM flicker, especially when you turn the brightness right down (which maximizes the amount of time each LED spends in an "off" state.
he reason doctors prescribe antibiotics even if the person has a viral illness is because of secondary or opportunistic infections.
It's *also* because people want the doctor to do something to make them feel better. I've heard multiple doctors admit that they do stuff with no sound medical basis because it makes the patients feel like they're doing something useful.
Slashdot Mirror
I do linux kernel programming. Casting pointers is pretty much the only way to do what is essentially object-oriented template programming in C. The only real alternative is using unions, which have their own set of difficulties.
That said, you do need to be careful.
I'm a linux kernel hacker, C, C++, and bash kind of developer....
It seems at least plausible that this could be used in conjunction with some form of WDM to get higher densities than either alone.
Personally I *like* having wired connections for charging, plugging in video out, plugging in headphones, etc.
There are basically no high-quality bluetooth headphones for listening to music, and can you imagine how long it'll take before every single monitor/tv out there can accept wireless video signals? Also, if you have inductive charging as your only option it immediately makes all of the aftermarket usb chargers useless.
Now I *would* appreciate ports with waterproof covers/plugs.
I've had no problems with wireless charging on my touchpad.
The application says that USB/SD is one example but that it could apply to many others as well:
"The foregoing description has broad application. For example, while examples disclosed herein may focus on an input port for receiving a USB plug and a SD card, it should be appreciated that the concepts disclosed herein may equally apply to connectors and plugs. Similarly, although the input port may be discussed with respect to a computer, the devices and techniques disclosed herein are equally applicable to any type of device including an external connector for transferring data and/or power."
In the real world, plan to never be able to come back and refactor your code until the next feature that touches it.
Then it's a relatively few lines of code to do regex matching.
While I'm generally on the check-for-errors case, I find that I generally don't have the time to test for every single documented error code and handle each one differently. I usually test for a few that I know I can deal with, and then bail out with loud log messages if the others happen.
Something as simple as open() can spit out something like 22 separate errors. I generally don't check for each one separately.
I work on highly-available systems (telecom equipment, core network stuff). Even there, some parts of the system can be less robust and some parts need to be as robust as possible.
The design for a given component needs to take into account how robust that component needs to be. Do you check EVERY POSSIBLE error condition and figure out intelligent ways to handle them (can be quite difficult and very time-consuming) or can you just panic the system if you detect something has gone wrong and you don't know how to handle it?
In some cases, you need to trade off between reliability and performance. In other cases you need to ship a product so it goes out with known corner cases that aren't handled because in the real world that condition should never happen.
So if you think the patron had no influence on the music ever, at all....I think you'd be mistaken.
Imagine if they wanted to send a message "Mr X is patient zero of a horrible plague, quarantine anyone who contacted him."
Would you really want that in the clear?
even the encrypted communications have identifiers in the clear to indicate who they're coming from
It would be straightforward to have "marriage" be separate from "legally joined in the eyes of the state"
The best use of goto is for an orderly cleanup of resources. If something goes wrong partway through acquiring all the necessary resources to do a task, you just "goto" the appropriate stage of the cleanup. See http://programmers.stackexchange.com/questions/154974/is-this-a-decent-use-case-for-goto-in-c/154980#154980 for example.
It's also good for breaking out of multiply-nested loops, for checking a bunch of possible error conditions before starting the meat of a procedure, etc.
Turning up the duty cycle will reduce both the time that they're on and the time that they're off, but the ratio will remain the same.
LCD displays with CCFL backlights are less susceptible to the problem than ones with LED backlights. And some monitors use non-pulsed backlights or at least smooth it out with a filter circuit or something.
According to this article (http://www.tftcentral.co.uk/articles/pulse_width_modulation.htm) LED backlights generally pulse between 90-420Hz, not in the KHz or MHz range.
Older LCD displays used CCFL backlight, while many newer ones use LED. The LED ones show backlight flicker due to PWM much more clearly.
With CCFL backlights flicker was less of an issue because the backlight itself smoothed out the flickering. With LED backlights the on/off cycle is sharp and immediate and therefore more noticeable.
Also, some LED backlights drive the PWM as low as 90Hz, which can be visible when the *whole screen* is flickering at that rate.
Drives me nuts. I'm so happy when I see the occasional one using DC or high-frequency PWM.
I have a Dell 2407 and I run at 25% brightness. It also doesn't use PWM since it's old enough to use CCFL. At 100% brightness it is uncomfortable to look at for any length of time.
There are monitors out there with DC backlights...check the more technical reviews like the one mentioned in the summary.
Go check out the HardOCP display forums. There are lots of people sensitive to PWM flicker, especially when you turn the brightness right down (which maximizes the amount of time each LED spends in an "off" state.
he reason doctors prescribe antibiotics even if the person has a viral illness is because of secondary or opportunistic infections.
It's *also* because people want the doctor to do something to make them feel better. I've heard multiple doctors admit that they do stuff with no sound medical basis because it makes the patients feel like they're doing something useful.