C. Grant wrote:
>
> The ANSI standard will standardize various utility libraries with the
> aim of portability between different implementations of C++.  Surely
> where that portability is needed most is in the area of "window manager
> libraries", that is to say those classes that are responsible for
> managing the graphical output and user interaction on a windowed
> display.
>
> Every program needs such functionality, so what hinders C++ portability

Not true. Many programs have no need for a user interface of any kind.
Many programs that do need one, don't need the overhead costs of a
graphical interface.


[ 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              ]

The ANSI standard will standardize various utility libraries with the
aim of portability between different implementations of C++.  Surely
where that portability is needed most is in the area of "window manager
libraries", that is to say those classes that are responsible for
managing the graphical output and user interaction on a windowed
display.

Every program needs such functionality, so what hinders C++ portability
the most is the lack of uniformity across operating systems and vendors.
One of the strengths of (say) Java is that its standard also specifies
these libraries, and means that Java is truly portable (at least before
Microsoft deliberately tried to change this).  C++ will never
practically be portable until windowing libraries are also the subject
of standardization, and the aims of a standardizing comittee should be
to make the C++ language portable and uniform across every platform.

While it would be natural for specific windowing environments to derive
special classes offering specific functionality, there is so much
commonality between windowing environments, that it is not unreasonable
to expect that I should be able to use an ANSI std class to program a
windowed environment, and be able to recompile on another platform.
This would also help break the unhealty viscous circle of products being
tied to a specific operating system.  C++ should not be vendor specific!

Having said that, this probably won't happen, because it would be too
big a change for the final review.

-- Calum
---
[ 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              ]

C. Grant wrote:
[yet another "window manager in ANSI C++" proposal]

This belongs in a "Frequently Made Language Proposals" file somewhere.
The short answer is that environmental libraries like window manager
interfaces typically belong in external standards which are compatible
with but not part of the language.

A slightly longer answer: Having a window library in Java makes sense
because it is primarily used in a graphical environment, the World Wide
Web. (Not all web browsers are graphical, but the ones that support Java
are.) It makes less sense in a general-purpose language which is largely
used for server programming, background processes, batch processing,
toolsmithing, and other non-output-oriented uses. I don't think the lack
of use of C++ as "window client software" in windowing environments is
so much due to any lack in C++ as it is market positioning by tool
vendors. C++ is a fairly low-cost development language in the hands of
experienced users, but there are lower-learning-curve languages which
are widely promoted both by vendors and IS departments for graphical
development: therefore, C++ more often has a role which is either
non-graphical or highly-specialized (like games and CAD). These typical
applications mean that C++ gets by rather well without a native
windowing library.

C++ currently makes one "optional" library distinction, and it's roughly
related to the presence or absence of a file system. This also makes
sense because of the historical development of C and the needs of
embedded programmers. More comprehensive systems, however, like POSIX
(Unix) and advanced mathematics, have their own standards which aim to
be compatible with C and C++ but are not part of the languages proper.
--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~Bradds


[ 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              ]

C. Grant wrote in message <34F40FEA.129FFDA9@hermes.cam.ac.uk>...
>While it would be natural for specific windowing environments to derive
>special classes offering specific functionality, there is so much
>commonality between windowing environments

...and so much that is completely different and has no equivalent on other
platforms. The trouble with this sort of thing (and the trouble with AWT and
Tk) is that one gets lowest common denominator functionality. This is useful
for a few applications, but not for non-trivial applications on the more
functionally rich platforms.

Anyway, it's not just in the GUI area that this problem occurs. Access to
operating system services (threads, semaphores, critical sections, IPC, the
local object model, etc) also suffers.

Hence, it _is_ unreasonable to expect the C++ committee to standardize on
libraries for this stuff. Their business is standardizing the _language_,
not the operating environment.

Unfortunately (or fortunately, depending on your point of view), this is not
an ideal world.

--
Daniel Neades
---
[ 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              ]

C. Grant wrote:

> The ANSI standard will standardize various utility libraries with the
> aim of portability between different implementations of C++.  Surely
> where that portability is needed most is in the area of "window manager
> libraries", that is to say those classes that are responsible for
> managing the graphical output and user interaction on a windowed
> display.

I am curently writing such a thing, with the advices of Dave Abraham.

> Every program needs such functionality,

Not at all. Every program that _you_ use, perhaps, but certainly
not every resonnable C++ program. Many real world programs runs
in background, as a server, ect... and don't need any UI.

> C++ should not be vendor specific!

Unlike Java folks, we don't have the illusion that we can offer
everything one might need in the std to only have portable programs.

> Having said that, this probably won't happen, because it would be too
> big a change for the final review.

You mean for _this_ standard ? The final review was done in
november 97. It's too late to fix even some known errors.

I now think in term of the next std. BTW, when do we begin to
work on it ? I hope it'll be soon.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ 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              ]

Valentin Bonnard wrote in message <34F44FE7.41C67EA6@pratique.fr>...
>I now think in term of the next std. BTW, when do we begin to
>work on it ? I hope it'll be soon.

That's a good question, and what forums do you take suggestions once they've
had an airing here?  A few weeks ago I suggested a "const blocks" idea and
still wouldn't mind giving it a push along when the time is right.

Paul Sorensen
---
[ 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              ]