Bit operations on bytes or chars

[Vlad Dogaru]

Hello,

I am trying to use bitwise operators on chars. What is the simplest
way to make this work? The only way that came to my mind was:

char c = 'a';
c = c | 0x02;

This yields a "Possible loss of precision" error.

Thanks in advance,
Vlad

 

[Arne Vajhøj]

I am trying to use bitwise operators on chars. What is the simplest
way to make this work? The only way that came to my mind was:

char c = 'a';
c = c | 0x02;

This yields a "Possible loss of precision" error.

c = (char) (c | 0x02);

because the result of th e| is an int not a char.

Arne

 

[Daniel Pitts]

c = (char) (c | 0x02);

because the result of th e| is an int not a char.

Arne

Also, futzing with bits on as char is probably a bad idea, unless you
fully understand UTF-16 and Unicode. What are you trying to do this?

 

[Vlad Dogaru]

Also, futzing with bits on as char is probably a bad idea, unless you
fully understand UTF-16 and Unicode. What are you trying to do this?

I have a homework to implement RUDP[1] in Jasper[2]. Now, Jasper uses
a specific format for packages, namely all data is a String (which
makes sense, since it abstracts all headers and the like). However, my
homework is to also implement the package header; hence my char
troubles. I agree that it is not a very healthy way to work, and I
blame the teacher who gave the homework, but I am unable to find a
different solution.

Vlad

[1] http://en.wikipedia.org/wiki/RUDP
[2] http://www.cs.stir.ac.uk/~kjt/software/comms/jasper.html

 

[Mark Space]

I have a homework to implement RUDP[1] in Jasper[2]. Now, Jasper uses

RUDP = reliable UDP. Cool, thanks for the pointer, I didn't know such a
thing existed.

a specific format for packages, namely all data is a String (which
makes sense, since it abstracts all headers and the like). However, my

Ugh. No, it doesn't make sense to use Strings. They should use classes
with the UDP fields defined appropriately. Stuffing random data into a
String is utter laziness and horrible design.

homework is to also implement the package header; hence my char
troubles. I agree that it is not a very healthy way to work, and I
blame the teacher who gave the homework, but I am unable to find a
different solution.

Between your teacher, and whatever grad student that wrote the mess that
is Jasper, I'd consider a new school.

You may want to check out a book by Douglas Comer called Internetworking
With TCP/IP, Volume II. It contains a full TCP implementation. At no
point does he do anything lazy like stuff fields in to byte arrays. He
defines a full, complete, well documented C struct for each and every
packet he uses. Much better design philosophy, imo.

 

[Roedy Green]

char c = 'a';
c = c | 0x02;

This yields a "Possible loss of precision" error.

bitwise operations work on ints. your char is promoted to an int
first. You must cast it back to char.
e..g.

c = (char) (c | 0x02);

or try the |= which might do a built-in cast for you.

c |= 0x02;

 

[Wojtek]

Mark Space wrote :

whatever grad student that wrote the mess that is Jasper

I am in the process of deciding whether to use BIRT or Jasper.

What is it that you do not like about Jasper?

 

[Logan Shaw]

Also, futzing with bits on as char is probably a bad idea, unless you
fully understand UTF-16 and Unicode. What are you trying to do this?

I have a homework to implement RUDP[1] in Jasper[2]. Now, Jasper uses
a specific format for packages, namely all data is a String (which
makes sense, since it abstracts all headers and the like). However, my
homework is to also implement the package header; hence my char
troubles.

I would treat the header (when finally rendering it to the wire
format from some higher-level format, like an object) as byte[].
Then you avoid all the character set issues because you're not
working with characters; you're working with bytes, which is what
you want to work with anyway (right?).

- Logan

 

[Mark Space]

Mark Space wrote :

I am in the process of deciding whether to use BIRT or Jasper.

What is it that you do not like about Jasper?

Well, I have not used Jasper. I was just going from the OP's
description that, apparently, the IO interface consists of passing UDP
packets encode as arrays of bytes, plopped on top of a String. That's
just ugly, if it's correct.

Jasper looks like a simulation, and they could have spent some time to
actually encapsulate the various packets that are used for the simulator.

Just going from a quick look at the docs though...

 

[Vlad Dogaru]

I have a homework to implement RUDP[1] in Jasper[2]. Now, Jasper uses

RUDP = reliable UDP. Cool, thanks for the pointer, I didn't know such a
thing existed.

a specific format for packages, namely all data is a String (which
makes sense, since it abstracts all headers and the like). However, my

Ugh. No, it doesn't make sense to use Strings. They should use classes
with the UDP fields defined appropriately. Stuffing random data into a
String is utter laziness and horrible design.

homework is to also implement the package header; hence my char
troubles. I agree that it is not a very healthy way to work, and I
blame the teacher who gave the homework, but I am unable to find a
different solution.

Between your teacher, and whatever grad student that wrote the mess that
is Jasper, I'd consider a new school.

I know it's off topic, but it's my intention to /become/ the teacher
and stop making this kind of mistakes.

You may want to check out a book by Douglas Comer called Internetworking
With TCP/IP, Volume II. It contains a full TCP implementation. At no
point does he do anything lazy like stuff fields in to byte arrays. He
defines a full, complete, well documented C struct for each and every
packet he uses. Much better design philosophy, imo.

Well, as far as I could tell, Jasper is more about seeing how the
protocol actually works. Actual data is not usually transmitted and
the user decides the actions taken (such as timeouts, CRC fails,
medium losses, etc.). Still, that's no excuse to hand out a homework
like the one I am facing.

That being said, I got the answer to my question. Thank you all and
apologies if this turned offtopic.

Have a nice day,
Vlad

 

[Mark Space]

Actual data is not usually transmitted and
the user decides the actions taken (such as timeouts, CRC fails,
medium losses, etc.). Still, that's no excuse to hand out a homework
like the one I am facing.

Yes, I understand how simulations work. I'm saying, regardless of the
type of project (simulation or real thing) stuffing data into an
unstructured buffer is the worst way of organizing a design.

In other words, your education is being cheated by giving an example of
bad design, and telling you that it doesn't matter because it's not
real. Simulations and academic projects are real designs too, and
should be treated as such. There's no excuse for sloppiness.

 

[Wojtek]

Mark Space wrote :

Well, I have not used Jasper. I was just going from the OP's description
that, apparently, the IO interface consists of passing UDP packets encode as
arrays of bytes, plopped on top of a String. That's just ugly, if it's
correct.

Jasper looks like a simulation, and they could have spent some time to
actually encapsulate the various packets that are used for the simulator.

Ah, ah, ...

Ok, I should have paid more attention to the topic I guess.

There is a Java reporting tool named Jasper, used for making pretty
reports from database values.

http://www.jasperforge.org/jaspersoft/opensource/business_intelligence/jasperreports/

Thanks...

 

[bugbear]

Arne Vajhøj wrote:
Vlad Dogaru wrote:
I am trying to use bitwise operators on chars. What is the simplest
way to make this work? The only way that came to my mind was:
char c = 'a';
c = c | 0x02;
This yields a "Possible loss of precision" error.
c = (char) (c | 0x02);
because the result of th e| is an int not a char.
Arne
Also, futzing with bits on as char is probably a bad idea, unless you
fully understand UTF-16 and Unicode. What are you trying to do this?

I have a homework to implement RUDP[1] in Jasper[2]. Now, Jasper uses
a specific format for packages, namely all data is a String (which
makes sense, since it abstracts all headers and the like). However, my
homework is to also implement the package header; hence my char
troubles.

I would treat the header (when finally rendering it to the wire
format from some higher-level format, like an object) as byte[].
Then you avoid all the character set issues because you're not
working with characters; you're working with bytes, which is what
you want to work with anyway (right?).

Yes; mapping strings (e.g. user level data) into byte packets
is a likely operation in this context, but it must be done explicitly;
simply assuming that String is nearly equal to byte[] will lead
to all manner of trouble.

BugBear