In article <CLJp09.Mqx@ucc.su.OZ.AU>

JMS>>hall_j@sat.mot.com (Joseph Hall @ Motorola Inc., Satellite Communications)
[...]
JMS>>I don't think it is in the interest of users to have such non-standard
JMS>>features because such features lock them into a single supplier.

maxtal@physics.su.OZ.AU (John Max Skaller) writes:
[...]
JMS>I agree but there is a flip side of the coin.
JMS>While the committee may be slow or unwilling to provide
JMS>certain facilities, vendors of compilers for diverse
JMS>systems are forced to provide non-standard extensions
JMS>that lock users in anyhow. So it doesnt make so
JMS>much difference, once you're locked in, that you use
JMS>other vendor extensions.

JMS>Any vendor with the courage to provide object
JMS>closures so that callbacks to member functions could work,
JMS>would solve major problems for those working in
JMS>Windowing environments. For example.

One vendor (who I won't name) intentionally _dropped_ that
exact extension from their 4.0 version, because ANSI wouldn't
approve it (even though they thought it was in the bag),
because competitors and users constantly flaunted it as
"lack of conformance".  This particular vendor takes great
pride in its level of conformance.

JMS>Responsible vendors provide compatibility switches,
JMS>so you can check the portability of your code.

That's a good idea.  The same vendor I mention above provides
such switches.  You know.... they could have provided a
"Dynamic Dispatch Table" switch, and made everybody happy,
but their UI library depended upon that feature, and they
wanted to make the UI library portable.  Hmm... which
brings us back Joseph's the original sentiment.

[next statement is not shown in original order]
JMS>hopefully several vendors will agree to provide similar
JMS>extensions that can subsequently be Standardised.

Maybe this could solve all of my problems.
(1)  I want a standard for the language itself.
(2)  I want a minimal set of standardized container classes.

If fall is a realistic timeframe for (1), this makes me happy.
If some movement is made within the industry to provide a
consensus on (2), it would be satisfactory until another
committee could be convened to discuss the standardization
of libraries.
regards,
chris
---
. OLX 2.2 . Plagarism prohibited.  Derive carefully.

----
Faster-Than-Light (FTL) Atlanta GA; Public access numbers:
404-292-8761 / 404-296-3120 / 404-299-3930 / 404-292-0236

In article <1404.363.uupcb@ftl.atl.ga.us> chris.smith@ftl.atl.ga.us (Chris Smith)  writes:
>
>JMS>Any vendor with the courage to provide object
>JMS>closures so that callbacks to member functions could work,
>JMS>would solve major problems for those working in
>JMS>Windowing environments. For example.
>
>One vendor (who I won't name)

 Let me guess :-)

>intentionally _dropped_ that
>exact extension from their 4.0 version, because ANSI wouldn't
>approve it (even though they thought it was in the bag),

 Thats not a reasonable statement. Object closures
were in a paper I wrote that proposed nested functions,
and nested function closures, but I lost the paper
and had to rewrite it and I left object closures
out, except for a remark.

 There was never any serious proposal for them,
so its hard to see how they could have been thought
to be "in the bag".

 It is, however, fairly simple to provide
nested functions and dynamic nested functions closures,
GNU C does both in C! Object closures are easy but there
is a small cost associated with them.

>because competitors and users constantly flaunted it as
>"lack of conformance".

 How silly. Had they provided them, there's a good
chance a proposal for Standardising them would be approved.
Existing practice is the strongest argument.

>This particular vendor takes great
>pride in its level of conformance.

 Conformance to a non-existant American standard
is not that intersting to me, I'm Australian.
>
>JMS>Responsible vendors provide compatibility switches,
>JMS>so you can check the portability of your code.
>
>That's a good idea.  The same vendor I mention above provides
>such switches.  You know.... they could have provided a
>"Dynamic Dispatch Table" switch, and made everybody happy,
>but their UI library depended upon that feature, and they
>wanted to make the UI library portable.  Hmm... which
>brings us back Joseph's the original sentiment.

 How can a Windows program possibly be "portable"
when the C++ documents are biased towards dumb console
based environments?

>
>[next statement is not shown in original order]
>JMS>hopefully several vendors will agree to provide similar
>JMS>extensions that can subsequently be Standardised.
>
>Maybe this could solve all of my problems.
>(1)  I want a standard for the language itself.
>(2)  I want a minimal set of standardized container classes.
>
>If fall is a realistic timeframe for (1), this makes me happy.

 You've missed something. Fall is only the
scheduled time for registration of the Committee Draft.
Following that, there will certainly be a second CD,
then a vote to make it a Draft International Standard
and then a vote to make it an International Standard
and then finally ISO will ratify it. The scheduled
end point is 1997.

 I dont believe the schedule can be met.  My guess is 1998.

>If some movement is made within the industry to provide a
>consensus on (2), it would be satisfactory until another
>committee could be convened to discuss the standardization
>of libraries.

 I proposed that, but the committee wasnt too interested
at the time. Perhaps things will change. Standardising
Libraries is probably more important than Standardising
the Language -- but the one must happen before the other
makes sense.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA