[Info-vax] OpenVMS Development Annoyances

[Stephen Hoffman]

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.


-- 
Pure Personal Opinion | HoffmanLabs LLC