[Info-vax] OpenVMS Development Annoyances

[John Reagan]

On Sunday, April 7, 2019 at 4:07:58 AM UTC+2, Stephen Hoffman wrote:
> On 2019-02-08 16:08:30 +0000, Stephen Hoffman said:
> 
> > Things about developing for OpenVMS that have annoyed me (again) this month:
> > ...
> 
> C++ has little OpenVMS system integration.  Outside of OpenVMS message 
> files, there seems little else.   Nothing obvious in iostream, for that 
> matter.
> 
> Specifying RMS file attributes on the fopen() is entertaining when 
> working with the strict compilation mode, as the compilations produce 
> (expected) diagnostics for the OpenVMS fopen extensions.
> 
> Which meant reverting and switching to __USE_STD_IOSTREAMS to get the 
> C++98-era "modern" behavior.
> 
> C does slightly here with OpenVMS, but still lacks OpenVMS integration.
> 
> OpenVMS descriptors, RMS, etc., most of what could be useful for 
> working with C++ on OpenVMS is seemingly missing.
> 
> Keeping old code mostly-working is certainly valuable, but the 
> "Specifying /DEFINE=__USE_STD_IOSTREAM forces the inclusion of the ANSI 
> standard version of the iostream header file.
> 
> This is the default in STRICT_ANSI mode. Otherwise, the pre-standard 
> AT&T-compatible version of iostream is used." is a stinky default for 
> anything other than remedial work.
> 

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.  

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.  

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".