Volker Hetzer wrote:
>
> Rinie Kervel wrote:
> >
> > I have just started using Borlands C++ Builder.
> >
> > It's main RAD features:
> >     properties,
> >     design time properties
> >     closures,
> >     components.
> >
> > are not standard C++, but make Windows programming a lot easier than the
> > 'standard'
> > MFC way. Moreover Java implements these features (JDK 1.1 / JavaBeans)
> > in a
> > platform independant way.
> >
> > I understand that it is too late to add it to the current, proposed,
> > standard, but I would
> > like to start a discussion if and how these features should be added to
> > C++.
>
> I've had a look at it and I didn't like it at all.
> Closures are some sort of extended function pointers in that they
> contain the
> objects address in them too. They are supposed to make callbacks easier.
> However, the C++ way of doing callbacks is much more powerful and
> flexible
> (taking the address of an object conforming to a certain interface) and
> I don't
> want C++ clogged up with windoze specific stuff.

Closures are not windows specific. They provide a mechanism for
implementing callbacks that are usable from C code.
 -- Pete
---
[ 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                             ]

Pete Becker <petebecker@acm.org> writes:

>
> Colin Rafferty wrote:
>
>  > Now, the following code works:
>  >
>  >     foo.property = 10;
>  >     int n = foo.property;
>  >
>  > and is effectively translated into:
>  >
>  >     foo.set_prop(10);
>  >     int n = foo.get_prop();
>  >
>  > In fact, this is also a method for having "virtual member variables".
>  >
>  > I don't see how we need to extend the language for properties, given
>  > something like what I outlined.
>
> Put thirty or forty of these into a class and see how big it gets.
> Having builtin properties makes it possible to do this with no
> additional data members. Plus, doesn't it bother you, just a little bit,
> to be storing the same this pointer, in the object that the pointer
> points to, for each of these property objects? <g>

The suggested solution has a number other problems as well.

1. It uses member function pointers which add a level of indirection
to the call.

2. It requires that set/get methods are out of line, which adds
another level of indirection.  This is a particularly horrible
requirement since most set/get operations would involve a single CPU
instruction.

3. (As pointed out above, but not quantified) It is exceedingly bulky.
An integer property on a 32-bit architecture will occupy 16 bytes!
The bare minimum would be 13 bytes for a char.

I debugged and compiled the suggested code.  The following code:

  foo.property = v;
  return foo.property;

generated 18 CPU instructions including the out of line set/get
members that it forced out of the compiler.  The following:

  foo.set_prop(v);
  return foo.get_prop();

generated three instructions.

Given that C++ is intended as a high performance systems language, I
would hardly qualify this as an adequate substitute for properties.
My personal view is that properties are a syntatic nicety.  They would
definitely be beneficial in cases where direct access to data members
is desired.  The primary disadvantage is that it only supports access
and assignment, wherease C++ objects (classes and pods alike)
generally have much richer semantics.  For instance, it is not
possible to do ++foo.property, either with the above suggestion or
with built-in properties.  In my view, this severely limits the
usefulness of properties.

Bottom line: Is set_prop(v) really that much of an inconvenience?


--
______________________________________________________________________
Marcelo Cantos, Research Assistant       __/_  marcelo@mds.rmit.edu.au
Multimedia Database Systems Group, RMIT   /       _ Tel 61-3-9282-2497
L2/723 Swanston St, Carlton VIC 3053, Aus/ralia ><_>Fax 61-3-9282-2490
Acknowledgements: errors - me; wisdom - God; sponsorship - RMIT
---
[ 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
]

Volker Hetzer wrote:
>
> Rinie Kervel wrote:
> >
> > I have just started using Borlands C++ Builder.
> >
> > It's main RAD features:
> >     properties,
> >     design time properties
> >     closures,
> >     components.
> >

[...]
> My impression of the whole thing is that those extensions were
> provided for prestige and add no functionality worth messing
> C++ up with it.
>
It's deja vu all over again! :~). Borland added some wierdo stuff
to C++ way back in OWL 1.0 days that went the way of the dodo.

Perhaps the desire to get the successful Delphi stuff ported
to C++ meant adding proprietary extensions. Perhaps the current
marketing types weren't born when the OWL 1.0 extensions failed
to take hold.

C++ Builder is probably a good product after all Delphi is
however it is not C++ it's Borland's Pascal - compiler, libraries
and all - dressed up as C++. I'm even unsure of the relationship
to BC++ 5.0 (anyone know the answer to this?)

The last thing we need NOW is more proprietary extensions to C++.

OTOH any future language should probably include standard hooks
for point and click development (properties, component frameworks,
etc).

Nick







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

Konstantin Baumann wrote:
 >
 > Volker Hetzer wrote:
 >
 > > > Properties are supposed to provide member variable syntax while allowing
 > > > the implementation to provide side-effects.  Eg:
 > > >
 > > >    foo->property = 10;  // might actually invoke a method
 > > >    int n = foo->property;  // ditto
 > > >
 > > > The idea is to hide the fact that "property" is anything other than a
 > > > value associated with the object.  The closest C++ equivalent would be:
 > > >
 > > >    foo->property (10);  // set
 > > >    int n = foo->property();  // get
 > > So you mean you want to hide the get and set functionality inside
 > > some sort of operator=?
 >
 > Why not something like this:
 >
 >         foo->property() = 10;
 >         int n = foo->property();
 >
 > With
 >         int& Foo::property() { return(prop); }
 >         const int& Foo::property() const { return(prop); }
Of course!
property() returns the reference of the variable! (like the array
subscript operator)!

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

Pete Becker writes:
> Colin Rafferty wrote:

>> There are ways of doing this right now without resorting to changing
>> the language.  The simplest is to use proxy objects for the member
>> variables.

>> [ elided my own code ]

> Put thirty or forty of these into a class and see how big it gets.
> Having builtin properties makes it possible to do this with no
> additional data members. Plus, doesn't it bother you, just a little bit,
> to be storing the same this pointer, in the object that the pointer
> points to, for each of these property objects? <g>

I agree -- I wouldn't want to have these in my classes.  I am sure that
given more than five minutes, I could come up with a better method of
implementing properties.  That is not the point.

The point is that properties are something that can be easily
implemented without changing the language, and I have yet to see anyone
defend its utility with anything stronger than "it's pretty."

If we are going to extend the language, lets at least do it for
something that cannot be implemented already.  Something like "super".

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

Colin Rafferty wrote:
>
> Pete Becker writes:
> > Colin Rafferty wrote:
>
> >> There are ways of doing this right now without resorting to
> changing
> >> the language.  The simplest is to use proxy objects for the member
> >> variables.
>
> >> [ elided my own code ]
>
> > Put thirty or forty of these into a class and see how big it gets.
> > Having builtin properties makes it possible to do this with no
> > additional data members. Plus, doesn't it bother you, just a little
> bit,
> > to be storing the same this pointer, in the object that the pointer
> > points to, for each of these property objects? <g>
>
> I agree -- I wouldn't want to have these in my classes.  I am sure
> that given more than five minutes, I could come up with a better method of
> implementing properties.  That is not the point.

That is exactly the point.

>
> The point is that properties are something that can be easily
> implemented without changing the language,

So far, nobody here has been able to demonstrate that. Assertions of
faith are not sufficient.
 -- Pete
---
[ 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
]

Nick Thurn wrote:

> C++ Builder is probably a good product after all Delphi is
> however it is not C++ it's Borland's Pascal - compiler, libraries
> and all - dressed up as C++. I'm even unsure of the relationship
> to BC++ 5.0 (anyone know the answer to this?)
>

Delphi 2.0/3.0, C++ Builder and BC++ 5.0 are supposed to share the same
compiler backend
C++ Builder also compiles all C++, STL, OWL and MFC code, so its C++
with some Delphi extensions and compatability

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

Volker Hetzer wrote:

> So you mean you want to hide the get and set functionality inside
> some sort of operator=?
> I have to admit that I'm more comfortable with the "old" way.
> Variables
> should be kept out of the interface and that includes any hint of
> their
> existence. Imagine a point class with X and Y as properties. If you
> change to polar coordinates you could replace them and just change the
>
> body of getX and getY (in addition to providing some new functions
> setAngle and setRadius).
> The property solution would require additional variables and functions
>
> to update both sets included in the property functions. This might
> work
> for small examples but you run into big memory and performance
> problems
> if you deal with larger objects.
>

I think your example is wrong, X and Y are not properties but variables.

If you replace them by say Fx and Fy, then properties X and Y would be
wrappers
for the getX and setX functions:
    x = X;    // calls  x = getX(); or inlined as x = Fx
and X = x; // calls  setX(x);

Adding polar properties would add Angle and Radius
so you have public properties and private variables or methods...

JavaBeans use properties via getXX and setXX functions, and naming
conventions.
Designtime manipulation of properties uses these naming conventions or
introspection/reflection

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

Pete Becker wrote:
>
> Colin Rafferty wrote:
> >
> > The point is that properties are something that can be easily
> > implemented without changing the language,
>
> So far, nobody here has been able to demonstrate that. Assertions of
> faith are not sufficient.

anybody cares to provide complete definition and requirements for
properties, so that we may tackle this challenge on a sound basis ?
---
[ 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                             ]

I have seen (and used) two methods to achieve property syntax (the
method suggested here) and something close (returning proxy objects with
overloaded conversion and assignment).  Neither is a good alternative,
IMO.  Properties add a new level of expressiveness that C++ currently
lacks.  They could do so with no overhead (something these two methods
cannot claim).  The power of any programming language is based on how
well it allows one to express oneself.  This is only my opinion of
course.  They would be a heck of a lot more useful than mutable,
const_cast or typeid <G>...

What do you mean by "super"?  Are you talking about the base class of a
class?  So B derived from A, B::super == A?
---
[ 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                             ]

In article <33C96F5B.37BCF35F@farallon.com>, Don Griffin <dgriffin@farallon.com> wrote:
>What do you mean by "super"?  Are you talking about the base class of a
>class?  So B derived from A, B::super == A?

Actually, it's more useful to think of super as an imaginary new class
introduced between A and B.  That way, the super (or inherited, as it is
usually called in non-portable C++ extensions that implement it) can
still be useful with multiple inheritance -- very useful, in fact.  It
can be hacked by actually introducing a new class and using a typedef,
but then you have to reimplement all your constructors and assignment
operators in this new class, causing a lot of overhead and maintenance
problems.

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

wkdugan@ix.netcom.com (Bill Dugan) writes:

|>  On 02 Jul 97 08:42:06 GMT, Volker Hetzer <hetzer.abg@sni.de> wrote:
|>
|>  snip
|>
|>  >__closure: This is a new keyword that defines a pointer which contains
|>  >          the address of a particular object and that of a method of the
|>  >  object. This is supposed to make callbacks easier.
|>
|>  Why did they make this a new keyword? I've seen a callback class that
|>  matches this description implemented using templates and pointers to
|>  member functions. What does _closure do that can't be done within the
|>  standard?

A true closure would keep the stack frame alive as long as there were
any references to it (with the obvious implication that it isn't really
a stack).  There's no way you can simulate this with templates and
pointers.

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

James Kanze wrote:
> wkdugan@ix.netcom.com (Bill Dugan) writes:
> |>  On 02 Jul 97 08:42:06 GMT, Volker Hetzer <hetzer.abg@sni.de> wrote:
> |>  >__closure: This is a new keyword that defines a pointer which contains
> |>  >          the address of a particular object and that of a method of the
> |>  >    object. This is supposed to make callbacks easier.
> |>
> |>  Why did they make this a new keyword? I've seen a callback class that
> |>  matches this description implemented using templates and pointers to
> |>  member functions. What does _closure do that can't be done within the
> |>  standard?
>
> A true closure would keep the stack frame alive as long as there were
> any references to it (with the obvious implication that it isn't really
> a stack).  There's no way you can simulate this with templates and
> pointers.

But as far as I understand, the __closure keyword in Borland's C++
builder
only ties a member function with an object instance, in effect making
what
looks like a C function pointer.

It does *not* imply a Scheme-like lexical closure [[a lambda form]].  In
other words, they don't take a snapshot of lexical variables stack and
wrap
it into an object.

IMHO, this __closure thing is an unfortunate misnomer and can probably
be
simulated to some degree with templates.  However, giving such callbacks
the appearance of genuine C function pointers definitely requires some
language
support, at least to dynamically generate ``call thunks'' or
``trampolines''
out of an object pointer + a member function pointer.

I'd like to see such ``trampoline'' support added to a future version of
C++.

 + Nicolas Chapados
---
[ 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 04 Jul 97 14:05:18 GMT, James Kanze
<james-albert.kanze@vx.cit.alcatel.fr> wrote:

>wkdugan@ix.netcom.com (Bill Dugan) writes:
>
>|>  On 02 Jul 97 08:42:06 GMT, Volker Hetzer <hetzer.abg@sni.de> wrote:
>|>
>|>  snip
>|>
>|>  >__closure: This is a new keyword that defines a pointer which contains
>|>  >          the address of a particular object and that of a method of the
>|>  >  object. This is supposed to make callbacks easier.
>|>
>|>  Why did they make this a new keyword? I've seen a callback class that
>|>  matches this description implemented using templates and pointers to
>|>  member functions. What does _closure do that can't be done within the
>|>  standard?
>
>A true closure would keep the stack frame alive as long as there were
>any references to it (with the obvious implication that it isn't really
>a stack).  There's no way you can simulate this with templates and
>pointers.

But the original message didn't say the pointer defined by the
_closure keyword does anything special with stack frames. It just said
it has the addresses of an object and a method of that object. That is
a fairly sensible way to implement a callback concept in C++, but it
doesn't take a special keyword to do it.

A true closure, as you define it, might be an interesting addition,
but it's far enough from the current language that it would deserve a
good bit of debate. If the call stack couldn't always really be
implemented as a stack, there could be some significant impacts.
---
[ 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
]

Rinie Kervel <rinie@xs4all.nl> wrote in article <33B6D13D.BDD71D73@xs4all.nl>...
> I have just started using Borlands C++ Builder.
>
> It's main RAD features:
>     properties,
>     design time properties
>     closures,
>     components.
>
> are not standard C++, but make Windows programming a lot easier than the
> 'standard' MFC way. Moreover Java implements these features (JDK 1.1 /
> JavaBeans) in a platform independant way.
>
> I understand that it is too late to add it to the current, proposed,
> standard, but I would like to start a discussion if and how these
> features should be added to C++.

There is no need to add these features to the C++.  They can all be
implemented using existing C++ constructs, such as template classes
and pointers-to-member-funcitons.  The JavaBeans model is implemented
in pure Java and the same is easy to do in C++, and arguably easier
because, unlike Java, C++ has generic classes and functions.

Just because MFC is "standard" does not mean that it is actually any
good at all.  I found it to be so poor that I wrote my own C++ framework
for Windows programming which provides support for many of the features
you mention, although I use pointers to abstract interfaces in place
of closures.  What makes Windows programming easy is a well designed
framework, not extensions to the core language.

BTW: "Components" is a very vague term.  A component only makes sense
within the context of a framework.  I guess that C++ Builder adds support
for ActiveX components -- that is components which are used within the
ActiveX framework.  C++ can support any number of component frameworks
and the language should definitely *not* be tied to any particular one.

Cheers,
 Nat.
---
[ 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 <rf5k9j7kvqn.fsf@vx.cit.alcatel.fr>,
James Kanze  <james-albert.kanze@vx.cit.alcatel.fr> wrote:
]wkdugan@ix.netcom.com (Bill Dugan) writes:
]
]|>  On 02 Jul 97 08:42:06 GMT, Volker Hetzer <hetzer.abg@sni.de> wrote:
]|>
]|>  snip
]|>
]|>  >__closure: This is a new keyword that defines a pointer which contains
]|>  >          the address of a particular object and that of a method of the
]|>  >  object. This is supposed to make callbacks easier.
]|>
]|>  Why did they make this a new keyword? I've seen a callback class that
]|>  matches this description implemented using templates and pointers to
]|>  member functions. What does _closure do that can't be done within the
]|>  standard?
]
]A true closure would keep the stack frame alive as long as there were
]any references to it (with the obvious implication that it isn't really
]a stack).  There's no way you can simulate this with templates and
]pointers.

Bill Dugan wrote:
 >
 > On 04 Jul 97 14:05:18 GMT, James Kanze
 > <james-albert.kanze@vx.cit.alcatel.fr> wrote:
 >
 > >wkdugan@ix.netcom.com (Bill Dugan) writes:
 > >
 > >|>  On 02 Jul 97 08:42:06 GMT, Volker Hetzer <hetzer.abg@sni.de> wrote:
 > >|>
 > >|>  snip
 > >|>
 > >|>  >__closure: This is a new keyword that defines a pointer which contains
 > >|>  >          the address of a particular object and that of a method of the
 > >|>  >   object. This is supposed to make callbacks easier.
 > >|>
 > >|>  Why did they make this a new keyword? I've seen a callback class that
 > >|>  matches this description implemented using templates and pointers to
 > >|>  member functions. What does _closure do that can't be done within the
 > >|>  standard?
 > >
 > >A true closure would keep the stack frame alive as long as there were
 > >any references to it (with the obvious implication that it isn't really
 > >a stack).  There's no way you can simulate this with templates and
 > >pointers.
 >
 > But the original message didn't say the pointer defined by the
 > _closure keyword does anything special with stack frames. It just said
 > it has the addresses of an object and a method of that object. That is
 > a fairly sensible way to implement a callback concept in C++, but it
 > doesn't take a special keyword to do it.

 The problem here is not to "implement a callback concept in C++". It is
to provide a simple mechanism for creating C callable functions that
bind an object and a member function. Note that you cannot use a
template function for this, because you cannot have more than one
overloaded function with C linkage. It is not at all obvious how this
might be done without a special keyword. Have you done it, or is this
speculation?
 -- Pete
---
[ 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                             ]

"Nicolas Chapados" <chapados@nortel.ca> writes:

>James Kanze wrote:
>>
>> A true closure would keep the stack frame alive as long as there were
>> any references to it ...
...
>IMHO, this __closure thing is an unfortunate misnomer

Regarding the terminology, I disagree.  There is a difference between
the terms "closure" and "closure with unlimited extent".  As I have
heard the terms used, the term "closure" does not imply garbage collection,
and the term "closure with unlimited extent" does.
(The distinction is often lost simply because most languages that support
closures also happen to have garbage collection and thus their closures
do have unlimited extent.)

For what it is worth, GNU C (but not GNU C++) also supports closures,
with nested functions.  Also, the committee did consider a proposal
to add support for nested functions and closures to C++, but rejected it.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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                             ]

Properties are supposed to provide member variable syntax while allowing
the implementation to provide side-effects.  Eg:

   foo->property = 10;  // might actually invoke a method
   int n = foo->property;  // ditto

The idea is to hide the fact that "property" is anything other than a
value associated with the object.  The closest C++ equivalent would be:

   foo->property (10);  // set
   int n = foo->property();  // get

Properties would be a nice way to provide "symmetry of access" in C++.
I would prefer to not care if "property" were an int member or a
Property with associated methods to get/set.  The implementation would
be free to change this as needed without breaking a user's source.

Of couse, there is RTTI about properties that are "published" (best I
can figure, Published is the same as Public except that you get RTTI for
anything that is Published--an efficiency consideration).  RTTI is used
to give the GUI builder the ability to provide reasonable editors for
the underlying type (and probably more).  This is largely Windows-ish,
but could be used in other contexts if you want to understand how to use
the generated RTTI info.

"Components" are simply classes that derive from a certain base class
(TComponent, I believe).

As to closures, I have used them as well as C++ interfaces.  In many
cases, interfaces are preferable, but using mixin interfaces has one
stipulation: you can have only one instance of a given interface per
class.  If I have a class that communicates with three other objects via
the same interface, I will have only one method that can be called from
any of the three other objects.  If I need to distinguish between the
callers (a common thing, IMO), the interface approach forces some ugly
work arounds.

To my knowledge, closures are not C callable.  They simply bind object
and method in a single type.  A template may very well accomplish this,
but I imagine it would be a family of templates since the signature of
the method is important<g>.  You would also need to duplicate the
templates to handle "void" returns, since void methods cannot say
"return (object->*method) ()" even if method is a void return type.

In short, properties (minus the RTTI/published stuff, and with a better
syntax than BCB) and closures would be useful additions to the language,
but I won't be holding my breath... :)
---
[ 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 07 Jul 97 06:49:17 GMT, Pete Becker <petebecker@acm.org> wrote:

>Bill Dugan wrote:

snip

> > >|>  On 02 Jul 97 08:42:06 GMT, Volker Hetzer <hetzer.abg@sni.de> wrote:
> > >|>
> > >|>  snip
> > >|>
> > >|>  >__closure: This is a new keyword that defines a pointer which
> > >|>  >   contains the address of a particular object and that of a
> > >|>  >   method of the object. This is supposed to make callbacks easier.
> > >|>
> > >|>  Why did they make this a new keyword? I've seen a callback class that
> > >|>  matches this description implemented using templates and pointers to
> > >|>  member functions. What does _closure do that can't be done within the
> > >|>  standard?

snip

>The problem here is not to "implement a callback concept in C++". It is
>to provide a simple mechanism for creating C callable functions that
>bind an object and a member function. Note that you cannot use a
>template function for this, because you cannot have more than one
>overloaded function with C linkage. It is not at all obvious how this
>might be done without a special keyword. Have you done it, or is this
>speculation?

I don't see anything in the original message quoted above that says
the _closure keyword provides a C callable interface. If it actually
does that, it is going further than what I've seen done in standard
C++. I'd agree that it's not obvious how to do this without a special
keyword, although I'd say it's also not obvious that it's impossible.

However, in another message of this thread, on 07 Jul 1997 15:43:40
PDT, Don Griffin <dgriffin@farallon.com> wrote:

snip

>To my knowledge, closures are not C callable.  They simply bind object
>and method in a single type.
---
[ 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                             ]

Don Griffin wrote:
>
> Properties are supposed to provide member variable syntax while allowing
> the implementation to provide side-effects.  Eg:
>
>    foo->property = 10;  // might actually invoke a method
>    int n = foo->property;  // ditto
>
> The idea is to hide the fact that "property" is anything other than a
> value associated with the object.  The closest C++ equivalent would be:
>
>    foo->property (10);  // set
>    int n = foo->property();  // get
So you mean you want to hide the get and set functionality inside
some sort of operator=?
I have to admit that I'm more comfortable with the "old" way. Variables
should be kept out of the interface and that includes any hint of their
existence. Imagine a point class with X and Y as properties. If you
change to polar coordinates you could replace them and just change the
body of getX and getY (in addition to providing some new functions
setAngle and setRadius).
The property solution would require additional variables and functions
to update both sets included in the property functions. This might work
for small examples but you run into big memory and performance problems
if you deal with larger objects.

> Properties would be a nice way to provide "symmetry of access" in C++.
Would be nice, but I think it's dangerous to put variables
in public interfaces, even if you could catch accesses via your property
functions.


> As to closures, I have used them as well as C++ interfaces.  In many
> cases, interfaces are preferable, but using mixin interfaces has one
> stipulation: you can have only one instance of a given interface per
> class.
> If I have a class that communicates with three other objects via
> the same interface, I will have only one method that can be called from
> any of the three other objects.  If I need to distinguish between the
> callers (a common thing, IMO), the interface approach forces some ugly
> work arounds.
Actually, this is the fault of the callers. If a caller expects a method
"work()" it is a very poor caller. It should expect something like
"FunctionCalledByWhatever()". However if you have three instances of
object X
wanting to do a callback to object Y you have a problem.
It would be possible to define three global callback functions
workfromX1(y &Y){Y.a();}
workfromX2(y &Y){Y.b();}
workfromX3(y &Y){Y.c();}
and register them together with the objects but it looks ugly.



> In short, properties (minus the RTTI/published stuff, and with a better
> syntax than BCB) and closures would be useful additions to the language,
> but I won't be holding my breath... :)
I don't like properties but I see that there is need for something
closure-like. It should enable to call methods of objects without
knowing their name. How do closures work with virtual functions,
inheritance and such?

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

Volker Hetzer wrote:

> > Properties are supposed to provide member variable syntax while allowing
> > the implementation to provide side-effects.  Eg:
> >
> >    foo->property = 10;  // might actually invoke a method
> >    int n = foo->property;  // ditto
> >
> > The idea is to hide the fact that "property" is anything other than a
> > value associated with the object.  The closest C++ equivalent would be:
> >
> >    foo->property (10);  // set
> >    int n = foo->property();  // get
> So you mean you want to hide the get and set functionality inside
> some sort of operator=?

Why not something like this:

 foo->property() = 10;
 int n = foo->property();

With
 int& Foo::property() { return(prop); }
 const int& Foo::property() const { return(prop); }

--
Konstantin Baumann                   Westfaelische Wilhelms-Universitaet
Institut fuer Informatik (Zi. 603),  Einsteinstr. 62,   D-48149 Muenster
mailto:kostab@math.uni-muenster.de                  Tel:+49-251-83-32701
http://wwwmath.uni-muenster.de/cs/u/kostab/         Fax:+49-251-83-33755
---
[ 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                             ]

Don Griffin writes:

> Properties are supposed to provide member variable syntax while allowing
> the implementation to provide side-effects.  Eg:

>    foo-> property = 10;  // might actually invoke a method
>    int n = foo->property;  // ditto

> The idea is to hide the fact that "property" is anything other than a
> value associated with the object.  The closest C++ equivalent would be:

>    foo-> property (10);  // set
>    int n = foo->property();  // get

> Properties would be a nice way to provide "symmetry of access" in C++.
> I would prefer to not care if "property" were an int member or a
> Property with associated methods to get/set.  The implementation would
> be free to change this as needed without breaking a user's source.

There are ways of doing this right now without resorting to changing the
language.  The simplest is to use proxy objects for the member variables.

Here is your class Foo that has a variable `property' which, when set or
got, will call a member function (note that I have not compiled any of
this):

    class Foo
    {
        public:
            Prop<Foo, int>  property;

            void set_prop(const int&    value);
            int get_prop() const;

            Foo()
                : property(this, set_prop, get_prop)
            {}
    };

Here is the general template class that will do everything that you
need.  You initialize it with the `set' and `get' member functions, and
the context in which you want them called.

    template <class Class, class Type>
    class Prop
    {
            Prop(const Prop<Class, Type>&   that); // unimplemented
        public:
            Prop(Class*         object,
                 void (Class*:: set)(const Type&);
                 Type (Class*:: get)() const)
                : _object(object),
                  _set(set),
                  _get(get)
            {}
            void set(const Type&    val)
            {
                (_object->*_set)(val);
            }
            Type get() const
            {
                return (_object->*get)();
            }
            Prop& operator=(const Prop<Class, Type>& rhs)
            {
                if (this != &rhs) set(that.get());
                return *this;
            }
            Prop& operator=(const Type& val)
            {
                set(val);
                return *this;
            }
            operator Type() const
            {
                return get();
            }
        private:
            Class*          _object;
            void (Class*::  _set)(const Type&);
            Type (Class*::  _get)() const;
    };


Now, the following code works:

    foo.property = 10;
    int n = foo.property;

and is effectively translated into:

    foo.set_prop(10);
    int n = foo.get_prop();

In fact, this is also a method for having "virtual member variables".

I don't see how we need to extend the language for properties, given
something like what I outlined.

--
Colin
---
[ 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 Tue, Jul 8, 1997 2:27 PM, Konstantin Baumann
<mailto:kostab@uni-muenster.de> wrote:
>Why not something like this:
>
> foo->property() = 10;
> int n = foo->property();
>
>With
> int& Foo::property() { return(prop); }
> const int& Foo::property() const { return(prop); }
>
>

One big problem with this approach
is that you can change a member from
outside, without the owner (this) of the
member being notified:

int& bla = foo->property();
...
bla = 42; /// foo cannot intercept this!

Although I have never gotten in touch with
member templates (yet), I could imagine another
approach:

class A
{
 int height;
 int width;

 HeightSetter(int h) { height = h; }

public:

 template <typename IN>
 struct Setter
 {
  A& ref; // could also be ref-counted
  void (A::*setter)(IN);
  Setter(A& r, (A::*setter)(IN)) : ref(r), setter(s) { }
  Setter& operator = (IN in) { (ref.*setter)(in); return *this; }
 };

 Setter<int> Height(void) { return Setter<int>(*this, &A::HeightSetter); }

};

Now this should work:

void main(void)
{
 A foo;
 foo.Height() = 10;

 //or:
 Setter<int> s(foo->Height());

 s = 42; // also calls foo->HeightSetter

}

An analogous construct could be defined for Getter or even GetterSetter.

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

>Why not something like this:
>
>        foo->property() = 10;
>        int n = foo->property();
>
>With
>        int& Foo::property() { return(prop); }
>        const int& Foo::property() const { return(prop); }

int& Foo::property() has no flexibility to change the underlying
representation with this approach :(  To do so would require one of two
things:

  1. Change the user's code (not as good as properties)
  2. Return a temporary object instead of int&.

The second proposal was also made by Ken Shan, so I'll reply to it over
there...

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

Colin Rafferty wrote:
 >
 >
 > There are ways of doing this right now without resorting to changing
 > the
 > language.  The simplest is to use proxy objects for the member
 > variables.
 >
 > Here is your class Foo that has a variable `property' which, when set
 > or
 > got, will call a member function (note that I have not compiled any of
 > this):
 >
 >     class Foo
 >     {
 >         public:
 >             Prop<Foo, int>  property;
 >
 >             void set_prop(const int&    value);
 >             int get_prop() const;
 >
 >             Foo()
 >                 : property(this, set_prop, get_prop)
 >             {}
 >     };
 >
 > Here is the general template class that will do everything that you
 > need.  You initialize it with the `set' and `get' member functions,
 > and
 > the context in which you want them called.
 >
 >     template <class Class, class Type>
 >     class Prop
 >     {
 >             Prop(const Prop<Class, Type>&   that); // unimplemented
 >         public:
 >             Prop(Class*         object,
 >                  void (Class*:: set)(const Type&);
 >                  Type (Class*:: get)() const)
 >                 : _object(object),
 >                   _set(set),
 >                   _get(get)
 >             {}
 >             void set(const Type&    val)
 >             {
 >                 (_object->*_set)(val);
 >             }
 >             Type get() const
 >             {
 >                 return (_object->*get)();
 >             }
 >             Prop& operator=(const Prop<Class, Type>& rhs)
 >             {
 >                 if (this != &rhs) set(that.get());
 >                 return *this;
 >             }
 >             Prop& operator=(const Type& val)
 >             {
 >                 set(val);
 >                 return *this;
 >             }
 >             operator Type() const
 >             {
 >                 return get();
 >             }
 >         private:
 >             Class*          _object;
 >             void (Class*::  _set)(const Type&);
 >             Type (Class*::  _get)() const;
 >     };
 >
 >
 > Now, the following code works:
 >
 >     foo.property = 10;
 >     int n = foo.property;
 >
 > and is effectively translated into:
 >
 >     foo.set_prop(10);
 >     int n = foo.get_prop();
 >
 > In fact, this is also a method for having "virtual member variables".
 >
 > I don't see how we need to extend the language for properties, given
 > something like what I outlined.

Put thirty or forty of these into a class and see how big it gets.
Having builtin properties makes it possible to do this with no
additional data members. Plus, doesn't it bother you, just a little bit,
to be storing the same this pointer, in the object that the pointer
points to, for each of these property objects? <g>
 -- Pete
---
[ 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                             ]

I have just started using Borlands C++ Builder.

It's main RAD features:
    properties,
    design time properties
    closures,
    components.

are not standard C++, but make Windows programming a lot easier than the
'standard'
MFC way. Moreover Java implements these features (JDK 1.1 / JavaBeans)
in a
platform independant way.

I understand that it is too late to add it to the current, proposed,
standard, but I would
like to start a discussion if and how these features should be added to
C++.

Rinie

(For a description of the additions that Borland made see
    http://www.cobb.com/cpb/9706/cpb9763.htm )
---
[ 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
]

Rinie Kervel wrote:
>
> I have just started using Borlands C++ Builder.
>
> It's main RAD features:
>     properties,
>     design time properties
>     closures,
>     components.
>
> are not standard C++, but make Windows programming a lot easier than the
> 'standard'
> MFC way. Moreover Java implements these features (JDK 1.1 / JavaBeans)
> in a
> platform independant way.
>
> I understand that it is too late to add it to the current, proposed,
> standard, but I would
> like to start a discussion if and how these features should be added to
> C++.

I've had a look at those "extensions" and I am not particularly
enthralled
by them.

__closure: This is a new keyword that defines a pointer which contains
          the address of a particular object and that of a method of the
  object. This is supposed to make callbacks easier. However I much
  prefer the method of inheriting a certain interface and taking
  the adress of the whole object. That way you are not limited to
  one address pair per "closure"-pointer but you can specify a whole
  interface.
__property: Original explanation:
  "You use the __property keyword within a component class declaration
  to identify a component's properties."
  What does this mean?
__published: Something that belongs to properties.
__int8, __int16, __int..: You don't need anew keyword for this. Just go
and
  have a look at GNU's Integer class.
__automated: No explanation given.
__classid: dito. Something like RTTI?

My impression of the whole thing is that those extensions were provided
for
prestige and add no functionality worth messing C++ up with it.
I exclude the properties from this opinion since I didn't understand
what they are supposed to to. Something with documentation?

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

On 02 Jul 97 08:42:06 GMT, Volker Hetzer <hetzer.abg@sni.de> wrote:

snip

>__closure: This is a new keyword that defines a pointer which contains
>          the address of a particular object and that of a method of the
>  object. This is supposed to make callbacks easier.

Why did they make this a new keyword? I've seen a callback class that
matches this description implemented using templates and pointers to
member functions. What does _closure do that can't be done within the
standard?
---
[ 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                             ]

Rinie Kervel wrote:
>
> I have just started using Borlands C++ Builder.
>
> It's main RAD features:
>     properties,
>     design time properties
>     closures,
>     components.
>
> are not standard C++, but make Windows programming a lot easier than the
> 'standard'
> MFC way. Moreover Java implements these features (JDK 1.1 / JavaBeans)
> in a
> platform independant way.
>
> I understand that it is too late to add it to the current, proposed,
> standard, but I would
> like to start a discussion if and how these features should be added to
> C++.

I've had a look at it and I didn't like it at all.
Closures are some sort of extended function pointers in that they
contain the
objects address in them too. They are supposed to make callbacks easier.
However, the C++ way of doing callbacks is much more powerful and
flexible
(taking the address of an object conforming to a certain interface) and
I don't
want C++ clogged up with windoze specific stuff.
As to properties, the page said that they are there to specify
properties. I
suppose that has something to do with documentation?
Components didn't get explained at all.
But the real highlight were __int8, __int16, __int... . New keywords for
that
nonsense! Just go and have a look at GNU's Integer class to see how its
done properly.

Summary: Forget about it. (I exclude properties and components, because
they
         were explained badly or not at all.)

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