Re: how to extend a byte[] array with a null byte?

Discussion in 'Java' started by Tom McGlynn, Apr 17, 2008.

  1. Tom McGlynn

    Tom McGlynn Guest

    On Apr 17, 1:47 pm, Rex Mottram <> wrote:
    > This should be simple but I'm struggling with it (and am somewhat of a
    > Java newbie). I have a string
    >
    > String foo = "abc";
    >
    > and need to write it into a database file as a C-style string (meaning a
    > trailing null is appended). The API takes a byte[] array, thus the
    > current usage is something like
    >
    > dbfile.add(foo.getBytes());
    >
    > I simply need to take the byte[] array returned by String.getBytes() and
    > add one extra byte containing 0 before passing it to the add() method.
    > Try as I might I can't find the way. Help!
    >
    > TIA,
    > RM


    Ignoring the complex questions of how the current encoding changes the
    translation between bytes and string, the simplest solution might just
    be (foo+'\000').getBytes()

    Regards,
    Tom McGlynn
    Tom McGlynn, Apr 17, 2008
    #1
    1. Advertising

  2. Tom McGlynn

    Tom McGlynn Guest

    On Apr 17, 2:37 pm, Rex Mottram <> wrote:
    ....
    > Thanks. Would not (foo+'\000').getBytes("UTF-8") solve the encoding
    > question (assuming all users are ok with that encoding, of course)?
    >
    > RM


    That works for me. The only other thing you might want to be careful
    of is checking if foo is null.
    Regards,
    Tom McGlynn
    Tom McGlynn, Apr 17, 2008
    #2
    1. Advertising

  3. Tom McGlynn

    Mark Space Guest

    Tom McGlynn wrote:
    > On Apr 17, 2:37 pm, Rex Mottram <> wrote:
    > ...
    >> Thanks. Would not (foo+'\000').getBytes("UTF-8") solve the encoding
    >> question (assuming all users are ok with that encoding, of course)?
    >>
    >> RM

    >
    > That works for me. The only other thing you might want to be careful
    > of is checking if foo is null.
    > Regards,
    > Tom McGlynn


    And that works if your DB takes UTF-8. Don't forget that it could be
    possible for non-ASCII characters to get mixed up in there. If you want
    ASCII, I think "ASCII" is one of Java's encoding types.

    If you are doing lots of little strings, object creation does have a
    penalty, so keep that in mind. Profile your code to make sure the
    conversion doesn't seem to be taking too much time, otherwise you might
    need some lower level tricks in there.

    For example, if you're reading from a file, the "strings" likely exist
    to begin with as a buffer in memory. You may wish to understand if you
    can use this buffer directly.
    Mark Space, Apr 18, 2008
    #3
  4. Tom McGlynn

    Tom McGlynn Guest

    On Apr 17, 9:05 pm, Mark Space <> wrote:
    > Tom McGlynn wrote:
    > > On Apr 17, 2:37 pm, Rex Mottram <> wrote:
    > > ...
    > >> Thanks. Would not (foo+'\000').getBytes("UTF-8") solve the encoding
    > >> question (assuming all users are ok with that encoding, of course)?

    >
    > >> RM

    >
    > > That works for me. The only other thing you might want to be careful
    > > of is checking if foo is null.
    > > Regards,
    > > Tom McGlynn

    >
    >..
    > If you are doing lots of little strings, object creation does have a
    > penalty, so keep that in mind. Profile your code to make sure the
    > conversion doesn't seem to be taking too much time, otherwise you might
    > need some lower level tricks in there.
    >

    ....
    While I have no technical disagreement here, I think that worrying
    about efficiency at this micro level before there is some indication
    of a problem is rarely helpful. First write the program in whatever
    way seems clearest and most natural. If you want to add a null to a
    string, then adding a null to a string seems a clear way to indicate
    your intent. Or pick whatever seems most natural to you. Once you
    have a clear, correct and running program, then if there are
    performance problems you can worry about optimization and the issues
    discussed in the Mark's post. More than once I've found that in
    making some clever optimization, I've introduced bugs and in
    correcting them found that the 'optimization' had no real impact on
    performance.

    Database updates are typically quite expensive. In practice I would
    not expect any significant difference to the total time of the program
    based upon the approach used to add null terminators.


    Regards,
    Tom McGlynn
    Tom McGlynn, Apr 18, 2008
    #4
  5. Tom McGlynn

    Mark Space Guest

    Tom McGlynn wrote:

    > While I have no technical disagreement here, I think that worrying
    > about efficiency at this micro level before there is some indication
    > of a problem is rarely helpful. First write the program in whatever


    Well, in my defense, I did say to profile the code first. I was just
    pointing out that copyArray and friends represent buffer copies, and
    buffer copying is one thing that known to cause issues on some types of
    system, esp. if there are a LOT of buffer copying.

    It's not CPU time, it's memory bandwidth, which is needed for both the
    copy and all IO. Buffer copies can kill IO intensive applications.

    But yeah, profile first. I was just saying it's something to be aware of.
    Mark Space, Apr 19, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kirby
    Replies:
    3
    Views:
    640
    Kirby
    Oct 8, 2004
  2. Replies:
    5
    Views:
    26,611
    Mike Schilling
    Mar 29, 2006
  3. Patricia Shanahan
    Replies:
    0
    Views:
    384
    Patricia Shanahan
    Apr 17, 2008
  4. Tom McGlynn
    Replies:
    2
    Views:
    407
    Andreas Leitgeb
    Apr 18, 2008
  5. aneuryzma
    Replies:
    3
    Views:
    706
    Jim Langston
    Jun 16, 2008
Loading...

Share This Page