I clearly understand the need for a guenuine C++, with a coherent
standard and a support among all the industry compilers.

But when you compare it to JAVA and Delphi, C++ will become a big
dinosaure, like ADA with a new version each 10 years.

What about creating a parallel standard, namely C**, with a small
inertia and "emerging" from industrial ideas, in the same way JAVA and
Delphi are managed ?

The avantages may be a operationnal draft of future version of C++
(personnaly, for most of my projects I do not care if it can be compiled
by an obscure compiler, only the compliance with Microsoft xor Borland
is important, so I can take the risk to try C**, a kind of beta of C++),
moreover I really think that C++ need some cool stuff to battle against
JAVA.

----------------------

"cool" ideas (ordered by more or less faisable ..), all seen elsewhere,
I'm sure you have many :

1) a class attribute to enable virtual calls in ctor :

  class X : [attr-name ]  public Y {
  }

2) default named  parameters :
   int f( int X =3, int Y=5);
    ...
   F( Y=1);

3) properties included in RTII :
  class X : properties public Y{
  private :
   int  _prop;
   void SetProp( int prop ) { _prop = prop; };
  public
   property  Prop : integer read _prop write SetProp;
  }

  ...
  X  x;
  x.Prop = 3;
  x.SetIntPropByName( "Prop", 3); // RTII

  for( int i=0; i< x.GetPropCount; i++)
  ...;

4) meta class and virtual static methods :

   class A {
      static virtual F();
   };


  class B {
    static virtual F();
  };


  void Foo( class of A c)
  {
     c.F();
  }

  main()
  {
 Foo( A );
        Foo( B );
  }


5 ) "override" keyword for virtual function overloading

6) include return type in function signature


7) garbaged classes (use of a gabaged collector):
  class X : garbaged public Y {
  }

x) inheritance of multiple classes ;

   class X : public Y=y1, public Y=y2 {
       int f() {  y1.Z(); }
       virtual y1::Op();
       virtual y2::Op();
   }


x) dynamic inheritance :
   class X : *p{
   }

x) finally keyword :

  int f( X &x)
  {
    x.AddRef();
    try{
      try{
         .....;
      } catch(...) {
         //error here
      }
    }finally {
     // no ncesessary error here
     x.Release();
    }
  }

x) "inherited" keyword


x) java-like packages (instead of basic *.h *.c couple)

x) include enough informations in the RTII in order to make
CORBA/DCOM-enabled classes ( no need for IDL processing). for instance :

  class X : public Y {
     remote int f();
  }

8) total compatibilty with JAVA :
 - source code
        - compiled code
---
[ 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 <351A2507.5204@cert.fr>,
  Loic Tregan <Loic.Tregan@cert.fr> wrote:
>
> I clearly understand the need for a guenuine C++, with a coherent
> standard and a support among all the industry compilers.
>
> But when you compare it to JAVA and Delphi, C++ will become a big
> dinosaure, like ADA with a new version each 10 years.

There will certainly be a new version of the C++ every 5-10 years.
ISO requires it.  We will shortly have a new version of the C standard,
for example.  Does this make C a big dinosaur.

Java and Delphi are too new to be judged in this regard.  If you are
looking for an example of an industry owned language, as opposed to
an ISO standard, I think PL/M would be a much better example.  (It's
interesting to note that Sun seems to think so to, since they are
pushing very strongly for Java standardization by ISO.)

> What about creating a parallel standard, namely C**, with a small
> inertia and "emerging" from industrial ideas, in the same way JAVA and
> Delphi are managed ?

Well, there is a subset available, embedded C++, supported by a number
of Japanese chip manufacturers and probably some others. See
http://www.caravan.net/ec2plus/index.html.

On the other hand, my impression from your proposals is that you
want just the opposite.  You seem to find that C++ is not complex
enough for you.

> The avantages may be a operationnal draft of future version of C++
> (personnaly, for most of my projects I do not care if it can be compiled
> by an obscure compiler, only the compliance with Microsoft xor Borland
> is important, so I can take the risk to try C**, a kind of beta of C++),
> moreover I really think that C++ need some cool stuff to battle against
> JAVA.

First, I'm not sure that there is a battle, and I'm very sure that
there shouldn't be.  Java is one thing, and C++ is another.

> "cool" ideas (ordered by more or less faisable ..), all seen elsewhere,
> I'm sure you have many :

    [...]
> x) finally keyword :

As I'm fond of pointing out, the way to handle this in C++ is
to define a built-in class __local_context, with all variables
visible in the current local context as public (or protected)
members.  Then derive from this.

    [...]
> x) java-like packages (instead of basic *.h *.c couple)

I rather think that some sort of real module system is necessary,
but Java's packages aren't really any different from namespaces.

In fact, packaging is one of Java's real weaknesses, compared to
C++ (which is already pretty weak).  In Java, it's impossible to
separate the interface from the implementation (except in a limited
fashion through inheritance).

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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 the other hand, my impression from your proposals is that you
>want just the opposite.  You seem to find that C++ is not complex
>enough for you.
>
>> The avantages may be a operationnal draft of future version of C++
>> (personnaly, for most of my projects I do not care if it can be compiled
>> by an obscure compiler, only the compliance with Microsoft xor Borland
>> is important, so I can take the risk to try C**, a kind of beta of C++),
>> moreover I really think that C++ need some cool stuff to battle against
>> JAVA.

I suppose really useful "extensions" to the C++ would reflect real world
practice sooner rather than later. One early idea was support for
mutli-threading in ADA and Modula-x. So Loic's idea about including support
for DCOM/CORBA makes some sense. But I mean in a non-proprietary way.

I think that support for invoking objects in other process spaces or between
CPU's or network disperse machines/OS is going to become vital. Java and RMI
looks clean, so could C++ be extended in a suitable way to support portable
code. I understand the split between what belongs  in a language and what is
in the OS, but if a HLL is supposed to abstract low level constructs, then
we need a way to think about distributed apps in a high level way without
resorting to the minutia of low-level CORBA/DCOM.

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              ]

Ed Howland <ed@moonvalley.com> wrote:
: >On the other hand, my impression from your proposals is that you
: >want just the opposite.  You seem to find that C++ is not complex
: >enough for you.
: >
: >> The avantages may be a operationnal draft of future version of C++
: >> (personnaly, for most of my projects I do not care if it can be compiled
: >> by an obscure compiler, only the compliance with Microsoft xor Borland
: >> is important, so I can take the risk to try C**, a kind of beta of C++),
: >> moreover I really think that C++ need some cool stuff to battle against
: >> JAVA.

: I suppose really useful "extensions" to the C++ would reflect real world
: practice sooner rather than later. One early idea was support for
: mutli-threading in ADA and Modula-x. So Loic's idea about including support
: for DCOM/CORBA makes some sense. But I mean in a non-proprietary way.

: I think that support for invoking objects in other process spaces or between
: CPU's or network disperse machines/OS is going to become vital. Java and RMI
: looks clean, so could C++ be extended in a suitable way to support portable
: code. I understand the split between what belongs  in a language and what is
: in the OS, but if a HLL is supposed to abstract low level constructs, then
: we need a way to think about distributed apps in a high level way without
: resorting to the minutia of low-level CORBA/DCOM.

This would go against the core C++ philosophy, which will not
change any time soon, probably never. Among other things, C++
is an abstraction of _a_ computer system (hardware+OS). Therefore it
provides abstraction for only those features which are
present on all computer systems and allow identical abstraction,
and which can be implemented easily [1] and efficiently on
any platform.

Neither concurrent programming nor ORB come even close to being
that.

Note that neither Java nor Ada has this problem. Java abstracts
the Java Virtual Machine, and Ada abstracts wishful thinking of the
Department of Defence.

[1] C++ gave a new meaning to `easily''.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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 Howland <ed@moonvalley.com> wrote:
>: I think that support for invoking objects in other process spaces or
>: between CPU's or network disperse machines/OS is going to become
>: vital. Java and RMI looks clean, so could C++ be extended in a
>: suitable way to support portable code. I understand the split between
>: what belongs  in a language and what is in the OS, but if a HLL is
>: supposed to abstract low level constructs, then we need a way to
>: think about distributed apps in a high level way without resorting
>: to the minutia of low-level CORBA/DCOM.

Oleg Zabluda wrote:
> This would go against the core C++ philosophy, which will not
> change any time soon, probably never. Among other things, C++
> is an abstraction of _a_ computer system (hardware+OS). Therefore it
> provides abstraction for only those features which are
> present on all computer systems and allow identical abstraction,
> and which can be implemented easily [1] and efficiently on
> any platform.

But one thing that is definitely missing from C++ is persistent
objects, whether or not you're talking about distributing them.
There is no standard way, today, in the C++ language or library, to
store a class object and then retrieve it later with another
program.  Writing and reading nonvolatile data is present on all
but the most toy-like computer systems.

Oh, sure, I can write member functions that pack the data members
of my classes into POD structs and write them to disk, and other
member functions that do the reverse.  But it's my code, not part
of C++ or the library.  There is no library base class or STL
container template, for instance, for persistence.  While it has
the concept of "persistent data" (via cin and cout for example),
the language has no concept of "persistent class data".  Pity.

(Based on what I know, anyway.  The C++ draft weighs about ten
pounds, and I haven't pored over the whole STL yet.)

-- David R. Tribble, david.tribble@noSPAM.central.beasys.com --
C++, the PL/1 of the 90s.
---
[ 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              ]