[Info-vax] OpenVMS Development Annoyances

[Arne Vajhøj]

On 4/7/2019 7:47 PM, Simon Clubley wrote:
> On 2019-04-07, Arne Vajhøj <arne at vajhoej.dk> wrote:
>> But I also don't like vms::string inheriting from std::string. Either
>> the application will use vms:string and VMS specific libraries all
>> over or it will end up with a lot of copy constructor calls to get from
>> std::string to vms::string. That type of inheritance is rarely good.
> 
> Inheriting does have some advantages if you want to extend this
> approach to implement VMS specific functionality in other classes.
> 
> If the program is designed correctly (isolating the VMS specific
> stuff from the rest of the program), I am not convinced the overhead
> is as high as you think it could be.

Too many places where std::string is out (in is obviously not a problem).

>> I will recommend the primitive solution:
>>
>> std::string s;
>> vms::string_descriptor = vms::get_descrptor(s);
>>
>> No messing around with classes - just a simple function that does the job.
>>
> 
> I'm not happy about that as it means that an unrelated class
> potentially needs access to the internal implementation details
> of the std:: classes.

That is really the same problem with inheriting - assuming that those
details are not protected, which I very much doubt.

> In the case of std::string, you can argue that the information you
> need to build the descriptor is available from public API information
> but that might not be true for other VMS specific extensions to the
> std:: classes.
> 
> I don't use C++ on VMS so I don't know if this is currently supported
> by HPE C++, but one potential use might be to provide a marshalling
> mechanism to marshall a vector (for example) to a VMS specific
> variable length array descriptor.
> 
> Does HPE C++ currently support that, and if so, can the marshalling
> be done in either direction ?

Marshal and unmarshal seems a pretty heavy operation for this purpose.

Arne