Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Re: how to extend a byte[] array with a null byte?

Reply
Thread Tools

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

 
 
Tom McGlynn
Guest
Posts: n/a
 
      04-17-2008
On Apr 17, 1:47 pm, Rex Mottram <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Tom McGlynn
Guest
Posts: n/a
 
      04-17-2008
On Apr 17, 2:37 pm, Rex Mottram <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Mark Space
Guest
Posts: n/a
 
      04-18-2008
Tom McGlynn wrote:
> On Apr 17, 2:37 pm, Rex Mottram <(E-Mail Removed)> 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.
 
Reply With Quote
 
Tom McGlynn
Guest
Posts: n/a
 
      04-18-2008
On Apr 17, 9:05 pm, Mark Space <(E-Mail Removed)> wrote:
> Tom McGlynn wrote:
> > On Apr 17, 2:37 pm, Rex Mottram <(E-Mail Removed)> 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
 
Reply With Quote
 
Mark Space
Guest
Posts: n/a
 
      04-18-2008
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Null pointer (NULL array pointer is passed) aneuryzma C++ 3 06-16-2008 05:48 AM
Re: how to extend a byte[] array with a null byte? Tom McGlynn Java 2 04-18-2008 01:00 PM
Re: how to extend a byte[] array with a null byte? Patricia Shanahan Java 0 04-17-2008 06:47 PM
"stringObj == null" vs "stringObj.equals(null)", for null check?? qazmlp1209@rediffmail.com Java 5 03-29-2006 10:37 PM



Advertisments