***   C++ on MPE/iX:   Requirements and Options   ***
 
1)   If a compiler existed which handled only Unix-like
constructs (at least initially) were supported, would
you use it ?
 
I''m not really sure what this means; C++ is defined by things like "The
C++ Programming Language" (Stroustrup), "The Annotated Reference Manual"
(Ellis & Stroustrup), a.k.a. the "ARM", and the ANSI X3J16/ISO WG14 Draft
Working Papers, so I'm not clear about "only Unix-like constructs".
Assuming that it means something like "only standard C++ language
features", the answer is "no". Without access to MPE intrinsics, I would
not be able to use C++, and would be forced to stick to the C/iX product.
 
2)   If an MPE C++ compiler were enhanced after the
initial port, what capabilities would it need:  indicate
"don't care", "useful", or "must have" for each ?
        Intrinsic support: Must have, *as part of* the initial port
        Access to IMAGE: What does this mean? With intrinsic support,
I've got access to IMAGE. The C++ language itself has no built-in access
to anything except files and streams, so I don't see how IMAGE access
would be integrated into C++ in any immediately-obvious fashion.
        Access to KSAM: Same as for IMAGE.
        Long pointer support: Since there are currently-used intrinsics
that require long pointer parameters (specifically IPCRECV and IPCSEND in
my case), this is another "must have, as part of the initial port" item.
Unless HP is willing to provide alternate MPE intrinsics that accept
32-bit pointers, that is; this would work fine for my applications.
        Ability to run in MPE Name Space: Not sure what this means. The
name string passed to 'fopen()' or 'filebuf::open()' is not constrained
by the language; whether it is interpreted as file.group.account, or
file.ext.additionalext, or anything else, is a library issue.
        Use default MPE naming conventions: Huh?
 
3)   Would you trust a third-party compiler that was
supported by HP ?
 
Depends. Who is going to be responsible for tracking the C++ standard?
Who is going to be responsible for tracking updates to MPE/iX?
 
4)   What would you be willing to pay HP for annual
support of C++ on MPE/iX ?
 
I would expect C++ to receive the same level of support as any other
language product, and for such support to be priced the same as other
language products.
 
5)   If the cost of acquisition of the compiler were
minimal or non-existent, would you be willing to pay
higher support fees over a guaranteed term ?
 
Cost of acquisition is really a minor- or non-issue in most cases, and
I'm not sure that a lower cost-of-entry justifies a higher
cost-of-ongoing-use compared to other HP language products. If you got a
$?? discount on your car, would you be willing to pay 25% more for gas?
 
6)   Additional comments/remarks/concerns on this
subject:
 
HP still seems to be missing the "big picture" on this issue. C++ is a
language product, like TRANSACT or C. You aren't going to sell 50,000
copies of it, you're going to sell 5,000. But those of us who buy it are
going to create MPE applications that are going to contribute to people's
decisions to use your machines, buy bigger machines, or buy new machines.
 
 
Steve Dirickson         WestWin Consulting
(360) 598-6111  [log in to unmask]