위키원
"D 언어"의 두 판 사이의 차이
(새 문서: == 개요 == 2001년 12월에 처음 발표된 후, 2007년 1월에 정식 발표된 컴파일 언어이자 멀티 패러다임 프로그래밍 언어. C++이 본래 C언어를 대체...) |
leejia1222 (토론 | 기여) |
||
| (사용자 4명의 중간 판 125개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | + | [[파일:D 언어 로고.png|썸네일|200픽셀|'''D 언어''']] | |
| − | 2001년 12월에 처음 발표된 후, 2007년 1월에 정식 발표된 컴파일 언어이자 멀티 패러다임 프로그래밍 | + | |
| − | C++이 본래 | + | '''D 언어'''(D Language)는 2001년 12월에 처음 발표된 후, 2007년 1월에 정식 발표된 컴파일 언어이자 멀티 패러다임 프로그래밍 언어이다. [[C++]]이 본래 [[C 언어]]를 대체하기 위한 언어로 출발했듯이 D 언어는 C++을 대체하기 위한 목적으로 출발한 언어이다. |
| + | |||
| + | ==개요== | ||
| + | D 프로그래밍 언어는 컴퓨터 [[소프트웨어]]를 만들기 위한 범용 [[프로그래밍 언어]] 중 한 가지이다. 범용이라 표현하는 이유는 어느 한 분야에 국한되지 않고 여러 분야에 사용할 수 있도록 설계되었다는 뜻이다. D 언어를 이용해 게임을 만들거나, 서버 애플리케이션을 만들거나 혹은 윈도우 애플리케이션도 만들 수 있다. D 언어는 미국의 컴퓨터 프로그래머인 [[월터 브라이트]](Walter Bright)에 의해 첫 버전이 탄생했다. 처음에는 상용 [[컴파일러]]였으나 소스 코드를 누구나 열람하고 수정할 수 있게 공개한 이후, 유명한 부스트 라이브러리 개발자인 [[안드레 알렉산드레스쿠]](Andrei Alexandrescu) 외 다양한 개발자들이 D 언어의 개발에 합류하게 된다. 오랜 기간 동안 [[구글]], [[페이스북]] 등의 거대 IT 기업에 종속되지 않고 커뮤니티 중심으로 운영되다가, D 언어의 발전 가속과 활성화를 위해 D 언어 재단을 설립 후 이를 중심으로 계속 개발되고 있다. 2001년에 공개되어서 C++의 리엔지니어링으로 기원하였으나 D는 해당 언어와는 별개의 언어이다. 일부 핵심 C++ 기능들을 다시 설계하였으며 [[자바]], [[파이썬]], [[루비]], [[C#]], [[에펠]]과 같은 다른 언어들의 특징들을 공유하기도 한다. 관용적인 D 코드는 동등한 C++ 코드보다 크기가 짧더라도 C++만큼 속도가 빠른 것이 보통이다. 이 언어는 전반적으로 메모리 안전에 속하지 않으나 메모리 안전을 검사하도록 설계된 선택적 속성을 포함한다.<ref>D (프로그래밍 언어) 위키백과 - https://ko.wikipedia.org/wiki/D_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4)</ref><ref>〈[https://wikidocs.net/73120 D 프로그래밍 언어란]〉, 《위키독스》, 2020-06-09</ref> | ||
| + | |||
| + | ==역사== | ||
| + | ;D 1.0 | ||
| + | 최초의 네이티브 C++ 컴파일러였던 Zortech C++(Symantec C++이 되었다가 DMC++로 변천되어옴)의 메인 개발자였던 월터 브라이트는 C++의 복잡도를 줄이고 현대적인 언어 개념들을 포함한 언어를 만들기로 했고 1999년부터 작업을 시작해 2001년 12월 8일에 첫 번째 버전을 발표한다. 처음에는 마스 언어라고 이름 붙였지만 그의 동료 중 한 명이 계속 D라고 부르면서 D로 이름을 바꾸게 되었다는 사연이 있다. 버전업이 매우 느렸기 때문에 D 1.0 버전이 발표된 건 2007년 1월 2일이 되어서였다. 범용 시스템 프로그래밍 언어인 C++을 대체하는 것을 목적으로 만들어졌으므로 C++과 같이 기계어 [[컴파일]]이 되는 언어였으며 파이썬, 자바, C# 등 현대화된 메이저 언어들의 영향을 많이 받았다. 그러면서도 최근의 현대 언어들과 같이 인터프리터나 [[가상머신]]으로 실행되는 구조가 아니었으므로 퍼포먼스 지향적이어서 처음에는 많은 기대를 받았다. D는 표준 런타임 라이브러리로서 포보스가 존재했지만 D 커뮤니티는 포보스 라이브러리의 느린 발전 속도에 만족하지 못했다. 언어와 개발 환경의 느린 발전 속도는 D 언어가 원래 오픈소스가 아니고 디지털 마스에 카피 라이트가 있고 상용 언어를 목표로 했기 때문이었다. D 사용자 커뮤니티는 포보스와는 별도로 오픈소스로서 존재하는 런타임 라이브러리를 만들기로 했고 탱고 라이브러리가 발표되었다. 탱고는 포보스보다 다양한 기능을 제공했으며 커뮤니티가 참여해서 만들어졌기 때문에 발전 속도가 빨랐다. D 언어에 관한 책은 거의 없지만 "D 프로그래밍 위드 탱고"라는 입문서가 출판될 정도였다. 그러나 이런 상황은 커뮤니티 자체를 분열시키는 결과를 낳았고 언어 자체의 발전 속도를 저하시키고 인터넷상의 정보를 파편화시켜 D 언어를 지탱한 표준 런타임 라이브러리가 분열되고 말았다. 이 때문에 정보가 많지도 않은 상황에서 입문자들은 전혀 다른 스타일의 런타임 라이브러리에 혼란을 겪어야 했다. 비슷한 상황을 맞은 파이썬을 보면 구글이 창시자를 영입하고 재단을 출범해 로드맵을 조정하는 것과 대조적이었다. 결국, 월터 브라이트는 D 1.0이 실패라고 판단하고 언어 자체를 재설계하기로 결정했다. D의 행보에 실망한 커뮤니티는 대부분 흩어지고, 초반에 받았던 세간의 관심으로부터도 멀어졌다.<ref name="D언어">D언어 나무위키 - https://namu.wiki/w/D%EC%96%B8%EC%96%B4</ref> | ||
| + | |||
| + | ;D 2.0 | ||
| + | D 2.0 버전을 줄여서 D2로 알려진 것이 바로 D 언어를 가리킨다. C++ 그룹 중 한 명이며 모던 C++ 디자인이라는 책에서 템플릿 메타 프로그래밍에 기반한 정책 기반 설계라는 개념을 정립한 것으로 널리 알려진 안드레이 알렉산드레스쿠(Andrei Alexandrescu)가 D2 프로젝트에 공동 설계자로서 합류하게 된다. 그가 합류하면서 D는 메타 프로그래밍 언어로서의 성향이 매우 강해졌으며 관련된 언어 상 기능들이 다수 추가되었다. 2007년 6월 17일에 정식 발표되면서 D2를 D2라고 불리지 않으며 그냥 D라고 부르게 된다. 1.0 버전으로 발표된 지 5개월밖에 안 된 기존의 D 언어는 바로 버려진 것은 아니고 꾸준히 버전업되면서 버그 수정(안정화 작업) 정도로만 유지되었다가 2012년 12월 31일에 발표된 1.076 버전을 마지막으로 지원 중단되었다. D 언어로 불리는 2.0 버전은 오픈소스 프로젝트로서 [[깃허브]]에 전체 프로젝트가 공개되어 있으며 커뮤니티가 활발하게 기여를 하고 있다. 핵심 개발자인 안드레이 알렉산드레스쿠는 페이스북에서 연구자로 소속되어 있으며 페이스북 내에서 D를 사용한 프로젝트를 진행하고 있다고 한다. [[페이스북]]은 주로 HHVM을 사용하고 있는데 구글 내에서 파이썬이 그랬던 것처럼 메이저 IT 회사 중 하나인 페이스북 내에서 어느 정도의 입지를 가지게 되느냐에 따라 향후 D의 운명이 결정될 가능성이 크다. 그러나 알렉산드레스쿠는 D 언어 재단에 더 힘을 쏟기 위해 페이스북을 그만두었다. 본인도 많은 고민 끝에 내린 결정이라고 한다.<ref name="D언어"></ref> | ||
| + | |||
| + | ==특징== | ||
| + | 고수준 모델링 지원을 위한 기반을 제공한다. 실행 전 컴파일을 미리 해 둬야 하는 언어이며, 높은 성능을 보여준다. 정적 타입(static typing) 특성을 갖는다. 모든 타입은 컴파일 시점 전에 결정된다. 예를 들어, 값을 반환하는 함수 등에서 어떤 타입을 반환하는지 명확히 알 수 있다. 운영체제와 하드웨어가 제공하는 API를 직접 제어할 수 있다. 컴파일에 드는 소요시간이 짧다. 메모리 안전을 보장하는 제한된 D 언어 환경을 제공한다. 프로그램 유지 및 보수에 편리하며, 이해하는데 어려움이 없는 코드를 작성할 수 있다. 갑자기 어려워지는 부분 없이, 일정한 코딩 난이도 상승 속에서 배워 갈 수 있는 언어이다(C나 자바와 비슷한 문법 구조이다). C 응용 프로그램/라이브러리와의 호환성을 갖는다. C++ 응용 프로그램/라이브러리와의 제한적 호환성을 갖는다. 다양한 프로그래밍 패러다임을 포함하고 있다.(명령형, 구조형, 객체지향, 제네릭, 함수형 프로그래밍, 어셈블리가 존재한다) 언어에 내장된 오류 탐지 기능이 있다.<ref>〈[https://tour.dlang.org/tour/kr/welcome/welcome-to-d D 프로그래밍 언어의 세계에 오신 걸 환영합니다.]〉, 《D 프로그래밍 언어》</ref> | ||
| + | |||
| + | ===종류=== | ||
| + | ;DMD | ||
| + | 디지털 마스 D 컴파일러(Digital Mars D compiler)의 약자이며 D 언어 재단에서 공식적으로 유지 보수&배포 중인 레퍼런스 컴파일러이다. 기존에는 C++로 구현되었으나 2015년 11월 3일에 2.069.0 버전부터 프런트엔드를, 뒤이어 2018년 11월 11일에 백엔드를 D로 구현하는 데 성공했다. D 언어로 DMD를 작성했다는 뜻에서 DDMD라 부르기도 한다. D 언어 재단에서 제공하는 표준 레퍼런스 컴파일러다. 빌드 속도는 GDC와 LDC보다 빠르다. 빌드 한 결과물의 퍼포먼스는 GDC나 LDC에 비해 떨어진다. [[윈도우]], [[리눅스]], [[맥]] 모두 지원하며, 윈도우에서 설치하는 게 제일 쉽다.<ref name="D언어"></ref> | ||
| + | |||
| + | ;GDC | ||
| + | 이름에서 추측할 수 있듯이 GCC 기반의 D 컴파일러이다. 예전에는 DMD의 심각한 성능 문제나 [[디버깅]]의 어려움 때문에 커뮤니티에서는 DMD를 포기하고 GDC를 쓰라는 말이 나오기도 했었지만 꾸준한 DMD의 성능 개선으로 모두 옛날이야기가 됐다. 하지만 2017년을 기준으로 GCC가 D를 공식으로 포함했기 때문에 그대로 GCC를 쓸 수 있게 되었다. 버전 릴리스는 가장 느리다. 빌드 속도는 DMD와 비슷하다.<ref name="D언어"></ref> | ||
| + | |||
| + | ;LDC | ||
| + | LLVM를 기반으로 둔 D 컴파일러이다. DMD 컴파일러가 [[안드로이드]]와 [[iOS]] 환경에 대한 공식적인 지원이 없는데 비해 상대적으로 모바일 환경에 대한 지원이 활성화되어 있다. 1.18버전부터 안드로이드용 [[컴파일러]] [[바이너리]]를, 1.20버전부터 iOS(tvOS · watchOS 포함)를 위한 코드젠을 제공하기 시작했다. 그 외에도 D 커뮤니티 내 몇몇 능력자들의 [[포크]](Fork)나 사이드 프로젝트를 통한 기여가 많은 편이다. C++ 라이브러리를 바인딩 코드 없이 그대로 가져와 쓸 수 있는 LDC 컴파일러(Calypso)나 웹 어셈블리 애플리케이션 개발을 위한 라이브러리 등이 존재한다.<ref name="D언어"></ref> | ||
| + | |||
| + | ;DUB | ||
| + | DUB은 D 언어를 위한 빌드 프로그램이다. 단순히 프로젝트 빌드뿐만 아니라 code.dlang.org에 게시된 제3자 라이브러리를 가져와 쓸 수 있도록 패키지 매니저의 역할(파이썬의 Pypi, Lua의 LuaRocks 같은 셈이다)도 하며 DMD, GDC, LDC로의 선택이나 플래그도 dub.json 또는 dub.sdl 파일(프로젝트 설정 파일)을 통해 쉽게 작성할 수 있다. 원래 DUB은 D 언어 재단에서 공식적으로 개발하는 [[소프트웨어]]가 아니다. DUB 역시 Vibe.d 프로젝트의 커뮤니티로부터 공존해오고 있는 프로젝트이지만 사실상 D 언어로 스크립트 수준의 작은 프로그램이 아니라 외부 라이브러리, 이를테면 바인딩이나 3th Party library를 쓸 일이 생긴다면 DUB은 필수이다. D 유저들 사이에서는 암묵적인 표준 소프트웨어나 다름없는 셈. 이미 D 언어 재단에서도 공식적으로(official) 밀어주는 모습을 보여준다. 얼마 전까지만 해도 DUB은 바이브 커뮤니티 사이에서 따로 배포되어 왔었으나 러스트 컴파일러 패키지에 카고가 기본적으로 포함되어 있는 것을 D 유저들이 의식하고 DMD 컴파일러 패키지에도 DUB을 포함하자는 의견이 있었다. 2.72.x 버전부터 포함되어 함께 배포되고 있다.<ref name="D언어"></ref> | ||
| + | |||
| + | ===활용=== | ||
| + | ;예시 1 | ||
| + | import std.stdio; // Let's get going! | ||
| + | |||
| + | void main() | ||
| + | |||
| + | { | ||
| + | :writeln("Hello World!"); | ||
| + | |||
| + | } | ||
| + | 컴파일하고 실행하려면 이 텍스트를 main.d라는 파일로 저장해야 한다. 명령행에서 dmd main.d를 실행하여 프로그램을 컴파일한 후 ./main 을 실행하여 bash 쉘에서 프로그램을 실행하거나 윈도우에서 실행 파일을 누를 수 있다.<ref name="D 언어 시작하기">〈[https://riptutorial.com/ko/d D 언어 시작하기]〉, 《RIP 튜토리얼》</ref> | ||
| + | |||
| + | ;예시 2 | ||
| + | 고전적인 "Hello, world" 인쇄 프로그램을 만들려면 다음 코드가 포함된 텍스트 편집기로 hello.d 파일을 만든다.<ref name="D 언어 시작하기"></ref> | ||
| + | |||
| + | import std.stdio; | ||
| + | |||
| + | void main() | ||
| + | |||
| + | { | ||
| + | :writeln("Hello, World!"); //writeln() automatically adds a newline (＼n) to the output | ||
| + | |||
| + | } | ||
| + | |||
| + | ;설명 | ||
| + | import std.stdio | ||
| + | |||
| + | 이 행은 표준 라이브러리 모듈 std.stdio가 정의된 함수가 사용될 것임을 컴파일러에 알린다. 컴파일러가 모듈을 찾을 위치를 알고 있는 한 모든 모듈을 가져올 수 있다. 많은 기능이 D의 방대한 표준 라이브러리의 일부로 제공된다. | ||
| + | |||
| + | |void main() { | ||
| + | |||
| + | 이 줄은 main 함수를 선언하고 void를 반환한다. C 및 C ++과 달리 D를 사용하면 main이 void 유형이 될 수 있다. 함수 main은 프로그램의 시작점이므로 특별하다. 함수의 이름은 문자로 시작하고 문자, 숫자 및 밑줄로 구성된 모든 것이 될 수 있다. 예상되는 매개 변수는 쉼표로 구분된 변수 이름 및 해당 데이터 유형의 목록이다. 함수가 반환할 것으로 예상되는 값은 기존 데이터 형식이 될 수 있으며 함수 내의 return 문에서 사용된 식의 형식과 일치해야 한다. 중괄호 { … }는 쌍으로 사용되어 코드 블록이 시작하고 끝나는 곳을 나타낸다. 그것들은 많은 방법으로 사용될 수 있지만, 이 경우에는 함수가 시작하고 끝나는 곳을 나타낸다. | ||
| + | |||
| + | writeln("Hello, World!"); | ||
| + | |||
| + | writeln 은 std.stdio에서 선언된 함수로 해당 악기를 stdout로 쓴다. 이 경우 인수는 "Hello, World"이며 콘솔에 기록된다. ＼n , ＼r 등과 같이 C의 printf로 사용되는 것과 비슷한 다양한 형식의 문자가 사용될 수 있다. 모든 문장은 세미콜론으로 끝나야 한다. | ||
| + | |||
| + | //writeln() automatically adds a newline (＼n) to the output | ||
| + | |||
| + | 주석은 코드를 읽는 사람에게 무언가를 나타 내기 위해 사용되며 컴파일러가 공백처럼 취급한다. 위의 코드에서 이것은 주석이다. 이것은 컴파일러에서 무시되는 코드 조각이다. D에서 논평하는 방법으로는 아래와 같은 세 가지가 있다. | ||
| + | |||
| + | *// : 같은 줄의 모든 텍스트를 // 뒤에 주석 처리한다. | ||
| + | */* comment text */ : 여러 줄 /* comment text */에 유용하다. | ||
| + | */+ comment text + : 여러 줄 주석 | ||
| + | 이것은 코드의 기능 / 조각이 동료 개발자에게 무엇을 전달하는지를 알려주는데 매우 유용하다.<ref name="D 언어 시작하기"></ref> | ||
| + | |||
| + | ;프로그램 컴파일 및 실행 | ||
| + | 이 프로그램을 실행하려면 코드를 실행 파일로 컴파일해야 한다. 이것은 컴파일러의 도움으로 수행할 수 있다. DMD를 사용하여 컴파일하려면 참조 D 컴파일러에서 터미널을 열고 생성 한 hello.d 파일의 위치로 이동한 후 다음을 실행한다. | ||
| + | |||
| + | dmd hello.d | ||
| + | |||
| + | 오류가 발견되지 않으면 컴파일러는 소스 파일의 이름을 따서 명명된 실행 파일을 출력한다. 이제 다음을 입력하여 실행할 수 있다. | ||
| + | |||
| + | ./hello | ||
| + | |||
| + | 실행 시, 프로그램은 Hello, World!로 인쇄한 후 줄 바꿈이 뒤따른다.<ref name="D 언어 시작하기"></ref> | ||
| + | |||
| + | ===문제점=== | ||
| + | C++을 대체하기 위한 D 언어가 쓰레기 수집기(GC)를 내장함으로써 발생하는 성능적인 비용 때문에 게임과 같이 빠른 연산이 필요한 곳, 특히 60FPS을 목표로 렌더링 해야 하는 고사양 게임 개발에 사용하기에는 부적합하다는 의견이 중론이다. 물론 @nogc로 쓰레기 수집기의 사이클을 어느 정도는 회피할 수 있다고는 하지만 언어적 차원에서 지원되는 기능이라 GC를 사용하지 않았을 때의 제약점이 생긴다. 그래서 GC를 싫어하는 D 사용자들은 아예 D의 런타임(druntim)에 의존하지 않고 D 그 자체로 직접 메모리를 다뤄 C, C++처럼 쓰는 경우도 종종 보인다. 하지만 C, C++처럼 다루어야 한다는 제약 조건 자체가 D의 치명적인 약점인데, GC 기반의 고성능 언어가 기존에 이미 많이 있었고 (자바, C# 등) GC로 커버가 가능한 분야에서는 이미 성공적으로 C++를 대체하고 있었다. 그래서 C++에 남은 코드들은 GC로는 도저히 커버 불가능한 경우일 뿐이었는데, D가 GC를 요구하면서 이 사용자들에게 외면받았기 때문이다. GC로 커버 가능한 코드들은 이미 다른 언어로 옮겨갔으므로 그쪽에서도 사용자들을 끌어올 수 없었고, 이것은 D를 그대로 묻어버린 결정적인 실책이 된다. 그 후에 D는 실책을 깨닫고 GC 없이 동작하는 모드를 제공했으나, 문제는 이렇게 하면 표준 라이브러리인 D의 런타임을 사용할 수 없고 표준 라이브러리에 의존하는 모든 다른 라이브러리 또한 사용할 수 없는 상황이 되는 데다 결정적으로 이 모드에서는 메모리 안전성을 포기해야 했다. 그럴 경우 C++와 별로 달라지는 게 없다는 평가가 이루어지기에 이 모드도 실패도 끝났다. 나중에 이 모드에서 작동 가능한 표준 라이브러리를 제공하기는 했으나 안전성까지 보완된 것은 아니라서, GC를 완전히 배제하면서도 안전성을 제공하고 C++의 거의 모든 문제를 실제로 해결한 러스트가 뜨기 시작하자 최종적으로 사용되지 않게 된다.<ref name="D언어"></ref> | ||
| + | |||
| + | ===비교=== | ||
| + | ;C 언어·C++로부터 유지되는 기능 | ||
| + | 일반적인 외형은 C 언어나 C++ 와 비슷하다. 이것은 D 언어를 학습, 포팅 하는 것을 쉽게 만든다. C언어 / C++로부터 D 언어로의 전환은 편안하게 느껴질 것이다. 프로그래머는 이를 위해서 모든 것을 새로운 방식으로 배울 필요는 없다. D 언어를 사용한다는 것은 프로그래머가 자바나 스몰토크의 VM(Virtual Machine)처럼 특정 런타임 VM에 제한적이게 된다는 의미가 아니다. D 언어에는 VM이 없다. 링크 가능한 오브젝트 파일을 직접 컴파일러가 생성한다. C 언어에서처럼 D 언어도 운영 체계에 연결한다. 일반적으로 메이크같이 친숙한 툴들이 D 언어 개발에도 적합할 것이다. | ||
| + | |||
| + | 일반적인 외양, 느낌은 C 언어 / C++의 상태를 유지하였다. C 언어 / C++의 상태와 표현양식, 외양이 거의 동일하다. D 프로그램은 C 스타일(함수와 데이터), C++ 객체지향 스타일, C++ 템플릿 메타 프로그래밍, 혹은 3가지의 조합으로도 사용할 수 있다. 바이트코드로 컴파일되고 해석되는 것을 배제한 것은 아니지만 컴파일/링크/디버그 개발 모델이 유지되었다. D 언어는 C언어의 함수 호출 규약과 호환성을 유지한다. 이것은 D 프로그램이 운영 체계의 API에 직접 접근할 수 있게 해준다. 기존 API에 대한 프로그래머의 지식과 경험, 패러다임은 최소한의 노력으로 D 언어에 적용 가능하다. D 언어는 다른 언어로 컴파일된 외부 모듈의 도움 없이도, down-and-dirty programming을 할 수 있다. 때때로, 시스템 작업을 위해서 포인터를 써야만 하거나, 어셈블리를 이용할 필요가 있다. D 언어의 목적은 down and dirty programming 을 못하게 하는 것이 아니라, 일상적인 코딩 업무를 해결하는 데 있어서 그 필요성을 최소화시키는 데 있다. | ||
| + | |||
| + | 많은 경험에 의해서 예외 처리가 C에서 전통적으로 에러 코드와 errno(error number의 줄임말) 전역변수들로 에러를 처리하는 것보다 우월한 방법이 될 것이다. D 프로그램은 연산자 오버 로딩이 가능하고, 이로 인해서 기본 데이터 타입을 사용자 정의 타입으로 확장 가능하다. :템플릿은 제네릭 프로그래밍을 구현하기 위한 하나의 방법이다. 다른 방법 중에는 매크로를 사용하거나, 배리언트 데이터 타입 사용 등이 있다. 매크로의 사용은 고려 대상이 아니다. 배리언트의 사용은 수월하기는 하지만 비효율적이고 형식 체크에 부족하다. C++ 템플릿의 어려움은 그 복잡성에 있다. 그것은 언어의 문법과 잘 어울리지 않는다. D 언어에서는 컨버전과 오버 로딩을 위한 모든 다양한 규칙들이 갖추어져있다. D 언어는 템플릿을 하는 데 있어서 훨씬 간단한 방법을 제공한다. RTTI(Runtime Type Identification)의 일부분이 C++에 구현되어 있다. D 언어에서는 완전하게 지원하며, 향상된 가비지 컬렉션, 디버거 지원, 보다 자동화된 퍼시스턴스(persistence) 등을 지원하고 있다. RAII(Resource Acquisition Is Initialization) 기법은 신뢰성 있는 소프트웨어를 개발하기 위한 필수 요소이다.<ref name="D 언어 overview>쭌안아빠, 〈[http://jeremyko.blogspot.com/2008/10/d-overview.html D 언어 overview]〉, 《블로거》, 2008-10-31</ref> | ||
| + | |||
| + | ;C 언어·C++로부터 제거된 기능 | ||
| + | C 언어 확장으로 소스코드의 호환성을 유지하려는 것은 이미 진행돼 왔다(C++와 [[오브젝티브-C]]). 이 영역에서의 향후 작업들은 수많은 기존 코드들로 인해 제한받게 될 것이고 괄목할만한 개선이 이루어지기는 어려울 것이기에 제거되었다. C++ 런타임 오브젝트 모델은 너무 복잡하다. 만약 호환성을 유지하려 한다면, 그것은 본질적으로 D 컴파일러를 완전한 C++ 컴파일러로도 만들어야 한다는 것을 의미한다. 매크로 처리는 실제 존재하지 않는 기능을 추가함으로써(심벌릭 디버거로 볼 수 없는) 언어를 확장시키는데 쉬운 방법 중의 하나이다. 조건적인 컴파일, 층층이 쌓인 인크루드(include) 문장, 매크로들, 토큰 연결, 등등은 본질적으로 하나가 아닌, 두 개가 함께 병합되어 그것들을 명확히 구분할 수 없는 언어를 형성한다. 더 안 좋은 것은 C 전처리기가 매우 원시적인 매크로 언어라는 것이다. 한걸음 뒤로 물러나, 전처리기가 무엇을 위해서 사용되는지 살펴보고, 또 그것의 능력을 직접 언어 안에서 지원하게끔 설계를 해야 하는 시점이다. 다중 상속은 복잡하며 논쟁의 여지가 있는 기능이다. 효율적인 방법으로 구현하기 매우 어렵고, 그것을 구현하면서 컴파일러는 많은 오류 발생의 여지가 있다. 거의 모든 다중 상속의 효용성은 단일 상속과 인터페이스, 통합(aggregation) 조합으로도 대체 가능하며, 더 이상 다중 상속 구현의 어려움을 정당화시키지는 못한다. 독립적으로 개발된 코드들을 모두 함께 연결하는 데 있어서 문제점은 이름들 간의 충돌이다. 모듈을 사용하는 것이 훨씬 간단하며 더욱 잘 동작한다. 태그 네임 스페이스라는 C언어의 잘못된 기능은, 분리되었지만 병행되어 같이 참조되는 심벌 테이블에 구조체들의 태그, 이름들이 존재하는 것에 기인한다. C++는 기존 C 코드와 호환성을 유지하면서, 태그 네임 스페이스를 일반 네임 스페이스와 병합하려 했다. 그 결과로 불필요한 혼돈이 야기되었다. C 컴파일러는 지금 존재하는 상태 이전의 내용에 대해서만 의미 파악을 할 수 있다. C++는 이것을 조금 확장해서, 클래스 멤버들은 이전에 참조된 클래스 멤버들에 의존할 수 있다. D 언어는 논리적인 결론에 도달했는데, 전방 선언은 더 이상 모듈 단위에서 불필요하다는 것이다. 함수들은 C 프로그램에서 전방 선언을 피하기 위해 흔히 사용되는, 뒤바뀐 함수들의 순서가 아닌 자연스러운 순서로 정의될 수 있다. 인크루드 파일은 각각의 컴파일 단위마다 수많은 양의 헤더 파일을 재해석해야 함으로서 컴파일이 느려지는 주원인이다. 파일들을 인크루드 하는 것은 심벌 테이블을 임포팅(importing) 할 때 처리되어야 한다. | ||
| + | |||
| + | C++에서는 클래스 설계자는 어떤 함수가 가상인지 비가상인지를 먼저 결정한다. 함수가 오버라이드 될 때, 베이스 클래스 멤버 함수를 가상 함수로 변경하는 것을 잊어버리는 것은 흔하고 매우 찾기 힘든 코딩 오류이다. 모든 멤버 함수를 가상 함수로 만들고 만약 아무런 오버라이드가 없다면 그 함수를 비가상함수로 전환시키는 것을 컴파일러가 결정하게 하는 것이 더 신뢰성이 있다. 비트 필드는 복잡하고 비효율적이며 거의 사용 안 되는 기능이다. Near/Far 포인터, 훌륭한 16비트 코드를 생성하기 위해 필요한 장치에 대한 고려는 없다. D 언어의 설계에서는 최소한 32비트 실수 메모리 공간을 가정한다. D 언어는 향후 64비트 구조에 원활하게 적응할 것이다. 상호 의존적인 컴파일러 단계 같은 경우 C++에서는 성공적인 소스 파싱은 심벌 테이블을 가지는 것, 그리고 전처리기의 다양한 명령에 의존한다. 이것은 C++ 소스를 먼저 파싱 하는 것을 불가능하게 만들고, 코드 분석기와 문법 통제된 편집기가 제대로 동작하는 것을 극도로 어렵게 만든다. 컴파일러 구현물의 복잡성을 감소시키는 것으로 다수의 올바른 컴파일러 구현을 가능하게 한다. 만약 누군가 현대의 부동 소수점을 구현한 하드웨어를 사용 중이라면, 그것은 하드웨어 간 통용되는 가장 낮은 정밀도의 부동 소수점을 사용 중인 프로그래머에게도 가능해야 한다. 특별히, D 언어의 구현은 IEEE 754 계산과 만약 확장된 정밀도가 가능하다면 그것을 지원해야 한다. C++에서의 < 과 > 부호를 이용한 템플릿 오버 로딩을 선택한 것은 수년간의 버그들, 비탄 그리고 프로그래머들, 컴파일러 구현자들, C++ 소스 파싱 벤더들의 혼란의 원인이 되어왔다. 이것은 완전한 C++ 컴파일러가 수행하는 것과 거의 같은 일을 하지 않는다면, C++ 코드를 제대로 파싱 하는 것을 불가능하게 만든다.<ref name="D 언어 overview></ref> | ||
| + | |||
| + | ==전망== | ||
| + | [[페이스북]], [[넷플릭스]], [[이베이]] 등에서 적용된 사례가 있으며, 실행 속도에 민감한 게임계에서도 레미디 엔터테인먼트가 퀀텀 브레이크의 일부 소스코드에 D를 사용하는 등 실제 비즈니스에 이용된 사례가 조금씩 늘어나는 추세지만, C++에 비해 D의 입지가 작은 것은 여전하다. 2017년 6월 21일에 GCC 컴파일러가 D를 공식으로 지원하기 시작해서 여건이 그나마 나아질 것 기대되고 있으나 러스트 언어가 각광받고 있는 상황을 봐서는 전망이 좋다고 보기 어렵다. C++의 대안을 자처하고 나왔기 때문에 항상 C++ 세계의 흐름에 영향을 받을 수밖에 없는 언어이다. D가 처음 나왔을 때는 C++이 겨우 표준안을 마련하고 현대화를 시작한 무렵이었으므로 C++의 복잡도를 크게 경감시킨 D가 설자리가 충분히 존재했다. 그러나 커뮤니티가 분열하고 언어가 재설계되는 동안 C++은 C++ 11로서 그 결과를 내놓으며 현대화에 박차를 가했다. .NET 프레임워크를 출시하고 오랫동안 C#을 밀던 마이크로소프트도 다시 돌아와 네이티브 환경에 힘을 쏟기 시작했고 비주얼 C++ 2010, 2012에서 C++ 11의 많은 기능을 수용했다. C#이 한창 푸시를 받던 당시 대우가 안 좋았던 비주얼 스튜디오의 C++ 인텔리센스 기능도 2013 버전에 와서는 드라마틱 하게 향상되었다. 레거시 코드의 컴파일을 보장해야 하고 헤더 인크루드 구조를 유지해야 하는 C/C++에 비해, 한 번역 단위 내에 명세와 구현이 같이 존재하고 사용하기 쉬우면서도, C와 같은 저 수준 개발이 가능하며 컴파일 속도가 빠른 네이티브 언어로서의 D의 유니크한 입지는 아직 유효하다. 그러나 네이티브 개발자 세계에서 예나 지금이나 주력은 C++이고 벌써 C++ 14, C++ 17, C++ 20을 논하며 현대화되는 현시점에서 D의 입지는 거의 사라져 버린 것이 현실이다. 그리고 결정적으로, C++의 문제점 때문에 C++를 버리고 "더 나은 대안"을 찾는 사람들에게는 D는 신택스(syntax) 정도만 갈아엎은 어정쩡한 [[솔루션]]인데 비해, 러스트는 신택스는 물론이고 모든 문제를 갈아엎으면서 Ada에 비교되는 안전함을 제공하는 혁신을 보여줬기 때문에 더더욱 비교가 되고 있다. ABA 게임즈의 서클장 쵸 켄타가 이 언어를 이용한 벡터 그래픽을 구현해 탄막 슈팅 게임을 제조하였으나, XNA로 바꾸게 되었다.<ref name="D언어"></ref> | ||
| + | |||
| + | {{각주}} | ||
== 참고자료 == | == 참고자료 == | ||
| − | * | + | * D (프로그래밍 언어) 위키백과 - https://ko.wikipedia.org/wiki/D_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4) |
| + | * D언어 나무위키 - https://namu.wiki/w/D%EC%96%B8%EC%96%B4 | ||
| + | * 〈[https://tour.dlang.org/tour/kr/welcome/welcome-to-d D 프로그래밍 언어의 세계에 오신 걸 환영합니다.]〉, 《D 프로그램 언어》 | ||
| + | * 〈[http://jeremyko.blogspot.com/2008/10/d-overview.html D 언어 시작하기]〉, 《RIP 튜토리얼》 | ||
| + | * 쭌안아빠, 〈[http://jeremyko.blogspot.com/2008/10/d-overview.html D 언어 overview]〉, 《블로거》, 2008-10-31 | ||
| + | * 〈[https://wikidocs.net/73120 D 프로그래밍 언어란]〉, 《위키독스》, 2020-06-09 | ||
| + | |||
| + | == 같이 보기 == | ||
| + | * [[C 언어]] | ||
| + | * [[C++]] | ||
| + | * [[자바]] | ||
| + | * [[파이썬]] | ||
| + | * [[루비]] | ||
| + | * [[C#]] | ||
| + | * [[오브젝티브-C]] | ||
| + | * [[에펠]] | ||
| + | |||
| + | {{프로그래밍 언어|검토 필요}} | ||
2020년 8월 5일 (수) 19:41 기준 최신판
D 언어(D Language)는 2001년 12월에 처음 발표된 후, 2007년 1월에 정식 발표된 컴파일 언어이자 멀티 패러다임 프로그래밍 언어이다. C++이 본래 C 언어를 대체하기 위한 언어로 출발했듯이 D 언어는 C++을 대체하기 위한 목적으로 출발한 언어이다.
개요[편집]
D 프로그래밍 언어는 컴퓨터 소프트웨어를 만들기 위한 범용 프로그래밍 언어 중 한 가지이다. 범용이라 표현하는 이유는 어느 한 분야에 국한되지 않고 여러 분야에 사용할 수 있도록 설계되었다는 뜻이다. D 언어를 이용해 게임을 만들거나, 서버 애플리케이션을 만들거나 혹은 윈도우 애플리케이션도 만들 수 있다. D 언어는 미국의 컴퓨터 프로그래머인 월터 브라이트(Walter Bright)에 의해 첫 버전이 탄생했다. 처음에는 상용 컴파일러였으나 소스 코드를 누구나 열람하고 수정할 수 있게 공개한 이후, 유명한 부스트 라이브러리 개발자인 안드레 알렉산드레스쿠(Andrei Alexandrescu) 외 다양한 개발자들이 D 언어의 개발에 합류하게 된다. 오랜 기간 동안 구글, 페이스북 등의 거대 IT 기업에 종속되지 않고 커뮤니티 중심으로 운영되다가, D 언어의 발전 가속과 활성화를 위해 D 언어 재단을 설립 후 이를 중심으로 계속 개발되고 있다. 2001년에 공개되어서 C++의 리엔지니어링으로 기원하였으나 D는 해당 언어와는 별개의 언어이다. 일부 핵심 C++ 기능들을 다시 설계하였으며 자바, 파이썬, 루비, C#, 에펠과 같은 다른 언어들의 특징들을 공유하기도 한다. 관용적인 D 코드는 동등한 C++ 코드보다 크기가 짧더라도 C++만큼 속도가 빠른 것이 보통이다. 이 언어는 전반적으로 메모리 안전에 속하지 않으나 메모리 안전을 검사하도록 설계된 선택적 속성을 포함한다.[1][2]
역사[편집]
- D 1.0
최초의 네이티브 C++ 컴파일러였던 Zortech C++(Symantec C++이 되었다가 DMC++로 변천되어옴)의 메인 개발자였던 월터 브라이트는 C++의 복잡도를 줄이고 현대적인 언어 개념들을 포함한 언어를 만들기로 했고 1999년부터 작업을 시작해 2001년 12월 8일에 첫 번째 버전을 발표한다. 처음에는 마스 언어라고 이름 붙였지만 그의 동료 중 한 명이 계속 D라고 부르면서 D로 이름을 바꾸게 되었다는 사연이 있다. 버전업이 매우 느렸기 때문에 D 1.0 버전이 발표된 건 2007년 1월 2일이 되어서였다. 범용 시스템 프로그래밍 언어인 C++을 대체하는 것을 목적으로 만들어졌으므로 C++과 같이 기계어 컴파일이 되는 언어였으며 파이썬, 자바, C# 등 현대화된 메이저 언어들의 영향을 많이 받았다. 그러면서도 최근의 현대 언어들과 같이 인터프리터나 가상머신으로 실행되는 구조가 아니었으므로 퍼포먼스 지향적이어서 처음에는 많은 기대를 받았다. D는 표준 런타임 라이브러리로서 포보스가 존재했지만 D 커뮤니티는 포보스 라이브러리의 느린 발전 속도에 만족하지 못했다. 언어와 개발 환경의 느린 발전 속도는 D 언어가 원래 오픈소스가 아니고 디지털 마스에 카피 라이트가 있고 상용 언어를 목표로 했기 때문이었다. D 사용자 커뮤니티는 포보스와는 별도로 오픈소스로서 존재하는 런타임 라이브러리를 만들기로 했고 탱고 라이브러리가 발표되었다. 탱고는 포보스보다 다양한 기능을 제공했으며 커뮤니티가 참여해서 만들어졌기 때문에 발전 속도가 빨랐다. D 언어에 관한 책은 거의 없지만 "D 프로그래밍 위드 탱고"라는 입문서가 출판될 정도였다. 그러나 이런 상황은 커뮤니티 자체를 분열시키는 결과를 낳았고 언어 자체의 발전 속도를 저하시키고 인터넷상의 정보를 파편화시켜 D 언어를 지탱한 표준 런타임 라이브러리가 분열되고 말았다. 이 때문에 정보가 많지도 않은 상황에서 입문자들은 전혀 다른 스타일의 런타임 라이브러리에 혼란을 겪어야 했다. 비슷한 상황을 맞은 파이썬을 보면 구글이 창시자를 영입하고 재단을 출범해 로드맵을 조정하는 것과 대조적이었다. 결국, 월터 브라이트는 D 1.0이 실패라고 판단하고 언어 자체를 재설계하기로 결정했다. D의 행보에 실망한 커뮤니티는 대부분 흩어지고, 초반에 받았던 세간의 관심으로부터도 멀어졌다.[3]
- D 2.0
D 2.0 버전을 줄여서 D2로 알려진 것이 바로 D 언어를 가리킨다. C++ 그룹 중 한 명이며 모던 C++ 디자인이라는 책에서 템플릿 메타 프로그래밍에 기반한 정책 기반 설계라는 개념을 정립한 것으로 널리 알려진 안드레이 알렉산드레스쿠(Andrei Alexandrescu)가 D2 프로젝트에 공동 설계자로서 합류하게 된다. 그가 합류하면서 D는 메타 프로그래밍 언어로서의 성향이 매우 강해졌으며 관련된 언어 상 기능들이 다수 추가되었다. 2007년 6월 17일에 정식 발표되면서 D2를 D2라고 불리지 않으며 그냥 D라고 부르게 된다. 1.0 버전으로 발표된 지 5개월밖에 안 된 기존의 D 언어는 바로 버려진 것은 아니고 꾸준히 버전업되면서 버그 수정(안정화 작업) 정도로만 유지되었다가 2012년 12월 31일에 발표된 1.076 버전을 마지막으로 지원 중단되었다. D 언어로 불리는 2.0 버전은 오픈소스 프로젝트로서 깃허브에 전체 프로젝트가 공개되어 있으며 커뮤니티가 활발하게 기여를 하고 있다. 핵심 개발자인 안드레이 알렉산드레스쿠는 페이스북에서 연구자로 소속되어 있으며 페이스북 내에서 D를 사용한 프로젝트를 진행하고 있다고 한다. 페이스북은 주로 HHVM을 사용하고 있는데 구글 내에서 파이썬이 그랬던 것처럼 메이저 IT 회사 중 하나인 페이스북 내에서 어느 정도의 입지를 가지게 되느냐에 따라 향후 D의 운명이 결정될 가능성이 크다. 그러나 알렉산드레스쿠는 D 언어 재단에 더 힘을 쏟기 위해 페이스북을 그만두었다. 본인도 많은 고민 끝에 내린 결정이라고 한다.[3]
특징[편집]
고수준 모델링 지원을 위한 기반을 제공한다. 실행 전 컴파일을 미리 해 둬야 하는 언어이며, 높은 성능을 보여준다. 정적 타입(static typing) 특성을 갖는다. 모든 타입은 컴파일 시점 전에 결정된다. 예를 들어, 값을 반환하는 함수 등에서 어떤 타입을 반환하는지 명확히 알 수 있다. 운영체제와 하드웨어가 제공하는 API를 직접 제어할 수 있다. 컴파일에 드는 소요시간이 짧다. 메모리 안전을 보장하는 제한된 D 언어 환경을 제공한다. 프로그램 유지 및 보수에 편리하며, 이해하는데 어려움이 없는 코드를 작성할 수 있다. 갑자기 어려워지는 부분 없이, 일정한 코딩 난이도 상승 속에서 배워 갈 수 있는 언어이다(C나 자바와 비슷한 문법 구조이다). C 응용 프로그램/라이브러리와의 호환성을 갖는다. C++ 응용 프로그램/라이브러리와의 제한적 호환성을 갖는다. 다양한 프로그래밍 패러다임을 포함하고 있다.(명령형, 구조형, 객체지향, 제네릭, 함수형 프로그래밍, 어셈블리가 존재한다) 언어에 내장된 오류 탐지 기능이 있다.[4]
종류[편집]
- DMD
디지털 마스 D 컴파일러(Digital Mars D compiler)의 약자이며 D 언어 재단에서 공식적으로 유지 보수&배포 중인 레퍼런스 컴파일러이다. 기존에는 C++로 구현되었으나 2015년 11월 3일에 2.069.0 버전부터 프런트엔드를, 뒤이어 2018년 11월 11일에 백엔드를 D로 구현하는 데 성공했다. D 언어로 DMD를 작성했다는 뜻에서 DDMD라 부르기도 한다. D 언어 재단에서 제공하는 표준 레퍼런스 컴파일러다. 빌드 속도는 GDC와 LDC보다 빠르다. 빌드 한 결과물의 퍼포먼스는 GDC나 LDC에 비해 떨어진다. 윈도우, 리눅스, 맥 모두 지원하며, 윈도우에서 설치하는 게 제일 쉽다.[3]
- GDC
이름에서 추측할 수 있듯이 GCC 기반의 D 컴파일러이다. 예전에는 DMD의 심각한 성능 문제나 디버깅의 어려움 때문에 커뮤니티에서는 DMD를 포기하고 GDC를 쓰라는 말이 나오기도 했었지만 꾸준한 DMD의 성능 개선으로 모두 옛날이야기가 됐다. 하지만 2017년을 기준으로 GCC가 D를 공식으로 포함했기 때문에 그대로 GCC를 쓸 수 있게 되었다. 버전 릴리스는 가장 느리다. 빌드 속도는 DMD와 비슷하다.[3]
- LDC
LLVM를 기반으로 둔 D 컴파일러이다. DMD 컴파일러가 안드로이드와 iOS 환경에 대한 공식적인 지원이 없는데 비해 상대적으로 모바일 환경에 대한 지원이 활성화되어 있다. 1.18버전부터 안드로이드용 컴파일러 바이너리를, 1.20버전부터 iOS(tvOS · watchOS 포함)를 위한 코드젠을 제공하기 시작했다. 그 외에도 D 커뮤니티 내 몇몇 능력자들의 포크(Fork)나 사이드 프로젝트를 통한 기여가 많은 편이다. C++ 라이브러리를 바인딩 코드 없이 그대로 가져와 쓸 수 있는 LDC 컴파일러(Calypso)나 웹 어셈블리 애플리케이션 개발을 위한 라이브러리 등이 존재한다.[3]
- DUB
DUB은 D 언어를 위한 빌드 프로그램이다. 단순히 프로젝트 빌드뿐만 아니라 code.dlang.org에 게시된 제3자 라이브러리를 가져와 쓸 수 있도록 패키지 매니저의 역할(파이썬의 Pypi, Lua의 LuaRocks 같은 셈이다)도 하며 DMD, GDC, LDC로의 선택이나 플래그도 dub.json 또는 dub.sdl 파일(프로젝트 설정 파일)을 통해 쉽게 작성할 수 있다. 원래 DUB은 D 언어 재단에서 공식적으로 개발하는 소프트웨어가 아니다. DUB 역시 Vibe.d 프로젝트의 커뮤니티로부터 공존해오고 있는 프로젝트이지만 사실상 D 언어로 스크립트 수준의 작은 프로그램이 아니라 외부 라이브러리, 이를테면 바인딩이나 3th Party library를 쓸 일이 생긴다면 DUB은 필수이다. D 유저들 사이에서는 암묵적인 표준 소프트웨어나 다름없는 셈. 이미 D 언어 재단에서도 공식적으로(official) 밀어주는 모습을 보여준다. 얼마 전까지만 해도 DUB은 바이브 커뮤니티 사이에서 따로 배포되어 왔었으나 러스트 컴파일러 패키지에 카고가 기본적으로 포함되어 있는 것을 D 유저들이 의식하고 DMD 컴파일러 패키지에도 DUB을 포함하자는 의견이 있었다. 2.72.x 버전부터 포함되어 함께 배포되고 있다.[3]
활용[편집]
- 예시 1
import std.stdio; // Let's get going!
void main()
{
:writeln("Hello World!");
}
컴파일하고 실행하려면 이 텍스트를 main.d라는 파일로 저장해야 한다. 명령행에서 dmd main.d를 실행하여 프로그램을 컴파일한 후 ./main 을 실행하여 bash 쉘에서 프로그램을 실행하거나 윈도우에서 실행 파일을 누를 수 있다.[5]
- 예시 2
고전적인 "Hello, world" 인쇄 프로그램을 만들려면 다음 코드가 포함된 텍스트 편집기로 hello.d 파일을 만든다.[5]
import std.stdio;
void main()
{
:writeln("Hello, World!"); //writeln() automatically adds a newline (＼n) to the output
}
- 설명
import std.stdio
이 행은 표준 라이브러리 모듈 std.stdio가 정의된 함수가 사용될 것임을 컴파일러에 알린다. 컴파일러가 모듈을 찾을 위치를 알고 있는 한 모든 모듈을 가져올 수 있다. 많은 기능이 D의 방대한 표준 라이브러리의 일부로 제공된다.
|void main() {
이 줄은 main 함수를 선언하고 void를 반환한다. C 및 C ++과 달리 D를 사용하면 main이 void 유형이 될 수 있다. 함수 main은 프로그램의 시작점이므로 특별하다. 함수의 이름은 문자로 시작하고 문자, 숫자 및 밑줄로 구성된 모든 것이 될 수 있다. 예상되는 매개 변수는 쉼표로 구분된 변수 이름 및 해당 데이터 유형의 목록이다. 함수가 반환할 것으로 예상되는 값은 기존 데이터 형식이 될 수 있으며 함수 내의 return 문에서 사용된 식의 형식과 일치해야 한다. 중괄호 { … }는 쌍으로 사용되어 코드 블록이 시작하고 끝나는 곳을 나타낸다. 그것들은 많은 방법으로 사용될 수 있지만, 이 경우에는 함수가 시작하고 끝나는 곳을 나타낸다.
writeln("Hello, World!");
writeln 은 std.stdio에서 선언된 함수로 해당 악기를 stdout로 쓴다. 이 경우 인수는 "Hello, World"이며 콘솔에 기록된다. ＼n , ＼r 등과 같이 C의 printf로 사용되는 것과 비슷한 다양한 형식의 문자가 사용될 수 있다. 모든 문장은 세미콜론으로 끝나야 한다.
//writeln() automatically adds a newline (＼n) to the output
주석은 코드를 읽는 사람에게 무언가를 나타 내기 위해 사용되며 컴파일러가 공백처럼 취급한다. 위의 코드에서 이것은 주석이다. 이것은 컴파일러에서 무시되는 코드 조각이다. D에서 논평하는 방법으로는 아래와 같은 세 가지가 있다.
- // : 같은 줄의 모든 텍스트를 // 뒤에 주석 처리한다.
- /* comment text */ : 여러 줄 /* comment text */에 유용하다.
- /+ comment text + : 여러 줄 주석
이것은 코드의 기능 / 조각이 동료 개발자에게 무엇을 전달하는지를 알려주는데 매우 유용하다.[5]
- 프로그램 컴파일 및 실행
이 프로그램을 실행하려면 코드를 실행 파일로 컴파일해야 한다. 이것은 컴파일러의 도움으로 수행할 수 있다. DMD를 사용하여 컴파일하려면 참조 D 컴파일러에서 터미널을 열고 생성 한 hello.d 파일의 위치로 이동한 후 다음을 실행한다.
dmd hello.d
오류가 발견되지 않으면 컴파일러는 소스 파일의 이름을 따서 명명된 실행 파일을 출력한다. 이제 다음을 입력하여 실행할 수 있다.
./hello
실행 시, 프로그램은 Hello, World!로 인쇄한 후 줄 바꿈이 뒤따른다.[5]
문제점[편집]
C++을 대체하기 위한 D 언어가 쓰레기 수집기(GC)를 내장함으로써 발생하는 성능적인 비용 때문에 게임과 같이 빠른 연산이 필요한 곳, 특히 60FPS을 목표로 렌더링 해야 하는 고사양 게임 개발에 사용하기에는 부적합하다는 의견이 중론이다. 물론 @nogc로 쓰레기 수집기의 사이클을 어느 정도는 회피할 수 있다고는 하지만 언어적 차원에서 지원되는 기능이라 GC를 사용하지 않았을 때의 제약점이 생긴다. 그래서 GC를 싫어하는 D 사용자들은 아예 D의 런타임(druntim)에 의존하지 않고 D 그 자체로 직접 메모리를 다뤄 C, C++처럼 쓰는 경우도 종종 보인다. 하지만 C, C++처럼 다루어야 한다는 제약 조건 자체가 D의 치명적인 약점인데, GC 기반의 고성능 언어가 기존에 이미 많이 있었고 (자바, C# 등) GC로 커버가 가능한 분야에서는 이미 성공적으로 C++를 대체하고 있었다. 그래서 C++에 남은 코드들은 GC로는 도저히 커버 불가능한 경우일 뿐이었는데, D가 GC를 요구하면서 이 사용자들에게 외면받았기 때문이다. GC로 커버 가능한 코드들은 이미 다른 언어로 옮겨갔으므로 그쪽에서도 사용자들을 끌어올 수 없었고, 이것은 D를 그대로 묻어버린 결정적인 실책이 된다. 그 후에 D는 실책을 깨닫고 GC 없이 동작하는 모드를 제공했으나, 문제는 이렇게 하면 표준 라이브러리인 D의 런타임을 사용할 수 없고 표준 라이브러리에 의존하는 모든 다른 라이브러리 또한 사용할 수 없는 상황이 되는 데다 결정적으로 이 모드에서는 메모리 안전성을 포기해야 했다. 그럴 경우 C++와 별로 달라지는 게 없다는 평가가 이루어지기에 이 모드도 실패도 끝났다. 나중에 이 모드에서 작동 가능한 표준 라이브러리를 제공하기는 했으나 안전성까지 보완된 것은 아니라서, GC를 완전히 배제하면서도 안전성을 제공하고 C++의 거의 모든 문제를 실제로 해결한 러스트가 뜨기 시작하자 최종적으로 사용되지 않게 된다.[3]
비교[편집]
- C 언어·C++로부터 유지되는 기능
일반적인 외형은 C 언어나 C++ 와 비슷하다. 이것은 D 언어를 학습, 포팅 하는 것을 쉽게 만든다. C언어 / C++로부터 D 언어로의 전환은 편안하게 느껴질 것이다. 프로그래머는 이를 위해서 모든 것을 새로운 방식으로 배울 필요는 없다. D 언어를 사용한다는 것은 프로그래머가 자바나 스몰토크의 VM(Virtual Machine)처럼 특정 런타임 VM에 제한적이게 된다는 의미가 아니다. D 언어에는 VM이 없다. 링크 가능한 오브젝트 파일을 직접 컴파일러가 생성한다. C 언어에서처럼 D 언어도 운영 체계에 연결한다. 일반적으로 메이크같이 친숙한 툴들이 D 언어 개발에도 적합할 것이다.
일반적인 외양, 느낌은 C 언어 / C++의 상태를 유지하였다. C 언어 / C++의 상태와 표현양식, 외양이 거의 동일하다. D 프로그램은 C 스타일(함수와 데이터), C++ 객체지향 스타일, C++ 템플릿 메타 프로그래밍, 혹은 3가지의 조합으로도 사용할 수 있다. 바이트코드로 컴파일되고 해석되는 것을 배제한 것은 아니지만 컴파일/링크/디버그 개발 모델이 유지되었다. D 언어는 C언어의 함수 호출 규약과 호환성을 유지한다. 이것은 D 프로그램이 운영 체계의 API에 직접 접근할 수 있게 해준다. 기존 API에 대한 프로그래머의 지식과 경험, 패러다임은 최소한의 노력으로 D 언어에 적용 가능하다. D 언어는 다른 언어로 컴파일된 외부 모듈의 도움 없이도, down-and-dirty programming을 할 수 있다. 때때로, 시스템 작업을 위해서 포인터를 써야만 하거나, 어셈블리를 이용할 필요가 있다. D 언어의 목적은 down and dirty programming 을 못하게 하는 것이 아니라, 일상적인 코딩 업무를 해결하는 데 있어서 그 필요성을 최소화시키는 데 있다.
많은 경험에 의해서 예외 처리가 C에서 전통적으로 에러 코드와 errno(error number의 줄임말) 전역변수들로 에러를 처리하는 것보다 우월한 방법이 될 것이다. D 프로그램은 연산자 오버 로딩이 가능하고, 이로 인해서 기본 데이터 타입을 사용자 정의 타입으로 확장 가능하다. :템플릿은 제네릭 프로그래밍을 구현하기 위한 하나의 방법이다. 다른 방법 중에는 매크로를 사용하거나, 배리언트 데이터 타입 사용 등이 있다. 매크로의 사용은 고려 대상이 아니다. 배리언트의 사용은 수월하기는 하지만 비효율적이고 형식 체크에 부족하다. C++ 템플릿의 어려움은 그 복잡성에 있다. 그것은 언어의 문법과 잘 어울리지 않는다. D 언어에서는 컨버전과 오버 로딩을 위한 모든 다양한 규칙들이 갖추어져있다. D 언어는 템플릿을 하는 데 있어서 훨씬 간단한 방법을 제공한다. RTTI(Runtime Type Identification)의 일부분이 C++에 구현되어 있다. D 언어에서는 완전하게 지원하며, 향상된 가비지 컬렉션, 디버거 지원, 보다 자동화된 퍼시스턴스(persistence) 등을 지원하고 있다. RAII(Resource Acquisition Is Initialization) 기법은 신뢰성 있는 소프트웨어를 개발하기 위한 필수 요소이다.[6]
- C 언어·C++로부터 제거된 기능
C 언어 확장으로 소스코드의 호환성을 유지하려는 것은 이미 진행돼 왔다(C++와 오브젝티브-C). 이 영역에서의 향후 작업들은 수많은 기존 코드들로 인해 제한받게 될 것이고 괄목할만한 개선이 이루어지기는 어려울 것이기에 제거되었다. C++ 런타임 오브젝트 모델은 너무 복잡하다. 만약 호환성을 유지하려 한다면, 그것은 본질적으로 D 컴파일러를 완전한 C++ 컴파일러로도 만들어야 한다는 것을 의미한다. 매크로 처리는 실제 존재하지 않는 기능을 추가함으로써(심벌릭 디버거로 볼 수 없는) 언어를 확장시키는데 쉬운 방법 중의 하나이다. 조건적인 컴파일, 층층이 쌓인 인크루드(include) 문장, 매크로들, 토큰 연결, 등등은 본질적으로 하나가 아닌, 두 개가 함께 병합되어 그것들을 명확히 구분할 수 없는 언어를 형성한다. 더 안 좋은 것은 C 전처리기가 매우 원시적인 매크로 언어라는 것이다. 한걸음 뒤로 물러나, 전처리기가 무엇을 위해서 사용되는지 살펴보고, 또 그것의 능력을 직접 언어 안에서 지원하게끔 설계를 해야 하는 시점이다. 다중 상속은 복잡하며 논쟁의 여지가 있는 기능이다. 효율적인 방법으로 구현하기 매우 어렵고, 그것을 구현하면서 컴파일러는 많은 오류 발생의 여지가 있다. 거의 모든 다중 상속의 효용성은 단일 상속과 인터페이스, 통합(aggregation) 조합으로도 대체 가능하며, 더 이상 다중 상속 구현의 어려움을 정당화시키지는 못한다. 독립적으로 개발된 코드들을 모두 함께 연결하는 데 있어서 문제점은 이름들 간의 충돌이다. 모듈을 사용하는 것이 훨씬 간단하며 더욱 잘 동작한다. 태그 네임 스페이스라는 C언어의 잘못된 기능은, 분리되었지만 병행되어 같이 참조되는 심벌 테이블에 구조체들의 태그, 이름들이 존재하는 것에 기인한다. C++는 기존 C 코드와 호환성을 유지하면서, 태그 네임 스페이스를 일반 네임 스페이스와 병합하려 했다. 그 결과로 불필요한 혼돈이 야기되었다. C 컴파일러는 지금 존재하는 상태 이전의 내용에 대해서만 의미 파악을 할 수 있다. C++는 이것을 조금 확장해서, 클래스 멤버들은 이전에 참조된 클래스 멤버들에 의존할 수 있다. D 언어는 논리적인 결론에 도달했는데, 전방 선언은 더 이상 모듈 단위에서 불필요하다는 것이다. 함수들은 C 프로그램에서 전방 선언을 피하기 위해 흔히 사용되는, 뒤바뀐 함수들의 순서가 아닌 자연스러운 순서로 정의될 수 있다. 인크루드 파일은 각각의 컴파일 단위마다 수많은 양의 헤더 파일을 재해석해야 함으로서 컴파일이 느려지는 주원인이다. 파일들을 인크루드 하는 것은 심벌 테이블을 임포팅(importing) 할 때 처리되어야 한다.
C++에서는 클래스 설계자는 어떤 함수가 가상인지 비가상인지를 먼저 결정한다. 함수가 오버라이드 될 때, 베이스 클래스 멤버 함수를 가상 함수로 변경하는 것을 잊어버리는 것은 흔하고 매우 찾기 힘든 코딩 오류이다. 모든 멤버 함수를 가상 함수로 만들고 만약 아무런 오버라이드가 없다면 그 함수를 비가상함수로 전환시키는 것을 컴파일러가 결정하게 하는 것이 더 신뢰성이 있다. 비트 필드는 복잡하고 비효율적이며 거의 사용 안 되는 기능이다. Near/Far 포인터, 훌륭한 16비트 코드를 생성하기 위해 필요한 장치에 대한 고려는 없다. D 언어의 설계에서는 최소한 32비트 실수 메모리 공간을 가정한다. D 언어는 향후 64비트 구조에 원활하게 적응할 것이다. 상호 의존적인 컴파일러 단계 같은 경우 C++에서는 성공적인 소스 파싱은 심벌 테이블을 가지는 것, 그리고 전처리기의 다양한 명령에 의존한다. 이것은 C++ 소스를 먼저 파싱 하는 것을 불가능하게 만들고, 코드 분석기와 문법 통제된 편집기가 제대로 동작하는 것을 극도로 어렵게 만든다. 컴파일러 구현물의 복잡성을 감소시키는 것으로 다수의 올바른 컴파일러 구현을 가능하게 한다. 만약 누군가 현대의 부동 소수점을 구현한 하드웨어를 사용 중이라면, 그것은 하드웨어 간 통용되는 가장 낮은 정밀도의 부동 소수점을 사용 중인 프로그래머에게도 가능해야 한다. 특별히, D 언어의 구현은 IEEE 754 계산과 만약 확장된 정밀도가 가능하다면 그것을 지원해야 한다. C++에서의 < 과 > 부호를 이용한 템플릿 오버 로딩을 선택한 것은 수년간의 버그들, 비탄 그리고 프로그래머들, 컴파일러 구현자들, C++ 소스 파싱 벤더들의 혼란의 원인이 되어왔다. 이것은 완전한 C++ 컴파일러가 수행하는 것과 거의 같은 일을 하지 않는다면, C++ 코드를 제대로 파싱 하는 것을 불가능하게 만든다.[6]
전망[편집]
페이스북, 넷플릭스, 이베이 등에서 적용된 사례가 있으며, 실행 속도에 민감한 게임계에서도 레미디 엔터테인먼트가 퀀텀 브레이크의 일부 소스코드에 D를 사용하는 등 실제 비즈니스에 이용된 사례가 조금씩 늘어나는 추세지만, C++에 비해 D의 입지가 작은 것은 여전하다. 2017년 6월 21일에 GCC 컴파일러가 D를 공식으로 지원하기 시작해서 여건이 그나마 나아질 것 기대되고 있으나 러스트 언어가 각광받고 있는 상황을 봐서는 전망이 좋다고 보기 어렵다. C++의 대안을 자처하고 나왔기 때문에 항상 C++ 세계의 흐름에 영향을 받을 수밖에 없는 언어이다. D가 처음 나왔을 때는 C++이 겨우 표준안을 마련하고 현대화를 시작한 무렵이었으므로 C++의 복잡도를 크게 경감시킨 D가 설자리가 충분히 존재했다. 그러나 커뮤니티가 분열하고 언어가 재설계되는 동안 C++은 C++ 11로서 그 결과를 내놓으며 현대화에 박차를 가했다. .NET 프레임워크를 출시하고 오랫동안 C#을 밀던 마이크로소프트도 다시 돌아와 네이티브 환경에 힘을 쏟기 시작했고 비주얼 C++ 2010, 2012에서 C++ 11의 많은 기능을 수용했다. C#이 한창 푸시를 받던 당시 대우가 안 좋았던 비주얼 스튜디오의 C++ 인텔리센스 기능도 2013 버전에 와서는 드라마틱 하게 향상되었다. 레거시 코드의 컴파일을 보장해야 하고 헤더 인크루드 구조를 유지해야 하는 C/C++에 비해, 한 번역 단위 내에 명세와 구현이 같이 존재하고 사용하기 쉬우면서도, C와 같은 저 수준 개발이 가능하며 컴파일 속도가 빠른 네이티브 언어로서의 D의 유니크한 입지는 아직 유효하다. 그러나 네이티브 개발자 세계에서 예나 지금이나 주력은 C++이고 벌써 C++ 14, C++ 17, C++ 20을 논하며 현대화되는 현시점에서 D의 입지는 거의 사라져 버린 것이 현실이다. 그리고 결정적으로, C++의 문제점 때문에 C++를 버리고 "더 나은 대안"을 찾는 사람들에게는 D는 신택스(syntax) 정도만 갈아엎은 어정쩡한 솔루션인데 비해, 러스트는 신택스는 물론이고 모든 문제를 갈아엎으면서 Ada에 비교되는 안전함을 제공하는 혁신을 보여줬기 때문에 더더욱 비교가 되고 있다. ABA 게임즈의 서클장 쵸 켄타가 이 언어를 이용한 벡터 그래픽을 구현해 탄막 슈팅 게임을 제조하였으나, XNA로 바꾸게 되었다.[3]
각주[편집]
- ↑ D (프로그래밍 언어) 위키백과 - https://ko.wikipedia.org/wiki/D_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4)
- ↑ 〈D 프로그래밍 언어란〉, 《위키독스》, 2020-06-09
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 D언어 나무위키 - https://namu.wiki/w/D%EC%96%B8%EC%96%B4
- ↑ 〈D 프로그래밍 언어의 세계에 오신 걸 환영합니다.〉, 《D 프로그래밍 언어》
- ↑ 5.0 5.1 5.2 5.3 〈D 언어 시작하기〉, 《RIP 튜토리얼》
- ↑ 6.0 6.1 쭌안아빠, 〈D 언어 overview〉, 《블로거》, 2008-10-31
참고자료[편집]
- D (프로그래밍 언어) 위키백과 - https://ko.wikipedia.org/wiki/D_(%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D_%EC%96%B8%EC%96%B4)
- D언어 나무위키 - https://namu.wiki/w/D%EC%96%B8%EC%96%B4
- 〈D 프로그래밍 언어의 세계에 오신 걸 환영합니다.〉, 《D 프로그램 언어》
- 〈D 언어 시작하기〉, 《RIP 튜토리얼》
- 쭌안아빠, 〈D 언어 overview〉, 《블로거》, 2008-10-31
- 〈D 프로그래밍 언어란〉, 《위키독스》, 2020-06-09
같이 보기[편집]
