Pessoal, preciso descobrir se uma variável do tipo int é nula, tento fazer da seguinte forma:
if(i == null){
}Mas logicamente dá erro. Tem como isso ser feito em Java?
primitivos em java NUNCA são nulos.
se sua variavel é de instancia, ela é inicializada por default com o valor 0. vc pode testar isso.
se for uma variavel de metodo, vc é obirgado a inicializa-la com algum valor para poder testa-la.
a logica é essa.
mas se mesmo assim vc quer testar com null, vc pode usar o objeto Integer.
[]´s
se vc criar uma variavel do tipo int, e não inicializar o compilador vai reclamar e vai dar erro, e tipos primitivos vc não pode inicializar com null, no seu caso ele será zero
Usa Integer.
Com Integer você pode tirar e colocar tipos int e pode testar se é null.
int numeroPrimitivo = 2;
Integer numeroObjeto = numeroPrimitivo;
numeroPrimitivo = numeroObjeto;
Só para exemplificar o que já foi explicado
Integer i=null;//i como Integer pode ser null
if(i == null){
}Vlw pessoal, vou trabalhar aqui para alterar e usar Integer.
Para comparar objetos Integer use o equals e não o == pois esse ultimo apenas ve se as instâncias são para o mesmo objeto.
Bem lembrado,
pra mim com inteiros nunca fez diferença, pois sempre uso primitivos, porém com String…
acho que string deveria ser tratada como primitiva…
[quote=fabioissamu]Bem lembrado,
pra mim com inteiros nunca fez diferença, pois sempre uso primitivos, porém com String…
acho que string deveria ser tratada como primitiva…[/quote]
Tem um ótimo motivo para String não ser variável primitiva: ela não se comporta como uma. Uma variável tem tamanho, operações e comportamentos fixos e bem definitos, com objetos você tem uma maior flexibilidade. Para se ter algo parecido com String em variáveis primitivas, terias que usar um array de char, mas mesmo esse é um objeto.
Eu ainda acho bom que String seja objeto, o modelo do C para esse tratamento de caracteres me desagrada.
Até!
[quote=maquiavelbona]
Eu ainda acho bom que String seja objeto, o modelo do C para esse tratamento de caracteres me desagrada.
Até![/quote]
mais um que sofreu usando strcpy e tratando “\0” huahuauah
Eu também sofri. Mas foi pra aprender que não se deve usar gets ou fgets e coisarada quando não sei o tamanho do array de chars que vou usar.
Mas concordo com você, maquiavelbona. Acho que os primitivos que fiquem como primitivos e ninguém mais entra.
Sem contar que é muito mais facil usar um nextLine() do que ficar trabalhando com scanfs, gets e fgets um char[]. Na minha opinião pelo menos. Outra coisa são os métodos. Só tive um problema até hoje (na verdade tem um tópico meu sobre isso, um pouco mais abaixo). Eu lia um inteiro, um inteiro uma String. Tudo nessa ordem, porém, passava reto na hora de ler a String (com nextLine()). O que tive que fazer? Usar um next() pra “limpar o buffer” antes de mostrar a frase do nome. Vi numa thread da Sun que havia problema desse tipo ://
Alguém sabe alguma maneira melhor de resolvê-lo?
Galera, eu vim de
VB , ASP, PHP, ActionScript, JavaScript,
um pouco de py um pouco de lua e no final do ano passado Java
nota se que o tipo de comparação para string eu sempre fiz com ==
então para mim é um choque comparar string com “equals” já que
para toda linguagem script string é um tipo muito básico.
se bem que VB não é script, aliás hoje não é nada 
Se não me engano até em pascal é comparado com ==
foge a este padrão C e Java
Aos iniciantes a String é de fato um OBJETO então a concatenação sofre uma penalidade gigante na concatenação.
Ou seja,
for(int i=0;i<3000;i++){
a+="minha string parte " + i;
}
não é uma operação muito rápida, usem StringBuilder, StringBuffer, etc.
[quote=dedejava]Eu lia um inteiro, um inteiro uma String. Tudo nessa ordem, porém, passava reto na hora de ler a String (com nextLine()). O que tive que fazer? Usar um next() pra “limpar o buffer” antes de mostrar a frase do nome. Vi numa thread da Sun que havia problema desse tipo ://
Alguém sabe alguma maneira melhor de resolvê-lo?[/quote]
Tem uma classe Scanner, acho que vc está lendo da entrada padrão.
import java.util.Scanner;
public class UsandoScanner {
public static void main(String args[]){
int a,b;
String c;
Scanner scanner = new Scanner(System.in);
a=scanner.nextInt();
b=scanner.nextInt();
c=scanner.next();
System.out.println("a="+a);
System.out.println("b="+b);
System.out.println("c="+c);
}
}[quote=fabioissamu]…
Aos iniciantes a String é de fato um OBJETO então a concatenação sofre uma penalidade gigante na concatenação.
Ou seja,
for(int i=0;i<3000;i++){
a+="minha string parte " + i;
}
não é uma operação muito rápida, usem StringBuilder, StringBuffer, etc.[/quote]
Não que a dica dele seja inútil, mas nas últimas versões, o compilador trata esse tipo de operação com StringBuilder. Como? Teste esse código do colega compilando e logo depois rodando com javap. Temos algumas surpresas com a otimização que o compilador faz antes de rodar na JVM. Um exemplo de código que podem ver está nesse tópico: http://guj.com.br/posts/list/77452.java#409347
Até!
Fiz um teste rápido e para mostrar o que eu disse. Olhem a classe:
Teste.java
public class Teste{
public static void main(String... args){
String a="";
for(int i=0;i<3000;i++){
a+="minha string parte " + i;
}
}
}
Depois de javac Teste.java e javap -v Teste, temos no fim do resultado:
[code]public static void main(java.lang.String[]);
Code:
Stack=2, Locals=3, Args_size=1
0: ldc #2; //String
2: astore_1
3: iconst_0
4: istore_2
5: iload_2
6: sipush 3000
9: if_icmpge 42
12: new #3; //class java/lang/StringBuilder
15: dup
16: invokespecial #4; //Method java/lang/StringBuilder."":()V
19: aload_1
20: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
23: ldc #6; //String minha string parte
25: invokevirtual #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
28: iload_2
29: invokevirtual #7; //Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
32: invokevirtual #8; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
35: astore_1
36: iinc 2, 1
39: goto 5
42: return
LineNumberTable:
line 3: 0
line 4: 3
line 5: 12
line 4: 36
line 7: 42
StackMapTable: number_of_entries = 2
frame_type = 253 /* append /
offset_delta = 5
locals = [ class java/lang/String, int ]
frame_type = 250 / chop */
offset_delta = 36
}
[/code]
Dêem uma olhada na linha 12, 20 e 32. O compilador é inteligente o suficiente para saber que ele poderia usar StringBuilder para otimizar esse processo.
Até!
Eu não sabia que o compilador já fazia isso, eu sempre uso o StringBuilder, vou deixar esse trabalho pro compilador fazer sózinho agora.
Apenas completando: se o numero couber em um byte ou short ( ex: 100 ), o == vai retornar true mesmo que para referências diferentes.
Essa é mais uma daquelas “coisas que odeio em Java”.
Não entendi…
ou não quero entender
Integer a = 100;
Integer b = 20;
if(a==b){
//passa por aqui?
//não
}Imprime “Sim”
Integer a = 100;
Integer b = 100;
if (a == b) {
// passa por aqui?
System.out.println("Sim");
} Integer a = new Integer("100");
Integer b = new Integer("100");
if (a == b) {
// passa por aqui?
//Não
}[quote=fabioissamu]Não entendi…
ou não quero entender
Integer a = 100;
Integer b = 20;
if(a==b){
//passa por aqui?
}
[/quote]
Não ele quis dizer dois Objetos diferentes com valores iguais que caibam em um byte
Apesar que dessa eu também não sabia.