horstman@mathcs.sjsu.edu (Cay Horstmann) (06/27/91)
I just attended a product presentation by a Borland guy on their class
library for Microsoft Windows called ObjectVision. I was somewhat distressed
to see an odd construct
class MyWindow : public TWindow
{ // ...
public::
virtual void paint() = [ WM_START + WM_PAINT ];
// ...
};
(I am quoting from memory, so the details may not be correct 100%). The idea
is that the paint() function would be selected when the WM_PAINT message is
sent from MS Windows.
They have a fancy name for this, dynamic message dispatching.
Did anyone see this before? Supposedly it is supported in BCC 2.0. Is the
mechanism really tied to MS Windows, or does it something useful in a
general construct?
The speaker (I believe the project head for ObjectVision--can't remember
his name) insisted that this did not violate any C++ standard, being "merely"
an extension. To me, this sounds like utter nonsense. Assuming for the moment
that the feature is indeed closely tied to Windows (or maybe other event-
driven UI that use small integers as message ID's), one of two things will
happen:
Nobody else will support it, and Borland C++ (otherwise an admirable
product) will be on the route that killed Pascal, with proprietary
extensions in every implementation.
Every DOS vendor must support it to stay compatible, and Borland manages
to place a true wart into the de facto language without even bothering
to go through the ANSI committee.
Maybe other netters have more info on this. My impression that the speaker
was an evil person was amplified when, upon his question what Borland could
do for us, I told him "Improve the Usenet support", and he answered "The
what?".
Caybarmar@think.com (Barry Margolin) (06/28/91)
In article <1991Jun27.130247.5107@mathcs.sjsu.edu> horstman@mathcs.sjsu.edu (Cay Horstmann) writes: >The speaker (I believe the project head for ObjectVision--can't remember >his name) insisted that this did not violate any C++ standard, being "merely" >an extension. To me, this sounds like utter nonsense. Assuming for the moment >that the feature is indeed closely tied to Windows (or maybe other event- >driven UI that use small integers as message ID's), one of two things will >happen: > Nobody else will support it, and Borland C++ (otherwise an admirable > product) will be on the route that killed Pascal, with proprietary > extensions in every implementation. > > Every DOS vendor must support it to stay compatible, and Borland manages > to place a true wart into the de facto language without even bothering > to go through the ANSI committee. How do you think new features get added to languages? Almost all good features start out life as someone's private extension. If the extension becomes popular then it turns into a de facto standard, and may later find its way into an official standard. Features that are invented by the standards committee frequently turn out to be bad ideas, because they are adopted before there has been much experience with them. C++ itself was once someone's extensions to C. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
horstman@mathcs.sjsu.edu (Cay Horstmann) (06/28/91)
In article <1991Jun27.210518.19589@Think.COM> barmar@think.com writes: >In article <1991Jun27.130247.5107@mathcs.sjsu.edu> horstman@mathcs.sjsu.edu (Cay Horstmann) writes: [my tedious explanation of a nonstandard scheme in BC++ deleted...] > >How do you think new features get added to languages? Almost all good >features start out life as someone's private extension. If the extension >becomes popular then it turns into a de facto standard, and may later find >its way into an official standard. > >Features that are invented by the standards committee frequently turn out >to be bad ideas, because they are adopted before there has been much >experience with them. > >C++ itself was once someone's extensions to C. > All this is true enough. I guess there are three things that bother me about this. (1) Borland is trying very heavily to get the OMG to buy into their scheme. Now if anyone is ill-equipped to make any judgment on the side effect this would have on the C++ language, it is that body. [Maybe I am over- reacting here; I have not actually seen what their OMG proposal encom- passes.] Anyway, they shouldn't propose a library as a standard to the OMG which is based on a non-standard language extension. (2) As far as I can tell, this particular feature is extraordinarily poorly thought out. There almost certainly are better ways of doing this that don't require breaking the language. [I might be wrong; maybe the feature is much more general and useful than it appeared. Does anyone know?] (3) There generally are several phases in the design of any language. With C++, it seemed to be the feeling of the standards committee that the experimental phase is largely over (except, I guess, with templates and exception handling, the latter of which they have no business standar- dizing on, if you ask me), and to a degree I concur with that feeling. [I realize that I have in the past argued the other way around, but that was only with features I invented, hence truly great and necessary ones.] Really, I am hoping that someone who has actually used this feature can set me straight on its semantics and usefulness. Cay
blake@nthropy.uucp (Blake Freeburg) (06/28/91)
About this Borland Extension, What I really can't understand is how I would use it in a program. Can I also have a class that responds to messages, or is it something that must come out in order to support MS Win X.XX and all their yoga programming practices. I really don't know, but if I can use it as some sort of message based polymorphism (ie. it could go to all objects responding to the message), then as a global siren it would make a good idea. Like all things , we (people) are most often resistant to change. (Too bad there isn't a way to harness the friction a new idea creates - lots of energy there). Blake #include<disclaimer: This has nothing to do with the company I work for>
gary@neptune.uucp (Gary Bisaga x4219) (06/29/91)
In article <1991Jun28.141744.2323@nthropy.uucp> blake@nthropy.UUCP (Blake Freeburg) writes: >About this Borland Extension, > What I really can't understand is how I would use it in a program. Can >I also have a class that responds to messages, or is it something that must >come out in order to support MS Win X.XX and all their yoga programming >practices. ... Before we all get TOO worked up about this, is there a person from Borland who can explain what is really going on? Personally, the idea I got from the original poster was that the person who told HIM about the alleged extension (i.e., not the poster, but the poster's source) didn't necessarily know what he was talking about -- he was a marketing manager or something, wasn't he? Anyway, I can't imagine how such a thing could be added to C++ itself. Maybe he was describing a front-end to C++ that assists with writing Windows code? It wouldn't be the first time such a thing was done.
koussari@dorsai.com (Vahid Koussari) (06/29/91)
horstman@mathcs.sjsu.edu (Cay Horstmann) writes: > I just attended a product presentation by a Borland guy on their class > library for Microsoft Windows called ObjectVision. I was somewhat distressed > to see an odd construct > > class MyWindow : public TWindow > { // ... > public:: > virtual void paint() = [ WM_START + WM_PAINT ]; > // ... > }; > > (I am quoting from memory, so the details may not be correct 100%). The idea > is that the paint() function would be selected when the WM_PAINT message is > sent from MS Windows. > > They have a fancy name for this, dynamic message dispatching. > > Did anyone see this before? Supposedly it is supported in BCC 2.0. Is the > mechanism really tied to MS Windows, or does it something useful in a > general construct? > > The speaker (I believe the project head for ObjectVision--can't remember > his name) insisted that this did not violate any C++ standard, being "merely" > an extension. To me, this sounds like utter nonsense. Assuming for the moment > that the feature is indeed closely tied to Windows (or maybe other event- > driven UI that use small integers as message ID's), one of two things will > happen: > Nobody else will support it, and Borland C++ (otherwise an admirable > product) will be on the route that killed Pascal, with proprietary > extensions in every implementation. > > Every DOS vendor must support it to stay compatible, and Borland manages > to place a true wart into the de facto language without even bothering > to go through the ANSI committee. > > Maybe other netters have more info on this. My impression that the speaker > was an evil person was amplified when, upon his question what Borland could > do for us, I told him "Improve the Usenet support", and he answered "The > what?". > > Cay Could you explain the purpose of that funtion? This is the first time that I have seen this? Thank you.
kevin@msa3b.UUCP (Kevin P. Kleinfelter) (06/29/91)
horstman@mathcs.sjsu.edu (Cay Horstmann) writes: >In article <1991Jun27.210518.19589@Think.COM> barmar@think.com writes: >>In article <1991Jun27.130247.5107@mathcs.sjsu.edu> horstman@mathcs.sjsu.edu (Cay Horstmann) writes: >[my tedious explanation of a nonstandard scheme in BC++ deleted...] >> [Description of poor speaker also omitted.] There were two speakers in the presentation on OjbectWindows and BC++. One was pretty good, and the other should not be permitted to speak in front of gatherings of more that 2 people! :-) >(2) As far as I can tell, this particular feature is extraordinarily poorly > thought out. There almost certainly are better ways of doing this that > don't require breaking the language. [I might be wrong; maybe the feature > is much more general and useful than it appeared. Does anyone know?] The feature changes the way the VTAB is created. When you have a derived class, which overrides only a few virtual methods from a base class with many virtual methods, BC++ normally gives you a whole new VTAB. When you use dynamically dispatched messages, the new VTAB is some kind of linked-list with a "cache." Thus you end up with a smaller VTAB at the expense of speed. In the case of windows (which may have MANY virtual methods), this seems like worthwhile tradeoff (IMHO). However, it appears that this feature is only useful if you purchase ObjectWindows. You cannot use the normal language syntax to call a function (aka "message") which has been declared in this maner. If anyone knows how to call a function declared in this manner, I'd be interested to know how. The feature may be useful beyond Windows. It would seem to be useful in any case where you have a base class with a large VTAB, and your derived class overrides only a few virtual methods. Unfortunately, if you can't call the method, only AbjectWindows will be able to use this extension. -- Kevin Kleinfelter @ DBS, Inc (404) 239-2347 ...gatech!nanoVX!msa3b!kevin Dun&Bradstreet Software, 3445 Peachtree Rd, NE, Atlanta GA 30326-1276
caspers@fwi.uva.nl (B.M. Caspers (I)) (06/30/91)
About the extension of C++: this is something that is also available with Turbo Pascal for Windows: procedure A; VIRTUAL; = WM_XXXX + WM_YYYY; // or something like this.. Borland *could* do this with Pascal, since they set their own "standard" with TP. As soon as OWL for TPW came out, I have been wondering how they would do this in C++.. They wouldn't change the language! Now I know: they did, although tried to. Because this extension makes only sense in a event-driven env'mt (correct me if I'm wrong), I don't think it would make sense to include it in C++ itself. Another question: why did they do it in this way? There are several Windows class libs around which do work wqith regular c++. -- John
mwb@ulysses.att.com (Michael W. Balk) (07/01/91)
I was thinking of buying Borland C++, but if Borland is really going to install non-ANSI approved syntax into their product I will probably reconsider the purchase. Does anyone know of any other C++ vendors who might be doing or considering doing the same sort of thing with their C++ compilers? Mike Balk AT&T Bell Laboratories 600 Mountain Avenue Murray Hill, NJ 07974 mwb@ulysses.att.com
mike@taumet.com (Michael S. Ball) (07/01/91)
In article <15072@ulysses.att.com> mwb@ulysses.att.com (Michael W. Balk) writes: > > >I was thinking of buying Borland C++, but if Borland is really going to install >non-ANSI approved syntax into their product I will probably reconsider the >purchase. Since there is no such thing as ANSI-approved syntax, this is going to cause you no end of difficulties. > Does anyone know of any other C++ vendors who might be doing or >considering doing the same sort of thing with their C++ compilers? All MS-DOS native compilers include extensions to deal with the strange requirements of the environment. Consider, for example "near", "far", "pascal", "cdecl" and a variety of other wierd and wonderful extensions. Vendors include them because their customers feel they need them. One may presume that this is the exact reason that Borland chose to include this syntax. In this case it sounds as though one library vendor had enough clout to get the feature into the product. In other cases, many programmers request features and get them into the product. In no case is anyone required to use them. Since this feature is aimed at MS-Windows programs, which are inherently non-portable, it's hard to care a lot. -- Michael S. Ball mike@taumet.com TauMetric Corporation (619)697-7607
catfood@NCoast.ORG (Mark W. Schumann) (07/01/91)
mwb@ulysses.att.com (Michael W. Balk) writes: >I was thinking of buying Borland C++, but if Borland is really going to install >non-ANSI approved syntax into their product I will probably reconsider the >purchase. Does anyone know of any other C++ vendors who might be doing or >considering doing the same sort of thing with their C++ compilers? Or just don't use the extensions and invoke the compiler flags for "Standard C++" and ignore 'em. -- Mark W. Schumann 3111 Mapledale Avenue, Cleveland 44109 USA Domain: catfood@ncoast.org UUCP: ...!mailrus!usenet.ins.cwru.edu!ncoast!catfood "A union can't participate in a class hierarchy. It can't