bstring.erl in the next release?

[Jérôme Marant]

Robert Virding <rv@REDACTED> writes:


> While using binaries for strings is sometimes a big win you have to be
> careful.  The problem is that while the representation is more compact
> and scanning can be quite efficient, either using a driver as Sean
> Hinde or the bit-syntax directly, building binary strings incremently
> can become quite costly.  Much more costly than using lists.  Also
> binaries are like all other Erlang objects in that they canot be
> modified, only created.
> 
> This problem when creating binaries, even with the bit-syntax, is a
> general problem with binaries not just when using them as strings.  I
> recall there has already been a discussion about this.
> 
> However, as the string library is mainly about pulling apart strings
> then a bstring library would probably be in place.  A bregexp as well
> would be nice.

  Once again, the most efficient solution would be to handle strings
  as binaries internaly avoiding the use of extra layers such as a
  bstring library or driver. Any time to have to communicate with
  other applications via some Internet protocol, you have to convert
  strings to binaries and that could be avoided.

  Hence, I woud see:
  - strings implemented as binaries within the interpreter
  - a lstring library in order to manipulate strings as lists

  Cheers, 

-- 
Jérôme Marant <jerome.marant@REDACTED>
              <jerome@REDACTED>