[C++] GSL:Guidelines Support library (1st)

[C++] GSL:Guidelines Support library

 

GSL은 이러한 일련의 지침을 지원하기 위해 고안된 facilities의 작은 library이다. 이러한 facilities들이 없다면, 이 guidelines은 programming language detail들에 훨씬 더 제한적일 것이다.

 

Core Guidelines support library는 namespace 'gsl'에 정의되며, 이름은 standard library 또는 기타 잘 알려진 library 이름에 대한 별칭(aliases)일 수 있다. 'gsl' namespace를 통해 (compile time) indirection으로 사용하면 experimentation과 지원 facilities의 local variants이 가능하다.

 

GSL은 header only이며 GSL: Guidelines support library에서 찾을 수 있다. support library facilities은 매우 경량(zero-overhead)이 되도록 설계되어 기존의 대안을 사용하는 것에 비해 오버헤드가 발생하지 않도록 한다. 바람직한 경우 debugging과 같은 task에 대한 추가 기능(예: checks)의 "instrumented(계기)"가 될 수 있다.

 

본 Guidelines에서는 GSL의 type 외에 표준의 type(예: C++17)을 사용한다. 예를 들어, variant type을 가정하지만, 이건 현재 GSL에 있지 않다. 결국 the one voted into C++17을 사용하십시오.

 

아래 나열된 GSL types 중 일부는 현재 버전의 C++ 의 limitation과 같은 기술적 이유로 인해 당신이 사용하는 library에서 지원되지 않을 수 있다. 따라서 자세한 내용은 GSL 문서를 참조하십시오.

 

GSL components들의 요약

 

● GSL.view : Views

● GSL.owner

● GSL.assert : Assertions

● GSL.util : Utilities

● GSL.concept : Concepts

 

GSL의 "ISO C++ standard style" semi-format specification(준형식 사양)을 계획하고 있다.

우리는 ISO C++ Standard Library에 의존하며 GSL의 일부가 standard library에 흡수되기를 바란다.

 

원문출처

isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#gsl-guidelines-support-library

C++ Core Guidelines

[C++] GSL.view: Views

 

이러한 type들은 사용자가 소유하는(owning) 포인터와 소유하지 않는(non-owning) 포인터, 그리고 단일 object에 대한 pointer들과 시퀀스의 첫 번째 요소에 대한 pointer들을 구별할 수 있게 한다.

 

이런 "Views"들은 결코 owner들이 아니다.

 

Reference들은 Owner가 될 수 없다(R.4 참조). Reference들은 참조하는 object들보다 더 오래 남아 있는 기회가 많다(예를들어, reference에 의한 local variable를 return하거나, vector의 element에 대한 참조를 보유하며 push_back을 수행하고, std:::max(x, y + 1)에 binding). Lifetime safety profile은 그러한 것들을 다루는 것을 목표로 하지만, 심지어 소유주<T&>까지도 이치에 맞지 않고 권장되지 않는다

 

이름들은 대부분 ISO Standard library style(소문자 및 밑줄):

 

●T* //T*는 소유자가 아니고, null이 될지도 모름.  single element를 가리킨다고 가정함.

●T& //T&는 소유자가 아니고, 절대 "null reference"가 될 수 없음.  Reference들은 항상 object들에 binding된다.

 

"raw-pointer" 표기법(예: int*)은 가장 일반적인 의미를 갖는 것으로 가정한다. 즉, pointer가 object를 가리키지만 그것을 소유하지는 않는다. 소유자는 resource handle(예: uniquie_ptr 또는 vector<t>)로 변환되거나 또는 owner<T*>라고 표시해 줘야 한다.

 

●onwer<T*> //T* 는 pointed되었거나 referred된 object을 소유한다. nullptr일 수도 있다.

 

소유자는 적절한 resource handle을 사용하도록 업그레이드할 수 없는 코드에서 pointer들을 소유하는 것으로 표시하기 위해 사용된다. 그 이유는 다음과 같다.

 

● 전환 비용 (Cost of conversion)

● pointer는 ABI와 함께 사용된다.

● pointer는 resource handle 구현의 일부다.

 

owner<T>는 free store(heap)에서 object를 refer하는 것으로 가정한다.

만약 어떤 것이 nullptr이 아니라면 다음과 같이 하라.

 

● not_null<T> // T는 대개 nullptr이 아닌 pointer type이다. (예 not_null<int*> and not_null<owner<Foo*>>).

                        T는 "==nullptr"가 의미 있는 어떤 유형일 수 있다.

● span<T> [p:p+n], {p, q} 및 {p, n}의 생성자, T는 pointer type이다.

● span_p<T> {p, 술어(predicate)} [p:q) 여기서 q는 predicate(*p)가 참인 첫 번째 요소임

● string_span //span<char>

● cstring_span //span<const char>

 

span<T>는 T가 const type이 아닌 한, 0 이상의 변동가능한 T를 가리킨다.

 

"Pointer arithmetic(산술)"은 span안에서 잘 처리된다. 범위  만 C style string (예: input buffer에 대한 pointer)이 아닌 char*는 span으로 표시되어야 한다.

 

● zstring //C-style string로 생각되는 char* 즉, zero값으로 끝나는 순서를 가진 const char 또는 nulltr

● czstring //C-style string로 생각되는 const char*, 즉 zero값으로 끝나는 순서를 가진 const char 또는 nulltr

 

논리적으로, 그 마지막 두 개의 aliases은 필요하지 않지만, 우리는 항상 논리적인 것은 아니며, 그것들이 한 char에 대한 pointer와 C style string에 대한 pointer 사이의 구별을 분명히 한다. zero 값으로 끝난다고 가정하지 않는 일련의 character들은 zstring이 아니라 char*이어야 한다. 

 

nullptr 일 수 없는 C-style strings에는 "not_null<zstring>"을 사용하십시오. 우리는 not_null<zstring>을 위한 이름이 필요한가? 아니면 그것의 ugliness이 feature인가?