d96-mst@nada.kth.se (Mikael St   ldal) writes:

|>  In article <rf5zpxhvsy2.fsf@vx.cit.alcatel.fr>,
|>  James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:
|>
|>  >I do agree that there is some need for standardization (although there
|>  >are still a lot of applications that don't use a GUI, or even a console,
|>  >for that matter).  I rather doubt, however, that politics would allow
|>  >it.
|>
|>  What about networking then? UNIX Sockets are common and used by other
|>  non-UNIX OSes as well (such as OS/2 and Windows "Winsock"). It would be
|>  nice with a standardized C++ interface to Sockets (preferrably based on
|>  I/O-streams, but with additional features).

>From what I've been told, the only similarity between Winsock and a Unix
socket is four letters in the name.  For that matter, there are Unix
sockets and Unix sockets; anyone who has ported from UCB to System V
will have noticed:-).  And Posix doesn't define sockets (yet).

Given all this, I can hardly see what C++ is going to standardize.

What *might* be interesting would be to standardize a high level
interface for interprocess/interprocessor communication.  But I fear
that this would require the standards committee to invent, which is not
really their role.  (There might also be a political problem: the C++
standards committee is an ISO working group, and is supposed to align
itself with other ISO groups.  It is not hard to imagine political
presure being brought to push the interface in the direction of the ISO
OSI communications protocols, although 90% or more of the interprocessor
communications today uses the Internet protocol suite.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <rf5zpxhvsy2.fsf@vx.cit.alcatel.fr>,
James Kanze <james-albert.kanze@vx.cit.alcatel.fr> wrote:

>I do agree that there is some need for standardization (although there
>are still a lot of applications that don't use a GUI, or even a console,
>for that matter).  I rather doubt, however, that politics would allow
>it.

What about networking then? UNIX Sockets are common and used by other
non-UNIX OSes as well (such as OS/2 and Windows "Winsock"). It would be
nice with a standardized C++ interface to Sockets (preferrably based on
I/O-streams, but with additional features).
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

On 19 Feb 1997 09:57:35 PST, d96-mst@nada.kth.se (Mikael St=E5ldal)
wrote:

>
>What about networking then? UNIX Sockets are common and used by other
>non-UNIX OSes as well (such as OS/2 and Windows "Winsock"). It would be
>nice with a standardized C++ interface to Sockets (preferrably based on
>I/O-streams, but with additional features).
>---


Yes that is a good thing to do.  Infact One company has done a
commercial product already - Objectspace's Systems<Toolkit>  The
provide a nice class library for sockets, threads, date/time,
security, etc etc.  Short of making this sould like an ad, that would
a real nice idea.
   Nope Iam not associated with Objectspace in anyway :-)

Cheers,
Vivek Venugopalan
vivek(at)mcs(dot)net

That was done to prevent spammers.  =20
Please remove the *** in my reply to address before
emailing me.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Howard E. Hinant" <heh@beamtech.com> wrote:

>I've been spending a few days with java.  IMHO this language really
>screwed some things up.  But what it does right is provide standard
>libraries for networking and gui's.  The C++ standard guys have done a
>fine job with STL, but you really can't write an application today
>without a gui.  Sure would be nice if I could write a portable C++
>program.
>

You missed the thread(s) about getch().

C++ doesn't have library functions for interactive console
applications; why would it have a (probably larger) GUI library?


--
Mike Enright
menright@cts.com
http://www.users.cts.com/sd/m/menright/
Cardiff-by-the-Sea, California, USA
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Howard E. Hinant" <heh@beamtech.com> writes:

|>  I've been spending a few days with java.  IMHO this language really
|>  screwed some things up.  But what it does right is provide standard
|>  libraries for networking and gui's.  The C++ standard guys have done a
|>  fine job with STL, but you really can't write an application today
|>  without a gui.  Sure would be nice if I could write a portable C++
|>  program.
|>
|>  I know there are tons of options out there for portable C++ application
|>  frameworks.  That is the problem.  Learning one is a major investment.
|>  Pick a framework that isn't supported next year, and I've thrown a major
|>  chunk of time and code into the trash.
|>
|>  If STL defined a gui application framework (like java.awt), I'd learn it
|>  because I would have faith that it would stick around for a while.  I'd
|>  even put up with major revisions as the standard matured.   This would
|>  be a lot better than no standard at all.
|>
|>  One of the original purposes of high-level languages was to insulate the
|>  programmer from platform dependencies.  This used to mean standard read
|>  & write methods to/from a console.  Platforms have gotten a lot more
|>  complicated.  I think more languages should follow java's lead in this
|>  respect.
|>
|>  Other opinions?

I would rather see the GUI defined by a separate standard, independantly
of the language, and then just have language bindings defined.

I do agree that there is some need for standardization (although there
are still a lot of applications that don't use a GUI, or even a console,
for that matter).  I rather doubt, however, that politics would allow
it.  There is one more or less standard multiplatform GUI (X Windows),
but it is not the most frequently used.  And I don't see Microsoft
leading a standardization effort for MS-Windows, which would allow other
vendors guaranteed compatibility.

In the meantime, I'd go with one of the frameworks.  Some of the vendors
(I'm familiar with ILog, for example) have been around long enough, and
are big enough, that you don't have to worry for the next couple of
years.  And in 10 years time, who knows if we'll even be programming
C++.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Matt Austern (austern@sgi.com) wrote:
: If someone proposed a good portable windowing library for the C++
: standard library, I'd be quite prepared to consider it.  We're talking
: about the next round of standardization, of course; it's far too late
: for the current round.

Or even a separate standard. (To reduce integration problems if
nothing else.)

--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

I've been spending a few days with java.  IMHO this language really
screwed some things up.  But what it does right is provide standard
libraries for networking and gui's.  The C++ standard guys have done a
fine job with STL, but you really can't write an application today
without a gui.  Sure would be nice if I could write a portable C++
program.

I know there are tons of options out there for portable C++ application
frameworks.  That is the problem.  Learning one is a major investment.
Pick a framework that isn't supported next year, and I've thrown a major
chunk of time and code into the trash.

If STL defined a gui application framework (like java.awt), I'd learn it
because I would have faith that it would stick around for a while.  I'd
even put up with major revisions as the standard matured.   This would
be a lot better than no standard at all.

One of the original purposes of high-level languages was to insulate the
programmer from platform dependencies.  This used to mean standard read
& write methods to/from a console.  Platforms have gotten a lot more
complicated.  I think more languages should follow java's lead in this
respect.

Other opinions?

-Howard
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

heh@beamtech.com writes:
>I've been spending a few days with java.  IMHO this language really
>screwed some things up.  But what it does right is provide standard
>libraries for networking and gui's.  The C++ standard guys have done a
>fine job with STL, but you really can't write an application today
>without a gui.

A gui assumes that you have a bit-mapped display, and standard networking
assumes you have a network (Java assumes you have a TCP/IP network at
that).  C++ is intended for a wider range of applications than these,
particularly in embedded systems.

A well-designed C++ class library that could be obtained from multiple
vendors with compatible implementations for the various Windows flavors,
Macs, and Unix systems would be a good thing.  But before it can become
part of a standard someone must define it.  Without a coherent proposal
committees cannot act.  While such a thing would be too late to go into
the language standard, you can always have separate standards documents
describing libraries and build on top of the C++ standard.

>If STL defined a gui application framework (like java.awt),

java.awt is a hopelessly weak, least-common-denominator solution (e.g.
your mouse only has one working button on PC's and Unix because Macs have
only one button, etc).  The awt designers should have looked at, for
example, Tk, which is currently being developed inside the same company
(and also provides platform-independent graphics).  If someone wants to
use java.awt as a basis for some kind of C++ graphics standard they should
learn from its deficiencies.

>One of the original purposes of high-level languages was to insulate the
>programmer from platform dependencies.  This used to mean standard read
>& write methods to/from a console.

C and C++ do not even provide that; there is no console, only FILE
and streams.

--
-- Joe Buck http://www.synopsys.com/pubs/research/people/jbuck.html

Help stamp out Internet spam: see http://www.vix.com/spam/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

jbuck@Synopsys.COM (Joe Buck) writes:

> heh@beamtech.com writes:
> >I've been spending a few days with java.  IMHO this language really
> >screwed some things up.  But what it does right is provide standard
> >libraries for networking and gui's.  The C++ standard guys have done a
> >fine job with STL, but you really can't write an application today
> >without a gui.
>
> A gui assumes that you have a bit-mapped display, and standard networking
> assumes you have a network (Java assumes you have a TCP/IP network at
> that).  C++ is intended for a wider range of applications than these,
> particularly in embedded systems.

That's actually not a decisive argument against putting windowing and
networking in the C++ standard library.  C++ already recognizes a
distinction between "hosted" and "freestanding" implementations.
Clearly freestanding implementations wouldn't be expected to support
these features, so either the standard could require them for hosted
implementations or (preferably, in my opinion) it could introduce a
third type of implementation.

If someone proposed a good portable windowing library for the C++
standard library, I'd be quite prepared to consider it.  We're talking
about the next round of standardization, of course; it's far too late
for the current round.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]