[Info-vax] OpenVMS Development Annoyances

[Dave Froble]

On 4/8/2019 11:09 AM, Stephen Hoffman wrote:
> On 2019-04-07 05:55:10 +0000, John Reagan said:
>
>> Well, then you'll like clang on x86.  We're not going to put ancient
>> stuff back into clang or the headers.  Standard IOSTREAM is the only
>> choice; standard STAT is the only choice; etc.  Of course, we'll have
>> to VMS-ize things where needed, but the closer we get to a standard
>> distribution is better for everybody.
>
> Ayup.
>
>> I counted the other day on how many lines we've added to LLVM and
>> we're only at 561 lines (I didn't count the lines to workaround the
>> Itanium C++ compiler or missing stuff from inttypes.h/stdint.h).  I
>> suspect the count will grow to close to 1000, but looking around at
>> other target-specific changes inside of LLVM, that is a reasonable #.
>> I'm not ready to guess at the clang side.
>
> The closer that count gets to zero in LLVM, the better it is for all of
> us.  Not the least of which would be compatibility-related work in the
> standard libraries.  That count outside of OpenVMS-specific extensions.
>
>> As for platform-specific addons for descriptors, etc.  Would you
>> rather have things added to std::string (like being able to ask for a
>> descriptor of the data) or a new vms::string that inherits from
>> std::string?  I've play with both (and even considered C++17's
>> string_view) and none jump out as the "best".
>
> Could you post up some source code examples of what you're pondering
> with vms:: and with std::?
>
> Initially, I'm leaning toward adding vms:: here, rather than customizing
> the std:: namespace.   And this isn't just strings, it's also itemlists
> and other OpenVMS-isms.
>
> And this is calling-standard-level stuff.  I'm more interested in
> descriptors and itemlists and such when working with OpenVMS APIs or
> when swapping data with Fortran or BASIC source code.  Descriptors and
> itemlists aren't otherwise very interesting within C++ code.
>
> Another and longer-term consideration here is around what will probably
> be an eventual migration toward what .NET and such provide; toward OO
> interfaces into the system and the libraries.  The compatibility with
> the "new" calling standard that'll eventually be arising here.  Those
> changes are obviously not going to happen anytime soon, but remaining
> compatible with the solutions for C++ would be preferable, as the rest
> of the OpenVMS APIs are made more compatible with OO environments,
> including with the eventual OOBASIC implementation and support that'll
> keep David entertained.
>
>

Entertainment is fine.  Confusion, not so much.

I see you've chosen to ignore my little bit of entertainment in response 
to your latest "annoyances".  Looking back, I missed an even better 
response.  Should have been "Use Basic, it's in there ..."

For some of your annoyances, that's basically true, it's in there.

:-)

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486