By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,837 Members | 1,720 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,837 IT Pros & Developers. It's quick & easy.

How do i declare a byte variable?

P: n/a
hi,

I have a problem, a stupid problem. I can't declare a variable of type
byte.

The g++ said that i have syntactic error in this line. The code is
this: byte * variable;

well, i think that the mistake is a stupidity but i don't find it.
where is it?

Aug 10 '06 #1
Share this Question
Share on Google+
20 Replies


P: n/a
Manuel wrote:
hi,

I have a problem, a stupid problem. I can't declare a variable of type
byte.

The g++ said that i have syntactic error in this line. The code is
this: byte * variable;

well, i think that the mistake is a stupidity but i don't find it.
where is it?
Standard C++ doesn't have a built-in type called "byte." Just use a
char or, possibly, an unsigned char.

Try this:

char* variable1;
unsigned char* variable2;

Or perhaps you need to tell us more about what you intend to do with
the variable.

Best regards,

Tom

Aug 10 '06 #2

P: n/a
On 10 Aug 2006 13:57:01 -0700 in comp.lang.c++, "Manuel"
<mf*****@gmail.comwrote,
>I have a problem, a stupid problem. I can't declare a variable of type
byte.

The g++ said that i have syntactic error in this line. The code is
this: byte * variable;
A byte in C++ is char, or unsigned char, or signed char.

But your variable above would not be a byte an any case. It would
be a pointer. If you are asking what is a byte, you should probably
avoid bytes and pointers for now and use std::string etc..

Aug 10 '06 #3

P: n/a
ouch, iam stupid ;(

well, I thought about using the variable of type byte because I need to
store values from 0 to 255.
I think that i can use this:

Thomas Tutone wrote: typedef unsigned char byte;
So this way i can use byte.

Thank you for your help.

Bye.
Manuel Fernadez Campos
Manuel wrote:
hi,

I have a problem, a stupid problem. I can't declare a variable of type
byte.

The g++ said that i have syntactic error in this line. The code is
this: byte * variable;

well, i think that the mistake is a stupidity but i don't find it.
where is it?

Standard C++ doesn't have a built-in type called "byte." Just use a
char or, possibly, an unsigned char.

Try this:

char* variable1;
unsigned char* variable2;

Or perhaps you need to tell us more about what you intend to do with
the variable.

Best regards,

Tom
Aug 10 '06 #4

P: n/a
Manuel wrote:
ouch, iam stupid ;(

Please read the information below.


Brian

--
Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or the group FAQ list:
<http://www.parashift.com/c++-faq-lite/how-to-post.html>
Aug 10 '06 #5

P: n/a
Manuel posted:
well, I thought about using the variable of type byte because I need to
store values from 0 to 255.

C++ has a series of integer types, all of which come in a signed and
unsigned flavour:

char
short
int
long

The fundamental differences between them are:

(1) Their range:

rangeof(signed char) is a subset of rangeof(signed short),
which is a subset of rangeof(signed int), which is a subset of rangeof
(signed long).
rangeof(unsigned char) is a subset of rangeof(unsigned short),
which is a subset of rangeof(unsigned int), which is a subset of rangeof
(unsigned long).

Note that this does not forbid them from all having the same range -- the
following could very well be true on a given system:

rangeof(signed char)==rangeof(short)==rangeof(int)==rangeof(long)

Note though that it's possible that the upper limit of "unsigned char" be
higher than the upper limit of "long".

(2) The amount of memory they occupy.

Put quite simply:
sizeof(signed char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

(3) How efficiently the system deals with them (i.e. how fast it can work
with them)

The fastest type should be int, as it's supposed to be the "natural"
integer size for the system.

Now that we know a few differences between the integer types, we can make
an educated decision as to which to use for each purpose. Before we go any
further however, we should note that the Standard guarantees a minimum
range for each type:

(1) unsigned char : 0 through 255
(2) unsigned short : 0 through 65 535
(3) unsigned int : 0 through 65 535
(4) unsigned long : 0 through 4 294 967 295

(1) signed char: -127 through 127
(2) signed short: -32 767 through 32 767
(3) signed int: -32 767 through 32 767
(4) signed long: -2 147 483 647 through 2 147 483 647

The first thing to consider is whether we shall be storing negative
numbers; if so, we want a "signed" type. The first choice should be "signed
int" or "unsigned int":

int i = -3;

unsigned j = 5;

The next thing to consider is whether the number we store might fall
outside the guaranteed range of "signed int" or "unsigned int". If it does,
then we should "unsigned long" or "signed long":

long i = -70000;

long unsigned i = 70000U;

(If you're writing a positive integer literal which is larger than 65 535,
then append "U" to it.)

If the number is within range of "int" or "unsigned", then the last thing
to consider is whether memory is scarce. If we want to define an array of
87 thousand integers, we might consider using a "char" or a "short" -- it
will be less efficient, but it will use only half or a quarter of the
memory (depending on the system).

One last thing: If you don't specify the signedness of a type, then it
defaults to signed (i.e. "long" == "long signed"). However this isn't quite
true for "char". A plain char might be signed or unsigned, depending on the
system, so it isn't any use for doing arithmetic or storing numbers; it
should only be used for storing characters. If you want a signed char, then
make sure you specify "signed":

char unsigned a = 5; /* This is unsigned */

char signed b = -5; /* This is signed */

char c = 2; /* This could be either */

If you really want to become expert at working with integer types in C and
C++, then you might also want to learn about "integer promotion".

To answer your question though: If you want to store a number in the range
0 through 255, then just use "unsigned":

unsigned i = 255;

Only consider using "char" or "short" if memory is scarce, e.g.:

char unsigned array[99999999];

--

Frederick Gotham
Aug 10 '06 #6

P: n/a
Frederick Gotham posted:
(If you're writing a positive integer literal which is larger than 65
535, then append "U" to it.)

Actually, that's only necessary if the value is greater than 2 147 483 647.

The following is guaranteed to work fine on every system:

unsigned i = 2147483647;

The following might result in an ill-formed program on some systems (because
the signed integer literal might be out of range):

unsigned i = 2147483648;

Therefore, it's wise to append U to it:

unsigned i = 2147483648U;

--

Frederick Gotham
Aug 10 '06 #7

P: n/a

"Frederick Gotham" <fg*******@SPAM.comwrote in message news:2bOCg.12515
>
To answer your question though: If you want to store a number in the range
0 through 255, then just use "unsigned":

unsigned i = 255;

Only consider using "char" or "short" if memory is scarce, e.g.:

char unsigned array[99999999];
Why? I'd probably use "unsigned char", especially if I was porting Pascal
code or something. That's most likely what was meant by "byte", don't you
think?

-Howard

Aug 10 '06 #8

P: n/a
Howard posted:
>To answer your question though: If you want to store a number in the
range 0 through 255, then just use "unsigned":

unsigned i = 255;
Why? I'd probably use "unsigned char", especially if I was porting
Pascal
code or something. That's most likely what was meant by "byte", don't
you
think?

The extra efficiency of "unsigned int" is worth the cost of using up
another three bytes (or thereabouts).

Even if I were to write:

char unsigned i = 255;

, then it would still probably consume 4 bytes (or thereabouts) on most
systems.(If you have a system which can only access 4 bytes of memory at a
time, rather than one sole byte, then it would be efficient to store the
byte value in the least significant byte of the 4 bytes, and to just ignore
the values of the subsequent 3 bytes).

An easy test for this is the following:

#include <stdio.h>

int main(void)
{
struct FourBytes { char a,b,c,d; };

switch(sizeof(struct FourBytes))
{
case sizeof(char[4]):
puts("Packed nice and tight!");
break;

case sizeof(int[4]):
puts("Aligned for efficient access.");
break;

default:

puts("Something funky's going on...");
}

return 0;
}

Notwithstanding any of this, your char is going to be promoted to int every
time you lay a finger on it.

--

Frederick Gotham
Aug 10 '06 #9

P: n/a
Frederick Gotham posted:

<snip C code>

Forgot I was posting to comp.lang.c++ (rather than comp.lang.c) -- I would
have written C++-style code if I had realised.

Nonetheless, the code is also valid C++ code (with deprecated features
albeit).

--

Frederick Gotham
Aug 10 '06 #10

P: n/a
On 2006-08-10 18:20:25 -0400, Frederick Gotham <fg*******@SPAM.comsaid:
Frederick Gotham posted:
>(If you're writing a positive integer literal which is larger than 65
535, then append "U" to it.)


Actually, that's only necessary if the value is greater than 2 147 483 647.

The following is guaranteed to work fine on every system:
No it isn't. There are many systems out there with a type unsigned that
can only represent values up to 65535
unsigned i = 2147483647;

The following might result in an ill-formed program on some systems
(because the signed integer literal might be out of range):

unsigned i = 2147483648;

Therefore, it's wise to append U to it:

unsigned i = 2147483648U;

--
Clark S. Cox, III
cl*******@gmail.com

Aug 11 '06 #11

P: n/a
Clark S. Cox III posted:
No it isn't. There are many systems out there with a type unsigned that
can only represent values up to 65535
"long" must have at least the following range:

-2147483647 through 2147483647

"unsigned long" must have at least the following range:

0 through 4294967295

Sounds like these systems you mention are not Standard-compliant.

--

Frederick Gotham
Aug 11 '06 #12

P: n/a
Manuel wrote:
ouch, iam stupid ;(

well, I thought about using the variable of type byte because I need to
store values from 0 to 255.
I think that i can use this:

Thomas Tutone wrote: typedef unsigned char byte;
So this way i can use byte.

Thank you for your help.

Bye.
Manuel Fernadez Campos

>>Manuel wrote:
>>>hi,

I have a problem, a stupid problem. I can't declare a variable of type
byte.

The g++ said that i have syntactic error in this line. The code is
this: byte * variable;

well, i think that the mistake is a stupidity but i don't find it.
where is it?

Standard C++ doesn't have a built-in type called "byte." Just use a
char or, possibly, an unsigned char.

Try this:

char* variable1;
unsigned char* variable2;

Or perhaps you need to tell us more about what you intend to do with
the variable.

Best regards,

Tom

Do not use a byte variable. Use a variable that is the width of the
machine's word size that will accomodate your range. Today's computers
are optimized to handle words that are more than 8-bits wide. You
should be more concerned about the correctness and reliablity of
your program than storage requirements.

For example, the ARM7 processor is designed to handle 32-bit words.
The 8-bit quantities cause more work for the processor. Saving space
is not as important as getting the program to work correctly and
delivered on time. If the program doesn't fit in its container,
then and only then, worry about the size it occupies or the memory
it requires.
At work I am battling code that has variables declared in terms
of bits, rather than "int" or "unsigned int". When the time comes
to move to a processor with larger word size, all these variables
will have to be changed. Argggh.


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

Aug 11 '06 #13

P: n/a
Frederick Gotham wrote:
Clark S. Cox III posted:

>>No it isn't. There are many systems out there with a type unsigned that
can only represent values up to 65535


"long" must have at least the following range:

-2147483647 through 2147483647

"unsigned long" must have at least the following range:

0 through 4294967295

Sounds like these systems you mention are not Standard-compliant.
No, they are not. "unsigned" is shorthand for "unsigned int", which is
only required to represent values up to 65535.

"unsigned long" is a different type.

--
Ian Collins.
Aug 11 '06 #14

P: n/a
On 2006-08-10 22:23:54 -0400, Frederick Gotham <fg*******@SPAM.comsaid:
Clark S. Cox III posted:
>No it isn't. There are many systems out there with a type unsigned that
can only represent values up to 65535

"long" must have at least the following range:

-2147483647 through 2147483647

"unsigned long" must have at least the following range:

0 through 4294967295

Sounds like these systems you mention are not Standard-compliant.

Who said anything about "unsigned long"? The type in question was
"unsigned" (aka "unsigned int")

--
Clark S. Cox, III
cl*******@gmail.com

Aug 11 '06 #15

P: n/a
Ian Collins posted:
No, they are not. "unsigned" is shorthand for "unsigned int", which is
only required to represent values up to 65535.

We were referring to usigned integer types (note the plural).

--

Frederick Gotham
Aug 11 '06 #16

P: n/a
Clark S. Cox III posted:
Who said anything about "unsigned long"? The type in question was
"unsigned" (aka "unsigned int")

I see where the confusion stems from. I initially said that the following
is fine:

unsigned i = 2147483647;

What I meant was that it is not ill-formed, nor does it invoke undefined
behaviour. (However, it would have been more intuitive had I written:

long unsigned i = 2147483647;

The point I was trying to make is that the following statement is ill-
formed:

long unsigned i = 2147483648;

, because a program is ill-formed if it contains an integer literal which
is out of range. We must explicitly make the literal unsigned:

long unsigned i = 2147483648U;

You are correct, however, that the max range of "unsigned int" is not
obliged to exceed 65535.

--

Frederick Gotham
Aug 11 '06 #17

P: n/a
Frederick Gotham wrote:
Ian Collins posted:

>>No, they are not. "unsigned" is shorthand for "unsigned int", which is
only required to represent values up to 65535.

We were referring to usigned integer types (note the plural).
Nonsense, you said:
The following is guaranteed to work fine on every system:

unsigned i = 2147483647;
Which is false and was corrected by Clark.

You then said:
>"unsigned long" must have at least the following range:

0 through 4294967295

Sounds like these systems you mention are not Standard-compliant.
Singular and very specific.

--
Ian Collins.
Aug 11 '06 #18

P: n/a
Ian Collins posted:
>We were referring to usigned integer types (note the plural).
Nonsense, you said:
>The following is guaranteed to work fine on every system:

unsigned i = 2147483647;

Which is false and was corrected by Clark.

I explained this elsethread. The following statement is neither ill-formed,
nor does it invoke undefine behaviour (hence fine):
unsigned i = 2147483647;

--

Frederick Gotham
Aug 11 '06 #19

P: n/a
It occurred to me that Frederick Gotham wrote in comp.lang.c++:
Howard posted:

The extra efficiency of "unsigned int" is worth the cost of using up
another three bytes (or thereabouts).
Utter nonsense. There are plenty of reasons and plenty of applications
where you *do* want to use a char if possible, and where it would even
be *faster*.
>
Even if I were to write:

char unsigned i = 255;

, then it would still probably consume 4 bytes (or thereabouts) on most
systems.
*most* systems? Nonsense. Only on systems with a severe alignment problem.
While there might be processors out there which do suffer from this, they
are most definately NOT common.
(If you have a system which can only access 4 bytes of memory at a
time, rather than one sole byte, then it would be efficient to store the
byte value in the least significant byte of the 4 bytes, and to just ignore
the values of the subsequent 3 bytes).
1) Those systems, should they exist, are rare.
2) It would only be "efficient" from a minimum-execution-time point of view.
It's grossly inefficient regarding memory usage.
>
An easy test for this is the following:

#include <stdio.h>

int main(void)
{
struct FourBytes { char a,b,c,d; };

switch(sizeof(struct FourBytes))
{
case sizeof(char[4]):
puts("Packed nice and tight!");
break;
This "proves" nor disproves absolutely nothing.
Notwithstanding any of this, your char is going to be promoted to int every
time you lay a finger on it.
Nonsense. Again.

--
Martijn van Buul - pi**@dohd.org - http://www.stack.nl/~martijnb/
Geek code: G-- - Visit OuterSpace: mud.stack.nl 3333
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...' Isaac Asimov
Aug 13 '06 #20

P: n/a
Martijn van Buul posted:
>The extra efficiency of "unsigned int" is worth the cost of using up
another three bytes (or thereabouts).

Utter nonsense. There are plenty of reasons and plenty of applications
where you *do* want to use a char if possible, and where it would even
be *faster*.

Show me where a char is faster than an int.

Furthermore, given that a char is slower than an int, show me why you would
want to use one for storing an integer (or than creating massive arrays).

>Even if I were to write:

char unsigned i = 255;

, then it would still probably consume 4 bytes (or thereabouts) on most
systems.

*most* systems? Nonsense. Only on systems with a severe alignment
problem.

"char" doesn't have alignment requirements.

>(If you have a system which can only access 4 bytes of memory at a
time, rather than one sole byte, then it would be efficient to store
the byte value in the least significant byte of the 4 bytes, and to
just ignore the values of the subsequent 3 bytes).

1) Those systems, should they exist, are rare.

Don't a lot of Intel chips work like that? 486? Pentium?

2) It would only be "efficient" from a minimum-execution-time point of
view.

Yes indeed, it would be quicker.

It's grossly inefficient regarding memory usage.

Three bytes is a drop in the ocean.

>An easy test for this is the following:

#include <stdio.h>

int main(void)
{
struct FourBytes { char a,b,c,d; };

switch(sizeof(struct FourBytes))
{
case sizeof(char[4]):
puts("Packed nice and tight!");
break;

This "proves" nor disproves absolutely nothing.

It proves that the char's haven't been placed directly after each other in
memory. Guess why.

>Notwithstanding any of this, your char is going to be promoted to int
every time you lay a finger on it.

Nonsense. Again.

Perform arithmetic or equality on it and see what happens.

My stance is this: Never use char unless memory is scarce.

--

Frederick Gotham
Aug 13 '06 #21

This discussion thread is closed

Replies have been disabled for this discussion.