Sorry for this long mail, but I'd like to get things back to the
original discussion. First, I get the impression that looking at the
Java API can be fruitfull and looks promising. There are the following
difficulties:

1 - The interface will difficult to design. "If applications are hard
to design, and toolkits are harder, then frameworks are the hardest of
all." ('Design Patterns', from E. Gamma et al.)
I'll look at the language features for now:
 * Threadding support (different threading models per OS)
 * Closures that could be used for the
 I still don't completely understand the concept
 of closures and why we would need them but it looks
 interesting... (a code example, please:)
 * (more?)

2 - Vendor support. This point was raised by Scott and boils down to
"Big companies have invested a lot of money in their properitairy
APIs".
We all know why they do this, it is to their advantage to keep their
APIs non-portable: They want to tie programmers to their products. On
the other hand, the programmers don't want to be bothered with these
APIs. Programmers move to Java for this reason.
The usefull stuff that Java implements is available across all major
application platforms. Why? Because the programmer _needs_ stuff like
networking, multithreadding and GUI programming.

We already have strings and vectors now, and reasonable, further
standardisation should take place, and it is possible too... (And we
don't need a virtual machine to do it;)

Bert

===
P.S.:  What I had in mind was to keep very close to the original Java
API and place it in a seperate namespace:)
------------------------------------------------------------------------
#include <iostream>
#include <string>
#include <cstdlib>
#include <java/net>
int main()
{
 java::ServerSocket serverSocket = 0;
 try { serverSocket = new java::ServerSocket(4444); }
 catch (java::IOException e) {
  std::cout << "listen error" << std::endl; exit(1);
 }
 // stuff deleted...
 serverSocket.close();
 return 0;
}


[ 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 <36122e9e.19177826@news.xs4all.nl>
           bjweerd@xs4all.nl "Bert van der Weerd" writes:

> Sorry for this long mail, but I'd like to get things back to the
> original discussion. First, I get the impression that looking at the
> Java API can be fruitfull and looks promising. There are the following
> difficulties:
>
> 1 - The interface will difficult to design. "If applications are hard
> to design, and toolkits are harder, then frameworks are the hardest of
> all." ('Design Patterns', from E. Gamma et al.)
> I'll look at the language features for now:
>         * Threadding support (different threading models per OS)
>         * Closures that could be used for the
>         I still don't completely understand the concept
>         of closures and why we would need them but it looks
>         interesting... (a code example, please:)
>         * (more?)

I think it would be unwise to look at language features - there is
enough work for compiler vendors getting into step with the standard.

Anything new must be done within the scope of the existing language or
it just won't happen.

The output of this effort must be a library definition whose interface is
entirely within the existing language.  (If the library can be implemented
within the language so much the better - but at the very least it will need
to invoke platform APIs.)

So, by all means work on a threading library definition - but don't
change the language to support it.

C++ doesn't have closures (nor does Java, but it's closer).  The library
must not rely on them. As I indicated in a prior post it is possible to
implement sufficient functionality to support "callback" objects without.
The library must provide a usable interface where this is needed.

PS

A "closure" is a way of passing the current scope around - so that, for
example auto variables could be accessed "outside" the function that owns
them.  In C++ we explicitly pass references or pointers to achieve this
effect.

--
Alan Griffiths              | Senior Systems Consultant, Experian
alan.griffiths@experian.com (agriffiths@ma.ccngroup.com, Tel. +44 115 934 4517)



[ 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 <360EE4FA.DEDA235C@abraxis.com>,
  eddielee@abraxis.com wrote:
>
> Scott Johnson wrote:
> > I can think of several language features it would be nice to have in
> > order to implement this more effectively--"closures" (essentially a
> > combination of a pointer to an object and a pointer to its member
> > function), and/or inner classes.  Neither of these is mandatory to
> > implement an event-driven GUI model, but they sure make life easier.
>
> Closures work very well with Inprise's C++ Builder and make it easy to hook
functions in classes to events. I would very much like to see this in the next
version of C++ since the idea
> extends beyond the event programming model. I have always believed that it

should be possible in an object oriented language to assign to a "pointer" to
a method of a given signature any

> function, no matter in what class, that has the same signature. The concept of
"closure" is just such a "pointer".

However, we don't need closures to wrap an (object pointer, member function
pair) callback.  Generics suffice. Vis (from the system I'm working on):

    /// Abstract interface for validator callback.
    template<typename MyPropertyType>
    class M6ValidatorCallback
    {
    public:

        /// make a clone
        virtual M6ValidatorCallback* makeClone() const = 0;

        /* do the validation.
        * @return 0 or an application specific error code
        */
        virtual int validateChange(MyPropertyType newValue) const = 0;
    };

    // implementation
    template<typename MyPropertyType, typename MyValidatorObject>
    class M6ValidatorCallbackImplementation :
            public M6ValidatorCallback<MyPropertyType>
    {
    public:

        typedef int (MyValidatorObject::*MyValidatorMethod)(MyPropertyType
newValue);

        M6ValidatorCallbackImplementation(MyValidatorObject* validator,
MyValidatorMethod  method);


        virtual M6ValidatorCallback<MyPropertyType>* makeClone() const;

        virtual int validateChange(MyPropertyType newValue) const;

    private:

        MyValidatorObject* myValidator;
        MyValidatorMethod  myMethod;
    };

(OK there is some code missing, but that is enough for this discussion.)

The above approach could be applied to an analog of the AWT
"Listener"/"Adaptor" objects.  The lack of closures does mean that there
needs to be a target method on the target object (i.e. no direct updates of
the state).

Of more concern are object lifetime and thread synchronisation issues which
are addressed by the JVM but not by the C++ "abstract machine".  I believe
that the former can be addressed portably (but would be easier with full GC
including finalisation), the latter runs into problems with differing
threading models (last time I looked - a while ago - Java still had
portability issues with its threading model).

But the technical problems are solvable and irrelevant compared to the
difficulty of pursuading anyone to make the effort. For myself I'd prefer
working on this to my current job, but not to my current hobbies.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


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

I believe that the amount of code necessary to implement just a single "object
pointer, member function pair callback" illustrates why a "closure" built in to the
language would be so valuable.

agriffiths@ma.ccngroup.com wrote:

> In article <360EE4FA.DEDA235C@abraxis.com>,
>   eddielee@abraxis.com wrote:
> >
> > Scott Johnson wrote:
> > > I can think of several language features it would be nice to have in
> > > order to implement this more effectively--"closures" (essentially a
> > > combination of a pointer to an object and a pointer to its member
> > > function), and/or inner classes.  Neither of these is mandatory to
> > > implement an event-driven GUI model, but they sure make life easier.
> >
> > Closures work very well with Inprise's C++ Builder and make it easy to hook
> functions in classes to events. I would very much like to see this in the next
> version of C++ since the idea
> > extends beyond the event programming model. I have always believed that it
>
> should be possible in an object oriented language to assign to a "pointer" to
> a method of a given signature any
>
> > function, no matter in what class, that has the same signature. The concept of
> "closure" is just such a "pointer".
>
> However, we don't need closures to wrap an (object pointer, member function
> pair) callback.  Generics suffice. Vis (from the system I'm working on):

Code example snipped for brevity.
---
[ 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              ]

Hello everybody,

I've been programming with C++ for quite a while now, and when the ISO C++=
 standard came out, I was really content with it. Finally we can program in=
 a higher-level more way and are released of the burdon of reprogramming=
 stuff over and over again.

I was also very content with Java, it's ideas and it's API, which again=
 releases the programmer of the burdon of reprogramming, for example,=
 low-level socket-stuff. Java will sometime become an ANSI standard too...

Why not reuse this design somehow and take some of it's API and declare it=
 a standard too? The advantage for the programmer is twofold:
 * More usable classes that are standard across different implementations
 * Lower learningcurve when programming both Java and C++, and let's face=
 it Java and
 C++ are no concurrents, they operate in different fields of computing...

Bert van der Weerd.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Bert van der Weerd                             Lost Boys Interactive Bv.
                                     Herengracht 280, 1016 BX, Amsterdam
                                      tel: 020-4203371, fax: 020-4203356
---
[ 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 <199809241115390730.05553D47@lostcity.nl>
           bert@lostcity.nl "B.J. van der Weerd" writes:

> I was also very content with Java, it's ideas and it's API, which again=
>  releases the programmer of the burdon of reprogramming, for example,=
>  low-level socket-stuff. Java will sometime become an ANSI standard too...
>
> Why not reuse this design somehow and take some of it's API and declare it=
>  a standard too? The advantage for the programmer is twofold:
>  * More usable classes that are standard across different implementations
>  * Lower learningcurve when programming both Java and C++, and let's face=
>  it Java and
>  C++ are no concurrents, they operate in different fields of computing...

Given the PITA that GUI programming is in C++ (I suffer from MFC) and the
serious lack of portability I'd be very happy for a platform independent
"Swing" equivalent.

I'd also enjoy working on designing and implementing the same.  (But in order
to devote adequate time I'd need to find an employer that would pay for it.)

However, C++ is applied in a lot of domains where such a library is
irrelevant - so it shouldn't be in the C++ Standard.  (No reason though
why such libraries and/or API should not be standardised - posix functions
are not in the C standard, but they are in an international standard.)

Basically, if enough people are willing to do the work, then it can and will
happen.

Are you willing & able to do the work, or to fund it?

--
Alan Griffiths              | Senior Systems Consultant, Experian
alan.griffiths@experian.com (agriffiths@ma.ccngroup.com, Tel. +44 115 934 4517)



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

B J van der Weerd writes:

> Java will sometime become an ANSI standard too...

> Why not reuse this design somehow and take some of it's API and
> declare it a standard too?

That is an interesting and intelligent idea.

However, there is no current Java standard, so there is nothing to
standardize on.

As a side note, I notice that it would be impossible to implement STL
in Java.

--
Colin


[ 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 24 Sep 1998 18:02:24 GMT, aGriffiths@ma.ccngroup.com (Alan
Griffiths) wrote:

>> Why not reuse this design somehow and take some of it's API and declare it=
>>  a standard too? The advantage for the programmer is twofold:
>>  * More usable classes that are standard across different implementations
>>  * Lower learningcurve when programming both Java and C++, and let's face=
>>  it Java and
>>  C++ are no concurrents, they operate in different fields of computing...

>Given the PITA that GUI programming is in C++ (I suffer from MFC) and the
>serious lack of portability I'd be very happy for a platform independent
>"Swing" equivalent.

It will also give way for a lot of gui-development-tools that will be
able to work naturally with both C++ as Java. Seriously, there would
be more useful ideas possible, I believe.
In almost any C++ book from Bjarne Stroustroupp he explains that he
does look at other programming languages, so why not do it now?

[ moderator's note: Excessive quoting deleted. Please quote
  only as much material as is needed to understand the reply. -sdc ]


[ 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 24 Sep 1998 18:21:19 GMT, Colin Rafferty <craffert@ms.com> wrote:

>However, there is no current Java standard, so there is nothing to
>standardize on.

But it will, in general, look like how it's now. And ofcourse the
challenge here is to make such interfaces that the application
programmer doesn't notice too much differences, except for those that
you cannot avoid. After all C++ and Java are 'grown from the same
root' but very different.

>As a side note, I notice that it would be impossible to implement STL
>in Java.

It's just looking at Java, not the other way round, because as a
language I consider C++ superior over Java.



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

Colin Rafferty (craffert@ms.com) wrote:
: As a side note, I notice that it would be impossible to implement STL
: in Java.

To be a little more explicit: Java doesn't have STL and it is very
desirable for high quality C++ code bases to interoperate well with STL.
Both so that they can be used with naturally written ISO C++ and to make
them more efficient in their use of resources (code space, implementation
time, etc.).

So repurposing Java API's into C++ poses an interesting issue of how to
utilize STL and other template emchanisms. On the flip side, one also has
to figure out some tough memory management issues as ISO C++ does not require
garbage collection.

Cross language standards are a good idea but they are not easy to design
and specify. Especially for broad deep areas such as graphics and user
interface. (Where we have huge differences of opinion on how to do things
even within the same language :-))

-Z-


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

Alan Griffiths wrote:
>
> In article <199809241115390730.05553D47@lostcity.nl>
>            bert@lostcity.nl "B.J. van der Weerd" writes:
>
> > I was also very content with Java, it's ideas and it's API, which
> > again= releases the programmer of the burdon of reprogramming, for
> > example,= low-level socket-stuff. Java will sometime become an ANSI > > standard too...
> >
> > Why not reuse this design somehow and take some of it's API and
> > declare it= a standard too? The advantage for the programmer is
> > twofold: * More usable classes that are standard across different
> > implementations * Lower learningcurve when programming both Java and > > C++, and let's face= it Java and C++ are no concurrents, they > > operate in different fields of computing...

> Given the PITA that GUI programming is in C++ (I suffer from MFC) and > the serious lack of portability I'd be very happy for a platform
> independent "Swing" equivalent.


Would be nice.

I can think of several language features it would be nice to have in
order to implement this more effectively--"closures" (essentially a
combination of a pointer to an object and a pointer to its member
function), and/or inner classes.  Neither of these is mandatory to
implement an event-driven GUI model, but they sure make life easier.

> I'd also enjoy working on designing and implementing the same.  (But
> in order to devote adequate time I'd need to find an employer that > would pay for it.)
>
> However, C++ is applied in a lot of domains where such a library is
> irrelevant - so it shouldn't be in the C++ Standard.

Agreed, at least as far as the base standard is concerned.  What about
as an optional component, like POSIX does???

Other things, like networking, might even be useful into the standard.
Not all implementations support networks, of course, but there isn't any
reason that networking functions wouldn't exist--they just would always
return an appropriate error on such an implementation.  The big issue is
what networking standard, if any, will apply.  TCP/IP is an obvious
choice, being ubiquitous and an open standard...

> (No reason though why such libraries and/or API should not be
> standardised - posix functions are not in the C standard, but they are > in an international standard.)
>
> Basically, if enough people are willing to do the work, then it can
> and will happen.

The bigger issue is vendor support.  Groups of engineers can get
together and form standards to their hearts' content; but lots of
players (MS, etc.) have a lot of money invested in propreitary UI
technologies.  Some folks, such as Zinc, have bothered to write decent
cross-platform GUI libraries, but they seem to only be found in niche
markets (folks who do lots of Windoze/Unix codevelopment, and the
embedded market.)


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

B.J. van der Weerd wrote:
> Why not reuse this design somehow and take some of it's API and declare it a standard too?             ]

Because one of the main advantages of C++ is you can write all the
keywords on half a sheet of paper.

It would be fine if a vendor wanted to produce a library which
implemented some portions of the Java SDK in C++.
---
[ 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              ]

Scott Johnson wrote:

> Alan Griffiths wrote:
> >
> > In article <199809241115390730.05553D47@lostcity.nl>
> >            bert@lostcity.nl "B.J. van der Weerd" writes:
> >
> > > I was also very content with Java, it's ideas and it's API, which
> > > again= releases the programmer of the burdon of reprogramming, for
> > > example,= low-level socket-stuff. Java will sometime become an ANSI > > standard too...
> > >
> > > Why not reuse this design somehow and take some of it's API and
> > > declare it= a standard too? The advantage for the programmer is
> > > twofold: * More usable classes that are standard across different
> > > implementations * Lower learningcurve when programming both Java and > > C++, and let's face= it Java and C++ are no concurrents, they > > operate in different fields of computing...
>
> > Given the PITA that GUI programming is in C++ (I suffer from MFC) and > the serious lack of portability I'd be very happy for a platform
> > independent "Swing" equivalent.
>
> Would be nice.
>
> I can think of several language features it would be nice to have in
> order to implement this more effectively--"closures" (essentially a
> combination of a pointer to an object and a pointer to its member
> function), and/or inner classes.  Neither of these is mandatory to
> implement an event-driven GUI model, but they sure make life easier.

Closures work very well with Inprise's C++ Builder and make it easy to hook functions in classes to events. I would very much like to see this in the next version of C++ since the idea
extends beyond the event programming model. I have always believed that it should be possible in an object oriented language to assign to a "pointer" to a method of a given signature any
function, no matter in what class, that has the same signature. The concept of "closure" is just such a "pointer".




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