According to the web site, the red, green, and blue pixels differ in size of the gap between the two layers, when the pixel is in the non-black, or "on" state. I wonder if, rather than fabricating pixels that pop open to a fixed gap size in the "on" state, instead, the gap size could be "streched" by the bias voltage to control the color in the on state. This way, any pixel could appear to be any color in the on state. Not only would this increase the resolution or reduce the number of pixels needed, but it might increase the gamut of the monitor, since any frequency of light could be represented by varying the gap size.
Aside from the difficulties of fabricating a stretchy pixel, another drawback of my suggestion is that it would presumably require a lot more power to hold a gap stretched open, rather than having it be bistable, which they make a big deal about on the website.
On a separate topic, I would guess that for handheld devices, a certain degree of control over the intensity of a pixel could be acheived by flashing the pixel rapidly.
While I would agree that overzealous inlining can be harmful, there are many cases where it is essential for good performance Code using the STL containers can run much more slowly when inlining is turned off. Moderation is the key.
To characterize loop unrolling and function inlining as out-of-date is disingenuous. While you are right that they can increase code size, each has its rightful place.
I program a lot in c++, and I particularly like to use the STL. Thus, my programs often have a lot of inlined functions in them. I have found gprof to be much less useful when profiling such programs. When a function is inlined, gprof does not account for that functions time. Nor should it be exepcted to, since optimizations may reorder the code so much that it is not feasable to attribute a particular assembly instruction to a particular function. I have tried recompiling my programs with -fno-inline to expose the names of the inlined functions, but this changes the program performance so much in some cases that I am hesititant to draw any conclusions about a program from such a profile. Short of abandoning inlining (and interprocedural optimizations, which poses the same sort of problem), does anyone have suggestions on how to profile such programs?
You are right that containers of two different class types cannot use the same object code. But in my example, I refer to containers of pointers. As Stroustrup discusses in section 13.5 (3ed.), a container of int * and of Shape * _can_ share the same object code.
Re:Not all compilers support it, god-awful comp er
on
Downsides to the C++ STL?
·
· Score: 2, Interesting
>The fact that no compilers support all of STL is admitted by Stroustrop (sp?).
Hmm. Perhaps you are refering to his remark that no C++ compiler supports the export keyword? This keyword is not necessary to use the STL, and at least one commerical compiler now implements it.
Or perhaps you are refering to his remark that not all compilers support member templates and partial specialization. Perhaps true at the time he wrote the book, but no longer true. GCC and many others do support them. MSVC 6.0 does not.
Unlike an inheritcance-based container, like those in Java, the template-based containers of STL do not use virtual function calls to achieve genericity. Although this may result in an increase in code size, there are cases where different types can use the same code at runtime. For example, a container of int * and a container of char * might use the same object code.
Some of the benefits of template-based containers over inheritance-based containers are: 1) static type checking 2) can hold non-class type objects. 3) no virtual function call overhead.
To elaborate on item 2: If you want a container of intgers in a Java container (i think) you have to have a container of "Int" rather than "int".
It appears that this tape can hold more than even a two-layer, two-side DVD. Also, a tape for this machine will almost certainly be cheaper than a recordable DVD for some time to come. On these points alone, I think that the machine is a good idea. I agree that someday it would be nice to have a cheap machine that could record many hours of HDTV on a cheap disk-type medium. But until then, this looks like a good machine.
I dont see your point. Clearly, it is desirable to have a machine which can record and replay digital video signals. The fact that the media is the same form factor as the media used in an analog VCR does not make the machine any less digital. In this case, digital is not being used as a buzzword.
Or perhaps they could require that all people who make a CD available would also have to write a short review of the CD, or at least check a few checkboxes to rank the CD. Then MP3.com is primarily providing music reviews, and just including the music to help illustrate the review. That would be a lot closer to fair use, and it might actually provide some additional useful content.
Slashdot Mirror
According to the web site, the red, green, and
blue pixels differ in size of the gap between the two layers, when the pixel is in the non-black, or "on" state. I wonder if, rather than fabricating pixels that pop open to a fixed gap size in the "on" state, instead, the gap size could be "streched" by the bias voltage to control the color in the on state. This way,
any pixel could appear to be any color in the on
state. Not only would this increase the resolution or reduce the number of pixels needed, but it might increase the gamut of the monitor, since any frequency of light could be represented by varying the gap size.
Aside from the difficulties of fabricating a stretchy pixel, another drawback of my suggestion is that it would presumably require a lot more power to hold a gap stretched open, rather than having it be bistable, which they make a big deal about on the website.
On a separate topic, I would guess that for handheld devices, a certain degree of control over the intensity of a pixel could be acheived by flashing the pixel rapidly.
While I would agree that overzealous inlining can be harmful, there are many cases where it is essential for good performance Code using the STL containers can run much more slowly when inlining is turned off. Moderation is the key.
To characterize loop unrolling and function inlining as out-of-date is disingenuous. While you are right
that they can increase code size, each has its rightful place.
I program a lot in c++, and I particularly like to use the STL. Thus, my programs often have a lot of inlined functions in them. I have found gprof to be much less useful when profiling such programs.
When a function is inlined, gprof does not account for that functions time. Nor should it be exepcted to, since optimizations may reorder the code so much that it is not feasable to attribute a particular assembly instruction to a particular function. I have tried recompiling my programs with -fno-inline to expose the names of the inlined functions, but this changes the program performance so much in some cases that I am hesititant to draw any conclusions about a program from such a profile. Short of abandoning inlining (and interprocedural optimizations, which poses the same sort of problem), does anyone have suggestions on how to profile such programs?
You are right that containers of two different class types cannot use the same object code.
But in my example, I refer to containers of pointers. As Stroustrup discusses in section 13.5 (3ed.), a container of int * and of Shape * _can_ share the same object code.
>The fact that no compilers support all of STL is admitted by Stroustrop (sp?).
Hmm. Perhaps you are refering to his remark
that no C++ compiler supports the export keyword?
This keyword is not necessary to use the STL,
and at least one commerical compiler now implements it.
Or perhaps you are refering to his remark that not all compilers support member templates and partial specialization. Perhaps true at the time he wrote the book, but no longer true. GCC and many others do support them. MSVC 6.0 does not.
Unlike an inheritcance-based container,
like those in Java, the
template-based containers of STL
do not use virtual function calls to achieve
genericity. Although this may result in an
increase in code size, there are cases
where different types can use the same
code at runtime. For example, a container
of int * and a container of char * might use
the same object code.
Some of the benefits of template-based containers
over inheritance-based containers are:
1) static type checking
2) can hold non-class type objects.
3) no virtual function call overhead.
To elaborate on item 2: If you want a
container of intgers in a Java container
(i think) you have to have a container of
"Int" rather than "int".
It is not supposed to challenge DVD, it fills the place of DVD-R.
It appears that this tape can hold more than even a two-layer, two-side DVD. Also, a tape for this machine will almost certainly be cheaper than a recordable DVD for some time to come. On these points alone, I think that the machine is a good idea. I agree that someday it would be nice to have a cheap machine that could record many hours of HDTV on a cheap disk-type medium. But until then, this looks like a good machine.
I dont see your point. Clearly, it is desirable to have a machine which can record and replay digital video signals. The fact that the media is the same form factor as the media used in an analog VCR does not make the machine any less digital. In this case, digital is not being used as a buzzword.
Or perhaps they could require that all people who make a CD available would also have to write a short review of the CD, or at least check a few checkboxes to rank the CD. Then MP3.com is primarily providing music reviews, and just including the music to help illustrate the review. That would be a lot closer to fair use, and it might actually provide some additional useful content.