안전한 C++ 제공 - Bjarne Stroustrup - CppCon 2023 - https://www.youtube.com/watch?v=I8UvQKvOSSw 

    안전성에 대한 정의를 위해 C를 작성하는 방법에 대해 이야기해 보겠습니다. 그리고 일반적인 아이디어는 안전성이란 무엇인가? 어떤 종류의 안전성이 있는가? 무엇이 필요한가? 이것이 첫 번째 분기입니다. 그런 다음 수십 년 동안 우리가 그것에 대해 조금씩 다가가고 있다는 것을 보여드리겠습니다. 그것은 C의 초기 목표의 일부입니다. 그런 다음 C 핵심 지침이라는 레이블 아래에서 좋은 현대적 C를 작성하는 방법에 대해 이야기하겠습니다. 그리고 안전을 보장하는 방법에 대한 프로필에 대해 이야기하겠습니다. 지침과 주의만으로는 모든 영역에서 충분하지 않기 때문입니다. 따라서 안전성에 대한 이야기가 많은 이유 중 하나는 미국 정부의 일부가 안전성에 대해 이야기하기 시작했기 때문인데, 이는 매우 타당하지만 그들은 전체 커뮤니티에 대해 이야기하고 있으며, 이는 사실일 수도 있고 아닐 수도 있습니다. 그리고 그들은 신화적인 언어인 C C에 대해 이야기하고 있는데, 저는 그것에 대해 말할 것이 있습니다. 어쨌든요. 찾아보실 수 있습니다. 이것은 우리가 다루어야 할 심각한 문제입니다. 반면에 당황할 이유는 없습니다. C는 일반적으로 잘하고 있습니다. 제 말은, t o b는 사용량이 아니라 소음을 측정한다는 것입니다. 따라서 이 숫자는 정확히 아무것도 보여주지 않지만, 아마도 10억 또는 20억 명이 우리가 하는 일에 의존하고 있다는 것을 보여주므로, 우리는 그것을 잘해야 합니다. 그래서 우리는 안전 문제를 해결해야 합니다. 이것은 정말 심각한 문제입니다. 제 말은, 제가 차를 가지고 있다면 브레이크를 밟았을 때 작동하지 않는 것을 정말로 원하지 않습니다. 그리고 다른 것들도 있습니다. 만약 당신이 금융에 있다면, 당신은 거래가 사라지는 것을 원하지 않을 것입니다. 특히 그것이 당신의 계좌로 들어갔을 때 말입니다. 그래서 이것에는 많은 측면이 있습니다. 그리고 흥미로운 것은 많은 영역에서 엄청난 개선이 실제로 가능하다는 것입니다. 이 강연에서 제가 전하고 싶은 메시지 중 하나는, C라고 쓰지 말고, C라고 쓰세요. C라고 쓰세요. 우리는 문서화된 문제들보다 훨씬, 훨씬 더 잘 할 수 있습니다. 그리고, 글쎄요, 우리가 그렇게 하지 않는다면, 다른 누군가가 우리에게 무엇을 해야 할지 말할 것이고, 우리는 그것을 더욱 싫어합니다. 그래서 안전 문제를 무시하는 것은 커뮤니티에 해가 될 것이고, 보장된 안전을 제공하는 것은 C의 가장 좋은 전통이 될 것입니다. 그래서 이것은 실제로 기회입니다. 제 말은, 문제가 여러분이 좋은 일을 하는 것을 막지 못하게 하세요. 그래서 완전한 유형과 리소스 안전이라는 아이디어는 처음부터 C에 있었습니다. Simula는 버그를 제외하고는 완전히 안전한 언어 중 하나였습니다. 저는 그것을 깨는 데 꽤 능숙했습니다. 하지만 우리가 아는 한 가지는 우리가 당시 가지고 있던 하드웨어로는 완전한 안전을 가질 수 없었고 지금도 모든 언어와 모든 용도에서 그럴 수 없다는 것입니다. 하지만 조심하는 것은 두렵지 않습니다. 그래서 우리는 라이브러리가 지원하고 언어 규칙과 분석으로 강화된 신중한 프로그래밍 기술을 사용해야 합니다. 그리고 저는 몇 년 전에 그것을 하는 방법에 대한 기본 모델을 작성했습니다. 사실 여기서 제시했지만, 별로 일어나지 않았습니다. C가 필요합니다. 즉, 우리가 할 수 있는 일에 제한이 없어야 하고, 어떻게 하는지에 제한이 있을 수 있지만, 성능 저하가 없어야 합니다. 이것은 C이고, 실제로 안전한 코드를 작성하는 기술 중 일부는 성능을 개선합니다. 저는 주로 컴파일러와 정적 검사로 할 수 있는 일에 대해 이야기하고 있는데, 무료이거나 실제로 성능을 개선하기 때문입니다. 하지만 물론 정적으로 처리할 수 없는 일을 처리하려면 범위 검사가 필요합니다. 그래서 기본적으로 저는 유형과 리소스 안전성에 대해 이야기하고 있습니다. 그리고 저는 이것이 꽤 잘 정의되어 있다고 생각합니다. 모든 객체는 정의된 유형에 따라 액세스됩니다. 그것이 유형 안전성입니다. 그리고 모든 객체는 적절하게 생성되고 파괴되며 리소스 안전성이 있습니다. 이런 방식으로 리소스를 관리할 수 있습니다. 초기화하지 않으면 어떤 규칙을 어기게 됩니다. 그리고 모든 포인터는 유효한 객체를 가리키거나 널 포인터입니다. 그것이 메모리 안전성입니다. 달성하기 어렵지만, 우리는 할 수 있습니다. 그리고 포인터를 통한 참조는 널 포인터를 통한 참조가 아닙니다. 즉, 우리는 가기 전에 널 포인터를 확인하고, 이러한 유효한 포인터를 역참조해야 하며, 서브스크립트 포인터를 통한 액세스는 런타임 검사가 필요한 범위에 있습니다. 그리고 저는 그것에 대해 이야기하겠습니다. 기본적으로, 이것은 규칙이 요구하는 것입니다. 표준을 읽으면 그것이 요구됩니다. 78년의 데니스 리치의 45페이지 C 매뉴얼을 읽어보세요. 그것이 요구됩니다. 그저 우리가 그것을 하지 않았을 뿐입니다. 그래서 제가 여기에 제시하는 규칙은 발명된 것보다 더 추론된 것입니다. 이 슬라이드에 있는 것을 하는 데 필요한 것에 대해 추론된 것입니다. 그리고 제가 제안하는 시행 규칙은 상호 의존적입니다. 맥락에서 한 가지를 꺼내서 그것으로부터 쉽게 특정된 이점을 얻을 수 있을 것이라고 기대할 수는 없습니다. 무엇을 얻으려고 계획하고 있는지 보려면 무엇을 하는지에 대한 프레임워크가 있어야 합니다. 그리고 C는 여전히 다양한 사용자와 영역을 제공해야 합니다. 우리는 수백만 명의 사용자와 수십억 명의 사람들이 우리에게 의존하고 있으며, 한 가지 크기가 모두에게 맞는 것은 아닙니다. 우리는 그냥 이게 안전이라고 말할 수 없습니다. 모두가 이렇게 합니다. 그것은 잘 안 됩니다. C도 시스템 프로그래밍입니다. 우리는 다양한 방식으로 하드웨어를 조작합니다. 우리는 언어 사양에 알려지지 않은 특이한 하드웨어를 사용하고, 이를 다른 언어로 아웃소싱할 수 없습니다. 소위 안전한 언어 중 많은 수가 모든 저수준 작업을 CSE에 아웃소싱합니다. 그러므로 우리가 그것을 잘 할 수 없다면, C가 남게 될 것이고 기본적으로. 하지만 누군가는 여기서 더러운 일을 해야 합니다. 그리고 우리는 수십억 줄의 기존 코드를 깰 수 없습니다. 저는 할 수 없다고 말하고, 해서는 안 된다고 말하지 않습니다. 왜냐하면 우리는 할 수 없기 때문입니다. 우리가 시도하면, 사람들은 오래된 컴파일러를 사용하고, 다른 하위 집합으로 이동하고, 우리를 무시할 것입니다. 이것은 할 수 없습니다. 그리고 우리는 수백만 명의 개발자를 빠르게 업그레이드할 수 없습니다. 오랜 시간이 걸립니다. 저는 10년이나 20년 된 비디오와 책에서 C를 배운 사람들을 계속 만납니다. 제 말은, 비극적이지만, 최신 자료가 있었다면 훨씬 더 쉬웠을 수도 있고 결과도 훨씬 더 좋았을 수 있었을 겁니다. 최신 순환적 방법을 가르치는 거죠. 하지만 이런 커뮤니티 전체를 앞으로 나아가게 하는 건 대부분의 사람들이 상상하는 것보다 훨씬 어렵습니다. 좋아요, 이런 것들은 어려움이지만, 우리는 개선해야 하고, 할 수 있습니다. 그래서 문제는 타입 안전한 C 사용이란 무엇을 의미하는지 설명하는 것입니다. 정적 타입 시스템 위반 없음, 리소스 누수 없음. 시스템에서 리소스, 메모리 잠금, 파일 핸들 등이 누수되면 서비스 거부 공격과 같은 것으로 충돌시킬 수 있기 때문에 안전하다고 생각하지 않습니다. 아니면 그냥 엉성하게 해서 리소스가 고갈되면 충돌시킬 수도 있습니다. 그래서 저는 리소스 안전성에 매우 관심이 많습니다. 그리고 이것은 실제로 처음 두 주 동안 순환적 플러스 플러스에 들어온 것 중 하나이고, 개발자들이 이렇게 하도록 설득해야 합니다. 지저분하고 복잡하고 저수준의 작업을 하면 더 빨라야 한다는 믿음이 많이 있습니다. 그리고 더 나아가, 저는 제가 얼마나 똑똑한지 보여주기 위해 이런 지저분하고 저수준의 복잡한 것을 쓸 수 있습니다. 이건 효과가 없습니다. 효과가 있습니다. 우리는 프로그래밍 수준을 높이고 이것을 대규모로 작동시켜야 합니다. 제 말은, 제가 학생들에게 말한 대로 하게 할 수 있다는 것입니다. 그렇지 않으면 나쁜 성적을 받을 테니까요. 만약 당신이 관리자라면, 사람들이 당신이 좋아하는 방식으로 코드를 쓰게 할 수 있습니다. 그렇지 않으면 급여가 오르지 않거나 해고됩니다. 하지만 대규모로, 우리는 실제로 사람들을 설득해야 합니다. 그들은 그것이 사실이라고 믿어야 합니다. 그래서 그게 중요한 것입니다. 그리고 수십 년에 걸친 안정성이 중요합니다. 제 말은, 사람들이 오늘 작성한 코드가 10년 후에도 실행될 것이라고 믿는 유일한 이유는 10년 전에 작성한 코드가 오늘날 실행되기 때문입니다. 그리고 안전성은 단순히 유형 안전성이 아닙니다. 제가 보는 대부분의 영역은 논리적 오류라고 생각합니다. 예상보다 크고 비용이 매우 큰 곳에서는 동등하지 않은 것을 보았습니다. 그리고 프로그램이 그렇게 한다는 것을 증명하고 싶다면, 정확히 무엇을 얻을 수 있습니까? 매우 제한적인 언어. 그 방향으로 가는 AdA 코드가 있습니다. 리소스 누수. 저는 동시성 오류에 대해 언급했습니다. 우리는 문제를 확장하고 그런 것들을 할 수 있도록 많은 동시성을 수행하고 있으며, 이것이 작동하는지 확인해야 합니다. 객체가 적절한 방식으로 사용되지 않았기 때문에 발생하는 모든 동시성 오류 유형 위반을 고려할 수 있지만, 직접 분석하고 해결할 수 있도록 분리하는 것이 좋습니다. 메모리 손상, 우리는 그저 그 유형 오류를 제거해야 합니다. 많은 비용과 void 스타 및 그와 같은 다른 까다로운 것들이 있는 저수준 코드를 사용하는 경우, void는 더 심하고, 우리는 그것을 피하고 타이밍 오류를 피해야 합니다. 예를 들어 1.2밀리초 내에 응답이 필요한 경우, 그것은 아닙니다. 제 시간에 도착하지 않으면 많은 실시간 제어 애플리케이션과 할당 예측 불가능성에서 충분하지 않습니다. 무료 스토어 인 플라이트 소프트웨어 사용에 대한 금지가 있습니다. 엔진이 시작된 후에는 무언가를 할당할 수 없고, 어떤 시점에서도 무언가를 할당 해제할 수 없습니다. 단편화와 같은 일이 발생할 수 있기 때문입니다. 즉, C에서 별도로 관리되는 메모리 청크가 매우 중요하다는 의미입니다. 모든 중요한 애플리케이션에는 메모리를 직접 관리하는 측면이 있습니다. 벡터는 첫 번째이자 가장 간단한 예입니다. 우리 모두 그것을 사용하고 있습니다. 실제로 메모리 청크를 가져와서 관리합니다. 그리고 종료 오류입니다. 종료가 허용되지 않는 시스템을 다루었습니다. 이제 프로세서가 40,000개라고 가정하면 매일 또는 적어도 매주 무언가가 충돌할 것이라는 점을 고려해야 합니다. 따라서 프로세서에 문제가 있으면 작동하도록 소프트웨어를 작성했기 때문에 충돌시키면 된다고 말하는 전략을 가질 수 있습니다. 하지만 그런 추가적인 것이 없다면 어떨까요? 충돌이 허용되지 않는다면 어떨까요? 제 친구는 스쿠버 컨트롤러를 프로그래밍하고 있다고 지적했습니다. 테마에는 프로세서가 하나뿐입니다. 아니요, 충돌은 옵션이 아닙니다. 일부 금융 시스템은 합법적으로 거래를 잃을 수 있기 때문에 충돌할 수 없고, 그것은 합법적으로 허용되지 않습니다. 그래서 여기에는 많은 것이 있습니다. 이런 종류의 예가 있는 다른 슬라이드나 반 슬라이드를 찾을 수 있을 것입니다. 우리는 무엇을 하려고 하는지 말할 수 있어야 합니다. 우리는 모든 것을 모든 곳에서 하려고 하지 않습니다. 많은 사람들에게 필요하지 않기 때문입니다. 그리고 어쨌든 우리가 말하는 규모에서는 실행 불가능합니다. 따라서 보안은 메모리 안전도 아닙니다. 보안과 안전 사이에 혼란이 있었습니다. 유형 안전. 유형 안전은 보안이 아닙니다. 저는 수년 전 Bell Labs에서 보안 과정을 수강했습니다. 첫 번째 수업은 자물쇠 따기였습니다. 두 번째 수업은 배지를 사용하여 건물에 들어갈 수 없습니다. 컴퓨터, 모든 백업 테이프, 모든 메모리 스틱을 가져올 수 있다면, 당신의 물건을 가져갈 수 있습니다. 내부 스파이 공격. 대규모 조직이라면, 회사의 일이 아닌 무언가에 대해 매수되거나 이상주의적으로 행동할 수 있는 자유로운 사람들이 있습니다. 스피어 피싱은 분명히 매우 잘 작동합니다. 충분히 많은 곳을 시도하면 문이 덜거덕거리고, 사람들은 올바른 일을 하지 않았습니다. 서비스 거부, SQL 주입, 손상된 입력 데이터. 따라서 무언가를 공격하려면 항상 가장 약한 고리를 공격합니다. 뉴하트 공항에서 차가 도난당하는 것을 피하는 방법은 무엇이냐고 들었습니다. 답은 더 좋은 차 옆에 주차하는 것입니다. 제가 지적하고자 하는 것은 유형 안전, 메모리 안전 및 이와 유사한 것들에 대한 것입니다. 하지만 보안과 혼동하지 마십시오. 보안은 시스템 속성이며, 시스템에는 컴퓨터, 사람, 저장 공간, 물리적 사물, 많은 것들이 포함됩니다. 저는 이 모든 것에 대해 말하는 것이 아니지만, 누군가가 와서 보안을 외치면 프로그램에 버그가 있을 수 있다는 것을 기억하십시오. 언어는 안전하지 않습니다. 이런 것보다 더 큰 것을 쓰는 대신 덜 쓰는 것과 같은 것입니다. 그리고 모든 안전한 범용 언어에는 이스케이프 절이 있습니다. 하드웨어 리소스에 액세스해야 합니다. 핵심 추상화의 효율성을 개선해야 합니다. 안전한 연결 리스트 구현을 하는 것은 검증된 안전성을 원한다면 매우 매우 어렵습니다. 보류 문제에 직면해 있다고 생각하지만, 거의 불가능하다고 합시다. 그래서 우리가 하고 싶은 일이 있고 검증 가능성이 없는 기술을 사용해야 합니다. 그리고 작동하는 신뢰할 수 있는 코드 세그먼트가 있습니다. 물론, 이것들은 문제가 있는 곳이지만 덜 엄격한 규칙에 따라 작성된 라이브러리 코드도 있습니다. 무언가를 호출해야 합니다. C로 작성된 운영 체제는 어떨까요? 그 이유로 운영 체제를 검증할 수 없습니다. 너무 복잡합니다. 그리고 종종 이스케이프 절은 C입니다. 그래서 우리는 모든 안전하지 않은 영역을 그냥 닫을 수 없습니다. 중요한 곳에서 안전하고, 중요한 곳에서 보장되고, 가급적이면 기본적으로 하는 것이 정말 좋습니다. 따라서 절대적인 안전성을 얻을 수 없다는 것을 지적하는 것은 안전성 문제를 무시할 변명이 아닙니다. 실제로 진전을 이룰 수 있는 곳에 노력을 집중해야 한다는 주장입니다. 그래서 저는 역사를 되돌아보고 있습니다. 제가 C로 시작한 이유 중 하나는 하드웨어를 다루고 싶었고, 더 나은 코드를 작성할 수 있도록 하드웨어에서 추상화하고 싶었기 때문입니다. 그리고 정적 유형 안전성이 그 아이디어였습니다. 저는 잠시 동안 정적 안전 언어, 즉 C의 많은 상위 수준의 근원인 simula를 포함하여 작성하고 작성했습니다. 우리는 클래스, 캡슐화, 그런 것들을 가지고 있었습니다. 하지만 그것은 이해하기 어려운 이상입니다. 때로는 진보가 필요하고, 때로는 우리가 이해하는 것에 더 나은 진보가 필요하기 때문입니다. 때로는 더 나은 하드웨어가 필요합니다. 따라서 하드웨어의 효율적인 사용, 그것이 C가 관리되는 곳이고, 복잡성, 그것이 simula가 있는 곳입니다. 그리고 저는 우리가 그것을 감당할 수 있는, 우리가 할 수 있는 유사한 영역으로 우리를 더 많이 옮기려고 노력해 왔습니다. 좋아요, 제가 시작했을 때, 제곱근을 호출하려면 머신이 충돌할 수 있었습니다. 제곱근 2는 운이 좋으면 머신을 충돌시킬 것입니다. 그렇지 않으면 나쁜 결과가 나올 뿐입니다. 요점은 컴파일러가 double이 필요하다는 것을 잊었고 변환되지 않았다는 것입니다. 그래서 제가 가장 먼저 한 일 중 하나는 그런 것들이 충돌하지 않도록 하는 것이었습니다. 충돌은 안전 문제로 간주되기 때문입니다. 사실, 저는 바로 이 일을 시작했다고 할 수 있습니다. 오늘날 언어를 강화하는 맥락에서 매우 흥미로웠던 것은 그 작은 수정으로 10년 동안의 문제를 겪었다는 것입니다. 오늘날의 c도 그렇습니다. 하지만 논란의 여지가 있었습니다. 무슨 뜻인지 알아보려면 선언문을 봐야 한다는 말인가요? 그냥 코드만 볼 수는 없습니다. 제가 많이 들었던 주장이었습니다. 호환되지 않습니다. 그래서 사람들이 c, c, 뭐든 초기에는 싫어할 때마다, 오, 호환되지 않아요, 달라요라고 지적했습니다. 제대로 하지 않았어요. 글쎄요, 호환되지 않으면 제 타입 안전을 얻을 수 없었습니다. 그리고 제가 배운 한 가지는 사람들이 c와 같은 언어를 사용하고 싶지 않을 때, 무언가를 골라서 오, 오늘날에는 그런 게 없어요. 안전합니다. 안전하지 않아요. 알겠습니다. 어쨌든 필수적이었습니다. 유형 검사, 오버로딩, 사용자 정의 유형, 일관된 연결, 유형 안전 연결, 이 모든 것들은 언어가 인수 검사를 제대로 지원해야 한다는 것을 요구합니다. 좋습니다. 그래서 때로는 그냥 해야 합니다. 중요합니다. 그리고 저는 우리가 안전 문제에 대해 다시 다룰 것이라고 생각합니다. 그리고 기본적인 아이디어는 코드에서 사물을 표현하고 사용할 수 있는 추상화를 만드는 것이었습니다. 그러면 코드가 더 단순해지고 실제로 더 안전해집니다. 벡터 문자열 파일은 동시 작업 메시지 대기열을 처리합니다. 다 다 다 다 다 다. 안타깝게도 오늘날에는 모두 표준이 아니지만 대부분은 그렇습니다. 일이 시간이 걸립니다. 안전을 해결하려면 그 개념을 지원하는 추상화가 필요하다고 생각합니다. 그리고 불변성은 일찍 등장했습니다. 저는 Const가 필요하다고 느꼈습니다. 저는 운영 체제와 그런 것에서 벗어나고 있었고, 상수가 있다면 일어날 수 없는 일, 일어나기를 원하지 않는 일을 알고 있었습니다. 사실, 제가 정말로 원했던 것은 읽기 전용과 쓰기 전용이었습니다. 하지만 저는 C 개발자들과 이야기를 나누었고 그들은 Const를 사용할 것이고 읽기 전용과 쓰기 전용은 사용하지 않을 것이라고 말했습니다. 우리는 그걸로 더 나았을 겁니다. 하지만 괜찮습니다. 기본적으로 작은 상수를 사용할 수 있고 이런 식으로 인터페이스를 사용할 수 있습니다. 그렇게 하면 더 나은 인터페이스를 얻을 수 있습니다. 이것도 계속되는 일입니다. RaiI는 처음 두 주 동안 객체를 생성하고, 객체를 초기화하고, 객체의 불변성을 설정하는 생성자가 있었습니다. 캡슐화가 있다면 필요합니다. 캡슐화가 없더라도 코드에 대해 생각할 수 있도록 캡슐화가 필요합니다. 그리고 작업이 끝나면 리소스를 확보했다면 다시 돌려줘야 합니다. 그렇지 않으면 리소스 누수가 발생합니다. 모든 사서가 사람들이 책을 빌려가서 돌려주는 것을 잊을 것이라고 말할 것입니다. 일종의 인간 본성이며, 우리는 이런 일을 규모에 맞게 해야 합니다. 따라서 리소스 해제는 자동화되어야 합니다. 그리고 그 당시에는 제가 용어를 발명하지 않았기 때문에 다소 다르게 표현되었습니다. 하지만 오늘날에는 그것이 있고, 우리 모두가 그것을 사용하고 있기를 바랍니다. 메모리가 아닌 리소스의 예에는 파일 핸들, 잠금, 소켓, 셰이더 등이 있습니다. 좋아요, 기본적으로 여기에 리소스 누수의 예가 있습니다. 이것은 순진하고 안전하지 않은 코드입니다. 그리고 저는 그것을 많이 보곤 했습니다. 사람들이 파일을 열고, 파일을 확보하고, 파일 핸들을 사용하고, 다시 나갑니다. 그리고 코드는 사실 그렇게 좋지 않습니다. 때로는 두 페이지 길이이고, 그 안에 return 문이나 긴 점프 또는 예외가 있습니다. f를 사용하면 fclose에 도달하지 못합니다. 따라서 그런 코드가 없어야 합니다. 컴파일러가 보는 모든 것, 우리가 보는 모든 분석, 프로그래머가 보는 모든 것은 포인터가 함수에서 나오고 매뉴얼에 다른 함수로 다시 반환해야 한다고 나와 있다는 것입니다. 이것은 좋은 코드가 아니며 버그의 원천이었습니다. 그래서 우리가 하는 것은 코드에서 직접 사물을 표현하는 것입니다. 리소스에 대해 말하면 코드에 있어야 합니다. 앗, 제가 그랬나요? 허, 이상하네요. 순서가 뒤바뀌었습니다. 어쨌든 객체 지향 프로그래밍은 잘 정의된 인터페이스, 클래스, 추상 기본 클래스, 오버로딩 등 모든 종류의 것에서 나왔습니다. 물건. 체크 무늬 재킷을 입은 사람은 올리오한 달이고 다른 재킷을 입은 사람은 크리스틴 누고입니다. 그는 상속과 기본적으로 객체 지향 프로그래밍을 발명한 사람입니다. 하지만 파일 핸들을 처리하는 방법을 보여주는 슬라이드를 놓친 곳에서, 당연히 파일 핸들 클래스를 만들고 그 구조가 파일을 닫고 문제는 해결됩니다. 그리고 우리는 그것을 더 많이 해야 합니다. 그래서 언어의 진화는 물론, 지속적인 템플릿을 통해 컴파일 타임에 구현을 선택할 수 있었고, 마침내 개념을 얻었습니다. 그래서 우리는 정확하게 정의된 인터페이스를 가지고 있고, 우리는 그것을 일관되게 사용해야 합니다. 제가 타임머신을 가지고 있다면, 88년으로 돌아가서 개념에 대해 말했을 것이고, 훨씬 더 나은 템플릿을 가지고 있었을 것이고, 컨테이너를 설계하고 구현하는 것이 더 쉬웠을 것입니다. 그래서 우리는 배열과 포인터를 만지작거릴 필요가 없습니다. 그리고 그것은 범위 검사를 가능하게 합니다. 컨테이너를 범위 검사하는 데 사용할 수 있는 충분한 정보가 있으며, 주요 구현 구현에는 범위 검사 벡터가 있습니다. 불행히도 그것에 대한 표준이 없고, 컴퓨터로 걸어가서 아무것도 하지 않고 비가 오는 것을 볼 수는 없습니다. 그것은 슬픈 일이라고 생각하고, 안전과 알고리즘의 맥락에서 관련이 있습니다. 우리는 전통적인 STL begin end를 사용했고, 이제 벡터나 컨테이너를 정렬할 수 있습니다. 그리고 다시 말해서, in에서 begin으로 정렬할 수 없거나 그런 것과 같은 버그를 만들 수 없다는 것을 의미합니다. 더 간단하고 명확하고 안전해집니다. 그리고 스마트 포인터를 사용할 수 있지만 여전히 포인터입니다. 그래서 루프에 대한 범위와 span이 있습니다. c 스타일 루프는 일종의 의심입니다. 제 말은, n이 실제로 요소의 수인가요? 그리고 언어 관점에서 볼 때, 범위 검사를 할 수 있는 포인터에 충분한 정보가 없기 때문에 범위 검사를 할 수 없습니다. 이제 크기를 아는 span이 있습니다. 필요한 곳에서 범위 검사를 할 수도 있고, 그 예에서처럼 전체를 할 수도 있습니다. 다시 한번 말씀드리자면, 데니스 리치와 저는 80년대에 이 문제에 대해 논의했고, 그는 span인 뚱뚱한 포인터를 원했습니다. 저도 그랬지만, 그것을 얻는 데 시간이 좀 걸렸습니다. 이게 아니고, 제 말은, 데니스가 c를 제어했다면 20년 전에 이런 일이 있었을 겁니다. 그리고 사라진 슬라이드가 여기 있습니다. 제자리에 놓겠지만, 기본적으로 적절한 검사를 수행하고 적절한 리소스를 해제하는 적절한 추상화를 통해 문제를 해결합니다. 좋습니다. 늦었지만 결코 늦지 않습니다. 좋아요, 저는 circummental에 대한 이상을 썼고, 기본적으로 첫 번째 사항 중 하나는 정적 유형 시스템을 암묵적으로 위반하지 않는 것입니다. 그리고 거기에는 꽤 많은 것들이 있습니다. 요점은, 제가 안전과 더 안전한 것에 대해 이야기할 때 이것은 잠시 동안 문서화되어 왔다는 것입니다. 그리고 상위 수준은 어제 시작된 것이 아닙니다. 그것은 언어의 가장 좋은 전통이며, 언어를 사용하면 이점이 있습니다. 글쎄요, 여기서 이야기하는 기능을 사용하고 삭제해야 하는 원시 포인터를 피하세요. 소유하는 원시 포인터. 실제로 범위가 무엇인지 모르기 때문에 원시 포인터를 서브스크립트하지 마세요. 그리고 무언가를 가리키는지 확인하기 전에 원시 포인터를 역참조하지 마세요. 초기화되지 않은 변수가 없으면 할 수 있습니다. 제가 2001년에 초보자를 위해 쓴 책에서, 그래픽을 하는 방법을 보여준 후 17장에서 포인터와 배열을 보여주기 전까지는 아무것도 보여주지 않는 것 같습니다. 할 수 있습니다. 좋은 c, 더 높은 수준의 C는 일관된 기능 세트입니다. 실제로 저수준의 것들을 건드리지 않아도 되므로 정말, 정말 해야 합니다. 거기까지 가지 않고도 완벽하게 좋은 코드와 완벽하게 좋은 애플리케이션을 작성할 수 있습니다. 따라서 안전성을 원한다면 C C를 쓰지 마세요. 그런 언어는 없지만 사람들이 그것을 가지고 있다고 생각할 만한 용도가 분명히 있습니다. 그들은 그것이 c라고 말하고, 이전 슬라이드에서 말한 모든 것을 하고, 더 높은 수준의 것들을 피하고, 보통 성능 문제를 주장하고 측정하지 않습니다. 저는 때때로 대학원생을 가르치는데, 그들은 여전히 측정 방법을 모르고 효율성에 대해 이야기합니다. 이런 일이 일어나서는 안 됩니다. 어쨌든, 우리는 입증 가능한 안전에 대한 스타일을 발전시켜야 합니다. 입증 가능한 안전은 다루기 가장 쉬운 일이기 때문입니다. 생각하기 가장 쉬운 일입니다. 그리고 평소처럼 저는 사람들을 설득하려고 노력하고 있습니다. 한계가 있으므로 조심하는 것은 확장되지 않습니다. 우리는 안전한 사용을 위한 규칙을 공식화해야 합니다. 사람들이 실제로 하려는 것을 하는지 확인할 수 있는 방법을 제공해야 합니다. 저는 여기 있는 누구도, 제가 배제되지 않았지만, 코드를 작성하지 않고 무언가를 한다고 생각했지만 그렇지 않은 사람은 없다고 생각합니다. 저는 그것이 잘 일어난다고 말하고 싶습니다. 아마도 매주 일어날 것입니다. 저에게는요. 그래서 저는 컴파일러를 좋아합니다. 그리고 우리는 우리가 말하는 것을 이해할 수 있도록 지침을 명확히 해야 합니다. 복잡한 규칙이나 그리스 문자의 길고 긴 목록은 실제로 따르기 쉽지 않을 것입니다. 그리고 필요한 경우 지침을 시행해야 합니다. 필요한 경우 이것이 내 코드에서 원하는 것이라고 말해야 하기 때문입니다. 나중에 설명하겠습니다. 따라서 사태의 상태는 본질적으로 모든 것입니다. 과거에 제가 설명한 내용과 나머지 강연에서 설명할 내용은 시도되었고, 범위 검사, 문자열, 벡터 및 span과 같이 많은 것이 대규모로 시도되었습니다. 그러나 모든 것이 일관되고 일관성 있는 전체로 통합된 곳은 없습니다. 제가 주장하는 바가 바로 그것입니다. 제가 이야기하는 작업의 대부분은 핵심 지침에 대한 작업의 영향을 받지만 지침보다 더 나아가야 합니다. 제가 말했듯이 조심하는 것만으로는 확장되지 않으며 목표는 여전히 보장됩니다. 유형 및 리소스 안전 C와 다른 것들도 있습니다. 이 유형 및 리소스 안전은 매우 기본적이지만 원하는 다른 것들이 있으므로 이러한 다른 것들이 무엇인지 지정해야 합니다. 그리고 오늘 많은 일을 할 수 있습니다. 표준의 새 릴리스나 그와 비슷한 것을 기다릴 필요가 없습니다. 그리고 이것은 안전에 대한 것만이 아닙니다. 더 높은 수준으로 이동하여 수행해야 할 작업을 더 명확하게 표현함으로써 코드가 속도를 높이는 것을 보았습니다. 내가 무슨 일이 일어날지, 무엇을 해야 할지 이해할 수 있다면, 옵티마이저도 이해할 수 있습니다. 그리고 종종 여러분은 혜택을 얻습니다. 요즘 제가 디버깅하고 속도를 높이는 가장 좋은 방법 중 하나는 복잡한 부분을 제거하고 옵티마이저가 잘 처리할 수 있는 남은 부분을 제거하는 것입니다. 오, 알겠습니다. C 코어 가이드라인 또는 정보 제공을 위해서요. 그것은 하이엔드 칩을 하이엔드 프로세스, 본질적으로 모든 것을 만드는 기계입니다. 그리고 물론, 그것은 C로 프로그래밍되어 있습니다. 그들은 저에게 연락하여 훌륭한 C 프로그래머를 고용하는 데 도움을 줄 수 있는지 물었습니다. 아니요, 저는 그 사업을 하지 않습니다. 하지만 정말 훌륭한 C 프로그래머는 정말 흥미로운 일을 할 수 있습니다. 일반적인 전략. 우리는 잠재적 오류를 제거하기 위해 정적 분석에 의존하고 있으며, 이는 일반적인 코드에서는 불가능합니다. 올바르다는 것을 증명할 수 없는 코드를 작성하는 것은 충분히 쉬운데, 글로벌 정적 분석은 감당할 수 없는 규모일 뿐입니다. 따라서 기본적으로 우리는 우리가 쓰고 있는 것을 단순화하기 위한 규칙이 필요하고, 효율적이고 저렴하게 분석할 수 있는 무언가가 필요합니다. 로컬 정적 분석. 그리고 그런 일을 하는 핵심 가이드라인에 대한 분석기가 몇 가지 있고, 그런 다음 이러한 규칙에 의존하는 것을 실현 가능하게 하는 라이브러리를 제공합니다. 언어 수준에서 모든 것을 해야 한다면, 쓰기가 느리고 불편해지고, 그러면 우리는 그것을 하지 않을 것입니다. 올바른 추상화와 올바른 라이브러리를 사용하면 거의 모든 것이 즐거워집니다. 좋아요, 여기에는 철학이 있습니다. 이것은 제가 만든 슬라이드인데, 거의 10년 전에 몇 가지를 빨간색으로 강조했습니다. 정적 유형 안전은 컴파일 시간에 검사할 수 있고, 리소스를 누출하지 않으며, 불변 데이터를 선호합니다. 이 모든 것은 안전과 관련이 있습니다. 다시 말하지만, 이것은 C의 가장 좋은 전통이며 쓰기 수준을 높이는 것입니다. 그리고 이러한 이상을 구현하는 데 사용하는 저수준 규칙이 있습니다. 기본적으로 우리는 원하는 것을 명시한 다음, 그것을 근사적으로 얻을 수 있도록 하는 긴 규칙 목록을 만듭니다. 그리고 그것이 저수준의 것들입니다. 그렇습니다. 그리고 제가 다음에 이야기할 핵심 가이드라인과 프로필의 전략은 관찰 단순 서브세팅이 작동하지 않는다는 것입니다. C를 뭔가 안전하고 우아한 것으로 서브셋하고 싶다면, 가장 먼저 제거해야 할 것은 소멸자에서 암묵적으로 해제하지 않고 원시 포인터와 명시적 메모리 관리를 구독하는 것입니다. 글쎄요, 그것을 없애버리면 아무것도 만들 수 없습니다. 그래서 대신 더 나은 추상화, 벡터, 스마트 포인터, 파일 핸들 클래스 등을 만드는 것입니다. 그리고 그것이 끝나면 맨 아래에 있는 복잡하고 위험한 것들을 많이 제거할 수 있습니다. 이 전략은 효과가 있는 것 같습니다. 물론 STL, 표준 라이브러리를 사용하고, 그다음에 span이 유래한 작은 지원 라이브러리인 GSL이 있습니다. 그리고 많은 사람들이 여전히 GSL span을 사용하는 이유는 범위가 보장되기 때문입니다. 하지만 요점은 새로운 언어 기능을 추가하지 않는다는 것입니다. 저는 이 모든 것을 사용한 결과가 ISO 표준 C가 되기를 바랍니다. 새로운 언어를 설계하고 싶지 않습니다. 너무 힘들고 시간이 너무 오래 걸립니다. 지금 코드를 작성하고 싶습니다. 좋은 코드입니다. 그래서 우리가 원하는 것은 스테로이드를 투여하는 것이지, 불쌍한 하위 집합이 아닙니다. 알겠어요? 그리고 우리는 실제로, 알겠어요, 제가 1시간 조금이 아니라 10시간이 있다면, 저는 이것을 살펴보고, 듣고, 우리가 그 모든 것을 할 수 있다고 주장할 수 있을 것입니다. 물론, 이를 위한 시간은 없습니다. 이것은 핵심 내용이며, 심층적인 기술 탐구가 아닙니다. 따라서 초기화되지 않은 변수, 범위 오류, 지식 포인터 역참조, 리소스 목록 및 매달린 참조를 제거할 수 있습니다. 우리는 더 많은 것을 할 수 있습니다. 유니온은 변형과 캐스트를 사용하지만, 그냥 하지 마세요. 오버로딩과 템플릿 프로그래밍은 올바르게 수행하면 대부분의 비용을 제거합니다. 언더플로우. 저는 직접 작업하지 않았지만, 엔진 사진을 보여드렸습니다. 이전에 선박용 디젤 엔진이 너무 커서 주의 깊게 보면 실린더 헤드 번호 5로 엔지니어를 볼 수 있었습니다. 그리고 그것은 언더플로우와 오버플로우를 검사하는 일반적인 프로그래밍으로 실행되므로 수행할 수 있습니다. 저는 그것에 대한 구체적인 제안이 없습니다. 그리고 데이터 지우개를 처리하는 몇 가지 방법이 있지만, 적어도 하루 종일 걸립니다. 그게 전부입니다. 초기화되지 않은 변수입니다. 그냥 하세요. 초기화처럼 작동하는 지연된 초기화를 갖는 영리한 방법이 많이 있지만, 코드가 취약해지고 컴파일러가 모든 객체가 적절하게 초기화되었는지 확인하는 데 문제가 없더라도 사람이 무슨 일이 일어나고 있는지 보기 어렵습니다. 저는 모든 것을 초기화하는 것을 지지합니다. 예외적인 사례가 하나 있는데, 적어도 더 많을 가능성이 있는데, 거대한 버퍼입니다. 그리고 대기 시간이 짧은 작업을 하는 경우, 먼저 버퍼를 초기화한 다음 좋은 것으로 채우고 싶지 않을 것입니다. 그러면 버퍼를 채우는 데 걸리는 시간이 두 배가 됩니다. 초기화 규칙에서 이스케이프 절을 사용하여 표시할 수 있는 항목이 필요한 산업이 꽤 있다고 생각합니다. 이것은 초기화되지 않았으므로 코드에서 눈에 띄므로 재킷과 같은 것을 확인할 수 있습니다. 이러한 규칙 중 많은 부분이 현실적이 되려면 일종의 이스케이프 절이 있어야 하며, 사람과 정적 분석기가 무슨 일이 일어나고 있는지 이해할 수 있도록 명시적으로 지정해야 합니다. 범위 검사는 물론 범위 검사를 원합니다. 개별 포인터의 구독은 원하지 않습니다. C 스타일 코드를 작성한다면 겁에 질려야 하지만 없어도 됩니다. 벡터와 스팬은 범위 검사를 수행할 수 있는 두 가지 주요 예이며, 때로는 포인터로 검사할 수 있는 충분한 정보가 있기 때문에 수행되기도 합니다. 그렇지 않습니다. 범위를 올바르게 검사했는지 신뢰해야 하며 때로는 제대로 검사하지 못하므로 추상화를 사용하는 것이 훨씬 좋습니다. 범위 4는 정말 좋습니다. 시작과 끝만 검사하면 되기 때문에 정적 검사를 많이 제거합니다. 알고리즘은 좋습니다. 2주 전에 많은 학생들에게 루프를 측정하게 했습니다. 그들은 각각에 대해 정말 깊은 충격을 받았고 손으로 코딩한 C 스타일 루프를 눈에 띄게 이겼습니다. 하지만 제 학생들을 보셨어야 합니다. 알겠습니다. 당연합니다. 그들은 저수준의 것들이 중요하고 효율적이라고 들었기 때문에 종종 신경망이 여기를 가리킨다고 합니다. 널이 아닌 포인터가 있는지 확인하는 것은 꽤 쉽습니다. TSL에 추상화가 있습니다. 아니면 정적 분석기가 사용에 충분히 가까운 테스트가 있는지 확인하여 수행되었는지 확인할 수 있습니다. 다시 말하지만, 분석기가 지나치게 똑똑해지기를 바라지 않습니다. 저도 이해하고 싶기 때문입니다. 리소스 누수가 없습니다. RaII를 따르는 추상화를 사용하여 일관성을 유지하세요. 우리는 추상화를 많이 가지고 있습니다. 맨손으로 new를 실행하면 코드 냄새가 납니다. 사용하지 마세요. 맨손으로 delete를 실행해도 마찬가지입니다. 사용하지 마세요. 애플리케이션 코드가 아닙니다. 추상화 구현에 속합니다. 그리고 저는 이와 비슷한 코드를 상당히 많이 봅니다. 대부분 Java와 C sharp에서 온 사람들이 만든 코드인데, 사용자를 가져오려면 new를 말해야 하고, 사용자 정의 클래스의 객체를 가져와야 합니다. 그래서 가젯이 있는 것입니다. 가젯 내부에 무엇이 있는지 모르겠습니다. 잠금을 잡을 수도 있고, 파일 핸들과 같은 것을 잡을 수도 있습니다. 그리고 코드를 작성하고 나서 삭제해야 한다는 것을 기억해야 합니다. 그리고 사람들은 꽤 현실적으로 말합니다. 글쎄요, 저는 삭제를 쓰고 싶지 않지만 가비지 콜렉터를 원한다고 합니다. 하지만 가비지 콜렉터는 가젯 내부에 있는 것 때문에 도움이 되지 않습니다. 무엇인지 알 수 없습니다. 명시적으로 해제해야 하는 것일 수 있으며, 해당 코드는 물론 throw하고 나가서 삭제에 도달하지 못하거나 반환할 수 있습니다. 완벽하게 평범한 것들입니다. 하지만 이것은 예외와는 아무런 관련이 없습니다. 저는 예외를 좋아하고, 이런 종류의 것에 정말 좋습니다. 그게 없이도 문제가 생길 수 있습니다. 그리고 리소스 핸들, 우리는 요즘 많은 고유 포인터와 공유 포인터를 사용하고, 그것이 문제를 해결합니다. 이제 우리는 구조가 호출되고 모든 것이 적절하게 해제되고 간단하고 저렴하다는 것을 보장받습니다. 하지만 여전히 포인터이고 여전히 무료 저장소를 사용합니다. 할당이 있습니다. 따라서 우리가 실제로 해야 할 일은 거기에 더 많은 로컬 객체를 두는 것입니다. 모든 것이 추가된 표기법과 추가된 할당 없이 작동합니다. 물론, 스택 공간이 매우 제한된 임베디드 프로세서를 위한 코드를 작성하는 경우 이에 대해 조심해야 합니다. 하지만 일반적인 프로그래밍에서, 그리고 실제로 대부분 프로그래밍에서 이것이 선호됩니다. 걱정해야 할 것은 이것뿐만이 아니라, 당신은 맨살의 새로운 것을 보고 분석가가 쉽게 경고할 것입니다. 하지만 당신은 스마트 포인터에 대해서도 약간 의심해야 합니다. 왜냐하면 그것들은 정말 우아하지 않기 때문입니다. 좋아요, 그럼 매달린 포인터, 당신은 정말로 매달린 포인터를 제거해야 합니다. 매달린 포인터로 인해 일어날 수 있는 온갖 나쁜 일들이 있습니다. 당신은 그것을 통해 다른 사람의 메모리에 쓸 수 있고, 그것을 읽고 쓰레기 데이터를 얻을 수 있고, 사물을 뒤섞을 수 있습니다. 이것은 정말 나쁩니다. 그리고 포인터란 객체를 직접 참조하는 모든 것을 의미합니다. 매달리는 것이 허용된다면 이것은 스마트 포인터가 될 수 있습니다. 참조일 수도 있고, 당신이 명명할 수 있습니다. 그리고 우리는 그것들을 제거해야 합니다. 우리는 규칙의 조합과 원시 포인터가 소유자가 아니라고 가정함으로써 그것들을 제거할 수 있습니다. 그래서 우리는 여기서 메모리 관리 문제로 인해 간섭을 받지 않아도 됩니다. 좋아요, 여기 괜찮지 않은 코드가 있습니다. 무해해 보입니다. 포인터를 가져와 삭제합니다. 글쎄요, 제가 만든 규칙에 따르면 그것은 벌거벗은 nu이고 분석기는 그것을 거부합니다. 그리고 그것은 좋은데, 왜냐하면 g를 볼 때, 그것은 무언가를 객체로 만들고, 그것을 f에 전달한 다음 그것을 사용하기 때문입니다. 거기에서 사용하는 것은 매달린 포인터의 사용입니다. 그리고 물론 실제 코드에서 void f는 그렇게 보이지 않습니다. 아마 여러분이 본 적이 없는 어딘가의 라이브러리에 있는 o일 것입니다. 하지만 정적 분석기는 이것을 처리할 수 있습니다. 그리고 저는 정말로 이런 일이 제 코드에서 일어나지 않는다는 보장을 원합니다. 그리고 여러분이 하는 것은 모든 객체가 단 하나의 소유자를 가지고 있다는 것을 처리하는 것입니다. 즉, 우리는 누가 삭제, 닫기 또는 여러분이 부르는 것을 해야 하는지 알고 있습니다. 그리고 소유자가 있던 곳 뒤의 실행에 있지 않는 한, 원하는 만큼 많은 포인터가 있을 수 있습니다. 이것은 매우 간단한 모델이며 적용할 수 있습니다. 여기에 예가 있습니다. 여기 로컬 변수가 있는 함수가 있는데, 그 주소로 g를 호출하고, g는 전역에 저장합니다. 이걸 멈춰야 합니다. 이걸 분석해서 인수로 들어온 것을 전역에 저장하는 건 옳지 않다고 말해야 합니다. 유효한지 알 수 없으니까요. 실행한 후에는 종료합니다. 반면에 포인터에서 얻는 건 꽤 괜찮은데, 이 규칙에 따르면 함수에 들어올 때 유효하고, 함수에서 다시 나올 때까지 유효하기 때문입니다. 범위 밖에서 왔기 때문입니다. 여기서 무엇을 얻었을까요? 컨테이너, 포인터, 뭐든 기억하세요. 점은 컨테이너에 있을 수 있습니다. 그래서 정수 벡터를 가져왔습니다. 나머지는 뭔가였고, 괜찮습니다. 포인터, 반복자, 어디서 호출하든 컬렉션을 만들고, 호출할 함수를 몇 개 제공하면 함수가 다시 돌아옵니다. 모든 게 괜찮습니다. 포인터가 호출 코드 f hereda에서 유효하다는 사실은 콜드 코드에서도 유효하다는 것을 의미하기 때문입니다. 괜찮습니다. 우리는 실제로 모든 종류의 것을 제거할 필요가 없습니다. 이것은 작동합니다. 반면에, 범위를 벗어나고 우리가 떠날 때 무효화될 로컬 요소에 대한 포인터가 있기 때문에 그 나머지를 반환하는 것은 괜찮지 않습니다. 무효화는 심각한 문제가 될 수 있으므로 제거해야 합니다. 죄송합니다. 여기서 우리는 모든 요소를 재배치할 수 있는 9의 푸시백을 사용하는 전통적인 벡터를 가지고 있습니다. 좋습니다. 보통은 괜찮지만 G는 그것을 좋지 않은 방식으로 사용합니다. 그것은 첫 번째 요소에 대한 포인터, 첫 번째 요소에 대한 반복자를 잡고, 그런 다음 함수를 호출하고, 푸시백을 수행하고, 그런 다음 보관한 포인터를 사용하려고 합니다. 제 말은, 이것이 reserve를 사용하고 목록과 같은 연결된 컨테이너를 사용하는 이유인데, 사물이 재배치되지 않기 때문입니다. 그러나 우리는 이 코드 조각이 잘못되었다는 것을 감지할 수 있습니다. 그것은 수행되었습니다. 그래서 우리가 실제로 하는 것은 무효화라는 아이디어입니다. 포인터가 무효화된 요소를 호출한 컨테이너의 요소를 재배치했을 수 있는 경우, 유효할 수도 있고 그렇지 않을 수도 있으며, 그런 다음 매우 간단한 규칙에 따라 처리할 수 있습니다. 아니요, const 멤버 함수는 무효화되지 않습니다. const에 뭔가 나쁜 짓을 해야 하기 때문입니다. 캐스트나 그런 걸 사용해야 합니다. 따라서 분석기로 쉽게 검증할 수도 있습니다. 반면에, 모든 비 cont 멤버 함수가 무효화될 수 있다고 가정해야 합니다. 데이터에 액세스할 수 있고 재배치되고, 사물을 옮길 수 있습니다. 핵심 지침과 프로필에 새로운 주석이 필요하다고 생각합니다. 기본적으로 이것은 무효화되지 않습니다. 비 const 표준 예제인 벡터 연산자 서브스크립트이더라도 말입니다. 재할당하지 않지만 const가 될 수 없으므로 쉽게 검증할 수도 있습니다. 따라서 증명할 수 있는 것입니다. 따라서 완벽하게 안전하고 쉽게 할 수 있습니다. 따라서 소유권을 나타냅니다. 평소처럼 소유권 추상화를 사용합니다. 높은 수준을 유지하고, 그렇지 않다면 낮은 수준의 것에 손을 대지 마세요. 하지만 우리는 항상 우리의 규칙에 따라 작성되지 않은 코드, 예를 들어 C 스타일 인터페이스에 많은 포인터가 있는 코드를 어떻게 처리할지 고려해야 합니다. 그래서 우리는 핵심 가이드라인에 주석을 달았는데, 주로 세상이 그렇게 단순하지 않다는 사실을 다루기 위해서입니다. 그리고 우리는 모든 것을 소유하지 않습니다. 그것을 소유자라고 합니다. 저는 소유자로서 이 점을 말할 수 있고, 저는 그것을 당신에게 넘기고, 이것을 삭제하는 것이 당신의 일이라는 것을 압니다. 할 수 있습니다. 그래서 기본적으로 이것에 대해 상당한 양의 작업이 이루어졌고, 소유자를 복사하는 방법에 대한 몇 가지 규칙이 있고 안전한 것에서 그것을 추론할 수 있습니다. 그래서 여기서는 그것들을 살펴보지 않을 것입니다. 슬라이드쇼를 보고 있다면 이것을 정지시키고 이것이 무엇인지 볼 수 있습니다. 그럼 이제 미래의 것으로 넘어가고 싶습니다. 여기서 어디로 가야 할까요? 우리는 좋은 c를 쓸 수 있습니다. 제가 그것에 대해 합리적인 주장을 했기를 바랍니다. 그리고 너무 많은 개발자들이 C C를 쓰지 않나요? 이 신화적인 언어, 가이드라인, 충분하지 않아요. 우리는 실수를 하기 때문에 부분적으로 보장이 필요하고, 실제 증거가 있으면 더 편안하기 때문입니다. 그리고 정적 분석기, 컴파일러가 분석하는 것에 대한 새로운 표준이 필요합니다. 그래서 우리는 여기에서 진행하여 c를 변경할 수 있는 보장을 얻는 방법에 대한 몇 가지 대안이 있습니다. 우리는 다른 언어를 사용하기 시작할 수 있는데, 이는 물론 다른 모든 새로운 언어의 지지자들이 제안하는 것이고, 우리는 다양한 가이드라인을 시행할 수 있습니다. 그것이 제가 주장하는 프로필입니다. 그래서 c를 수정하는 것, c를 변경하는 방법에 대한 너무나 많은 다르거나 비교할 수 없는 아이디어가 있고, 제가 이야기해 온 문제를 해결하는 방식으로 c를 변경하는 것입니다. 그래서 그것은 c처럼 보이지 않을 것이고, 몇 가지 제안이 있습니다. 그래서 우리는 수년간의 지연과 혼란을 겪었고, 단일 정리 언어는 단일 종류의 안전을 제공할 것입니다. 물론 그것이 프로필 접근 방식을 채택하지 않는 한 말입니다. 그리고 그것은 많은 사람들이 이야기하는 것이 아닐 것입니다. 그리고 정리된 C는 클래식 C 코드와 영원히 상호 운용되어야 합니다. 그게 사실입니다. 이 수십억 줄의 코드는 사라지지 않을 것입니다. 그리고 그 중 많은 부분이 중요하고 많은 부분이 정말 고품질입니다. 따라서 점진적인 채택이 필수적이고 부분적인 채택이 필수적입니다. 그리고 글쎄요, C의 경우, 진화하도록 의도되었지만 합리적이고 호환되는 방식으로 진화하도록 의도되었습니다. 마지막 진술을 받아들인다면 사람들이 그것에 대해 이야기하는 방식으로 고정되지 않을 것입니다. 그리고 나서 우리는 다른 언어를 사용해 볼 수 있습니다. 안전성은 종종 C C와 같은 논거로 사용되며, 매우 전형적으로 C의 강점을 무시하고 매우 자주 대안의 약점을 무시합니다. 종종 안전한 차원은 단지 메모리 안전성일 뿐입니다. 그것만으로는 충분하지 않으며 안전하지 않은 구조의 필요성은 크게 다루어지지 않습니다. 그리고 C와 C를 포함한 다른 언어와 상호 운용해야 할 필요성은 언급되지 않는 경향이 있으며 변환 비용은 엄청날 수 있습니다. 그것은 거의 언급되지 않습니다. 그리고 물론 이것은 자연스러운 것이고 인간의 본성입니다. 당신은 당신의 주장을 주장하고 당신이 가진 것의 장점을 과대평가하고 반대의 강점을 과소평가합니다. 하지만 여전히 우리는 이러한 주장을 하는 방식에 대해 더 진지해야 하며, 몇 가지 숫자를 얻어야 합니다. 그리고 어쨌든, 제가 본 다른 언어는 지금까지의 제안에 따르면 약 7개의 다른 언어로 c를 대체할 것입니다. 40년 후가 되면 아마도 20개의 다른 언어가 있을 것이고 그들은 상호 운용되어야 합니다. 이것은 어려울 것입니다. 어쨌든 살펴보겠습니다. 새로운 언어, 새로운 리소스, 새로운 전문가 사용자가 있습니다. 물론 모든 새로운 언어는 C보다 더 간단하고, 깔끔하고, 안전하고, 더 생산적이라고 주장합니다. 반면에 우리는 당시 Java에서 그런 말을 들었습니다. 저는 그렇다고 말했습니다. 네, 살아남는다면 3배 더 커지고 더 좋아질 것입니다. 저는 그 점에 대해 옳았습니다. 그 주장을 대부분의 새로운 언어에 적용할 수 있으며 종종 우월성 주장은 제한된 영역에서 이루어지고, 다시 말하지만 종종 c와 비교됩니다. C. 그리고 제가 알아차린 한 가지는, 새로운 언어가 있을 때 이런 일이 C에서도 일어났다는 것입니다. 많은 위탁자들이 코드를 작성하게 됩니다. 그들은 평균보다 훨씬 뛰어납니다. 그들은 훨씬 더 위탁적이고, 더 많은 정보를 가지고 있으며, 모든 최신 정보를 알고 있습니다. 그리고 나서 많은 수의 법칙에 부딪히게 됩니다. 대규모로 사용되는 언어가 있을 때, 개발자들은 평균적인 자질, 평균적인 열정 등을 가지고 있습니다. 즉, 작은 새로운 커뮤니티와 큰 오래된 커뮤니티를 비교하는 숫자는 왜곡될 것입니다. 봅시다, 저는 무언가를 변환하는 데 무엇이 필요한지 생각해 보았습니다. 1,000만 줄 시스템을 변환하는 것을 생각해 보세요. 그런 것들이 많이 있습니다. 높은 신뢰성과 높은 성능이 필요합니다. 그렇지 않다면 왜 변환을 귀찮게 하겠습니까? 안전상의 이유로요. 그리고 그렇게 훌륭한 개발자는 하루에 n줄의 프로덕션 품질 코드를 완성합니다. n이 무엇인지는 모르겠지만, 어떤 종류의 코드에 대해 이야기하는지에 따라 다릅니다. 하지만 지금 우리가 이야기하는 중요한 소프트웨어의 경우, 1년에 510, 100, 2000줄 정도면 그렇게 틀리지 않습니다. 그리고 1000만 줄 시스템을 새로운 언어로 처음부터 500만 줄, 절반 크기로 새로운 방식으로 작성할 수 있다고 가정해 보겠습니다. 매우 낙관적인 생각이지만, 사실이라면 500명의 개발자가 5년 동안 새로운 시스템을 완성해야 합니다. 그리고 이전 시스템은 교체할 때까지 5년 동안 유지 관리해야 합니다. 그러면 훌륭한 개발자의 실제 급여는 얼마일까요? 급여 비용입니다. 연금 기금, 건물, 난방, 냉방, 컴퓨팅, 이런 모든 종류의 비용입니다. 미국에서 50만 달러라고 가정해 보겠습니다. 그렇게 틀리지 않습니다. 각각 10만 달러라고 말할 수는 있지만, 이런 것입니다. 따라서 5년 동안 약 10억 달러가 추가로 들 것입니다. 100만 달러는 나눌 수 있고, 1억 달러는 곱할 수 있습니다. 그리고 저는 개발자들이 새로운 언어에 대한 관련 경험이 있는 개발자를 찾을 수 있다면, 그것은 종종 문제가 될 것이라고 가정했습니다. 그리고 아웃소싱이 비용을 절감할 수 있을지도 모릅니다. 아웃소싱을 할 때 항상 그런 일이 일어나는 것은 아니고, 특히 보안 등에 대해 이야기하기 시작할 때 고유한 문제가 있습니다. 그 비용을 어떻게 극적으로 절감할 수 있는지는 명확하지 않습니다. 어쨌든 저는 새로운 시스템이 이전 시스템의 크기를 반으로 줄일 것이라고 가정했다고 말했습니다. 그렇게 되는 일은 매우 드물지만, 문제에 대한 이해도가 높고, 언어가 더 좋고, 툴링이 더 좋다면 확실히 가능합니다. 그리고 5년 동안 기능 확장은 없을 것입니다. 이것은 어렵습니다. 그리고 새로운 시스템은 작동하고 제때 제공될 것입니다. 이 멍청한 시스템에서 무슨 일이 일어나고 있는 걸까요? 오, 그 시스템에서 무슨 일이 일어났는지 알겠습니다. 저는 지금 여러분이 보고 있는 것을 보지 못하고 있습니다. 저는 보고 있습니다. 좋아요, 물론 10억 달러나 1억 달러가 많은 돈이 아닌 사람들이 있습니다. 그러니 그런 이유로 모든 것을 무시하지 맙시다. 1,000만 줄 시스템이 중간 수준이라고 생각하는 사람들이 있습니다. 여기저기서 몇 가지 질문을 했습니다. 그래서 저는 이런 종류의 숫자가 새로운 것을 그냥 사용하는 것보다 점진적이고 진화적인 접근 방식을 주장하는 것이라고 생각합니다. 그리고 분명히 그것은 c일 수도 있고, C와 C와 원활하게 상호 운용할 수 있는 다른 언어의 조합일 수도 있으며, 두 가지 모두의 커뮤니티를 가질 수 있습니다. 저는 어쨌든 C를 사용하는 것이 더 낫다고 생각합니다. C는 앞으로 수십 년 동안 중요한 역할을 할 것이고, 우리는 계속해서 노력해야 합니다. 표준 위원회는 집중해서 C를 더 좋게 만들어야 합니다. 그리고 저는 인용문과 같은 사람들의 인용문을 찾기 위해 제가 아는 것을 찾고 있었습니다. 그래서 게일의 법칙이라는 것이 있습니다. 작동하는 복잡한 시스템은 항상 작동하는 간단한 시스템에서 진화한 것으로 밝혀졌습니다. 다시 말해, 이전 시스템의 문제 없이 새로운 시스템을 그냥 구축한다는 아이디어는 환상입니다. 하지만 그것은 매우 인기 있는 환상입니다. 저는 저기 아래의 마지막 진술에 동의합니다. 따라서 프로파일, 표준 C 코드 가이드라인으로 안전성을 보장하는 방법은 충분하지 않으며 여기 프로파일 요약은 모든 것이 ISoC 표준이라는 것입니다. 기본 보장은 우리가 원하는 가장 기본적인 보장은 완전한 유형과 리소스 안전성입니다. 소유권은 dag를 구성해야 합니다. 그렇지 않으면 모델이 무너집니다. 루프 등이 있는 경우 공유 포인터와 약한 포인터로 루프를 처리할 수 있지만 쉽게 증명하려면 dag에 고수하세요. 포인터는 처리했습니다. 앞서 말했듯이 보장을 제공하는 점진적 변환을 지원해야 합니다. 보장 세트는 개방적입니다. 모든 사람이 보장에 대해 무엇을 원하는지 모르겠습니다. 최신 최적화 프로그램에서 모든 안전하지 않은 기능을 사용할 수 있는 안전하지 않은 보장을 원하는 사람이 있을 수 있습니다. 다시 말해, 개방형 세트이고 몇 가지 기본 보장이 표준이 되기를 바랍니다. 유형 및 리소스 안전성, 메모리 안전성, 범위 안전성, 산술 안전성 등이 표준화될 수 있다고 생각합니다. 표준화하기 쉬운 것은 없지만 가능합니다. 그리고 가정되는 보장 세트는 코드에 명시되어 있습니다. 그렇지 않으면 우리는 코드에 어떤 종류의 분석을 적용해야 할지 모르고, 사용자라면 해당 코드에 어떤 종류의 분석이 더 나쁜지 알 수 없습니다. 그리고 안전에 대한 개념이 많이 있습니다. 저는 이전에도 말했지만, 사람들이 잊어버리고 일상적인 문제에서 지금 보고 있는 것에만 집중하는 경향이 있기 때문에 목록을 다시 보여줄 가치가 있다고 생각합니다. 그리고 여기 유형 및 리소스 안전 정의가 있습니다. 기본적으로 모든 객체는 정의된 유형에 따라 액세스됩니다. 붐. 멋진 정의입니다. 그리고 누수도 없습니다. 그럼 C는 어떨까요? C? 글쎄요, 언어는 아니지만 제가 좋아하지 않는 사용 스타일인 것 같습니다. C 라이브러리를 호출해야 하고 모든 보장을 사용하여 코어를 어떻게 할지 생각해야 하기 때문에 피할 수 없는 일일 것입니다. 소유자 주석과 null이 아닌 검사가 그 예입니다. 모든 것의 새롭고 멋진 버전을 만드는 데만 집중할 수는 없습니다. 정적 분석에는 너무 복잡합니다. 임의의 코드를 작성할 수 있다면 동적 연결 비용과 보류 문제에 직면하게 됩니다.임의의 C는 저수준 추상화를 처리하는 데 중점을 둡니다.따라서 우리는 추상화 수준을 분석이 가능하고 사람이 이해할 수 있는 지점까지 높여야 합니다.그리고 우리는 성능과 유형, 리소스 안전성을 중요하게 생각합니다.따라서 정적 분석의 보장은 분석이 실행 가능한지 확인하는 코딩 규칙이 있고 그러한 코드를 작성하는 것이 합리적이도록 하는 라이브러리가 있으며 프로파일은 관련 없는 테스트 세트가 아닌 일관된 보장 세트입니다.그리고 프로파일은 보장 세트로 지정된 다음 원하는 보장을 제공하는 규칙 세트로 구현됩니다.그리고 저는 이것이 너무 참신하고, 너무 복잡하고, 너무 새롭다고 말하는 사람들을 보았습니다.우리가 원하는 것은 간단하고 새로운 것입니다.45페이지로 정의할 수 있는 이 반짝이는 새로운 언어, 첫 번째 버전의 C와 똑같습니다.저는 그렇게 생각하지 않습니다.그곳에는 투표가 있습니다. 당신은 항상 새로운 것을 하지 말아야 하고, 오래된 것에 어떤 종류의 외관을 씌워야 합니다. 저는 이것이 실현 가능하다고 믿지 않습니다. 우리는 전반적인 접근 방식, 일반적인 접근 방식을 가져야 한다고 생각합니다. 각 개별 기술과 기능은 이전에 여러 번 시도되었고, 그것은 좋지만, 특정 작업의 경우, 그리고 그렇지 않은 경우, 그 중 어느 것도 모든 문제를 해결하지 못합니다. 따라서 결합되고 일관된 접근 방식이 필요합니다. 그리고 프로필은 가이드라인을 넘어서야 합니다. 왜냐하면 우리는 그것을 검증하고, 코드 주석을 제공하고, 프로필과 다양한 보장 세트를 혼합해야 하기 때문입니다. 대규모 시스템에서는 정확히 동일한 규칙을 따르는 백만 줄의 코드를 상상할 수 없습니다. 그리고 가능하다면, 저는 그 수를 1,000만 줄로 늘릴 것입니다. 그래서 우리는 프로필을 혼합하고, 검증되지 않고 보장되지 않는 기능을 사용할 수 있는 가장 엄격한 사양을 찾아야 한다고 생각합니다. 우리는 이 수십만 줄은 검사되지 않았다고 말할 수 없습니다. 그것만으로는 충분하지 않습니다. 연결 목록의 구현이 있으면 좋습니다. 두 페이지의 코드에 그것이 지정되어 있습니다. 그래서 여기서 일부 디자인 작업이 진행 중이며, 아직 개발 중입니다. 모듈 기반 컨트롤, 메모리 안전, 유형 안전이 제안되고 컨트롤을 인코딩하고 이 영역에서 유형 안전을 억제하고 이 영역에서 유형 안전을 강제로 적용하는 것이 좋습니다. 변환하기 너무 복잡하거나 어려운 코드가 있어서 할 수 없습니다. 하지만 이 섹션에 대해 분석을 수행하고 표준 프로필을 제안하고 유형 안전 범위 산술이 좋은 초기 세트가 될 것이라고 말할 수 있습니다. 구문 측면에서 이를 수행하는 데 필요한 내용에 대한 요약은 다음과 같습니다. 이는 진행 중인 작업입니다. 이에 대해 작성된 논문이 있고 찾아보실 수 있으며 이에 대한 토론도 있습니다. 기본적으로 아니요, 아직 여기에 도달하지 못했습니다. 클래식 C와 CV 클래스, C 11에서 멀리, 멀리 왔습니다. 그리고 우선 C에 익숙하지 않은 사람들을 최신 상태로 만들어야 합니다. 모든 새로운 기능을 독점적으로 사용하고 모든 멋진 새 것을 사용하는 것을 의미하지 않습니다. 아니요, 원하는 것을 정의하고 가장 간단한 방법을 찾는 것을 의미합니다. 핵심 가이드라인은 이를 위한 시도이며, 설명된 대로 프로파일을 표준화하기 시작해야 합니다. 물론 한두 사람이 할 수 없는 일입니다. 5년 안에 할 수 있을지도 모르지만, 5년은 없을 것 같습니다. 그러면 어떻게 도울 수 있을까요? 프로파일을 어떻게 개선할까요? 어떤 프로파일이 필요할까요? 프로파일 사양을 가장 잘 공식화하려면 어떻게 해야 하며, 무엇을 할 수 있을까요? 지금은 프로파일의 대부분을 보장하지만 정적 분석기가 아직 따라가지 못해서 마지막 모든 작업을 할 수 없는 profiles lite와 같은 것을 꿈꾸고 있습니다. 그리고 어떤 라이브러리 구성 요소를 사용하기 위해 단순화할 수 있을까요? 저는 누군가가 푸시백을 한다는 걱정 없이 동시 시스템에서 사용할 수 있도록 푸시백이 없는 din 배열을 사용해 왔습니다. 아니면 다른 스레드에서 더 필요할 수도 있습니다. 그리고 사람들이 제안을 할 수 있고 제가 초안 등을 넣을 수 있는 GitHub을 설정해서 이런 종류의 작업을 적당한 시간 안에 완료하기 위한 커뮤니티를 만들 수 있도록 하겠습니다. GitHub은 아직 공개되지 않았지만 오늘 오후에 공개될 예정입니다. 알겠습니다. 감사합니다. 질문이 있나요? 질문할 시간이 있나요? 아니면 제가 너무 심하게 들이받았나요? 질문이 있으면 마이크 앞으로 나오세요. 저기에도 하나 있습니다. 안녕하세요, 정말 감사합니다. 예를 들어 특정 프로필에서 푸시백 없는 벡터에 대해 언급하셨죠. 프로필이 어떤 경우에 멤버 함수를 제거한다고 생각하시나요? 아니면 멤버 함수가 다르게 동작하게 하시나요? 질문을 잘 이해하지 못하겠네요. 특정 맥락에서 푸시백이 없는 벡터 클래스가 필요할 수 있다고 언급하셨죠. 네. 즉, 특정 멤버 함수를 제거하는 프로필이 있을 수 있습니다. 그게 한 가지 방법입니다. 그게 제가 상상했던 방식이 아니었어요. 음, 사실 저는 벡터의 표준 구현을 실제로 건드릴 수 없었기 때문에 다른 방식으로 했어요. 예를 들어, 제 학생들은 범위 검사 벡터를 얻습니다. 구현을 건드리지 않고는 그럴 수 없고, 구현이 여러 개 있으므로 그렇게 하지 않습니다. 마찬가지로 무효화의 경우 제가 한 일은 din 배열이라는 다른 클래스를 사용한 것입니다. GSL에서 찾을 수 있을 텐데, 그 연산이 없었기 때문에 다른 방식입니다. 그리고 표준 위원회나 표준 라이브러리 공급업체가 아니라면 그렇게 해야 합니다. 그래서 그렇게 했습니다. 알겠습니다. 불변 데이터에 대한 질문입니다. 가변 데이터보다 불변 데이터를 선호한다고 말씀하셨습니다. 동시에 문자열 클래스와 C는 가변적입니다. 그리고 저는 불변 문자열 클래스에 대한 많은 토론을 보았지만, 실제로는 인기를 얻지 못했습니다. 불변 문자열 클래스에 대한 이야기를 많이 듣지만, 저는 어떤 문자열을 가끔 변형하는 걸 좋아하는데, 왜 불변으로 기본 설정하는 게 더 나은지에 대한 일관된 주장을 본 적이 없습니다. 어떤 이점이 있을까요? 어떤 문제가 있을까요? 그런 제안이 없다면, 우리는 하나도 얻을 수 없을 겁니다. 게다가, 거기에는 너무 많은 코드가 있기 때문에, 거의 확실히 불변인 다른 것의 예가 될 것입니다. 하지만 누군가는 불변 문자열이 좋은 이유에 대한 철저하고, 논리적이며, 바라건대 데이터 주장을 해야 합니다. 정확성의 문제일까요? 성능의 문제일까요? 그런 종류의 주장을 본 적이 없습니다. 감사합니다. 여러분이 하는 다양한 제안 중 많은 부분이 정적 분석기나 컴파일러와 별도로 다른 툴링에 의해 적용된다는 것을 알았습니다. 제가 개인적으로나 직장에서 새로운 C 프로젝트를 설정할 때 관찰한 문제 중 하나는 빌드 체인과 CI에 추가 툴링을 도입하는 데 노력이 들고, 프로덕션 규모에서는 사소한 노력이 아니라는 것입니다. 그 과정을 더 쉽게 만드는 방법, 툴링 통합을 더 간단하게 만드는 방법에 대한 제안이 있나요? 툴 체인과 관련된 몇 가지 문제가 있고, 물론 툴 체인에 새로운 것을 도입하기는 어렵습니다. 그리고 CDH의 일반적인 문제는 우리가 결코 하지 않는 많은 것을 가지고 있다는 것입니다. C에 그래픽 시스템이 없는 것이 아니라, 많은 그래픽 시스템이 있습니다. 우리는 많은 빌드 시스템과 많은 정적 분석 시스템을 가지고 있습니다. 그래서 제가 바라는 것은 프로필이 사람들이 특정 프로필을 지원하는 정적 분석기를 빌드하도록 장려하고, 빌드 시스템, 컴파일 시스템이 이것이 필요하다는 것을 알고 설치된 정적 분석기를 사용한다는 것입니다. 지금 제가 하는 일의 많은 부분은 실제로 컴파일러 자체에 넣을 수 있습니다. 컴파일러는 정적 분석기이고, 요즘은 꽤 정교한 정적 분석기이기 때문입니다. 가장 간단한 것은 초기화되지 않은 데이터 없음 규칙인데, 그들은 이미 초기화되었는지 여부를 감지하기 위해 더 복잡한 작업을 하고 있습니다. 하지만 저는 프로필 주석이라는 아이디어가 그 문제를 해결하는 데 도움이 될 것이라고 생각합니다. 감사합니다. 따라서 안전성과 c에 대한 새로운 개선 사항이 언어에 추가되거나 추가되고, 새로운 주석, 새로운 유형이 추가되는 것 같습니다. 기본값이 실제로 안전성과 비안전성인 경우가 있을 것이라고 생각하십니까? 호환성을 유지하려면 실제로 추가가 필요하고 확장을 통해 작업해야 하므로 언어에서 기능을 효과적으로 제거할 수 없습니다. 우리는 사용 중단 등을 여러 번 시도했고 호환되지 않는 변경 사항조차도 많은 문제를 일으켰습니다. 그래서 저는 그런 식으로 가지 않을 것입니다. 제가 실제로 원하는 것은 지침을 통해 언어 사용을 단순화하는 것입니다. 그런 다음 지침을 따르면 처리하기 쉬운 언어가 생깁니다. 분석이 작성을 중단시키기 때문에 void에 대한 포인터의 공포를 알 필요는 없습니다. 따라서 언어를 확장하고 적용할 수 있는 언어의 더 간단한 하위 집합을 만듭니다. 감사합니다. 안녕하세요, 언어 기능으로 Const에 대해 이야기할 때 쓰기 전용을 추가하고 싶다고 간단히 언급했습니다. 더 나은 인터페이스나 그런 것을 만들 것이라고 언급했습니다. 그럼 writeonly의 사용 사례에 대해 어떻게 생각하셨나요? 그리고 대안으로 사용할 수 있는 것이 있나요? 네, write only 사례에 대한 것이라면 무엇이든요. 죄송하지만 저는 그것을 이해하지 못했습니다. 오, const에 대해 언급했을 때, read only와 write only에 대해 이야기했고, const와 같이 write only가 있다면 더 나은 인터페이스가 만들어졌을 겁니다. const 예제는 아주 초창기부터 우리가 더 안전한 언어, 실수하기 어렵고 이해하기 쉬운 언어를 만들려고 노력한 방법의 예일 뿐입니다. 그리고 저는 읽기 전용인 const가 실제로 있었던 것이 아니라 write only도 있었지만, 그것을 얻을 수 없었다는 역사적 사실을 덧붙였습니다. 알겠습니다. 알겠습니다. 고맙습니다, Will. 그러면 때때로 함수가 스레드로부터 안전하거나 I o 작업을 수행한다고 표현하고 싶을 때가 있다고 생각하십니까? 후드 아래에서 태그 디스패칭을 사용하여 이야기한 프로필을 구현할 수 있다고 생각하십니까? 저는 그것에 대해 생각해 본 적이 없습니다. 그래서 이것은 기침을 하는 코멘트입니다. 하지만 네, 프로필의 일부가 될 수 있는 스레드 안전 주석이 있을 수 있다고 상상할 수 있습니다. 프로필은 항상 다른 프로필에서 부분적으로 빌드됩니다. 현재 핵심 지침에는 메모리 안전 및 유형 안전이 있습니다. 유형 및 리소스 안전에 추가될 세 가지가 있다고 생각합니다. 그리고 스레드 안전 스레드가 프로필의 일부가 될 것이라고 생각합니다. 제가 정말 보고 싶지 않은 것은 요청할 수 있는 총 50개 또는 100개의 항목입니다. 그러면 혼란이 생기기 때문입니다. 그리고 현재 정적 분석기를 살펴보면 자유로운 선택을 제공할 가능성이 매우 높습니다. 그리고 그것은 종종 일관된 보장 세트로 추가되지 않습니다. 그래서 네, 그것은 무언가의 후보가 될 수 있지만 무엇인지 잘 모르겠습니다. 언어의 일부로 반사를 컴파일했다면 외부 분석기 대신 개념이나 함수 개념을 사용하여 대부분의 정적 분석 검사를 구현할 수 있을 것이라고 생각하십니까? 아니요, 그렇게 생각하지 않습니다. 해결합니다. 정적 반사를 보고 싶지만, 그것이 다른 문제 집합을 다룬다고 생각합니다. 네, 발표해 주셔서 감사합니다. 제어된 환경에 있을 때, 코드 작성자일 때 좋은 예가 있다고 생각합니다. 하지만 어떻게, 어떻게, 어떻게 생각하세요? 라이브러리를 다룰 때 안전성을 어떻게 개선할 수 있을까요? c, c, c, 포스트 라이브러리가 포인터를 전달하면 무엇을 할 수 있을까요? 이것이 제가 프로필 혼합이라고 부르는 문제입니다. 가져오거나 포함하는 것에 대해 어떤 가정을 할 수 있는지에 대한 주석을 달 수 있습니다. 그리고 그것이 할 수 있는 전부입니다. 프로필의 하위 집합을 임의로 처리할 수 있고, 하위 집합을 분리할 수 있지만, 일종의 임의의 보장 집합은 기계적으로 처리하기에는 너무 어렵습니다. 그래서 우리는 주석을 달고 사람들이 실제로 시도하고 이해하고 그들이 다루는 것을 확인해야 할 것입니다. 그리고 문제는 수십 년 동안 사라지지 않을 것입니다. 기본적으로 범위가 있다면 그것이 문제라는 것을 알아야 합니다. 우리는 최선을 다해 그것을 처리해야 하지만, 그것을 없앨 수는 없습니다. 감사합니다. 안녕하세요. 당신이 당신의 강연에서 concept에 대해 언급한 것을 알아챘고, 우리는 직장의 라이브러리에서 그것을 사용하려고 노력합니다. 우리가 겪는 문제는 다른 사람들이 적용 위험을 유지하려고 할 때 코드가 더 복잡해지고 이해하기 어렵게 만든다는 것입니다. 그리고 우리는 concept를 사용하는 것의 실제적인 이점을 찾지 못했습니다. 그래서 당신이 그것의 이점과 그것을 올바르게 사용하기 위한 지침에 대한 리소스를 자세히 설명해 줄 수 있는지 궁금합니다. 물론입니다. 저는 컴퓨터 과학이 아닌 코드, 특히 통신 소프트웨어에서 그것을 성공적으로 사용했고, 그것이 매우 유용하다는 것을 알았습니다. 피해야 할 한 가지는 사람들이 require 절을 require, require, 그리고 보증의 저수준 사용으로 사용하는 것입니다. 그것은 더러운 엉망을 만듭니다. 당신이 한 것이 그런지는 모르겠지만, 제가 본 것 중 하나는 실패한 것입니다. 사람들은 모듈을 사용한다고 생각합니다. 그렇지 않습니다. 그들은 모듈을 만드는 데 어셈블리 코드를 사용하고 있습니다. 그리고, 글쎄요, 어셈블러만큼 성공적이고, 적절한 개념을 구축하려면 약간의 경험이 필요합니다. 저는 사람들이 모든 것에 대한 절대적인 최소한의 개념 제약이어야 한다는 생각에 개념을 구축하려고 시도하는 것을 보았습니다. 다시 말하지만, 너무 많은 개념을 얻고 기억할 수 없습니다. 제가 개념에 대해 쓰고, 개념에 대해 말할 때, 저는 개념이 구성을 장려하도록 설계되어야 한다고 말합니다. 즉, 개념이 많은 곳, 많은 알고리즘에서 사용될 수 있을 만큼 충분히 높은 수준이어야 합니다. 따라서 사람들이 덜 개념을 구축하고 다른 사람이 덜과 같음 개념을 사용하면 혼란스러운 무언가로 가는 길에 있는 것입니다. 반면에 표준에 있는 것처럼 순서 개념을 구축하면 네 가지 작업을 모두 사용하여 더 나은 무언가로 가는 길에 있는 것입니다. 제 말은, 문제 영역에 우리가 다루지 않은 것이 있을 수 있지만, 대부분의 경우 저는 그런 문제를 보았습니다. 그것은 사용의 미숙함이었습니다. 사람들이 코드를 작성하기 시작하면 좋은 코드를 작성하지 않고 초보자 실수를 하는 것과 같습니다. 그리고 제가 그게 가능할 수 있다고 제안했을 때 무례하다고 생각하지 않았으면 좋겠어요. 당신이 당신의 물건을 분석하고 그것이 무엇인지 정확하게 말할 수 있는지 보세요. 그것은 효과가 없는 것 같았어요. 그것에 대해 듣고 싶어요. 네, 고맙습니다. 그리고 저는 그것이라고 생각합니다. 고맙습니다.