Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr
  • RAD 스튜디오 버전별 신기능:
    12 아테네

    12.0 아테네 델파이 컴파일러

       (0 reviews)

    << 위로 이동 (최신 버전 포함 모든 버전)

    RAD 스튜디오 12.0 아테네 "새 기능 한글 요약본: 델파이 컴파일러" 입니다.
    12.0 아테네의 모든 새 기능,  강화된 기능, 버그 픽스 등에 대해서는 Docwiki의 What's New (영문 보기, 한글 자동 번역 보기) 와 관련 페이지를 보기 바랍니다.

    12.0 아테네 새 기능 요약 - 델파이 컴파일러


    다음 장은 델파이 컴파일러에서 이번에 강화되고 업데이트 된 것들이다. 

    긴 문자열 리터럴과 여러줄 문자열 리터럴

    RAD 스튜디오 12.0 아테네에서는 델파이 컴파일러가 문자열 리터럴을 처리하는 방식에 매우 중요한 변경 사항이 도입되었다. 처음부터 지금까지, 델파이의 문자열 리터럴(String Literal)은 원래의 터보 파스칼 문자열 타입, 즉 지금의 Short string 타입에 갇혀 있었다.

    이제 문자열 리터럴에 255자를 넘게 적을 수 있다. 다시 말해, 리터럴 문자열은 더 이상 클래식 파스칼의 ShortString 타입으로 제한되지 않는다. 그러나 리터럴 문자열의 길이는 여전히 코드 에디터의 한계 (즉, 한 줄당 4천자)에 따른 제한을 받게 된다는 점도 알아두자. 될 것이다. 구문(syntax) 상의 변경은 없다. 그냥 255자보다 긴 리터럴 문자열을 사용하면 된다.

    Long_multine_string.png

    델파이 언어에는 리터럴 문자열에 여러 줄 문자열을 사용할 수 있는 지원이 추가되었다. 여러 줄 문자열을 시작할 때는 따옴표 세개(''')와 새 줄을 사용한다 (따라서 따옴표 세개 바로 뒤에 텍스트가 올 수 없으며 줄을 바꿔야 한다) 그 뒤에 나오는 여러 줄로 된 소스 코드는 하나의 문자열 리터럴로 인식된다. 끝은 따옴표 세개(''')을 사용하는데, 이것은 그 줄의 맨 앞에 나와야 한다. 참고로,  첫 번째 줄에 있는 따옴표 세 개에 이어서 그 줄 안에 있는 텍스트들은 유효하지 않다는 점을 알아 두자. 상당한 차이는 예전처럼 + 기호를 사용하여 여러 줄을 한 줄 문자열로 연결할 필요가 없다는 것이다.

    Multiline_string.png

    긴 문자열 리터럴과 여러 줄 문자열 리터럴, 그리고 들여쓰기 규칙에 대한 더 많은 정보는 String Types 도움말 페이지를 참조하면 된다.

    NativeInt가 약한 별칭(Weak Alias)로 취급됨

    RAD 스튜디오 12.0 아테네에서는 한 가지 큰 컴파일러 변경이 있었다. 이것은 몇 가지 정수 타입을 오버로딩하는 작업과 32-비트와 64-비트 사이의 호환성에 주로 영향을 미친다. 델파이 컴파일러에는  NativeInt (또는 NativeUInt)라는 "부동소수점(floating)" 타입이 있다. 이 타입은 플랫폼의 비트 체계(bitness)에 맞춰지는 타입이다. 

    RAD 스튜디오 12.0 부터는, NativeInt가 "약한 별칭(weak alias)"가 된다. 즉, 사용자는 이것들 더 이상 별도의 타입으로 사용할 수 없게 되었다. 이것을 사용하는 방법과 예문을 보려면 NativeInt 페이지를 참조하면 된다.

    NaN 비교를 IEEE의 요구 사항에 맞도록 지원

    IEEE는 NaN과 연관되는 모든 비교 동작에서 false를 반환하도록 요구한다. 규칙은 다음과 같다 "IEEE 754 assigns values to all relational expressions involving NaN. In the syntax of C, the predicate x != y is True but all others, x < y, x <= y,x == y , x >= y and x > y, are False whenever x or y or both are NaN..."

    델파이 윈32 컴파일러는 이제 위 규칙에 맞게 작동한다. 우리의 Internal Data Formats 도움말 페이지를 보면 더 많은 것을 알 수 있다.

    제네릭 클래스 안의 경고(Warning) 향상

    제네릭 클래스 안에 있는 코드는 비-제네릭 코드와 같은 경고(warning)를 보여주지 못하는 상황이 있었다. 델파이 컴파일러는 이제 제네릭 타입 안에 있는 메서드 또는 제네릭 메서드를 분석하여 힌트(hint)와 경고(warning)을 일반 메서드에서와 같은 모습으로 보여준다. 예를 들면 일반 메서드에서 제공되는 메세지는 다음과 같다.

    W1035 Return value of function '%s' might be undefined
    W1036 Variable '%s' might not have been initialized
    H2077 Value assigned to '%s' never used
    H2164 Variable '%s' is declared but never used in '%s'

    다음 경고 메세지(들) 예문은 우리의 테스트 코드에서 나온 것들이다.

    Warning: W1035 Return value of function 'TEStatic.Func<T1,TResult>.[0]' might be undefined
    Warning: W1035 Return value of function 'TEStatic.Func<T1,T2,TResult>.[0]' might be undefined
    Hint: H2077 Value assigned to 'G<T>.foo' never used

    새 LLVM 심볼

    RAD 스튜디오 12.0 아테네에서는 모든  LLVM-기반 델파이 컴파일러들에 predefined symbol (사전 정의된 심볼)로 "LLVM"가 추가되었다. 그래서 LLVM 컴파일러 백엔드에 의존하는 코드를 넣기가 더 쉬워졌다. 최근 버전에서는 EXTERNALLINKER 심볼을 사용해서 똑같은 확인을 할 수 있었지만 의미가 덜 명확하고 가독성도 더 좋지 않다.

    델파이에서 uese 그래프를 GraphViz 파일로 내보내기

    델파이 컴파일러는 사용자들이 프로젝트의 구조를 이해하는 것을 도와주고 불필요한 유닛 순환 참조( circular unit references)를 피할 수 있도록 도와준다. 유닛 순환 참조는 컴파일을 느리게 하고, 언어의 다른 기능과 함께 사용하는 경우 컴파일러 자체에서 부작용이 생길 수 있다.
    uses 구문 그래프를 (별도의 구문 파악 도구가 없이) 컴파일러 수준에서 직접 생성할 수 있는 기능은 많은 상황에서 유용하며, 대체로 애플리케이션의 구조를 이해하는데 사용된다.

    델파이 컴파일러에는 새 옵션인 --graphviz 가 있다. 이 옵션은 의존성 그래프를 .gv 파일 즉 GraphViz 파일을 만들어낸다. 그러면, 다양한 도구들을 사용하여 생성된 파일을 사용할 수 있다. 심지어 온라인에서도 사용할 수 있다.

    또는, 사용자가 (개별 또는 그룹 별) 유닛을 빼고 생성하도록 할 수도 있다.
    --graphviz<실행파일이름(exename)>: .gv 파일을 출력한다.
    --graphviz-exclude:<유닛목록(UnitList)>: 특정 유닛 이름을 출력에서 제외한다.
    --graphviz-exclude:<유닛목록(UnitList)> 패턴에서는 '*' 와일드 카드를 사용할 수 있다. 또한, 여러 가지 유닛 이름 패턴을 사용하려면, <유닛목록(UnitList)> 안에서 ';'로 구분하면 된다.

    예를 들어: --graphviz-exclude:System.*;VCL.*;FMX.* 는 모든 System, VCL, FireMonkey 유닛을 제외한다.

    알아둘 점: 필요한 유닛들, System, SysInit, System.Variants는 항상 제외된다.

    예를 들어, 메인 폼 하나, 보조 대화창 하나, 데이터 모듈 하나가 있는 간단한 애플리케이션을 생각해보자. 이 유닛들이 서로 참조하려면 interface 구역 또는 implementation 구역 안에 uses 구문을 넣게된다. 이 프로젝트를 다음 명령 줄을 통해 (system 유닛을 빼고) 빌드해보자.

    dcc32 --graphviz --graphviz-exclude=System.*;Vcl.*;WinApi.* GraphTest.dpr

    그러면 아래와 같은 .gv 파일이 생성된다. 이 파일 안에 있는 style=dashed는 implementation 구역 안에 있는 uses 를 위해 사용된다:

     digraph GraphTest {
        GraphTest -> { GT_mainform GT_dialog GT_datamodule }
        GT_mainform -> { GT_datamodule GT_dialog }
        GT_datamodule
        GT_dialog -> { GT_datamodule GT_mainform } [arrowhead=open,style=dashed]
     }

    생성된 .gv 파일에는 유닛들 사이의 관계에 대한 자세한 정보가 들어있다. 일종의 텍스트 파일이며, 구문 분석을 하는 코드를 작성한다면 유닛 순환 정보만 뽑아 낼 수도 있다. 또한 이 파일을 가지고 그래프를 바로 뽑아 낼 수도 있다 (비로 대규모 프로젝트라면 매우 복잡해지겠지만 말이다). 위 예제를 통해 생성된 그래프는 다음과 같다.

    GraphViz.png

    품질 강화

    • 컴파일러에서 많은 품질 향상이 있었다. 다음과 같다:
    • 제수가 상수인 경우 div 작업에 대해 최적화된 생성 코드
    • 이제 컴파일러는 예상대로 XMLDoc 아티팩트에 대한 XML 문서 출력 디렉터리를 사용함. 예전에는 대신 C++ .hpp 폴더를 사용하고 있었음
    • 개방형 배열 파라미터를 위해 숨겨져 있던 "high bound"(상한)" 파라미터의 타입이 Integer에서 NativeInt (Integer 또는 Int64의 별칭)으로 변경되어서 타겟 CPU에 따라 달라진다. 그래서 이제는 64비트 컴파일러의 개방형 배열 파라미터 대한 Length, High, Low 값을 이제는 64비트 값으로 반환한다.
    • 이제 델파이 컴파일러는 순환 단위 참조 오류가 발생할 경우 자세한 정보를 제공한다. 이제는 오류 메시지를 확장하면,  유닛 순환 참조를 일으키는 유닛 참조의 실제 순서를 담은 추가 정보를 제공한다. 예를 들면 다음과 같다.
    [dcc32 Fatal Error] GT_mainform.pas(7): F2047 Circular unit reference   to 'GT_MainForm'
        GT_dialog.pas(7): Unit 'GT_datamodule' is used by 'GT_dialog'
        GT_mainform.pas(7): Unit 'GT_dialog' is used by 'GT_mainform'
        GT_datamodule.pas(6): Unit 'GT_MainForm' is used by
          'GT_datamodule'

     

    << 위로 이동 (최신 버전 포함 모든 버전)

     




    User Feedback

    표시할 리뷰가 없습니다.


×
×
  • Create New...

중요한 정보

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