Gilbert Chen wrote:

> Our research group has developed a component-oriented extension to C++
> that advocates the idea of building programs by composing basic
> blocks.  The addition of keywords and syntatic rules is minimal.  We
> mainly use this extended language in discrete event simulation,
> although it could be equally well applied to other domains
> (hopefully).  If you are interested, please take a look at:
>
> http://www.cs.rpi.edu/~cheng3/compc++/
>
> Comments and suggestions are welcome.
>
> Gilbert Chen
Frankly, I don't quite see the use: what does this provide that, e.g.,
boost::function doesn't?

I.e.: if you want to call a function of an unknown class from some other
class, you can simply have that class contain a pointer to a function
and hand it the function to call some time before its use. Or you could
just make it a template class and have it call some function on one of
its template arguments, e.g.

template <class B>
class A
{
 B * b;

 void f()
 {
  b->g();
 }
};

A never needs to know what B is about - it just won't compile if B::g
doesn't exist.

rlc


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

vidar@hokstad.name (Vidar Hokstad) wrote in message news:<3ef78faf.0407270358.69687915@posting.google.com>...
 > gilbertchen@gmail.com (Gilbert Chen) wrote in message news:<e9c628e.0407261254.2d012406@posting.google.com>...
 > > Our research group has developed a component-oriented extension to C++
 > > that advocates the idea of building programs by composing basic
 > > blocks.  The addition of keywords and syntatic rules is minimal.  We
 > > mainly use this extended language in discrete event simulation,
 > > although it could be equally well applied to other domains
 > > (hopefully).  If you are interested, please take a look at:
 > >
 > > http://www.cs.rpi.edu/~cheng3/compc++/
 > >
 > > Comments and suggestions are welcome.
 >
 > While it looks interesting on the surface, I can't really see a
 > benefit that would be large enough for me to bother with new syntax.
 >
 > The examples on your web page can easily be achieved with standard C++
 > by factoring the "ports" out as abstract base classes and providing a
 > tiny bit of glue to implement the "connect" keyword as methods
 > instead.
 >
 > "Components" the way you use the term have been used in C++ for years
 > without any syntactical support - Personally I routinely implement
 > reusable functionality this way (having classes that forward parts of
 > their functionality to objects that implement an abstract interface)
 > when templates doesn't make sense (in particular where it makes sense
 > to plug in different components with different dynamically set state
 > at runtime).
 >
 > Your extension might save some typing, but at the expense of adding
 > more keywords and elevating a specific architectural pattern to part
 > of the language itself.
 >
 > What is the rationale for adding extra syntax for this instead of
 > using long established C++ idioms?

{quoted signature and clc++m banner snipped. -mod}

It is all about efficiency.  Sure, the same thing can be implemented,
with ugly syntax, in pure C++.  In fact, the older version of the
simulation toolkit (for which we designed this new language extension)
was implemented entirely in standard C++, using a lot of templates.
After we rewrote it with the extended language, the simulation speeds
were improved by 20%-80%, depending on applications.  The improvement
might not seem a lot, but it truly frees us from any contraints on the
component granularity.  Now we can use components that perform
operations as simple as increment and decrement, without any loss of
efficiency.  It is impossible to achieve this with standard c++ (I
would be happy to learn if anyone can invent a clever way to do so),
so we believe our effort is justifiable.


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

* Gilbert Chen:
>
> Our research group has developed a component-oriented extension to C++
> that advocates the idea of building programs by composing basic
> blocks.  The addition of keywords and syntatic rules is minimal.  We
> mainly use this extended language in discrete event simulation,
> although it could be equally well applied to other domains
> (hopefully).  If you are interested, please take a look at:
>
> http://www.cs.rpi.edu/~cheng3/compc++/
>
> Comments and suggestions are welcome.

Others have already commented on the ease with which what is described can
be implemented in the language as-is, without adding new keywords.

I'd like to add a comment about terminology.

Usually what is meant by "component" is an external class (or collection
of such) that is dynamically linked to the client code.  Depending on the
component technology a component instance may be shared by several clients,
and it may reside in another process, even on a remote computer.  And again
depending on the technology, but usually, a component may provide design-
time support in addition to its main role in client code.

What this paper describes isn't a component technology in the traditional
sense.

Instead it describes connectable member functions.

The main rationale for having a language extension for this seems to be


  <quote>
  But how about efficiency? Does [connectable functions] programming incur
  any inter-[object] communication overhead?  Not in CompC++.  In fact, this
  is what distinguishes CompC++ from numerous other so-called component-oriented
  programming languages/approaches, such as ViusalBasic, C#, and Dephi.  The
  CompC++ compiler will replace the function call to an outport with the
  function call to all inports that have been connected to the outport.
  </quote>


which if true would still be of dubious value considering what a virtual
call entails and the optimization capabilities of current compilers.

However, the 'connect' statement is a dynamic action, not a declaration,
which means the above can not be correct except as special case optimization.

Also, the comments about Visual Basic, C# and (assuming spelling error) Delphi
are incorrect.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> It is all about efficiency.  Sure, the same thing can be implemented,
> with ugly syntax, in pure C++.

Surprisingly I dont find the paper mention anything about efficiency. Any concrete reason
as to why there is a gain in performance ?


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

alfps@start.no (Alf P. Steinbach) wrote in message news:<41085236.1216491281@news.individual.net>...
> * Gilbert Chen:
> >
> > Our research group has developed a component-oriented extension to C++
> > that advocates the idea of building programs by composing basic
> > blocks.  The addition of keywords and syntatic rules is minimal.  We
> > mainly use this extended language in discrete event simulation,
> > although it could be equally well applied to other domains
> > (hopefully).  If you are interested, please take a look at:
> >
> > http://www.cs.rpi.edu/~cheng3/compc++/
> >
> > Comments and suggestions are welcome.
>
> Others have already commented on the ease with which what is described can
> be implemented in the language as-is, without adding new keywords.
>
> I'd like to add a comment about terminology.
>
> Usually what is meant by "component" is an external class (or collection
> of such) that is dynamically linked to the client code.  Depending on the
> component technology a component instance may be shared by several clients,
> and it may reside in another process, even on a remote computer.  And again
> depending on the technology, but usually, a component may provide design-
> time support in addition to its main role in client code.
>

    The traditional component technology, as I see it, has two serious
flaws: first, binding between components usually is not efficient;
second, composition cannot be done in a recursive/hierarchical way.
Therefore, traditionally components are used at library/application
level where inter-component communication overhead matters little.


> What this paper describes isn't a component technology in the traditional
> sense.

    CompC++ provides efficient component linkage as well as
hierarchical composition.  The consequence is, programmers can now use
components at any level, however small there are, without the fear of
losing any execution speed.  In other words, CompC++ extends the
traditional component technology to the very low granularity level.
Is the way components are composed in CompC++ radically different from
the traditional way? I don't think so.  So why can't it be called
component?

>
> Instead it describes connectable member functions.

I agree and I like this term.  It is connectable member functions that
enable the new way of using components in CompC++.

>
> The main rationale for having a language extension for this seems to be
>
>
>   <quote>
>   But how about efficiency? Does [connectable functions] programming incur
>   any inter-[object] communication overhead?  Not in CompC++.  In fact, this
>   is what distinguishes CompC++ from numerous other so-called component-oriented
>   programming languages/approaches, such as ViusalBasic, C#, and Dephi.  The
>   CompC++ compiler will replace the function call to an outport with the
>   function call to all inports that have been connected to the outport.
>   </quote>
>
>
> which if true would still be of dubious value considering what a virtual
> call entails and the optimization capabilities of current compilers.
>

    Yes, a virtual call entails little overhead when compared to a
normal function call.  But the real difference is, it is too difficult
for the compiler to inline a virtual call, while a normal function
call can be easily made inline.  This is where the performance gap
results from.

    Besides, another source of overhead exists when multiple inports
can be connected to a single outport.  In such a case a for loop has
to be used and there is no way any modern c++ compiler can optimize
this.

> However, the 'connect' statement is a dynamic action, not a declaration,
> which means the above can not be correct except as special case optimization.

    You hit the point.  In fact, the 'connect' statement should be
declarative.  In the current version of CompC++ it looks like a
dynamic action simply because this is easier to implement, but it is
actually interpreted by the CompC++ compiler as a declaration.

    So finally it all came down to static versus dynamic.  All CompC++
features can be implemented in pure C++, which has been pointed out by
many others and which we did before, at the expense of significant
inter-component overhead.  At the heart of CompC++ is static component
composition, which gives the compiler an extra opportunity to optimize
the code.  Modern C++ compilers, however smart they are, cannot do the
same.

    I also want to add that the above discussion does not apply to
component arrays and outport arrays, which due to their nature cannot
have efficient linkage.

>
> Also, the comments about Visual Basic, C# and (assuming spelling error) Delphi
> are incorrect.

    I would like to know why.

>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?
>
> [ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

gilbertchen@gmail.com (Gilbert Chen) wrote in message news:<e9c628e.0407281616.3a57d4c3@posting.google.com>...
> vidar@hokstad.name (Vidar Hokstad) wrote in message news:<3ef78faf.0407270358.69687915@posting.google.com>...
>  > What is the rationale for adding extra syntax for this instead of
>  > using long established C++ idioms?
> It is all about efficiency.  Sure, the same thing can be implemented,
> with ugly syntax, in pure C++.  In fact, the older version of the
> simulation toolkit (for which we designed this new language extension)
> was implemented entirely in standard C++, using a lot of templates.
> After we rewrote it with the extended language, the simulation speeds
> were improved by 20%-80%, depending on applications.  The improvement
> might not seem a lot, but it truly frees us from any contraints on the
> component granularity.  Now we can use components that perform
> operations as simple as increment and decrement, without any loss of
> efficiency.  It is impossible to achieve this with standard c++ (I
> would be happy to learn if anyone can invent a clever way to do so),
> so we believe our effort is justifiable.

This seems like a very dubious claim for me. The virtual base class
method I suggested clearly has a performance overhead. So does any
approach based on function pointers. The reason I usually prefer these
methods is that it allows runtime reconfiguration.

However, if you want to allow dynamic reconfiguration the only way you
can do better than a call via function pointers would be dynamic
recompilation at runtime. The functional pointer method is crude, but
unlikely to be much improved upon performance wise(though you can
certainly make it look cleaner with templates).

If runtime reconfiguration isn't required (that is, the types
connected are known at compile time), then making a template approach
that is as efficient as a normal method call is trival. In fact, I did
a tiny test with your Hello World example, and found GCC to reduce the
whole thing to just a printf() call in main() once I passed it "-O".

It still did so when I added local state in the objects (and made it
use it in the printf) and added a method to "reconnect" the out port
to another object. I'm sure I could confuse it into not being able to
inline as aggressively, but whether it would be a realistic test is
another matter. I tried making which object I connected to conditional
on input - didn't help. I changed the internal state of the objects
based on input and that didn't help either. Everything still got
inlined.

So if you are getting 20% - 80% performance improvements your examples
must be doing something a lot more complication. Care to elaborate on
what kind of examples you see 20%-80% performance improvements for?

Vidar


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

* Gilbert Chen:
>
> * Alf P. Steinbach:
> >
> > The main rationale for having a language extension for this seems to be
> >
> >   <quote>
> >   But how about efficiency? Does [connectable functions] programming incur
> >   any inter-[object] communication overhead?  Not in CompC++.  In fact, this
> >   is what distinguishes CompC++ from numerous other so-called component-oriented
> >   programming languages/approaches, such as ViusalBasic, C#, and Dephi.  The
> >   CompC++ compiler will replace the function call to an outport with the
> >   function call to all inports that have been connected to the outport.
> >   </quote>
> >
> > ...
> > Also, the comments about Visual Basic, C# and (assuming spelling error) Delphi
> > are incorrect.
>
>     I would like to know why.

It's a bit off-topic for both groups posted to, but if the moderators are
willing...

Actually there _is_ a little C++ in here! :-)

I think it's sufficient to consider the case of Visual Basic 6.0 (Visual
Basic.NET is the same case as C#, and as I've understood it the same situation
holds for Delphi, with some prior COM-based versions and a new .NET one).

Visual Basic 6.0 and earlier were based on COM technology, Microsoft's
Common Object Model.

A COM object is simply a traditional C++ vtable-based interface, which
means the client code has a pointer to an object that in turn contains
a pointer to a vtable, which contains the member function pointers.

This is the same as holding a pointer to any polymorphic C++ object whatsoever,
except for the guarantee of having three member functions that provide
the essential COM functionality of reference counting and "dynamic cast".

When the component is implemented as a DLL and is single-threaded and "early
bound" (in Visual Basic: using a type library) the object that client code has a
pointer to is actually the real object, and so except for inlining, which is
virtually impossible when all you have is an interface pointer, those calls are
exactly as efficient as calls to a non-COM object  --  it is the same situation.

The qualifications: single-threaded, yes you can let the COM infrastructure take
care of synchronization and such between threads, paying for that service with
some overhead; implemented as DLL, yes you can implement the object in a
separate process or on a different machine, which incurs cost in marshaling and
synchronization, again paying for services rendered; "early bound", yes you can
have COM objects that support scripting languages, again paying for that by some
inefficiency (scripting is not efficient) if you choose to use the object that
way instead of early binding; except for inlining, yes that is a real cost, but
I doubt that inlining can account for e.g. 20% improvement.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Our research group has developed a component-oriented extension to C++
that advocates the idea of building programs by composing basic
blocks.  The addition of keywords and syntatic rules is minimal.  We
mainly use this extended language in discrete event simulation,
although it could be equally well applied to other domains
(hopefully).  If you are interested, please take a look at:

http://www.cs.rpi.edu/~cheng3/compc++/

Comments and suggestions are welcome.

Gilbert Chen

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

gilbertchen@gmail.com (Gilbert Chen) wrote in message news:<e9c628e.0407261254.2d012406@posting.google.com>...
> Our research group has developed a component-oriented extension to C++
> that advocates the idea of building programs by composing basic
> blocks.  The addition of keywords and syntatic rules is minimal.  We
> mainly use this extended language in discrete event simulation,
> although it could be equally well applied to other domains
> (hopefully).  If you are interested, please take a look at:
>
> http://www.cs.rpi.edu/~cheng3/compc++/
>
> Comments and suggestions are welcome.

While it looks interesting on the surface, I can't really see a
benefit that would be large enough for me to bother with new syntax.

The examples on your web page can easily be achieved with standard C++
by factoring the "ports" out as abstract base classes and providing a
tiny bit of glue to implement the "connect" keyword as methods
instead.

"Components" the way you use the term have been used in C++ for years
without any syntactical support - Personally I routinely implement
reusable functionality this way (having classes that forward parts of
their functionality to objects that implement an abstract interface)
when templates doesn't make sense (in particular where it makes sense
to plug in different components with different dynamically set state
at runtime).

Your extension might save some typing, but at the expense of adding
more keywords and elevating a specific architectural pattern to part
of the language itself.

What is the rationale for adding extra syntax for this instead of
using long established C++ idioms?

Vidar


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gilbert Chen wrote:
> Our research group has developed a component-oriented extension to C++
> that advocates the idea of building programs by composing basic
> blocks.  The addition of keywords and syntatic rules is minimal.  We
> mainly use this extended language in discrete event simulation,
> although it could be equally well applied to other domains
> (hopefully).  If you are interested, please take a look at:
>
> http://www.cs.rpi.edu/~cheng3/compc++/
>
> Comments and suggestions are welcome.
>

The approach is very interesting, indeed. However, it seems to me that
one might achieve something very similar with a library-based approach,
without any language extension. Unless I'm very much mistaken, a
component is really nothing more than a class, an inport is nothing more
than a member function and an outport can easily be implemented with a
boost::function data member. I don't think port arrays are a serious
challenge either. Use boost::bind to write some nice template machinery
that implements the "connect" statement and you are there.

Please correct me if I'm wrong.

Alberto


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gilbert Chen wrote:

> Our research group has developed a component-oriented extension to C++
> that advocates the idea of building programs by composing basic
> blocks.  The addition of keywords and syntatic rules is minimal.  We
> mainly use this extended language in discrete event simulation,
> although it could be equally well applied to other domains
> (hopefully).  If you are interested, please take a look at:
>
> http://www.cs.rpi.edu/~cheng3/compc++/
>
> Comments and suggestions are welcome.

    That paper doesn't seem to make a clear distinction between
"object" and "class", which confuses the issue.  In C++,
unlike, say, Smalltalk, that distinction matters.
It's also not clear what "reuse" means, given that confusion.
Is "reuse" used to mean code reuse, or object instance reuse?

    John Nagle


      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]