Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

[Yukon 베타] 델파이 언어: NativeInt는 약한 별칭(Weak Alias)로 취급됨


Recommended Posts

마르코 칸투 (Marco Cantu)"[Yukon Beta Blog]: NativeInt as a Weak Alias" 를 번역했습니다. (원문 작성: 2023년 10월, 번역 업데이트:  2023년 10월)

이 글은 RAD 스튜디오 소프트웨어의 출시 전 버전을 기반으로 작성되었으며 엠바카데로의 허가를 받고 작성되었다. 사전 공개 되는 기능이 반드시 GA (정식 출시, General Availability)에 포함된다는 보장은 없다.

문자열 리터럴(String Literal)에서 긴 문자열과 여러 줄 문자열 지원이 델파이 컴파일러에 추가되었다는 변화 말고도, 12.0에서는 델파이 언어에 변경 사항들이 더 있다. 이것들은 눈에 잘 띄지 않는 것들이기도 하다.

새로 도입된 약한 별칭(Weak Alias) 데이터 타입이라는 개념도 그 중 하나이다. 약한 별칭 (Weak Alias)이란 이름이 다르지만, 원래 타입을 정확히 대체하는 역할을 수행하는 타입이다. 이와 대조적으로, 일반적인(regular) 별칭(Alias)은 원래 데이터 타입과 똑같이 동작하는 새 데이터 타입을 만든다.

논의되고 있는 이슈와 이것이 도입된 이유는, 32-비트와 64-비트에서 모두 동작하도록 컴파일되는 단일 소스 코드 애플리케이션을 개발자들이 관리하는 것을 돕기 위함이다. 이와 같은 맥락 즉 코드 호환성을 위해 사용되는 데이터 타입 중 하나로 NativeInt가 있다. 델파이에서 Integer 타입은 32-비트 숫자에 맵핑되는데, 이는 타겟 CPU의 비트 체계와 관계없이 항상 그렇다. 이와 달리, NativeInt 타입은 CPU 비트 체계에 맞게 조정된다. 타겟 플랫폼이 32-비트이면 32-비트에 맵핑된다 (즉, Integer의 별칭이 된다). 그리고  타겟 플랫폼이 64-비트이면 64-비트에 맵핑된다 (즉, Int64의 별칭이 된다).  다시 말해, NativeInt는 주어진 타겟 플랫폼의 Pointer 타입에게 맵핑된다.

이는 과거에도 그랬고, 12.0에서도 그대로 똑같다. 이 변경이 영향을 주는 곳은 오직 이 타입들 사이의 타입 호환성 그리고 이러한 타입들을 기반으로 메서드를 오버로를 할 수 있는지 여부와 그 방법뿐이다. 예전까지 NativeInt는 "강한 별칭(Strong Alias)"이었고, 플랫폼에 따라 Integer 또는 Int64의 별칭이 되었다. 이로 인해, 컴파일러는 사용 사례를 구분할 수 없어서 애매한 호출(ambiguous call)로 인한 많은 문제를 발생했었다. 

이제부터 NativeInt는 "약한 별칭(Weak Alias)"이다. 즉 별도의 타입으로 또는 더 이상 사용할 수 없다. 하지만,  NativeInt를 Integer 또는 Int64 를 대신해서 사용하는 것은 여전히 가능하다. 동시에 사용하지만 않는다면 말이다. 다시 말해, 이제는 델파이에서 아래와 같이 오버로드를 하지 못한다.

procedure doIt(I: Integer); overload; 
procedure doIt(I: Int64); overload; 
procedure doIt(I: NativeInt); overload;

120_nativeint-1174760.png?w=538&ssl=1 

위 코드에서 세 번째 줄은 컴파일러 에러가 발생한다. 위 그림와 같이 "재선언(redeclaration) 에러"이다. 32-비트 정수와 64-비트 정수를 처리하는 방법을 서로 구분해서 사용하려면 아래와 같이 하거나,

procedure doIt(I: Integer); overload; 
procedure doIt(I: Int64); overload;

또는 아래와 같이 하나만 만들어서 해당 플랫폼에 적용되도록 해야 한다.

procedure doIt(I: NativeInt); overload;

이 변경 사항이 여러분의 기존 코드에 영향을 미칠 수 있다는 점을 우리는 잘 알고 있다. 잘 알아두어야 할 사항은, 이 절충안이 32-비트 코드를 손상시키지 않는 쪽을 선호하고 있다는 점이다. 하지만, 64비트에서 작동하게 하려는 경우에는 개발자가 코드를 업데이트해야 할 수도 있다는 점 역시 알아야 한다.

우리는 RTL의 데이터 구조들과 메서드들 몇 가지를 대폭 변경하여, 이 변경의 장점을 활용하고, 여러 미해결 문제를 해소했지만, 다른 한편으로 비호환성 문제 몇 가지가 생겼다. 이 변경은 장기적으로 32비트/64비트 호환성을 개선하고 유지하는 데 도움이 되기 위함이다. 따라서, 우리는 이 변경이 기존 코드 일부에 영향을 미칠 수 있음에도 불구하고(하지만, 매우 오래된 32-비트 전용 코드에는 영향을 주지 않음), 이 변경이 델파이 언어의 미래를 위해 중요하다고 생각했다.

델파이 컴파일러 12.0에는 실제로 더 많은 것들이 들어 있다. 그러니 이 블로그를 팔로우하고 11월 10일에 열리는 '새 버전' 이벤트에 등록하여 RAD 스튜디오, 델파이 및 C++빌더 12.0에 대해 자세히 알아보기를 바란다.

이 글은 RAD 스튜디오 소프트웨어의 출시 전 버전을 기반으로 작성되었으며 엠바카데로의 허가를 받고 작성되었다. 사전 공개 되는 기능이 반드시 GA (정식 출시, General Availability)에 포함된다는 보장은 없다.

이 댓글 링크
다른 사이트에 공유하기

이 토의에 참여하세요

지금 바로 의견을 남길 수 있습니다. 그리고 나서 가입해도 됩니다. 이미 회원이라면, 지금 로그인하고 본인 계정으로 의견을 남기세요.

Guest
이 토픽(기고/질문)에 답하기

×   서식있는 텍스트로 붙여넣기.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   이전에 작성한 콘텐츠가 복원되었습니다..   편집창 비우기

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.