From: Xavier Leroy <xavier.leroy@inria.fr>
To: "William D. Neumann" <wneumann@cs.unm.edu>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] [RANT] String representation (was: Strings as arrays or lists...)
Date: Tue, 4 Mar 2003 19:38:59 +0100 [thread overview]
Message-ID: <20030304193859.A10907@pauillac.inria.fr> (raw)
In-Reply-To: <Pine.LNX.4.44.0303040901360.22735-100000@chipotle.cs.unm.edu>; from wneumann@cs.unm.edu on Tue, Mar 04, 2003 at 09:14:28AM -0700
> Unfortunately strings don't act like byte arrays (to the best of my
> knowledge anyway -- I'd love to find out I'm wrong). If you want to do
> any low level operations on the bytes, you first need to convert the chars
> to ints (and by low level, I'm talking about shifts, rotates, ands, ors,
> xors, etc), perform your ops, then convert back to chars before
> re-inserting them into the string, and this is slooooow.
Actually, Char.code (the conversion from char to int) is a no-op, but
it's true that Char.chr (the conversion from int to char) is slower
because it checks that its argument lies within [0..255].
An alternative is Char.unsafe_chr, which is a no-op (but doesn't
perform the range check).
A better alternative is to declare
external get_byte: string -> int -> int = "%string_safe_get"
external set_byte: string -> int -> int -> unit = "%string_safe_set"
and use these two functions to access strings as if they were byte
arrays. set_byte will store the low 8 bits of its third argument, so
you'd save on "land 0xFF" operations too.
> Since I do crypto for a living, I run into these problems all the time.
Sure. The two declarations above should help both with performance
and legibility of your code.
- Xavier Leroy
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2003-03-04 18:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-03 18:28 [oliver: Re: [Caml-list] Strings as arrays or lists...] Oliver Bandel
2003-03-03 20:10 ` brogoff
2003-03-03 21:05 ` William Lovas
2003-03-03 21:32 ` Basile STARYNKEVITCH
2003-03-03 22:10 ` [Caml-list] [RANT] String representation (was: Strings as arrays or lists...) Nicolas George
2003-03-04 12:43 ` Diego Olivier Fernandez Pons
2003-03-04 16:14 ` William D. Neumann
2003-03-04 18:38 ` Xavier Leroy [this message]
2003-03-04 18:50 ` William D. Neumann
2003-03-04 19:01 ` Nicolas George
[not found] ` <Pine.A41.4.44.0303041312560.4431978-100000@ibm1.cicrp.juss ieu.fr>
2003-03-04 13:49 ` David Chase
2003-03-04 0:20 ` [oliver: Re: [Caml-list] Strings as arrays or lists...] Issac Trotts
2003-03-04 0:24 ` Alain.Frisch
2003-03-04 1:06 ` Issac Trotts
2003-03-04 0:39 ` Olivier Andrieu
2003-03-04 0:39 ` brogoff
2003-03-03 21:40 ` [Caml-list] extensional polymorphism james woodyatt
2003-03-04 1:10 ` brogoff
2003-03-04 2:04 ` james woodyatt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030304193859.A10907@pauillac.inria.fr \
--to=xavier.leroy@inria.fr \
--cc=caml-list@inria.fr \
--cc=wneumann@cs.unm.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox