문제

당신은 얼마나 멀리 가나요? const?함수만 만드시나요? const 필요할 때 아니면 돼지 전체를 사용하여 어디에서나 사용합니까?예를 들어, 단일 부울 매개변수를 취하는 간단한 mutator를 상상해 보세요.

void SetValue(const bool b) { my_val_ = b; }

그거요? const 실제로 유용합니까?개인적으로는 매개변수를 포함하여 광범위하게 사용하기로 선택했는데, 이 경우에는 과연 쓸만한지 궁금합니다.

생략도 가능하다는 사실에 저도 놀랐어요 const 함수 선언의 매개변수에서 매개변수를 사용하지만 함수 정의에 이를 포함할 수 있습니다. 예:

.h 파일

void func(int n, long l);

.cpp 파일

void func(const int n, const long l)

이에 대한 이유가 있습니까?나에게는 조금 특이한 것 같습니다.

도움이 되었습니까?

해결책

그 이유는 매개변수의 const가 데이터 복사본에 대해 작업하기 때문에 함수 내에서 로컬로만 적용되기 때문입니다.이는 함수 서명이 어쨌든 실제로 동일하다는 것을 의미합니다.하지만 이런 일을 많이 하는 것은 아마도 나쁜 스타일일 것입니다.

나는 개인적으로 참조 및 포인터 매개변수를 제외하고는 const를 사용하지 않는 경향이 있습니다.복사된 객체의 경우 실제로는 중요하지 않지만 함수 내에서 의도를 나타내므로 더 안전할 수 있습니다.정말 판단이 필요한 상황입니다.나는 뭔가를 반복할 때 const_iterator를 사용하는 경향이 있고 그것을 수정할 생각이 없으므로 참조 유형에 대한 const 정확성이 엄격하게 유지되는 한 각자 자신의 것으로 추측합니다.

다른 팁

"인수가 값으로 전달되면 호출자의 개체를 수정하지 않으므로 const는 의미가 없습니다."

잘못된.

코드와 가정을 자체적으로 문서화하는 것입니다.

코드에 작업하는 사람이 많고 기능이 중요하지 않다면 가능한 모든 것을 "const"로 표시해야 합니다.강력한 코드를 작성할 때 항상 동료가 가능한 모든 방법으로 당신을 잡으려는 정신병자라고 가정해야 합니다(특히 미래에는 자신이 될 경우가 많기 때문에).

게다가 앞서 누군가가 말했듯이, ~할 것 같다 컴파일러가 작업을 약간 최적화하도록 돕습니다(긴 기회이긴 하지만).

때로는 (너무 자주!) 다른 사람의 C++ 코드를 풀어야 할 때도 있습니다.그리고 우리 모두는 그것을 알고 있습니다 다른 사람의 C++ 코드는 정의상 거의 엉망입니다. :) 그래서 로컬 데이터 흐름을 해독하기 위해 제가 가장 먼저 하는 일은 다음과 같습니다. const 컴파일러가 짖기 시작할 때까지 모든 변수 정의에서.이는 호출자가 초기화한 멋진 지역 변수일 뿐이므로 const 한정 값 인수도 의미합니다.

아, 변수가 있었으면 좋겠다 const 기본적으로 변하기 쉬운 const가 아닌 변수에는 필요했습니다 :)

다음 두 줄은 기능적으로 동일합니다.

int foo (int a);
int foo (const int a);

당연히 수정할 수 없습니다. a 몸에 foo 두 번째 방법으로 정의하면 외부와 별 차이가 없습니다.

어디 const 참조 또는 포인터 매개변수를 사용하면 정말 유용합니다.

int foo (const BigStruct &a);
int foo (const BigStruct *a);

이것이 의미하는 바는 foo가 크기가 기가바이트에 달하는 데이터 구조와 같은 큰 매개변수를 복사하지 않고도 사용할 수 있다는 것입니다.또한 발신자에게 "Foo는 해당 매개 변수의 내용을 변경하지 않을 것"이라고 말합니다. Const Reference를 전달하면 컴파일러가 특정 성능 결정을 내릴 수 있습니다.

*:불변성을 없애지 않는 한 그것은 또 다른 게시물입니다.

불필요한 불필요한 const는 API 관점에서 보면 좋지 않습니다.

값으로 전달되는 내장 유형 매개변수에 대해 코드에 불필요한 const를 추가합니다. API를 복잡하게 만든다 호출자나 API 사용자에게 의미 있는 약속을 하지 않으면서 구현을 방해할 뿐입니다.

필요하지 않을 때 API에 'const'가 너무 많으면 "우는 늑대", 결국 사람들은 'const'를 무시하기 시작할 것입니다. 왜냐하면 'const'는 여기저기에 있고 대부분의 경우 아무 의미도 없기 때문입니다.

API의 추가 const에 대한 "reductio ad absurdum" 인수는 처음 두 점에 적합합니다. 더 많은 const 매개변수가 좋으면 const를 가질 수 있는 모든 인수에는 const가 있어야 합니다.실제로 그렇게 좋았다면 const를 매개변수의 기본값으로 사용하고 매개변수를 변경하려는 경우에만 "mutable"과 같은 키워드를 사용하는 것이 좋습니다.

그러니 가능한 곳에 const를 넣어보도록 합시다:

void mungerum(char * buffer, const char * mask, int count);

void mungerum(char * const buffer, const char * const mask, const int count);

위의 코드 줄을 고려해보세요.선언이 더 복잡하고 길어지고 읽기 어려울 뿐만 아니라 API 사용자는 4개의 'const' 키워드 중 3개를 안전하게 무시할 수 있습니다.그러나 'const'를 추가로 사용하면 두 번째 줄이 잠재적으로 위험한!

왜?

첫 번째 매개변수를 빠르게 잘못 읽음 char * const buffer 전달된 데이터 버퍼의 메모리를 수정하지 않을 것이라고 생각하게 만들 수도 있습니다. 그러나 이는 사실이 아닙니다! 불필요한 'const'는 API에 대한 위험하고 잘못된 가정으로 이어질 수 있습니다. 빠르게 스캔하거나 잘못 읽을 때.


불필요한 const는 코드 구현 관점에서도 좋지 않습니다.

#if FLEXIBLE_IMPLEMENTATION
       #define SUPERFLUOUS_CONST
#else
       #define SUPERFLUOUS_CONST             const
#endif

void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source, SUPERFLUOUS_CONST int count);

FLEXIBLE_IMPLEMENTATION이 true가 아닌 경우 API는 아래 첫 번째 방법으로 함수를 구현하지 않을 것을 "약속"합니다.

void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source, SUPERFLUOUS_CONST int count)
{
       // Will break if !FLEXIBLE_IMPLEMENTATION
       while(count--)
       {
              *dest++=*source++;
       }
}

void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source, SUPERFLUOUS_CONST int count)
{
       for(int i=0;i<count;i++)
       {
              dest[i]=source[i];
       }
}

정말 어리석은 약속이군요.호출자에게 전혀 이익이 되지 않고 구현만 제한하는 약속을 해야 하는 이유는 무엇입니까?

둘 다 동일한 기능을 완벽하게 유효한 구현이므로 수행한 작업은 불필요하게 한 손을 등 뒤로 묶은 것뿐입니다.

게다가 이는 쉽게(그리고 법적으로 회피할 수 있는) 매우 천박한 약속입니다.

inline void bytecopyWrapped(char * dest,
   const char *source, int count)
{
       while(count--)
       {
              *dest++=*source++;
       }
}
void bytecopy(char * SUPERFLUOUS_CONST dest,
   const char *source,SUPERFLUOUS_CONST int count)
{
    bytecopyWrapped(dest, source, count);
}

보세요, 저는 그렇게 하지 않겠다고 약속했지만 어쨌든 래퍼 함수를 ​​사용하여 그렇게 구현했습니다.마치 영화에서 악당이 누군가를 죽이지 않겠다고 약속하고 부하에게 대신 죽이라고 명령하는 것과 같습니다.

그 불필요한 const는 영화 악당의 약속에 지나지 않습니다.


그러나 거짓말하는 능력은 더욱 악화됩니다.

가짜 const를 사용하면 헤더(선언)와 코드(정의)에서 const가 일치하지 않을 수 있다는 사실을 깨달았습니다.const를 선호하는 사람들은 이것이 const를 정의에만 넣을 수 있기 때문에 좋은 것이라고 주장합니다.

// Example of const only in definition, not declaration
class foo { void test(int *pi); };
void foo::test(int * const pi) { }

그러나 그 반대는 사실입니다 ...허위 const를 선언에만 넣고 정의에서는 무시할 수 있습니다.이는 API의 불필요한 const를 더욱 끔찍한 일이자 끔찍한 거짓말로 만들 뿐입니다. 다음 예를 참조하세요.

class foo
{
    void test(int * const pi);
};

void foo::test(int *pi) // Look, the const in the definition is so superfluous I can ignore it here
{
    pi++;  // I promised in my definition I wouldn't modify this
}

불필요한 const가 실제로 수행하는 모든 작업은 변수를 변경하거나 const가 아닌 참조로 변수를 전달하려고 할 때 다른 로컬 복사본이나 래퍼 함수를 ​​사용하도록 강제하여 구현자의 코드를 읽기 어렵게 만드는 것입니다.

이 예를 보세요.어느 것이 더 읽기 쉽나요?두 번째 함수에 추가 변수가 있는 유일한 이유는 일부 API 디자이너가 불필요한 const를 삽입했기 때문이라는 것이 분명합니까?

struct llist
{
    llist * next;
};

void walkllist(llist *plist)
{
    llist *pnext;
    while(plist)
    {
        pnext=plist->next;
        walk(plist);
        plist=pnext;    // This line wouldn't compile if plist was const
    }
}

void walkllist(llist * SUPERFLUOUS_CONST plist)
{
    llist * pnotconst=plist;
    llist *pnext;
    while(pnotconst)
    {
        pnext=pnotconst->next;
        walk(pnotconst);
        pnotconst=pnext;
    }
}

우리가 여기서 뭔가를 배웠기를 바랍니다.불필요한 const는 API를 어지럽히는 눈에 거슬리는 잔소리, 천박하고 무의미한 약속, 불필요한 방해이며 때로는 매우 위험한 실수로 이어집니다.

C++에서는 const가 기본값이어야 합니다.이와 같이 :

int i = 5 ; // i is a constant

var int i = 5 ; // i is a real variable

나는 직업으로 C++를 코딩할 때 가능한 모든 것을 구성했습니다.const를 사용하는 것은 컴파일러가 도움을 줄 수 있는 좋은 방법입니다.예를 들어 메서드 반환 값을 구성하면 다음과 같은 오타를 방지할 수 있습니다.

foo() = 42

다음을 의미했을 때:

foo() == 42

foo()가 non-const 참조를 반환하도록 정의된 경우:

int& foo() { /* ... */ }

컴파일러에서는 함수 호출에서 반환된 익명의 임시 항목에 값을 할당할 수 있습니다.const로 만들기:

const int& foo() { /* ... */ }

이러한 가능성을 제거합니다.

comp.lang.c++.moderated의 오래된 "Guru of the Week" 기사에 이 주제에 대한 좋은 토론이 있습니다. 여기.

해당 GOTW 기사는 Herb Sutter 웹 사이트에서 확인할 수 있습니다. 여기.

나는 당신의 가치 매개 변수를 const라고 말합니다.

이 버그가 있는 기능을 고려해 보세요.

bool isZero(int number)
{
  if (number = 0)  // whoops, should be number == 0
    return true;
  else
    return false;
}

숫자 매개변수가 const이면 컴파일러는 중지하고 버그에 대해 경고합니다.

나는 단지 [in] 데이터이고 함수에 의해 수정되지 않는 참조(또는 포인터)인 함수 매개변수에 const를 사용합니다.즉, 참조를 사용하는 목적이 데이터 복사를 방지하고 전달된 매개변수 변경을 허용하지 않는 것입니다.

예제에서 부울 b 매개 변수에 const를 추가하면 구현에만 제약이 가해지고 클래스 인터페이스에 기여하지 않습니다(일반적으로 매개 변수를 변경하지 않는 것이 좋습니다).

에 대한 함수 서명

void foo(int a);

그리고

void foo(const int a);

.c와 .h를 설명하는 동일합니다.

아사프

당신이 사용하는 경우 ->* 또는 .* 운영자님, 필수입니다.

그것은 당신이 다음과 같은 것을 쓰는 것을 방지합니다

void foo(Bar *p) { if (++p->*member > 0) { ... } }

내가 지금 거의 했던 일인데 아마도 당신이 의도한 대로 되지 않을 것입니다.

내가 말하려던 건

void foo(Bar *p) { if (++(p->*member) > 0) { ... } }

그리고 내가 하나를 넣었더라면 const 사이 Bar * 그리고 p, 컴파일러가 나에게 그렇게 말했을 것입니다.

아, 힘든 일이군요.한편으로 선언은 계약이므로 const 인수를 값으로 전달하는 것은 실제로 의미가 없습니다.반면에 함수 구현을 살펴보면 인수 상수를 선언하면 컴파일러가 최적화할 수 있는 기회가 더 많아집니다.

값 매개변수 'const'를 표시하는 것은 확실히 주관적인 것입니다.

그러나 나는 실제로 귀하의 예에서와 같이 값 매개변수를 const로 표시하는 것을 선호합니다.

void func(const int n, const long l) { /* ... */ }

나에게 값은 함수 매개변수 값이 함수에 의해 결코 변경되지 않는다는 것을 명확하게 나타냅니다.처음과 끝에서 동일한 값을 갖습니다.나에게 그것은 매우 기능적인 프로그래밍 스타일을 유지하는 것의 일부입니다.

짧은 함수의 경우 인수가 함수에 의해 수정되지 않는다는 것이 일반적으로 매우 명백하기 때문에 거기에 'const'를 갖는 것은 틀림없이 시간/공간 낭비입니다.

그러나 더 큰 기능의 경우 이는 구현 문서의 한 형태이며 컴파일러에 의해 시행됩니다.

'n'과 'l'을 사용하여 계산을 수행하면 하나 또는 둘 다 변경된 위치를 놓쳤기 때문에 다른 결과를 얻을 염려 없이 해당 계산을 리팩토링/이동할 수 있다고 확신할 수 있습니다.

구현 세부 사항이므로 구현에서 사용하는 것과 동일한 이름으로 함수 매개 변수를 선언할 필요가 없는 것처럼 헤더에 값 매개 변수 const를 선언할 필요가 없습니다.

인수가 값으로 전달되면 호출자의 개체를 수정하지 않으므로 const는 의미가 없습니다.

함수의 목적이 전달된 값을 수정하는 것이 아니라면 참조로 전달할 때는 const를 선호해야 합니다.

마지막으로, 현재 객체(this)를 수정하지 않는 함수는 const로 선언할 수 있고 선언해야 합니다.예는 다음과 같습니다.

int SomeClass::GetValue() const {return m_internalValue;}

이는 이 호출이 적용되는 객체를 수정하지 않겠다는 약속입니다.즉, 다음과 같이 호출할 수 있습니다.

const SomeClass* pSomeClass;
pSomeClass->GetValue();

함수가 const가 아닌 경우 컴파일러 경고가 발생합니다.

어쩌면 이것은 유효한 주장이 아닐 수도 있습니다.그러나 함수 컴파일러 내에서 const 변수의 값을 증가시키면 오류가 발생합니다."오류:읽기 전용 매개변수 증가".즉, 함수 내에서 실수로 변수를 수정하는 것을 방지하기 위한 방법으로 const 키워드를 사용할 수 있습니다(읽기 전용으로 가정되지 않음).따라서 컴파일 타임에 실수로 그런 일이 발생하면 컴파일러가 이를 알려줄 것입니다.당신이 이 프로젝트에 참여하는 유일한 사람이 아니라면 이는 특히 중요합니다.

언급한 경우에는 API 호출자에게 영향을 미치지 않으므로 일반적으로 수행되지 않으며 헤더에는 필요하지 않습니다.이는 함수 구현에만 영향을 미칩니다.

특별히 나쁜 일은 아니지만 API에 영향을 주지 않고 입력이 추가되므로 일반적으로 수행되지 않는다는 점을 고려하면 이점이 그다지 크지 않습니다.

값 전달 매개변수에는 const를 사용하지 않습니다.호출자는 매개변수 수정 여부를 신경 쓰지 않으며 구현 세부 사항입니다.

정말 중요한 것은 메소드가 인스턴스를 수정하지 않는 경우 const로 표시하는 것입니다.계속해서 이 작업을 수행하십시오. 그렇지 않으면 많은 const_cast<>가 발생하거나 const로 표시되어야 하는 다른 메소드를 호출하기 때문에 const를 표시하려면 많은 코드를 변경해야 한다는 것을 알 수 있습니다.

또한 수정할 필요가 없는 경우 로컬 변수를 const로 표시하는 경향이 있습니다.나는 "움직이는 부분"을 더 쉽게 식별함으로써 코드를 더 쉽게 이해할 수 있다고 믿습니다.

저는 가능하면 const를 사용하는 경향이 있습니다.(또는 대상 언어에 대한 다른 적절한 키워드.) 나는 순전히 컴파일러가 다른 방법으로는 할 수 없는 추가 최적화를 수행할 수 있도록 하기 때문에 이 작업을 수행합니다.나는 이러한 최적화가 무엇인지 전혀 모르기 때문에 어리석어 보일지라도 항상 그렇게 합니다.

내가 아는 모든 것에 대해, 컴파일러는 const 값 매개 변수를 잘 볼 수 있고 "이 기능은 어쨌든 그것을 수정하지 않으므로 참조로 전달하고 시계 사이클을 저장할 수 있습니다."라고 말합니다. 나는 그것이 함수 서명을 변경하기 때문에 그런 일을 할 것이라고 생각하지 않지만 요점을 만듭니다.어쩌면 다른 스택 조작이나 다른 작업을 수행할 수도 있습니다.요점은 모르겠지만, 컴파일러보다 더 똑똑해지려고 노력하면 부끄러움을 당할 뿐이라는 것입니다.

C++에는 const 정확성이라는 개념과 관련된 추가 수하물이 있으므로 더욱 중요해집니다.

컴파일러 최적화: http://www.gotw.ca/gotw/081.htm

가능하다면 const를 사용합니다.매개변수에 대한 Const는 값을 변경해서는 안 된다는 의미입니다.이는 참조로 전달할 때 특히 유용합니다.함수에 대한 const는 함수가 클래스 멤버를 변경해서는 안 된다고 선언합니다.

매개변수가 값으로 전달되고 참조가 아닌 경우 일반적으로 매개변수가 const로 선언되었는지 여부에 따라 큰 차이가 없습니다(참조 멤버가 포함되어 있지 않은 한 내장 유형에는 문제가 되지 않음).매개변수가 참조 또는 포인터인 경우 일반적으로 포인터 자체가 아닌 참조/지정된 메모리를 보호하는 것이 더 좋습니다(참조 자체를 const로 만들 수는 없지만 심판을 변경할 수 없기 때문에 중요하지 않다고 생각합니다). .const로 가능한 모든 것을 보호하는 것이 좋은 생각인 것 같습니다.매개변수가 단지 POD(내장 유형 포함)이고 나중에 변경될 가능성이 없는 경우(예:귀하의 예에서는 bool 매개변수).

.h/.cpp 파일 선언의 차이점에 대해 몰랐지만 어느 정도 의미가 있습니다.기계어 코드 수준에서는 "const"가 없으므로 함수(.h에서)를 non-const로 선언하면 코드는 const(최적화는 제외)로 선언하는 것과 동일합니다.그러나 함수(.ccp) 구현 내에서 변수 값을 변경하지 않도록 컴파일러를 등록하는 데 도움이 됩니다.변경을 허용하는 인터페이스에서 상속하는 경우 유용할 수 있지만 필요한 기능을 달성하기 위해 매개변수를 변경할 필요는 없습니다.

요약:

  • "일반적으로 Const Pass-By-Value는 전혀 불가능하고 오해의 소지가 있습니다." 에서 GOTW006
  • 그러나 변수와 마찬가지로 .cpp에 추가할 수 있습니다.
  • 표준 라이브러리는 const를 사용하지 않습니다.예: std::vector::at(size_type pos).표준 라이브러리에 충분하면 나에게도 좋습니다.

나는 그와 같은 매개 변수에 const를 넣지 않을 것입니다. 모두가 이미 부울 (부울과 반대로)이 일정하다는 것을 이미 알고 있으므로 사람들이 "기다리는 것"이라고 생각하게 할 것입니다. 또는 심지어 참조로 매개 변수를 전달하는 것조차도.

const에 대해 기억해야 할 점은 나중에 작성하는 것보다 처음부터 const를 만드는 것이 훨씬 쉽다는 것입니다.

무언가를 변경하지 않으려면 const를 사용하세요. 함수가 수행하는 작업과 예상되는 작업을 설명하는 추가 힌트입니다.나는 그 중 일부, 특히 c-문자열을 허용하는 API와 관련된 많은 C API를 보았습니다!

나는 헤더보다 cpp 파일에서 const 키워드를 생략하는 경향이 있지만 잘라내어 붙여넣는 경향이 있으므로 두 위치 모두에 보관됩니다.컴파일러가 왜 그것을 허용하는지 전혀 모르겠습니다. 컴파일러 문제인 것 같아요.가장 좋은 방법은 확실히 const 키워드를 두 파일에 모두 넣는 것입니다.

함수는 어쨌든 변수의 복사본만 수정할 수 있으므로 값 매개 변수를 "const"로 만들 이유가 없습니다.

"const"를 사용하는 이유는 더 큰 것을 전달하는 경우입니다(예:많은 멤버가 있는 구조체)를 참조로 사용합니다. 이 경우 함수가 이를 수정할 수 없도록 보장합니다.또는 오히려 기존 방식으로 수정하려고 하면 컴파일러가 불평할 것입니다.실수로 수정되는 것을 방지합니다.

Const 매개변수는 매개변수가 참조(예: 참조 또는 포인터)로 전달되는 경우에만 유용합니다.컴파일러는 const 매개변수를 볼 때 매개변수에 사용된 변수가 함수 본문 내에서 수정되지 않았는지 확인합니다.값별 매개변수를 상수로 만들고 싶어하는 이유는 무엇입니까?:-)

매개변수는 값에 의해 전달되므로 호출 함수의 관점에서 const를 지정하는지 여부는 아무런 차이가 없습니다. 기본적으로 값 전달 매개변수를 const로 선언하는 것은 의미가 없습니다.

예제의 모든 const에는 목적이 없습니다.C++는 기본적으로 값별 전달이므로 함수는 해당 정수 및 부울의 복사본을 가져옵니다.함수가 이를 수정하더라도 호출자의 복사본은 영향을 받지 않습니다.

그래서 나는 추가 const를 피할 것입니다.

  • 중복적이야
  • 그들은 텍스트를 어수선합니다
  • 그들은 유용하거나 효율적 일 수있는 경우 통과 된 가치를 바꾸지 못하게합니다.

나는 그 질문이 "약간" 오래된 것이라는 것을 알고 있지만 내가 그것을 발견했을 때 다른 누군가도 미래에 그렇게 할 수도 있습니다......그래도 그 불쌍한 친구가 내 댓글을 읽기 위해 여기에 목록을 올릴지는 의심스럽습니다. :)

우리는 여전히 C 스타일의 사고 방식에 너무 갇혀 있는 것 같습니다.OOP 패러다임에서는 유형이 아닌 객체를 가지고 놀 수 있습니다.Const 객체는 non-const 객체와 개념적으로 다를 수 있으며, 특히 논리적 const(bitwise-const와 대조)라는 의미에서 다를 수 있습니다.따라서 함수 매개변수의 const 정확성이 (아마도) POD의 경우 지나치게 주의를 기울이더라도 객체의 경우에는 그렇지 않습니다.함수가 const 객체와 함께 작동한다면 그렇게 말해야 합니다.다음 코드 조각을 고려해보세요.

#include <iostream>

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
class SharedBuffer {
private:

  int fakeData;

  int const & Get_(int i) const
  {

    std::cout << "Accessing buffer element" << std::endl;
    return fakeData;

  }

public:

  int & operator[](int i)
  {

    Unique();
    return const_cast<int &>(Get_(i));

  }

  int const & operator[](int i) const
  {

    return Get_(i);

  }

  void Unique()
  {

    std::cout << "Making buffer unique (expensive operation)" << std::endl;

  }

};

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void NonConstF(SharedBuffer x)
{

  x[0] = 1;

}

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
void ConstF(const SharedBuffer x)
{

  int q = x[0];

}

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
int main()
{

  SharedBuffer x;

  NonConstF(x);

  std::cout << std::endl;

  ConstF(x);

  return 0;

}

추신.:여기서는 (const) 참조가 더 적절하고 동일한 동작을 제공한다고 주장할 수 있습니다.글쎄요.다른 곳에서 보던 것과는 다른 그림을 보여주네요...

50개 이상의 노출된 함수가 있는 C++ 프로그램과 const 한정자를 산발적으로 사용하는 .h 파일을 사용해야 하는 VB.NET 프로그래머이기 때문에 ByRef 또는 ByVal을 사용하여 변수에 액세스해야 하는 시기를 알기가 어렵습니다.

물론 프로그램은 실수한 줄에서 예외 오류를 생성하여 알려주지만, 그런 다음 2~10개의 매개변수 중 어느 것이 잘못되었는지 추측해야 합니다.

이제 저는 모든 VB.NET 함수 정의를 쉽게 생성하는 자동화된 방법을 허용하는 방식으로 변수(.h 파일에)를 실제로 정의해야 한다고 개발자를 설득해야 하는 불쾌한 작업을 맡게 되었습니다.그러면 그들은 "이 글을 읽어보세요"라고 의기양양하게 말할 것입니다.선적 서류 비치."

.h 파일을 구문 분석하고 모든 Declare Function 명령을 생성하는 awk 스크립트를 작성했지만 어떤 변수가 R/O인지 R/W인지에 대한 표시기가 없으면 작업의 절반만 수행합니다.

편집하다:

다른 사용자의 격려로 다음을 추가합니다.

다음은 (IMO) 형식이 잘못된 .h 항목의 예입니다.

typedef int (EE_STDCALL *Do_SomethingPtr)( int smfID, const char* cursor_name, const char* sql );

내 스크립트의 결과 VB입니다.

    Declare Function Do_Something Lib "SomeOther.DLL" (ByRef smfID As Integer, ByVal cursor_name As String, ByVal sql As String) As Integer

첫 번째 매개변수에 "const"가 누락되어 있습니다.그것 없이는 프로그램 (또는 다른 개발자)은 첫 번째 매개 변수를 "Byval"으로 전달해야한다는 것을 알 수 없습니다. "const"를 추가하면 다른 언어를 사용하는 개발자가 작업 코드를 쉽게 작성할 수 있도록 .H 파일 자체 문서화가됩니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top