«

Good evening!

I'm using variables to count from 0 to 4 in a recursion, and I just
realized that I could save a lot of memory (and computational time?) by
using a BYTE instead of an int.

But, having an assignment like

BYTE b = 5, bb = 10;
b+= bb;

the vc8-compiler puts out a warning message C4244 saying: "conversion
from int to byte, possible loss of data (or similar"). So, I guessed
that the += operator converts all stuff to int and then back to BYTE?

If I replace the second line by b = b + bb, the warning message
disappears, but I prefer the += operator which saves memory allication.

Any clues?

Joachim

Joachim Börger wrote:

> BYTE b = 5, bb = 10;
> b+= bb;

> If I replace the second line by b = b + bb, the warning message
> disappears, but I prefer the += operator which saves memory allication.

Google "premature optimization".

At the level of bits, bytes, and integers, there's almost nothing you can do
to individual statements that an optimizing compiler won't do better. And
modern CPUs overwhelmingly optimize in favor of 32-bit integers. You cannot
guess that 8 bit unsigned values will ever be faster or smaller, when they
risk wasting 75% of the CPU's pipeline.

And += is never smaller or faster than = x +. You should learn to write
clear code that's easy to maintain. Someone reading your code shouldn't be
confused by BYTE types on trivial values with no application-specific reason
to only hold 8 bits.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Joachim Börger <> wrote:

> I'm using variables to count from 0 to 4 in a recursion, and I just
> realized that I could save a lot of memory (and computational time?) by
> using a BYTE instead of an int.

(I'm assuming that BYTE is just a typedef or define for unsigned char.)

The computational time would likely be slower, not faster, but yes you
might save a few bytes of space. Two questions, are you actually running
out of space? Is this particular function really the biggest space hog
you have in your system?

> But, having an assignment like
>
> BYTE b = 5, bb = 10;
> b+= bb;
>
> the vc8-compiler puts out a warning message C4244 saying: "conversion
> from int to byte, possible loss of data (or similar"). So, I guessed
> that the += operator converts all stuff to int and then back to BYTE?

This I don't know.

> If I replace the second line by b = b + bb, the warning message
> disappears, but I prefer the += operator which saves memory allication.

For intrinsic types, there is likely no advantage at all in using +=
over = x + y.

In article <>,
says...
> Good evening!
>
> I'm using variables to count from 0 to 4 in a recursion, and I just
> realized that I could save a lot of memory (and computational time?) by
> using a BYTE instead of an int.

Maybe. It's usually a time vs. space situation: if the compiler really
does pack the variables to save any space, it'll cost extra time. Unless
you can convert quite a few items, the space savings will be
insignificant at best (and probably nonexistent) but you're still likely
to lose some speed -- the compiler has to either override the
instruction operand size (bigger, potentially slower instruction) or
else add an extra instruction to mask the result to the correct result
size. Depending on processor, you also stand a chance of creating a
false dependency that will prevent instructions from executing in
parallel, even though they really operate on independent data.

> But, having an assignment like
>
> BYTE b = 5, bb = 10;
> b+= bb;
>
> the vc8-compiler puts out a warning message C4244 saying: "conversion
> from int to byte, possible loss of data (or similar"). So, I guessed
> that the += operator converts all stuff to int and then back to BYTE?

Yes, that's probably what you're seeing.

> If I replace the second line by b = b + bb, the warning message
> disappears, but I prefer the += operator which saves memory allication.

What makes you think that? It probably makes no difference to the
generated code -- though, as mentioned above, using ints throughout is
probably your best bet.

--
Later,
Jerry.

The universe is a figment of its own imagination.

On Jan 28, 4:44 am, Joachim Börger <fallerhaeusc...@gmx.net> wrote:
> Good evening!
>
> I'm using variables to count from 0 to 4 in a recursion, and I just
> realized that I could save a lot of memory (and computational time?) by
> using a BYTE instead of an int.
>
> But, having an assignment like
>
> BYTE b = 5, bb = 10;
> b+= bb;
>
> the vc8-compiler puts out a warning message C4244 saying: "conversion
> from int to byte, possible loss of data (or similar"). So, I guessed
> that the += operator converts all stuff to int and then back to BYTE?
>
> If I replace the second line by b = b + bb, the warning message
> disappears, but I prefer the += operator which saves memory allication.
>
> Any clues?
>
> Joachim

with unsigned char I do not recieve that warning on vc7.

Joachim Börger wrote:
>
> BYTE b = 5, bb = 10;
> b+= bb;
>
> the vc8-compiler puts out a warning message C4244 saying: "conversion from
> int to byte, possible loss of data (or similar"). So, I guessed that the
> += operator converts all stuff to int and then back to BYTE?

Write declaration of BYTE here and try to compile your code to asm.

--
Maksim A Polyanin

On 28 Jan., 02:44, Joachim Börger <fallerhaeusc...@gmx.net> wrote:
> Good evening!
>
> I'm using variables to count from 0 to 4 in a recursion, and I just
> realized that I could save a lot of memory (and computational time?) by
> using a BYTE instead of an int.
Are you sure? How did you measure your savings?
>
> But, having an assignment like
>
> BYTE b = 5, bb = 10;
> b+= bb;
>
> the vc8-compiler puts out a warning message C4244 saying: "conversion
> from int to byte, possible loss of data (or similar"). So, I guessed
> that the += operator converts all stuff to int and then back to BYTE?
This is exactly what happens - as mandated by the standard.

>
> If I replace the second line by b = b + bb, the warning message
> disappears, but I prefer the += operator which saves memory allication.

There is no saving of anything, and the disappearance of the warning
is simply a result of the compiler having an inconsistent view of what
warnings to issue.
I would go for the statements with the clearest demonstration of
intent - and for me that is operator +=.

/Peter

On Jan 28, 3:10 am, "Phlip" <phlip...@yahoo.com> wrote:
> And += is never smaller or faster than = x +.

One should take it easy with general statements like that, for built-
in types that is probably true, but for user-specified types the
difference can be huge.

--
Erik Wikström

On Jan 28, 10:08 pm, "peter koch" <peter.koch.lar...@gmail.com> wrote:
> On 28 Jan., 02:44, Joachim Börger <fallerhaeusc...@gmx.net> wrote:> Good evening!
>
> > I'm using variables to count from 0 to 4 in a recursion, and I just
> > realized that I could save a lot of memory (and computational time?) by
> > using a BYTE instead of an int.Are you sure? How did you measure your savings?
>
> > But, having an assignment like
>
> > BYTE b = 5, bb = 10;
> > b+= bb;
>
> > the vc8-compiler puts out a warning message C4244 saying: "conversion
> > from int to byte, possible loss of data (or similar"). So, I guessed
> > that the += operator converts all stuff to int and then back to BYTE?This is exactly what happens - as mandated by the standard.
>
>
>
> > If I replace the second line by b = b + bb, the warning message
> > disappears, but I prefer the += operator which saves memory allication.There is no saving of anything, and the disappearance of the warning
> is simply a result of the compiler having an inconsistent view of what
> warnings to issue.
> I would go for the statements with the clearest demonstration of
> intent - and for me that is operator +=.
>
> /Peter

VC compilers are good optimizers 4 such simple cases. no need to think
about it.

peter koch schrieb:
>
> On 28 Jan., 02:44, Joachim Börger <fallerhaeusc...@gmx.net> wrote:
>> Good evening!
>>
>> I'm using variables to count from 0 to 4 in a recursion, and I just
>> realized that I could save a lot of memory (and computational time?) by
>> using a BYTE instead of an int.
> Are you sure? How did you measure your savings?

Well, one BYTE (typedef'd as unsigned char) is one byte, while one
typically needs 4 bytes. I need variables counting from 0 to 4 to store
search states in a backtracking algorithm, and storing 1 Mio states with
about 32 variables each (for a card game) can be much cheaper using
bytes than ints.

But I actually overcame the situation using ints and a reformulation of
my algorithm hich needs far fewer states. Now, I've got new problems

Thanks for Your hints anyway! Ciao,

Joachim