James Kuyper wrote:
>
> vgps@slip.net wrote:
> >
> > To whom it may Concern,
> >
> > Why doesn't the C++ standard include constructs to write a pixel to the
> > screen at a certain row and column, with a certain color and luminosity?
> >
> > There are commands to print characters to the screen, i.e., cout and
> > cin, why not pixel commands.  Having to plow through some 800 page
> > booklet explaining some vendor's implementation of window's programming
> > is mind boggling.  Why don't standards committees strive for ease of use
> > and simplicity rather than complexity?
>
> One form of simplicity is achieved by factoring a complex system with
> many varieties, into two or more subsystems, each with a much smaller
> range of variation. In this case, the C++ language and its associated
> libraries are one subsystem, and the windowing software is another
> subsystem. You can access the same windowing libraries using many
> different languages, not just C++; you can use the same language, C++,
> to access many different windowing libraries, or even with none at all.
>
> C++ place extremely minimal hardware requirements on the implementation.
> It requires the existence of some kind of memory, some kind of file
> system, and standard input, output, and error streams; it doesn't
> specify many details about how any of those things work. C++ says
> absolutely nothing about any of the other typical peripheral devices,
> such as modems, printers, and network interfaces. All those details are
> left up to other standards, in order to keep C++ as simple as possible.

OTOH, a "pixel support" could be a general abstraction of
two-dimensional
fields of objects, where some basic algorithms are supported, like:

- setting a point at coordinates (x,y)
  = changing a value at coordinates (x,y)
- drawing a line from (x1, y1) to (x2, y2)
  = setting a range of elements to a certain value, where the elements
    are set up so that if mapped onto a visual device where x and y
    represent cartesian coordinates, the changed pixels would be
    approximately a line for the human eye
- drawing a rectangular box between (x1, y1) and (x2, y2)
  = setting all pixels with x1<=x && x<=x2 && y1<=y && y<=y2 to
    a certain value
- "extracting" a rectangular area from another "pixel map"
  = creating a pixel map which contains the contents of
    a rectangular area between (x1, y1) and (x2, y2)
- "inserting" a rectangular area into another "pixel map"
  = inverse of previous
- some other typical drawing operations
- getting the value of a certain pixel
- getting the size of the pixel map
- a "draw" function, which might be a no-op

Every implementation would have a "basic" pixel map which allows
to store "images" in memory, and would be allowed to provide
implementation defined pixel maps, which then can represent
f.ex. text screen (the pixels are the individual characters),
graphics screen (the pixels represent the graphics pixels),
windows (in windowing systems), ...

This way the whole thing would be kept implementation independant
(nothing but memory *must* be supported), but could easily be
adapted for real systems where ist would be useful (esp. windowing
systems, where there can be a pixel map associated to each
window).
Porting code using this would mainly mean to replace the exact type
of pixel map, and all the other code would work (of course, if you
port from a windowing system to one without windowing, you'd have
to support windowing yourself).

To allow maximum performance (graphics accelerators!), there should
not be the requirement that drawing on two pixel maps of different
type would result in the same pixels being set (except, of course,
for the trivial operations like setting a pixel or drawing a box,
and the extracting/inserting operations)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

vgps@slip.net wrote:
>
> To whom it may Concern,
Thanx for that polite greeting.

>
> Why doesn't the C++ standard include constructs to write a pixel to the
> screen at a certain row and column, with a certain color and luminosity?
Because the use of C++ is not limited to devices that have a screen with
pixels, or, more importantly, it is extremely seldom necessary or
desirable
to set individual pixels. For those rare occasions, a vendor supplied
class
library will do.

> There are commands to print characters to the screen, i.e., cout and
> cin,
1.: cin and cout are not commands but objects.
2.: They do not write to "the screen", but to the stdin and stdout
streams
    which are by no means guaranteed to be connected to any screen. Ever
    heard the words redirection or pipeline?
    And you cannot address rows nor columns that way (except by
outputting
    raw escape sequences). You need libraries to do so, just as with
pixels.

> why not pixel commands.
See above.

>  Having to plow through some 800 page
> booklet explaining some vendor's implementation of window's programming
> is mind boggling.
I don't really know what to answer to this one, but i'll try.

I have yet to see a book that spends 800 pages on the topic "how do I
write
one pixel to some particular screen?". Aren't those books you refer to
concerned with window frames, events, menus and mouse pointers?
So, what about looking up your topic (setting a pixel) in the index of
that
book you mean? Then the amount of pages you have to read is reduced to
initialisation, pixel setting and finalisation code.

> Why don't standards committees strive for ease of use
> and simplicity rather than complexity?
Well, they do strive for ease of use and simplicity. That's why they
didn't
bloat the C++ standard with some rarely used graphics stuff too.

Volker
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

To whom it may Concern,

Why doesn't the C++ standard include constructs to write a pixel to the
screen at a certain row and column, with a certain color and luminosity?

There are commands to print characters to the screen, i.e., cout and
cin, why not pixel commands.  Having to plow through some 800 page
booklet explaining some vendor's implementation of window's programming
is mind boggling.  Why don't standards committees strive for ease of use
and simplicity rather than complexity?

David Hooper
E-mail vgps@slip.net
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <351B0F51.2EA6@slip.net>,  <vgps@slip.net> wrote:
>Why doesn't the C++ standard include constructs to write a pixel to the
>screen at a certain row and column, with a certain color and luminosity?

Because it would be practically useless.  No significant graphical
programming is done by writing individual pixels.  There are entire
graphics libraries devoted to supporting this type of programming.

>There are commands to print characters to the screen, i.e., cout and
>cin, why not pixel commands.

I don't think cin and cout are specified in terms of a screen.  The access
standard input and standard output, which may or may not be associated with
a screen (on Unix and DOS you can easily redirect them to files and pipes).

>          Having to plow through some 800 page
>booklet explaining some vendor's implementation of window's programming
>is mind boggling.  Why don't standards committees strive for ease of use
>and simplicity rather than complexity?

If you don't want to struggle with a vendor-specific window system, you can
use the ANSI standard GKS.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]