>Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]<SNIP> >pered: >| > > The way tr/// works is that a 256-byte table is constructed at compile >| > > time that say for each input character what output character is >| > >| > Speaking of which, what's going to happen when there are more than 256 >| > values to map? >| >| It's already happened, but I forget the details. >Let me see if I understand this correctly. For every tr/// in a program, >256 bytes have to be allocated? Yes, once upon a time. >Even if I only do something like tr/a/A/? >And, it is going to get worse for UTF8/UTF16? Use the Source. >Is this really the optimal >solution for this (sorry, this is probably going into -internals space). >Seems to me that we could very quickly end up with a really large memory >image. Memory usage is irrelevant compared with speed. --tom
- Re: RFC 165 (v1) Allow Varibles in tr/// Bryan C . Warnock
- Re: RFC 165 (v1) Allow Varibles in tr/// Bart Lateur
- Re: RFC 165 (v1) Allow Varibles in tr/// Mark-Jason Dominus
- Re: RFC 165 (v1) Allow Varibles in tr/// Stephen P. Potter
- Re: RFC 165 (v1) Allow Varibles in tr... Bart Lateur
- Re: RFC 165 (v1) Allow Varibles ... Bart Lateur
- Re: RFC 165 (v1) Allow Varibles ... Stephen P. Potter
- Re: RFC 165 (v1) Allow Varib... Mark-Jason Dominus
- Re: RFC 165 (v1) Allow Varib... Stephen P. Potter
- Re: RFC 165 (v1) Allow Varib... Tom Christiansen
- Re: RFC 165 (v1) Allow Varibles in tr... Tom Christiansen
- Re: RFC 165 (v1) Allow Varibles ... Stephen P. Potter
- Re: RFC 165 (v1) Allow Varib... Bart Lateur
- Re: RFC 165 (v1) Allow Varib... Tom Christiansen
- Re: RFC 165 (v1) Allow Varibles in tr... Jonathan Scott Duff
- Re: RFC 165 (v1) Allow Varibles in tr/// Chaim Frenkel
- Re: RFC 165 (v1) Allow Varibles in tr/// Mark-Jason Dominus