[Info-vax] Calling $CREPRC in COBOL

[VAXman- at SendSpamHere.ORG]

In article <t9tmgc$39oe1$1 at dont-email.me>, Stephen Hoffman <seaohveh at hoffmanlabs.invalid> writes:
>On 2022-07-03 20:15:58 +0000, seasoned_geek said:
>
>> On Tuesday, June 28, 2022 at 7:43:54 AM UTC-5, Arne Vajhøj wrote:
>>> On 6/27/2022 10:46 PM, Craig A. Berry wrote:> >> B) UTF-16 internal and 
>>> UTF-8 external> >>> >> That one requires a lot of work.> >>> >> Library 
>>> support.> >>> >> Application changes.> >>> >> But it is efficient.> >>> 
>>> >> Which is why C/C++, Java and .NET all chose that path.> >> > I think 
>>> they made those choices when UCS-2 was current and everyone> > thought 
>>> a wider fixed-width encoding would be enough.
>>> Yes.
>>>> UTF-16 needs all> > of the same varying-width handling that UTF-8
>>> In theory yes.>> In practice it is common for applications only to support BMP.
>>>> does but uses twice as> > much memory for the most common characters.
>>> Most don't care.
>> Actually most do care about the memory consumption. Especially when it 
>> cascades out to disk that is too small. They also care about the 
>> overhead of CHAR processing.
>> 
>> C++ will soon follow the path CopperSpice took. They created QChar32 
>> because we are now out to 32-bit Unicode. UTF-8 and UTF-16 have their 
>> own hacks for multi-unit characters and that adds processing overhead. 
>> The 32-bit character approach allows the database/indexed file/real 
>> data storage that isn't JSON or XML to cleanly do record compression 
>> for storage and decompression for retrieval without making the 
>> processor drag the 8-bottom plow of multi-unit character processing.
>
>ObjC and ObjC++ solved this soup years ago.
>
>As for C++, that's been a bit of a dog's breakfast for a while, and I use it.
>
>Microsoft messed up with their wchar_t choice, which hasn't helped code 
>portability. Akin to the size_t choice on OpenVMS.
>
>Characters (first) outside of what can be stored in char16_t happened 
>just after Y2K with Unicode 3.1, not that most folks noticed.
>
>And yeah, the first plane (65536) is all but full now, so off into 
>char32_t for ~anything new.
>
>The ICU, Reichwein, libunicode, or other available libraries might help 
>with Unicode.  Or Boost, of course.
>
>Or Go, Rust, Swift, or various other language choices—if OpenVMS isn't 
>a target, that is.

Why does this thread make me think of Boltzmann's constant? ;)

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.