Thursday, December 24, 2020

Digest for comp.lang.c++@googlegroups.com - 2 updates in 2 topics

doctor@doctor.nl2k.ab.ca (The Doctor): Dec 24 01:16AM

Merry Christmas!
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Merry Christmas 2020 and Happy New Year 2021 !
"Öö Tiib" <ootiib@hot.ee>: Dec 23 05:13PM -0800

On Thursday, 24 December 2020 at 00:02:44 UTC+2, Richard Damon wrote:
> I want numbers printed in European format except for things intended to
> be cut and pasted into Excel which I have setup for a different format.
> The programmer needs to figure out which locale set to use for what.
 
I NEVER said it was i18n solution. I said it is utterly insufficient as
building block of one for my taste. I won't use <locale> even if paid
well as life is short and there are more fun and fruitful things to do.
Frameworks that have implemented i18n support have also usually
side-tracked <locale> so I'm not alone in that assessment. I already
indicated that we can disagree there as it is not really my business
what you use for i18n (if anything). I just disagree that it is good
idea.
 
> code-points represent, which requires updating character classification
> tables if (and only if) you want to process 'correctly' those new
> characters. These changes do NOT invalidate any older processing
 
I lost the point of your reasoning. So who does not want to process
things correctly? Or to avoid passing things that cooperating module
is incapable of processing correctly? That makes version supported
sometimes desirable to ask and to tell ... and that is all I said.

> VERY early days (once Unicode became a 21 bit character set). Valid (in
> that sense) UTF-8 should fully round trip to UTF-16 or UCS-4 without any
> changes.
 
That is unimportant as it does not affect what you say after "but".
The rule that everything before "but" is bullshit applies.
 
> people make encoding data that won't round trip if done right (and an
> application being strict is supposed to mark these cases with the
> replacement character, but many will just silently 'fix' them.
 
And here was the "but". Either such "fixes" should be illegal or we
have to run with pack, isn't it? Otherwise the distressed housewives
discard our product as inferior to those "many". Or what you suggest?
 
> > all the time.
> The problem here is that range of possible desired error recovery is so
> broad that it becomes unwieldy to implement.
 
That sounds like that what those "many" implement is unwieldy
to implement. It isn't easy but it is far easier than for example to
support reasonable sub-part of forest of "MarkDown format"
incarnations. Do you have some positive advise what to do
instead?
 
> potentially outside of the control of the programmer using them. This
> input potentially even comes from a source that is adversarial to the
> program.
 
Yes and Yes. So what? If we have to make filter that is helpful
with those adversarial sources then why should we not use it in
both directions?
 
 
> Yes, if the input is securely from a trusted source and known to be free
> from errors, you can be a bit more lax with parsing, and perhaps some of
> the simple input processing routines from the standard library can be used.
 
I do not trust even myself. I make typos constantly. This post has probably
several. So filter that safeguards regardless of what direction the
communication goes helps to find and resolve any problems and
<locale> that can't carry its own weight is useless.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)