In article <3p09i5$ru3@rover.village.org>, Warner Losh <imp@village.org> wrote:
>In article <3otmue$474@engnews2.eng.sun.com>,
>Steve Clamage <clamage@Eng.Sun.COM> wrote:
>>It wouldn't surprise me if the cost to MG of participating in the standards
>>process turns out to have been less than the cost to them of not
>>having the language feature they promoted.
>
>Given what has happened to certain language features, I know of at
>least one company that would have saved money by having active
>participation on the process.  They are now faced with rewriting a
>fair amount of code because the standard doesn't make enough
>guarantees wrt member function pointer casting and calling through
>those cast pointers.
>
>Clearly a case where existing practice is "allowed" by the standard,
>but unfortunately not guaranteed by it.

 Anyone else feel they cannot live with non-standard extensions?
Is all that code going to be Standard after the conversion anyhow?

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <3otmue$474@engnews2.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>It wouldn't surprise me if the cost to MG of participating in the standards
>process turns out to have been less than the cost to them of not
>having the language feature they promoted.

Given what has happened to certain language features, I know of at
least one company that would have saved money by having active
participation on the process.  They are now faced with rewriting a
fair amount of code because the standard doesn't make enough
guarantees wrt member function pointer casting and calling through
those cast pointers.

Clearly a case where existing practice is "allowed" by the standard,
but unfortunately not guaranteed by it.

Warner
--
Warner Losh  "VMS Forever" home: imp@village.org
TIA Development Engineer  work: imp@marketplace.com

In article 95May11180040@slsvhdt.lts.sel.alcatel.de, kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) writes:
>
>As for the big players, frankly, I wonder how they justify their
>activities to their stockholders.  ...  I could name a number of
>other companies, big and small, whose contributions probably outweigh
>the benefits they will reap.

I know that in some cases companies participate to ensure that language
features they need will be included if possible, and that features will
not be adopted that conflict with company goals. One need not be a C++
implementor to participate for such reasons.

Example: Mentor Graphics was very active early in the C++ standards process.
They were not C++ implementors, but bravely (foolishly?) decided early on
to settle on C++ as a development language. One feature they needed for
their systems was the ability to overload 'operator new' for array allocation --
which was not previously a language feature. Mentor Graphics representatives
formulated and championed a proposal which after discussion and some
modification was eventually approved. (It was approved not as a favor to MG,
and not via "log-rolling", but because the other committee members agreed it
was valuable and would cause problems for others as well if it were not adopted.)

It wouldn't surprise me if the cost to MG of participating in the standards
process turns out to have been less than the cost to them of not
having the language feature they promoted.

Similarly, one of the reasons Sun supports my participation is so that I
can help ensure that the adopted standard won't prohibit implementation
techniques that Sun wants or needs to use.
---
Steve Clamage, stephen.clamage@eng.sun.com