Ross Smith wrote:
>
> Francis Glassborow wrote:
> >
> > Exactly, and if we separate out the different libraries implementers can
> > specify whether they support consoles, files, graphics etc.
>
> And we get the SQL effect: combinatorial explosion of implementation
> choices, nobody can write portable code that counts on any particular
> feature being available, and the "standard" becomes so diluted as to be
> meaningless. You may remember this being brought up in the EC++
> flam^H^H^H^Hdebate.

But if the libraries are dedicated to certain supported "external
features", instead of just supporting additional library features,
I don't think this would happen.
That is, having a "C++ with containers" and a
"C++ without containers" would probably hurt C++. But having
a "C++ with GUI" and a "C++ without GUI" would _not_ hurt,
as well as a "C++ with files" and a "C++ without files"
doesn't hurt.

The point is that the difference is made by "external"
entities, whose existance is generally determined by the
Environment rather than the compiler (although a compiler
may add its own support on systems without native support).

However, I guess instead of a GUI standard library, a
better choice would be a general UI standard library,
which can be implemented in terms of console I/O as well
as in terms of GUI I/O, in terms of Voice Recognition
(which probably isn't that different from dumb consoles),
or even in terms of Virtual Reality devices.

The point is that many programs don't really care how
f.ex. dialogs are built (the design often is done separtely
with ressources anyway). That is, usually you don't care
that an OK button sends an cmOk, an ID_OK or an OkEvent,
or a ButtonPress<Ok>, or calls an Ok() method on the dialog
object, or calls a pressed() method on the button object,
or whatever the GUI definition demands. Indeed, many
programs are not really concerned about if the user presses
an Ok button after entering his data to the dialog box, or if
he has to press enter, or to select a "dialog finished"
menu. All it is generally concerned about is that the user
does enter some defined data (in a dialog box which _might_
be designed through the program, or with a ressource editor,
or built by the environment itself according to built-in style
rules), that it can validate the data, and that the user
has confirmed the data he has entered.
Also, the program might give hints for special kinds of
UIs, f.ex. "On GUIs, center the dialog", "On GUIs, put the
dialog near this point", "On consoles, ask for special
confirmation", "On voice output, emphasize this question",
"on voice recognition, double check each entry".

Such a framework would basically consists of "interaction
elements". Some elements which would probably be needed are:

* "command": could be a command entered into a command line
  interface, a command bound to a key, a command in a menu,
  a command bound to a button, a command spoken in a microphone
  for voice recognition

* "menu": basically a group of commands which may be displayed
  in an UI like interface (whatever "displayed" means on that UI).

* "message": just a general output, could be a message box,
  or a message on a terminal or voice output; should probably
  be devided into a "message class" ("information", "alert",
  etc. - a message box would put this into the title and/or
  put a special symbol for known message classes; a color
  console may put that in a different color; a voice output
  may just emphasize it; a dumb terminal just prints it,
  probably with a colon after it) and a "message text"
  (displayed in the window, or just output).

* "dialog": The most important (and most complex) structure.
  The program would have to communicate the UI system the
  data to enter (probably collected into a struct type),
  information about each data type (where in the structure
  it is - unfortunately there's no mechanism to automatically
  "decompose" structs in templates - by giving a pointer to
  member, what its name should be (to be displayed as label
  in dialog boxes, as prompt in console dialogs, to be asked
  for in voice interfaces), optionally a default value, some
  rules if they are required, grouping info, and possibly
  dependant dialogs (think of the "options" dialog which
  often is available as sub-dialog in other dialogs).
  Also there should be a callback for validating info,
  which is called as soon as the user has finished entering
  (has entered all items on a dumb terminal interface;
  has entered the close dialog command on a command line
  interface, has pressed the OK button on a GUI interface).

One important part of that UI interface as I imagine it
would be the hints. The hints could use some similar
mechanism like locales (though I must admit that I don't
know too much about the implementation of locales):
A mostly arbitrary data structure attached to each item,
communicating extra data to the UI implementation.
There would be standard hints which are useful on a great
number of UIs (like hint<placement> for all GUIs,
hint<color> for GUIs and color consoles,
hint<grouping_direction> [horizontal or vertical]
for GUIs and windowed text UIs), but each implementation
could define non-standard hints. Hints which are not
appropriate or not known to a certain target UI would
just be ignored. Besides providing additional information
possibly useful for the UI algorithms, it's also the
interface to the native UI, since such a hint could also
be "use this MFC dialog window for the dialog".

Of course, use of non-standard hints tends to make the
UI code non-portable (an "use that MFC dialog window"
hint cannot be coded on a system where no MFC is present,
since "that MFC dialog window" can't be expressed there).
However, the ultimate goal would be to allow maximum
portability even with non-standard hints (i.e. a way to
code non-standard hints so that they can be used even on
systems which do _not_ support the UI the tag was intended
for. Of course this is not completely possible, but to
a wide extend a mechanism like the following would work:

Assume the UI library is in the namespace ui. Then there
could be a special namespace ui::hints, which contains just
class declarations, and a general hint template:

namespace ui
{
  namespace hints
  {
    class placement;
    class color;
    class whatever;
    // ...
  }

  template<class T> class hint // ignored if present
  {
    // general hint infrastructure
  public:
    hint() {}
    template<class C1> hint(C1 const&);
    template<class C1, class C2> hint(C1 const&, C2 const&);
    // more of them, up to a reasonable given limit
  };

  template<> class hint<hints::placement> { ... };
  // other specialisations
}

The ::ui::hints namespace would be special in that the user is
allowed (and even expected) to add declarations to it,
despite it being a standard namespace.
The correct way to use a hint (probably even the standard ones)
would be to first declare the hint type(s) to be used, and then
proceed:

namespace ui
{
  namespace hints
  {
    class placement; // a standard hint, just redeclared
    namespace special_gui
    {
      class background_texture; // a non-standard hint
    }
  }
}

void foo
{
  ui::dialog<...> d(...);
  {
    using ui::hints;
    d.add_hint(ui::hint<placement>(10, 10));
    d.add_hint(ui::hint<special_gui::backgrount_texture>("bricks"));
  }
  // ...
}

The trick is, that for the special_gui, the class
ui::hints::special_gui::background_texture is just re-declared,
and a specialisation for ui::hint exists which tells the
special_gui to use the pattern "bricks" as background pattern,
while for any other UI the class ...::background_texture
is newly defined by the user, and therefore ui::hint is not
specialized on it, so the unspecialized template is used.
The constructor is generated from the member template, and
the generated "standard hint" is suitable, although ignored
by the dialog.
This pattern works as long as only constructor parameters
of standard types are used.

It might be more work to figure out such an interface
than to figure out a good GUI interface; however I think
it would be worth it. (The STL was probably much more
work than the average container library as well.)

Also, since it would be implementable within the language
(with a stdio/iostream console interface - or even multiple
ones [dumb, simple command line, script]), but allow access
to a lot of GUI functionality on GUI systems without limiting
programs through the interface (because of interfacing
to the native GUI through the hint interface), as well
as to advanced terminal features on such terminals
(f.ex. through a curses target), and would - with careful
specification - even be implementable with new sorts of
user interfaces (like voice input), I guess it would have
a better chance to get into a future standard than a
GUI-only solution.
---
[ 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 <37CC0C1A.D65FF303@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
>But if the libraries are dedicated to certain supported "external
>features", instead of just supporting additional library features,
>I don't think this would happen.
>That is, having a "C++ with containers" and a
>"C++ without containers" would probably hurt C++. But having
>a "C++ with GUI" and a "C++ without GUI" would _not_ hurt,
>as well as a "C++ with files" and a "C++ without files"
>doesn't hurt.

But I do not think it should only about supporting external features.
For example I would very much like to see a standard numerics in C++
library.  Many people would be uninterested.  The designers of such a
library need to be experts in the field and probably would not want to
be involved in other work (but having them work as part of WG21 would
be, IMO, beneficial to them and might point the pure language experts at
desirable extensions and future modifications)



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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 <37C6C63D.5C76@wanadoo.fr>,
Valentin Bonnard  <Bonnard.V@wanadoo.fr> wrote:
>
>Jack Klein wrote:
>
>> Desktop chauvinism strikes again.  Not every platform which runs C++
>> programs has a screen at all, let alone one which supports graphics.
>
>Console/file system chauvinism strikes again. Not every platform
>has a console at all, let alone support for files.

Which is why C (and by implication, C++) distinguishes between "hosted" and
"non-hosted" implementations.  A hosted implementation is your typical OS
environment, where standard input and output are available, there's a file
system, etc.  Non-hosted is for embedded systems, kernel internals, the
runtime library of a hosted system, etc.

It would be necessary to add "hosted with a graphical interface" to this if
we wanted to make a GUI library part of the standard.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ 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 <7q68ke$2cpi$1@hardcore.ivn.net>, Scott Robert Ladd
<scott@coyotegulch.com> writes
>And how is the current library standard "minimal" ?
>
>The Standard contains a hundred of pages (certainly not minimal in *my*
>book) devoted to the container, algorithm, and iterator classes. I'm not
>saying that Chapters 23-25 don't belong in *a* Standard, I just don't see
>that they belong in a *language* Standard. They certainly aren't
>minimalistic!

And I entirely agree with you, but we need to get SC22 to agree so that
it issues separate work items.  However there are some library features
(such as operator new support) that are tightly bound to the core of the
language.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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 <37C6C63D.5C76@wanadoo.fr>, Valentin Bonnard
<Bonnard.V@wanadoo.fr> writes
>> Desktop chauvinism strikes again.  Not every platform which runs C++
>> programs has a screen at all, let alone one which supports graphics.
>
>Console/file system chauvinism strikes again. Not every platform
>has a console at all, let alone support for files.

Exactly, and if we separate out the different libraries implementers can
specify whether they support consoles, files, graphics etc.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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 <7q5vjh$eha$1@nnrp1.deja.com>, James.Kanze@dresdner-bank.com
writes
>Note too that this may encounter resistance from people who are afraid
>of dialectization.

Yes, and I think they over do it.  There is a hard core to the language
which includes some library elements but there are many other things
where we would benefit from standard interfaces.  Many things were left
out of the Standard Library, not because they were not desirable but
because adding them would have delayed delivery of the single monolithic
standard that we had been asked to provide.



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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              ]

On 27 Aug 1999 17:25:15 GMT, Valentin Bonnard <Bonnard.V@wanadoo.fr>
wrote in comp.std.c++:

>
> Jack Klein wrote:
>
> > Desktop chauvinism strikes again.  Not every platform which runs C++
> > programs has a screen at all, let alone one which supports graphics.
>
> Console/file system chauvinism strikes again. Not every platform
> has a console at all, let alone support for files.

Where did I mention a console or a file system?  Most of the C and C++
applications I work on run in what the standards refer to as a "free
standing environment".

Jack Klein
--
Home: http://home.att.net/~jackklein



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

Francis Glassborow wrote:

> And I entirely agree with you, but we need to get SC22 to agree so that
> it issues separate work items.  However there are some library features
> (such as operator new support) that are tightly bound to the core of the
> language.

These are used by the core language:
- operator new and delete
- typeinfo
- exception, and some derived classes
- varargs
- atexit
but they are all grouped in
18 - Language support library [lib.language.support].

--

Valentin Bonnard


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

Francis Glassborow wrote:
>
> Exactly, and if we separate out the different libraries implementers can
> specify whether they support consoles, files, graphics etc.

And we get the SQL effect: combinatorial explosion of implementation
choices, nobody can write portable code that counts on any particular
feature being available, and the "standard" becomes so diluted as to be
meaningless. You may remember this being brought up in the EC++
flam^H^H^H^Hdebate.

--
Ross Smith ....................................... Auckland, New Zealand
<mailto:r-smith@ihug.co.nz> ........ <http://crash.ihug.co.nz/~r-smith/>
                       Quoth the raven, "404!"


[ 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 <UUAx3.477$m84.8944@burlma1-snr2>, barmar@bbnplanet.com
says...
> Which is why C (and by implication, C++) distinguishes between "hosted" and
> "non-hosted" implementations.  A hosted implementation is your typical OS
> environment, where standard input and output are available, there's a file
> system, etc.  Non-hosted is for embedded systems, kernel internals, the
> runtime library of a hosted system, etc.

Where can one get the specifications for the hosted vs. unhosted portions
of C and C++?  What part of what standard does one need to obtain?

Ed


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

Instead of arguing abstractly about whether we need graphic library in
language standard or not, let's think for a minute what part can possibly be
standardized.
First that comes to the mind are all the graphic primitives: 2-d coordinate
system (or 3-d ?), point, line, rectangle, circle, etc., transformations,
color management, font management, etc.
So far so good. But what about the popular at our time GUI concept of
windows. There is no unity in understanding what "window" is, how it
interacts with its child windows and other windows, what messages it
receives and sends, what controls should it contain, what shape should it
have, etc. Windows systems are implemented differently on different
platforms/environments, so who is going to decide that? Even more
interesting - who's going to comply with such decision?
There are dozens (hundreds) of other GUI components that have the same
problems as I mentioned above. Does it seem like a feasible task for C++
committee? What if tomorrow somebody comes up with some new concept of GUI,
say talking windows for blind. Will C++ committee gather to standardize
them?
What about pointing devices? Should standard specify what mouse, pen,
microphone and all other multimedia devices are? What about printers? They
are also graphic devices.
This is absolutely impossible task for standardization, and at the same time
there are well designed libraries on most platforms for creating GUI, that
evolve and change quickly enough to reflect new concepts and new devices.
In conclusion, I would certainly like all the platforms to support Windows
standard of GUI, but this may happen not through C++ standard, rather if
Windows finally supplant all the other OSes; that I believe is not the dream
of most people here :-)

Gene Bushuyev.

Brian B. McGuinness <brian.b.mcguinness@lmco.com> wrote in message
news:37C3FE09.B1256377@lmco.com...
>
> Since most modern C++ programs implement
> GUI interfaces, it would make sense to create
> a standard for a class hierarchy for commonly
> used GUI elements such as menus, windows,
> dialog boxes, check boxes, and radio buttons.
> This would make it much easier to port
> programs from one platform to another and
> share interface code between programs.




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

On 28 Aug 99 12:31:33 GMT, James.Kanze@dresdner-bank.com
>  jackklein@att.net (Jack Klein) wrote:

>> Desktop chauvinism strikes again.  Not every platform which runs C++
>> programs has a screen at all, let alone one which supports graphics.
>
>Not every processor which runs C++ (or could run C++) has a file system,
>either.  So it looks like we'll have to drop file IO from the standard
>on the same grounds.

Both of you have valid points.  I think it would have been nice if the
standard iostream classes used pure virtual functions.  This way, a
system that has no filesystem would leave fstream::operator<< pure
virtual.  And a system that had no character terminal would leave
cstream::operator<< pure virtual.

And they should have used polymorphic flag objects.  So 'in' 'out'
'append' are classes derived from a common base.  This way an
implementation could add its own flags.

Etc.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


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

> BTW, has someone heard about a C++ implementation of AWT or Swing?
> This could be a start.

Not AWT, I hope (JAVA already has legacy issues.)  I think it would be
interesting to study Swing as a model for a C++ GUI.  I think the approach
taken to provide lightweight controls  (rather than wrapping native
controls) is right.  But the threading model where all accesses to both
model and view are owned by the GUI thread seems wrong.   JAVA seems to want
you to either make a special copy of your model data for the GUI or else to
always access the model data on the GUI thread - both of which seem wrong.
Also, the abstractions in the table classes - JTable, TableModel,
TableColumn, TableColumnModel - seem a little confused and a bit mixed up
when it comes to separating out view and model aspects of tables.

But it would be an interesting place to start.

--
Regards,
Daniel Parker danielp@nshima.com




[ 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 <MPG.1231eaa24611e6bd989dd1@netnews.worldnet.att.net>,
EdT <Ed@my.home.net> wrote:

>Where can one get the specifications for the hosted vs. unhosted portions
>of C and C++?

In their respective standards documents.

> What part of what standard does one need to obtain?
>
Most of the differences are in the library portions of the two standards
(C and C++), though some also show up in the intro. and general features
sections at the beginning.


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

Francis Glassborow wrote:
>
> Scott Robert Ladd <scott@coyotegulch.com> writes
>> And how is the current library standard "minimal" ?
>>
>> The Standard contains a hundred of pages (certainly not minimal in
>> *my* book) devoted to the container, algorithm, and iterator
>> classes. I'm not saying that Chapters 23-25 don't belong in *a*
>> Standard, I just don't see that they belong in a *language*
>> Standard. They certainly aren't minimalistic!
>
> And I entirely agree with you, but we need to get SC22 to agree so
> that it issues separate work items.  However there are some library
> features (such as operator new support) that are tightly bound to the
> core of the language.

The C language itself is fairly small.  The C++ language is larger,
but still fairly manageable.

Throw in the standard C library, which really is not too big for one
person to fully comprehend.  Throw in the C++ library, including the
STL, and now we've probably passed the limit of comprehension for
one person.  So, yes, the C++ standard is quite a large thing.

But issuing a language spec without at least a minimal library to
go with it would border on the pointless.  C/C++ don't have built-in
I/O of any kind, unlike other languages.

And while it might be possible to separate the C language from its
library, C++ doesn't lend itself to such a clean split.  The
definition of 'new' and 'delete' are tied closely to the library,
as are, to a lesser extent, exceptions.  And the behavior of
templates directly influences the implementation of the STL.

Would you have been willing to accept a C++ language standard in,
say, 1995, and waited another three years for the library standard?
(Bear in mind that both were influencing each other in the final
two years or so.)

But as far as a standard C++ GUI library is concerned, people are
free to form their own ISO committee and get such a thing going.
But I don't see it happening any time soon, and even if it does
come to pass, I don't envision Microsoft and Mac and POSIX and etc.
embracing it.

-- David R. Tribble, david@tribble.com --


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

EdT wrote:

> In article <UUAx3.477$m84.8944@burlma1-snr2>, barmar@bbnplanet.com
> says...
> > Which is why C (and by implication, C++) distinguishes between "hosted" and
> > "non-hosted" implementations.  A hosted implementation is your typical OS
> > environment, where standard input and output are available, there's a file
> > system, etc.  Non-hosted is for embedded systems, kernel internals, the
> > runtime library of a hosted system, etc.
>
> Where can one get the specifications for the hosted vs. unhosted portions
> of C and C++?  What part of what standard does one need to obtain?

There is only one ISO C++ standard. You can't buy a only a part
of from ISO. (Of course, once you have the entire standard, you
can remove all the pages you aren't interrested in).

You can buy the standard from your NB or online from ANSI. Anyway,
see the FAQ.

--

Valentin Bonnard
---
[ 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 <37ca20a4.41599285@news.nikoma.de>,
  MikeAlpha@NoSpam_csi.com (Martin Aupperle) wrote:
> Most of the STL-part in the Standard does not belong into a "language
> standard". But the commitee decided to include language definition
> and library definition into one standard.
> This need not be so for a GUI library. It can be standardized, but
> need not be part of  "The Standard".

Much as the PTHREAD library is a standard but not part of the language.

> BTW, has someone heard about a C++ implementation of AWT or Swing?
> This could be a start.

Though it would be interesting to see such an implementation, I
*REALLY* don't think it would be a good start for a C++ GUI standard.
First of all, I personally think that the Swing and AWT libraries
suffer very badly in several areas, and that a standards committee
would never have accepted them as they are.  Then there's the fact that
they are libraries designed for Java and so aren't great choices for a
C++ library.  For instance they rely on a universal base class for a
lot of things that would be better served by template interfaces in C++.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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              ]

Ed@my.home.net (EdT) writes:

>Where can one get the specifications for the hosted vs. unhosted portions
>of C and C++?  What part of what standard does one need to obtain?

The C standard (ISO/ANSI 9899-1990) describes hosted and
freestanding implementations in section 5.1.2 and its subsections.
You can get a copy of the C standard from ANSI or ISO, or
you can buy the book "The Annotated ANSI C Standard" by
Herbert Schildt, Osborne McGraw-Hill, 1990.

The C++ standard (ISO IEC 14882-1998) describes hosted and
freestanding implementations in section 1.4. See the FAQ for
this newsgroup for how to get a copy.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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 <37C4506C.246F11CC@tribble.com>,
  David R Tribble <david@tribble.com> wrote:
> Consider the question: How would you implement a GUI library for
> an O/S that only supports character terminals?

I'd use characters to draw the boxes, lines, etc.  There have been
plenty of menu/windows UI libraries for text-only displays.  My
impression is that is what the Unix "curses" library is sometimes used
for.  NetWare has their NUT library for displaying windows and menus
using a text-only display.  Perhaps a better term would be a "UI"
library instead of a "GUI" library.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ 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 <Bonnard.V@wanadoo.fr> wrote in message
news:37C6CB4E.56BD@wanadoo.fr...
> Richard Browne wrote:
> >
> > > Which new graphic capabilities appeared, say, in the
> > > last three years (that people use) ? When did windows,
> > > buttons and menus appeared ?
> >
> > Ok, let's see.. on Windows:
> >
> > * OpenType fonts
> > * DirectX/Direct3D
> > * Color management
> > * GDI alpha blending
> > * World transforms
>
> Are these all related with GUI ? I believe that DirectX/Direct3D
> is only for games. Are these new features of better replacement
> for existing features ?

You asked about "graphic capabilities", not GUI. Besides, although
DirectX/Direct3D certainly has a focus on gaming, these APIs have other uses
as well (such as multimedia, modeling, animation, ...).




[ 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 <7qeaf3$gun$1@engnews1.eng.sun.com>,
Steve Clamage <clamage@eng.sun.com> wrote:
>The C++ standard (ISO IEC 14882-1998) describes hosted and
>freestanding implementations in section 1.4. See the FAQ for
>this newsgroup for how to get a copy.

With some additional details in the first Library section: specifically
this section specifies which library headers are required even in a
free-standing implementation.


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

On 26 Aug 99 21:48:31 GMT, David R Tribble <david@tribble.com> wrote:

>This has been asked dozens of times before.  It may even be in the
>C++ FAQ.
>
>The short answer is that a standardized GUI API does not belong in
>a language standard; a language standard should only define the
>language proper and a minimal library, so that it can be implemented
>on a wide variety of platforms *including those without graphical
>I/O devices*.
>
Most of the STL-part in the Standard does not belong into a "language
standard". But the commitee decided to include language definition
and library definition into one standard.
This need not be so for a GUI library. It can be standardized, but
need not be part of  "The Standard".
BTW, has someone heard about a C++ implementation of AWT or Swing?
This could be a start.

------------------------------------------------
Martin Aupperle
MikeAlpha@NoSpam_csi.com
(remove NoSpam_)
------------------------------------------------
---
[ 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 <Bonnard.V@wanadoo.fr> wrote in message
news:37C559D6.21D6@wanadoo.fr...
[snip]
>
> Which new graphic capabilities appeared, say, in the
> last three years (that people use) ? When did windows,
> buttons and menus appeared ?
In no way I consider myself an expert on GUI but I had quite a big
experience with various Borland compilers. Basically, every year with new
release of their compiler their graphic library evolves. First there were
text based menus, buttons, etc. then came OWL and everybody sighed with
relief, then a few years ago VCL came into being: far superior to OWL
approach. Now there are more than 400 classes in VCL, and probably half of
them have direct or indirect relation to graphic capabilities. Add to that
hundreds of 3d party classes and you realize how big the problem is.

Gene Bushuyev




[ 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 <7q3n73$355$1@hardcore.ivn.net>, Scott Robert Ladd
<scott@coyotegulch.com> writes
>My opinion: The language should be specified separately from its libraries.
>We should have a C++ language standard and a C++ library standard --
>separate documents, with separate (but interacting) committees, since these
>are separate concepts. The language definition is absolute, but the library
>definition can be ignored, extended, modified, or changed.

Something I have been saying for at least five years.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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 <7q68ke$2cpi$1@hardcore.ivn.net>,
Scott Robert Ladd <scott@coyotegulch.com> wrote:
>
>David R Tribble <david@tribble.com> wrote...
>> The short answer is that a standardized GUI API does not belong in
>> a language standard; a language standard should only define the
>> language proper and a minimal library, so that it can be implemented
>> on a wide variety of platforms *including those without graphical
>> I/O devices*.
>
>And how is the current library standard "minimal" ?
>
>The Standard contains a hundred of pages (certainly not minimal in *my*
>book) devoted to the container, algorithm, and iterator classes. I'm not
>saying that Chapters 23-25 don't belong in *a* Standard, I just don't see
>that they belong in a *language* Standard. They certainly aren't
>minimalistic!

The difference is that these things are all just supporting basic data
structures that are useful across the board, from batch processing to
interactive applications.  These data structures have been useful for
decades, and will undoubtedly continue for the forseeable future.  They
have proven their general utility, and programmers have a right to expect a
language to provide them as a standard feature, rather than having to roll
or procure their own.  C++ didn't invent this; take a look at Common Lisp,
which has had similar things for 15 years.

User interface libraries, on the other hand, are closely tied to the
current "fashion".  In the current decade, windows, menus, and dialog boxes
are the norm, but in the 80's most systems only had text interfaces.  These
days we see more applications being done with integration to browsers in
mind, and in 10 years voice control may be the normal UI.  It's pretty
obvious (to me, at least) that it would be inappropriate to pick a UI style
and declare it as *the* way to do I/O in C++.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


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

David R Tribble <david@tribble.com> wrote...
> The short answer is that a standardized GUI API does not belong in
> a language standard; a language standard should only define the
> language proper and a minimal library, so that it can be implemented
> on a wide variety of platforms *including those without graphical
> I/O devices*.

And how is the current library standard "minimal" ?

The Standard contains a hundred of pages (certainly not minimal in *my*
book) devoted to the container, algorithm, and iterator classes. I'm not
saying that Chapters 23-25 don't belong in *a* Standard, I just don't see
that they belong in a *language* Standard. They certainly aren't
minimalistic!

--
  *     Scott Robert Ladd
  *
  *     Coyote Gulch Productions - http://www.coyotegulch.com
  *     GameLore - http://www.gamelore.com





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

Jack Klein wrote:

> Desktop chauvinism strikes again.  Not every platform which runs C++
> programs has a screen at all, let alone one which supports graphics.

Console/file system chauvinism strikes again. Not every platform
has a console at all, let alone support for files.

--

Valentin Bonnard


[ 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 <37cf9d94.13144501@netnews.worldnet.att.net>,
  jackklein@att.net (Jack Klein) wrote:
> On 25 Aug 1999 15:54:51 GMT, "Brian B. McGuinness"
> <brian.b.mcguinness@lmco.com> wrote in comp.std.c++:
>
> >
> > Since most modern C++ programs implement
> > GUI interfaces, it would make sense to create
> > a standard for a class hierarchy for commonly
> > used GUI elements such as menus, windows,
> > dialog boxes, check boxes, and radio buttons.
> > This would make it much easier to port
> > programs from one platform to another and
> > share interface code between programs.
> >
> > I know that there are already graphics
> > standards such as PHIGS, and there are
> > proprietary GUI class hierarchies such as
> > the MS Foundation Classes or the one
> > shipped with Borland's Turbo Pascal 6.0,
> > but I know of no ANSI or ISO standard
> > set of C++ GUI classes.
>
> Desktop chauvinism strikes again.  Not every platform which runs C++
> programs has a screen at all, let alone one which supports graphics.

Not every processor which runs C++ (or could run C++) has a file system,
either.  So it looks like we'll have to drop file IO from the standard
on the same grounds.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ 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              ]

David R Tribble wrote:

> Consider the question: How would you implement a GUI library for
> an O/S that only supports character terminals?

Consider the question: How would you implement a console interface
for an O/S that supports no character terminals at all ?

--

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

Richard Browne wrote:
>
> > Which new graphic capabilities appeared, say, in the
> > last three years (that people use) ? When did windows,
> > buttons and menus appeared ?
>
> Ok, let's see.. on Windows:
>
> * OpenType fonts
> * DirectX/Direct3D
> * Color management
> * GDI alpha blending
> * World transforms

Are these all related with GUI ? I believe that DirectX/Direct3D
is only for games. Are these new features of better replacement
for existing features ?

--

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

Since most modern C++ programs implement
GUI interfaces, it would make sense to create
a standard for a class hierarchy for commonly
used GUI elements such as menus, windows,
dialog boxes, check boxes, and radio buttons.
This would make it much easier to port
programs from one platform to another and
share interface code between programs.

I know that there are already graphics
standards such as PHIGS, and there are
proprietary GUI class hierarchies such as
the MS Foundation Classes or the one
shipped with Borland's Turbo Pascal 6.0,
but I know of no ANSI or ISO standard
set of C++ GUI classes.

--- Brian



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

Brian B. McGuinness wrote in message <37C3FE09.B1256377@lmco.com>...

>Since most modern C++ programs implement
>GUI interfaces, it would make sense to create
>a standard for a class hierarchy for commonly
>used GUI elements such as menus, windows,
>dialog boxes, check boxes, and radio buttons.
[snip]

This is a controversial subject. We are moving farther and farther from the
language per se and to the particular applications.
One objection is that all the graphic functions existing in various
compilers are very system specific. In Windows for example, it's not a
compiler library but OS that provides API functions for building all the
elements you mentioned. Some other systems do not have graphic capabilities
at all.
More difficult part is that graphic capabilities are changing quite rapidly,
and by making something a standard you agree to freeze it for at least
several years (decades?) So, only the most basic graphic primitives can be
standardized, but then they don't really have big importance, since in
practice people are using more complex concepts that various systems offer.

Gene Bushuyev




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

Gene Bushuyev wrote:

> Some other systems do not have graphic capabilities
> at all.

Some other systems do not have console API at all.

> More difficult part is that graphic capabilities are changing quite rapidly,
> and by making something a standard you agree to freeze it for at least
> several years (decades?) So, only the most basic graphic primitives can be
> standardized, but then they don't really have big importance, since in
> practice people are using more complex concepts that various systems offer.

Which new graphic capabilities appeared, say, in the
last three years (that people use) ? When did windows,
buttons and menus appeared ?

--

Valentin Bonnard


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

On 25 Aug 1999 15:54:51 GMT, "Brian B. McGuinness"
<brian.b.mcguinness@lmco.com> wrote in comp.std.c++:

>
> Since most modern C++ programs implement
> GUI interfaces, it would make sense to create
> a standard for a class hierarchy for commonly
> used GUI elements such as menus, windows,
> dialog boxes, check boxes, and radio buttons.
> This would make it much easier to port
> programs from one platform to another and
> share interface code between programs.
>
> I know that there are already graphics
> standards such as PHIGS, and there are
> proprietary GUI class hierarchies such as
> the MS Foundation Classes or the one
> shipped with Borland's Turbo Pascal 6.0,
> but I know of no ANSI or ISO standard
> set of C++ GUI classes.
>
> --- Brian

Desktop chauvinism strikes again.  Not every platform which runs C++
programs has a screen at all, let alone one which supports graphics.

Jack Klein
--
Home: http://home.att.net/~jackklein
---
[ 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              ]

Hi,

It's all a matter of demarcation: Where does a language end and its
implementation begin?

My opinion: The language should be specified separately from its libraries.
We should have a C++ language standard and a C++ library standard --
separate documents, with separate (but interacting) committees, since these
are separate concepts. The language definition is absolute, but the library
definition can be ignored, extended, modified, or changed.

Vendors could then support the standards necessary for their environment and
customer base.

This would allow someone to create a standard GUI library for C++ without
altering the core language. I would tie the library standards to a specific
version of the language standard. And I could still be "standard" by
following the language definition, without having also to use the library as
well.

The current kitchen-sink approach to language specification (even worse for
Java) leads to complex standards that try to do too much.

--
  *     Scott Robert Ladd
  *
  *     Coyote Gulch Productions - http://www.coyotegulch.com
  *     GameLore - http://www.gamelore.com
---
[ 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              ]

"Brian B. McGuinness" wrote:
>
> Since most modern C++ programs implement
> GUI interfaces, it would make sense to create
> a standard for a class hierarchy for commonly
> used GUI elements such as menus, windows,
> dialog boxes, check boxes, and radio buttons.
> This would make it much easier to port
> programs from one platform to another and
> share interface code between programs.
>
> I know that there are already graphics
> standards such as PHIGS, and there are
> proprietary GUI class hierarchies such as
> the MS Foundation Classes or the one
> shipped with Borland's Turbo Pascal 6.0,
> but I know of no ANSI or ISO standard
> set of C++ GUI classes.

This has been asked dozens of times before.  It may even be in the
C++ FAQ.

The short answer is that a standardized GUI API does not belong in
a language standard; a language standard should only define the
language proper and a minimal library, so that it can be implemented
on a wide variety of platforms *including those without graphical
I/O devices*.

Consider the question: How would you implement a GUI library for
an O/S that only supports character terminals?

-- David R. Tribble, david@tribble.com --
---
[ 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              ]