Cast de tipos primitivos..(resolvido)

Ué mas o que há de errado nisso? Agora o compilador virou mãe Dinah pra saber que o seu A e o seu B vão ter uma soma que vai caber dentro de um valor byte?

Corrijindo minha ignorância, existe sim, um sentido em o compilador não permitir isso, pois ele em tempo de compilação ou execução, não tem como reconhecer os valores e analisar o resultado daquela operação se vai estar dentro da faixa do tipo primitivo, por isso se torna obrigatório o uso de cast.

byte c = (byte)a+ b; mesmo se fizer nao vai? alais um byte aceita ate 16 bits ne?

byte c = (byte) a + b;

não vai, porque você está somente converntendo o "a" para byte
e ficaria "byte + int = int"... (pelo menos é o que eu acredito que ocorra, nesse caso)

um cast correto seria:

byte c = (byte) (a+ b);

Detalhando mais oque todos estão dizendo, olha esse exemplo
de atribuição a tipos primitivos com uma expressão:

byte x = 6; //sem problemas
byte y = 4; //sem problemas
byte z = x + y; //a soma cabe em um byte, mas ocorre um erro em tempo de compilação.

Lembre-se que um inteiro literal é sempre um tipo int implicitamente
Lembre-se também que o resultado de uma expressão que envolva
um literal do tamanho de um int, ou menor será sempre um int.

Quer ver algo mais estranho?

01 public class TesteCast {
02    public static void main(String[] args) {
03       byte a = 10; //ok
04       metodoA(a); //ok
05       metodoA(10); //ERRO!!
06    }
07 
08    private static void metodoA(byte b){
09    }
10 }

O compilador poderia ser um pouco mais inteligente ali né…
Atribuir o valor literal 10 a um byte (linha 03) o compilador consegue ver que é compatível, mas ao passar o mesmo valor literal 10 (linha 05) para um método o compilador não faz a mesma coisa…

eltonk:

01 public class TesteCast { 02 public static void main(String[] args) { 03 byte a = 10; //ok 04 metodoA(a); //ok 05 metodoA(10); //ERRO!! 06 } 07 08 private static void metodoA(byte b){ 09 }

Bom, fiz uns testes aqui e interpretei da seguinte maneira:
Por mais que atribuir um int a um byte possa acarretar numa possível perder de precisão, um byte, no fim das contas, pode ser representado por um inteiro, e não ao contrário. Assim, o compilador analisa quais inteiros, numa atribuição de int a um byte, podem ser representados em um byte.
Ex:

public class Teste { public static void main( String args[] ) { byte a = 127; // ok byte b = 128; // erro: "possible loss of precision } }
No código acima, 127 pode ser representado por um byte, mas não 128.
Quanto à passagem do parâmetro, ele não permite o 10 por incompatibilidade de tipos. Na atribuição a "a", 10 foi convertido em um byte, e a é um byte. Logo, na passagem de argumentos, é byte para byte.
Contudo, ainda fica uma pergunta:
Já que ele permite isso com int -&gt byte, porque não permitir double -&gt int?
Ex:

O compilador deveria também verificar quais valores doubles poderiam ser atribuídos a um int sem perda de precisão.
Vai entender…

O problema não é precisão, o Java tem uma regra para isso:

Toda operação realizada com int e tipos primitivos “menores” que ele retornarão um int, sempre.

Então:

byte + byte = int
short + short = int
byte - short = int
int - short = int

Se o resultado sempre será int, não tem como armazenar um int dentro de um short ou byte.

Foi o que eu disse mais acima… :roll: Mas de qualquer forma valeu… :lol: