Well, the standard LCS works as follows: First, there's a polarizer which absorbs the light of the wrong polarization (so that the remaining light is polarized). Next. there are the liquid crystals. They don't absorb light (well, they surely also absorb a bit, but that's just losses). What they do it to change the direction the light is polarized depending on the electric field applied to them. In other words, by themselves, they don't produce black pixels. Now after the light has passed the liquid crystals, it passes another polarizing filter which again absorbs the light of one polarization. Now much of the light it absorbs depends on how much the polarization of the light was rotated.
I guess the GP took the polarizers as part of the LCD matrix, in which case he's right. If you consider the LCD matrix as only consisting of the actual liquid crystals + electrodes, then the LCD matrix doesn't absorb a significant amount of light. All relevant absorption happens in the polarizers. And yes, that absorption depends on the state of the liquid crystals.
Actually I'm naturally pubeless but thanks for discriminating against me.
I don't think anti-discrimination laws apply to sex.
Plaintiff: She discrimininated against me. She said she wouldn't want to have sex with me because I'm not hairy enough. Judge: You're right. I hereby order that she has to have sex with you. I personally will watch for checking compliance with this judgement. :-)
The reason why caps lock is above shift is that it's the position where it was on mechanical typewriters. And the reason it was there on mechanical typewriters is that it physically fixed the shift key, and therefore had to be on the metal bar connecting the shift key to the carriage.
Why should a Windows compiler and a Linux compiler and an OS X compiler be forced to use the same name mangling? Note that there are ABI standards for C++, although they are not published by ISO. There's e.g. the Itanium ABI (named that way because originally it was meant to be used on Itanium, but it's also used on other platforms, e.g. AFAIK all Linux compilers for x86 and x86-64 follow it, making it a de-facto Linux standard (indeed, gcc following it already makes it a standard for Linux). Since OS X uses gcc as main compiler (but shifting to LLVM lately), I guess they use the Itanium ABI, too.
However note that vendors not using an ABI will be reluctant to switch to it because it breaks compatibility with all earlier versions of the compiler. Even formal ISO standardization wouldn't help much, because those vendors would most likely simply decide to not be standard conforming, or not be standard conforming by default, in this regard.
How many more years do we have to wait before we get _one_ standard on name mangling??
Name mangling is outside the scope of the C++ standard. Indeed, I consider name mangling a hack to get non-C++ aware linkers to correctly treat C++ code. In an ideal implementation, C++ names would not get mangled, but the linker would understand C++ types.
3. Output should be done by a print(ostream) method instead of operatorostream.format("The answer is %x, %x, %12x", object1, object2, object3); would call object1.print(ostream), etc. The 'x' and '12' would be accessible from the ostream by the print functions. Hopefully the compiler features would be useful elsewhere too. The C++ i/o syntax is quite unreadable and lots of programmers resort to printf if they want to control number base or precision.
Of course before C++0x, this would not have been possible since C++ lacked variadic templates, and objects cannot be passed through traditional variadic functions (there are technical reasons for that). In C++0x this could easily be implemented on top of the existing streams (except that format would have to be a free function instead of a member function).
That's what coding guidelines and code review are for. And someone who thinks that everything that compiles must be working code shouldn't be left near a compiler anyway.
Actually, I'd argue that with unsigned numbers, overflow does not exist because unsigned arithmetic is defined modulo 2^N. But anyway, for unsigned overflow throwing an exception would not even be allowed.
And of course, avoid the diamond of death at all costs.
Why? There's nothing wrong with it. Just don't apply it to classes with non-virtual functions or data members. If you restrict it to pure interface type abstract classes and remember to always use virtual inheritance for them, you're fine.
I think you hit the problems with templates nicely. While they were sitting around arguing over concepts, they could have been including support for multithreading.
If with "coroutines" you mean multithreading, C++0x has it.
- multi-stage/active library programming (i.e., something that fixes the syntactical mess of most template libraries)
I have no idea what "multi-stage/active library programming" is, so I cannot comment on that one.
- precise garbage collection (not that I'm missing it)
If you are not missing it, why do you want it?
- fully opening up of the memory model (allowing libraries to implement complex memory handling such as garbage collection or persistence)
C++0x has some support for optional garbage collection. Completely specifying the memory model isn't possible because C++ is compiled to native code, and different architectures have different properties. Imagine they would have fixed the memory model back in the DOS days!
OK, so you consider concurrency useless? And lambda functions? And type inference? And strongly typed enums? And static assertions? And Unicode support? And variadic templates? And move semantics?
Don't stop reading too early. The true escapes start at VMftp.
Re:MAybe, but we generate more ideas I think
on
The Post-Idea World
·
· Score: 1
Well, the relevant measure is of course ideas/person. I think today there are more people living in New York than 2500BC on the whole earth.
Also, don't underestimate the number of ideas from former times. Many things which were found back then are so standard today that we don't even think about it any more. Figuring out the concept of zero was orders of magnitudes more complicated than figuring out how to make usable light bulbs. Also the invention of the alphabet was a major breakthrough.
Speaking about the alphabet: Most ideas from before invention of the alphabet are probably lost. There's no way to find out how many there were. Indeed, many ideas from afterwards are probably lost, too, because few people knew how to write back then.
Also note that many ideas from back then are totally useless today. An improvement in the way to hunt a mammoth may have been just a big achievement as some innovation in a modern processor. However that knowledge became useless as soon as mammoths disappeared. Of course that will be the case for many today's inventions as well. For example, all the inventions on oil production will stop being useful as soon as the last oil was removed from earth.
The fundamentals never get out of date. A new language may come with a new syntax and with new libraries, but only very rarely it comes with a new programming paradigm.
Re:"Software engineers" don't do web programming
on
Hard Truths About HTML5
·
· Score: 5, Funny
Just wait until we get the ultimate XML programming language.
Slashdot Mirror
Well, the standard LCS works as follows:
First, there's a polarizer which absorbs the light of the wrong polarization (so that the remaining light is polarized).
Next. there are the liquid crystals. They don't absorb light (well, they surely also absorb a bit, but that's just losses). What they do it to change the direction the light is polarized depending on the electric field applied to them. In other words, by themselves, they don't produce black pixels. Now after the light has passed the liquid crystals, it passes another polarizing filter which again absorbs the light of one polarization. Now much of the light it absorbs depends on how much the polarization of the light was rotated.
I guess the GP took the polarizers as part of the LCD matrix, in which case he's right. If you consider the LCD matrix as only consisting of the actual liquid crystals + electrodes, then the LCD matrix doesn't absorb a significant amount of light. All relevant absorption happens in the polarizers. And yes, that absorption depends on the state of the liquid crystals.
Actually I'm naturally pubeless but thanks for discriminating against me.
I don't think anti-discrimination laws apply to sex.
Plaintiff: She discrimininated against me. She said she wouldn't want to have sex with me because I'm not hairy enough.
:-)
Judge: You're right. I hereby order that she has to have sex with you. I personally will watch for checking compliance with this judgement.
Maybe if he had two brain cells in his head, he would not have been fired in the first place. Who knows?
The reason why caps lock is above shift is that it's the position where it was on mechanical typewriters. And the reason it was there on mechanical typewriters is that it physically fixed the shift key, and therefore had to be on the metal bar connecting the shift key to the carriage.
And if your employer suddenly doesn't let you access the computers again, you know that he has read your post. :-)
Why should a Windows compiler and a Linux compiler and an OS X compiler be forced to use the same name mangling? Note that there are ABI standards for C++, although they are not published by ISO. There's e.g. the Itanium ABI (named that way because originally it was meant to be used on Itanium, but it's also used on other platforms, e.g. AFAIK all Linux compilers for x86 and x86-64 follow it, making it a de-facto Linux standard (indeed, gcc following it already makes it a standard for Linux). Since OS X uses gcc as main compiler (but shifting to LLVM lately), I guess they use the Itanium ABI, too.
However note that vendors not using an ABI will be reluctant to switch to it because it breaks compatibility with all earlier versions of the compiler. Even formal ISO standardization wouldn't help much, because those vendors would most likely simply decide to not be standard conforming, or not be standard conforming by default, in this regard.
And you must use & to get <.
Name mangling is outside the scope of the C++ standard. Indeed, I consider name mangling a hack to get non-C++ aware linkers to correctly treat C++ code. In an ideal implementation, C++ names would not get mangled, but the linker would understand C++ types.
Of course before C++0x, this would not have been possible since C++ lacked variadic templates, and objects cannot be passed through traditional variadic functions (there are technical reasons for that). In C++0x this could easily be implemented on top of the existing streams (except that format would have to be a free function instead of a member function).
That's what coding guidelines and code review are for.
And someone who thinks that everything that compiles must be working code shouldn't be left near a compiler anyway.
I seem to remember that after Sealand, the rules were changed so that artificial islands cannot any more legally claim nation status.
Actually, I'd argue that with unsigned numbers, overflow does not exist because unsigned arithmetic is defined modulo 2^N. But anyway, for unsigned overflow throwing an exception would not even be allowed.
Why? There's nothing wrong with it. Just don't apply it to classes with non-virtual functions or data members. If you restrict it to pure interface type abstract classes and remember to always use virtual inheritance for them, you're fine.
That's because in C++, overflow is simply undefined behaviour.
They have included support for multithreading.
But cores are not everything. Think about what GC does to the cache.
- coroutines
If with "coroutines" you mean multithreading, C++0x has it.
- multi-stage/active library programming (i.e., something that fixes the syntactical mess of most template libraries)
I have no idea what "multi-stage/active library programming" is, so I cannot comment on that one.
- precise garbage collection (not that I'm missing it)
If you are not missing it, why do you want it?
- fully opening up of the memory model (allowing libraries to implement complex memory handling such as garbage collection or persistence)
C++0x has some support for optional garbage collection. Completely specifying the memory model isn't possible because C++ is compiled to native code, and different architectures have different properties. Imagine they would have fixed the memory model back in the DOS days!
OK, so you consider concurrency useless? And lambda functions? And type inference? And strongly typed enums? And static assertions? And Unicode support? And variadic templates? And move semantics?
The only pity is that concepts didn't make it in.
If 2% of the people take backups of his laptop, he surely finds one who is willing to restore his laptop from that backup. :-)
Besides, did you ever hear about software running inside VirtualBox or VMWare infecting the host system?
http://www.foolmoon.net/cgi-bin/blog/index.cgi?mode=viewone&blog=1185593255
Don't stop reading too early. The true escapes start at VMftp.
Well, the relevant measure is of course ideas/person. I think today there are more people living in New York than 2500BC on the whole earth.
Also, don't underestimate the number of ideas from former times. Many things which were found back then are so standard today that we don't even think about it any more. Figuring out the concept of zero was orders of magnitudes more complicated than figuring out how to make usable light bulbs. Also the invention of the alphabet was a major breakthrough.
Speaking about the alphabet: Most ideas from before invention of the alphabet are probably lost. There's no way to find out how many there were. Indeed, many ideas from afterwards are probably lost, too, because few people knew how to write back then.
Also note that many ideas from back then are totally useless today. An improvement in the way to hunt a mammoth may have been just a big achievement as some innovation in a modern processor. However that knowledge became useless as soon as mammoths disappeared. Of course that will be the case for many today's inventions as well. For example, all the inventions on oil production will stop being useful as soon as the last oil was removed from earth.
The fundamentals never get out of date. A new language may come with a new syntax and with new libraries, but only very rarely it comes with a new programming paradigm.
Just wait until we get the ultimate XML programming language.
That's what you get for giving up your gun right's you flippin fairies.
Sure, because that could never have happened to gun owners ...
</sarcasm>
Indeed, with that it works quick.
However, I'd also consider hanging on an incorrect query a bug.