C언어 유경험자가 Java 언어를 배울 때 주의할 점들

1. ==============================================

byte 형 변수에 int 형 상수를 대입할 수 있는가? 있다!
byte a = 100; // 문제 없음

float 형 변수에 double 형 상수를 대입할 수 있는가? 없다!
float b = 10.5; // 컴파일 에러

도대체 왜 이럴까요? 자~ 지금부터 설명해 보겠습니다.

100은 기본적으로 int형입니다. 총 32비트라는 이야기지요...
byte a에 상수값을 대입할 때, 상수값의 범위가 byte 범위 내에 있는지 조사합니다.
범위 내에 있다고 판단되면, 최하위 비트로부터 8비트를 가져옵니다.

즉, 정수형은 비트의 크기만 차이가 날 뿐 숫자를 표현하는 방법은 모두 같기 때문에 이러한 방식이 가능합니다.

그러나 부동소수점형식은 다릅니다. float(단정도)와 double(배정도)는 전체 비트 크기의 차이점 뿐만 아니라, 지수부와 가수부의 비트수, 그리고 각 표현 방식이 다르기 때문에 정수형처럼 단순하고 일관된 방식으로 값을 가져올 수가 없지요. 그래서 float b = 10.5;는 컴파일 에러가 나는 것입니다.

다음과 같이 변경해야 컴파일 에러가 나질 않습니다.

float b = 10.5f;

2. ==============================================

byte a = 10;
byte b = 20;
byte c = a + b;
왜 이 코드는 컴파일 에러(possible loss of precision)가 발생할까요?

Java 언어는 이항 산술 연산의 피연산자 중 어느 하나가 변수일 경우,  ing형보다 크기가 작은 자료형을 int형으로 형변환 후에 연산이 이루어집니다. a + b 연산시, a와 b를 int 형으로 형변환하고, 32비트 값을 c에 대입할 준비를 합니다. 그런데,  c가 byte이므로 컴파일 에러가 발생하는 것이지요.. 두 피연산자가 모두 상수일 경우에는 1번의 경우가 동일하게 적용되므로 문제가 없습니다. 위의 문제를 해결하려면 다음과 같이 하면 됩니다.

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

그러나 a + b 의 결과가 byte 형 범위를 초과하는 경우 강제적 형변환에 의해서 값 손실이 발생되겠네요..

 

3. ==============================================

Java 에서 배열은 객체입니다. C언어에서는 배열을 선언해야 하지만, Java에서는 배열 객체를 생성해야 하지요.

C 언어

int a[5]; // 선언
int a[5]={1,2,3,4,5}; // 선언과 초기화
int a[]={1,2,3,4,5}; // 선언과 초기화

Java 언어

int a[];
a = new int[5]; // 생성

int[] a;
a = new int[5]; // 생성

int a[] = new int[5]; // 생성
int[] a = new int[5]; // 생성

int[] a = {1,2,3,4,5}; // 생성과 초기화
int a[] = {1,2,3,4,5}; // 생성과 초기화
int[] a = new int[](1,2,3,4,5}; // 생성과 초기화

단, 주의할 점이 있습니다. Java 언어에서 ‘생성과 초기화’시 배열의 크기를 입력하면 안됩니다. 즉, 아래의 코드는 모두 컴파일 에러가 발생합니다.

int[5] a = {1,2,3,4,5};
int a[5] = {1,2,3,4,5};
int[] a = new int[5](1,2,3,4,5};


4. ==============================================

클래스를 선언하면서 메서드 외부에서 다른 메서드를 곧바로 실행할 수는 없습니다. 왜냐하면, 클래스는 객체를 생성하기 위한 틀이고, 이 틀로부터 객체를 생성하여 해당 객체의 메서드를 실행할 수 있지요...


5. ==============================================

인스턴스 메서드에서 자신의 객체를 생성하여 다른 인스턴스 메서드를 호출할 수는 있습니다. 그러나 일반적인 상황이 아니며, 객체 지향답지 못합니다. 안 쓰는 것이 좋습니다.