왜 postfix 증가가 있습니까?

면책 조항 : 접두사와 접미사 증가의 의미를 완벽하게 알고 있습니다. 그들이 어떻게 작동하는지 설명하지 마십시오.

스택 오버플로에 대한 질문을 읽으면 프로그래머가 접미사 증가 연산자에 의해 반복해서 혼란스러워한다는 것을 알 수는 없습니다. 이것으로부터 다음과 같은 질문이 발생합니다. postfix 증가가 코드 품질 측면에서 실질적인 이점을 제공하는 사용 사례가 있습니까?

예를 들어 내 질문을 명확히 해 드리겠습니다. 다음은 매우 간결한 구현입니다 strcpy.

while (*dst++ = *src++);

그러나 그것은 내 책에서 가장 자체적으로 문서화 된 코드는 아닙니다 (그리고 제정신 컴파일러에 대해 두 가지 성가신 경고를 생성합니다). 그렇다면 다음 대안의 문제점은 무엇입니까?

while (*dst = *src)
{
    ++src;
    ++dst;
}

그런 다음 조건에서 혼란스러운 할당을 제거하고 완전히 경고없는 코드를 얻을 수 있습니다.

while (*src != '\0')
{
    *dst = *src;
    ++src;
    ++dst;
}
*dst = '\0';

(그래, 난 알고, src그리고 dst이러한 대안 솔루션의 다른 결말 값을해야하지만 이후 strcpy즉시 루프 후 반환,이 경우에는 문제가되지 않습니다.)

postfix 증가의 목적은 가능한 한 코드를 간결하게 만드는 것입니다. 나는 이것이 어떻게 우리가 노력해야 하는지를 보지 못합니다. 이것이 원래 성능에 관한 것이라면 오늘날에도 여전히 관련이 있습니까?

한 번 성능에 영향을 미쳤지 만 실제 이유는 의도를 깨끗하게 표현하기위한 것이라고 생각합니다. 실제 질문은 무언가 while (*d++=*s++);가 의도를 명확하게 표현 하는지 여부 입니다. IMO는 그 대안을 제시 하지만 대안이 덜 명확하다는 것을 알았습니다. 하지만 이는 수십 년 동안 일이 수행되는 방식에 익숙해 져서 발생했을 수 있습니다. K & R에서 C를 배웠다면 (C에는 거의 다른 책 이 없었기 때문에 ) 아마 도움이 될 것입니다.

어느 정도까지는 오래된 코드에서 간결함이 훨씬 더 중요하다는 것이 사실입니다. 개인적으로, 나는 이것이 아주 좋은 것이라고 생각합니다. 몇 줄의 코드를 이해하는 것은 보통 사소한 일입니다. 어려운 것은 많은 양의 코드를 이해하는 것입니다. 테스트와 연구에 따르면 화면의 모든 코드를 한 번에 맞추는 것이 코드를 이해하는 데 중요한 요소라는 점이 반복적으로 나타났습니다. 화면이 확장됨에 따라 이것은 사실로 유지되므로 코드를 (합리적으로) 간결하게 유지하는 것이 중요합니다.

물론 선상으로 갈 수는 있지만 이것이 아니라고 생각합니다. 특히, 한 줄의 코드를 이해하는 것이 극도로 어려워 지거나 시간이 많이 걸리는 경우, 특히 더 적은 수의 코드 줄을 이해하면 더 많은 줄을 이해하는 것보다 더 많은 노력을 기울일 때이 문제가 극복 될 것이라고 생각합니다. Lisp와 APL에서는 빈번하지만, (적어도 나에게는) 그렇지 않습니다.

컴파일러 경고에 대해 덜 걱정합니다. 많은 컴파일러가 상당히 정기적으로 엄청나게 경고를내는 경험입니다. 분명히 사람들이 자신의 코드 (및 경고가 발생할 수있는 경고)를 이해해야 한다고 생각하지만 일부 컴파일러에서 경고를 유발하는 괜찮은 코드가 반드시 잘못된 것은 아닙니다. 물론 초보자는 항상 안전하게 무시할 수있는 것을 알지 못하지만 초보자는 영원히 머무를 필요가 없으며 우리처럼 코딩 할 필요도 없습니다.

하드웨어 오류였습니다.

당신이 알아 차리게 흥미 롭다. Postfix 증가는 아마도 완벽하게 좋은 이유가 많을 수도 있지만 C의 많은 것들과 마찬가지로 인기도 는 언어의 기원으로 추적 될 수 있습니다.

C는 다양한 초기 및 저전력 시스템에서 개발되었지만 C 및 Unix는 PDP-11의 메모리 관리 모델로 상대적으로 큰 인기를 얻었습니다. 이들은 비교적 중요한 컴퓨터 였고 Unix는 -11에서 사용할 수있는 다른 7 개의 초라한 운영 체제보다 훨씬 뛰어 났습니다 .

PDP-11에서도 마찬가지입니다.

*--p

과

*p++

... 어드레싱 모드 로 하드웨어에서 구현 되었습니다 . (또한 *p,하지만 다른 조합.) 그 초기 기계에서 모든 미만 0.001 GHz의, 루프에서 명령 또는 두 개의 저장 거의 대기-A-초-A-분을 기다리거나 이동 - 아웃을위한 없었다해야한다 점심 차이. 이것은 구체적으로 포스트 증가에 대해 말하지는 않지만 포인터 포스트 증가가있는 루프는 당시 색인보다 훨씬 좋을 수 있습니다.

결과적으로 C 관용구가 C 멘탈 매크로가 되었기 때문에 디자인 패턴이 나타납니다.

그것은 {C89가 최신이기 때문에 이것이 요구 사항이 아니었지만 지금은 코드 패턴입니다.

업데이트 : 분명히 *p++언어 의 주된 이유 는 언어가 자주하고 싶어하는 것이기 때문입니다. 코드 패턴의 인기 는 PDP-11이 도착하기 전에 약간 디자인 된 언어의 기존 패턴과 일치하는 인기있는 하드웨어에 의해 강화 되었습니다.

요즘에는 어떤 패턴을 사용하거나 인덱싱을 사용하는 경우 아무런 차이가 없으며 일반적으로 상위 수준에서 프로그래밍하지만 0.001GHz 시스템에서 많은 문제가 있었으며 다른 것을 사용 *--x하거나 *x++의미가 없었습니다. PDP-11을 "받지 못했습니다", 사람들이 당신에게 와서 "알고 있었나요?"라고 말했을 것입니다 :-) :-)

접두사와 접미사 --및 ++연산자는 켄 톰슨에 의해 B 언어 (C의 전신)에 도입되었다 - 그리고 아니, 그들은 PDP-11, 당시 존재하지 않았던 영감되지 않았다.

Dennis Ritchie의 "C 언어의 개발" 에서 인용 :

톰슨 발명에 의해 한 단계 더 갔다 ++와--증가 또는 감소하는 연산자; 접두사 또는 접미사 위치는 피연산자의 값을 기록하기 전 또는 후에 변경이 발생하는지 여부를 결정합니다. 그들은 초기 버전의 B에는 없었지만 그 길을 따라 나타났습니다. 사람들은 종종 C와 Unix가 처음으로 인기를 얻은 DEC PDP-11에서 제공하는 자동 증가 및 자동 감소 주소 모드를 사용하기 위해 만들어 졌다고 생각합니다. B가 개발되었을 때 PDP-11이 없었기 때문에 역사적으로 불가능합니다. 그러나 PDP-7에는 몇 개의 '자동 증가'메모리 셀이 있었으며,이를 통해 간접 메모리 참조가 셀을 증가시키는 특성이있었습니다. 이 기능은 아마도 그러한 연산자를 Thompson에게 제안했을 것입니다. 접두사와 접미사를 모두 만드는 일반화는 그 자체였습니다. 과연,++x보다 작습니다 x=x+1.

사후 증가 연산자가 존재하는 명백한 이유 는 장소 전체 (++x,x-1)또는 (x+=1,x-1)전체에 식을 쓰거나 이해할 수없는 부작용이있는 사소한 문구를 여러 명령문으로 쓸데없이 분리 할 필요가 없기 때문 입니다. 여기 몇 가지 예가 있어요.

while (*s) x+=*s++-'0';

if (x) *s++='.';

문자열을 순방향으로 읽거나 쓸 때마다 사전 증가가 아닌 후행 증가는 거의 항상 자연스러운 작업입니다. 나는 사전 증분에 대한 실제 사용을 거의 경험하지 못했으며, 사전 감소를 위해 찾은 유일한 주요 용도는 숫자를 문자열로 변환하는 것입니다 (인간 쓰기 시스템은 숫자를 거꾸로 쓰기 때문에).

편집 : 실제로 그것은 그렇게 추악하지는 않습니다. 대신 (++x,x-1)당신 물론 사용할 수 있습니다 ++x-1또는 (x+=1)-1. 여전히 x++더 읽기 쉽습니다.

PDP-11은 명령 세트에서 증가 후 및 감소 후 작업을 제공했습니다. 이제 이것들은 지침이 아니 었습니다. 그것들은 레지스터가 증가하기 전이나 감소 된 후에 레지스터의 값을 원한다는 것을 지정할 수있게 해주는 명령 수정 자입니다.

기계 언어의 단어 복사 단계는 다음과 같습니다.

movw (r1)++,(r2)++

레지스터를 통해 한 위치에서 다른 위치로 단어를 이동 시켰으며 레지스터는 다시 할 준비가되었습니다.

C가 PDP-11을 기반으로 구축되면서 C에 도입 된 유용한 개념이 많이 발견되었습니다. C는 어셈블러 언어를 대체 할 수있는 유용한 도구였습니다. 사전 증가 및 사후 감소가 대칭을 위해 추가되었습니다.

나는 그것이 정말로 필요했던 것을 의심한다. 내가 아는 한, 루프에서 사전 증분을 사용하는 것보다 대부분의 플랫폼에서 더 컴팩트 한 것으로 컴파일되지 않습니다. 그것이 만들어 질 당시에는 코드의 간결함이 코드의 선명도보다 더 중요했습니다.

즉, 코드의 선명도가 중요하지는 않지만 (또는 중요하지 않은) 것은 아니지만 모든 키 입력으로 인해 낮은 보드 모뎀 (보드에서 측정하는 것은 느림)에 입력 할 때 패리티 검사로 사용되는 단일 비트를 사용하여 메인 프레임을 한 번에 한 바이트 씩 다시 반향 할 수 있으므로 많이 입력하지 않아도됩니다.

이것은 &와 | ==보다 우선 순위가 낮은 연산자

최고의 의도 (& & 및 ||의 비 단락 버전)로 설계되었지만 이제는 프로그래머를 혼란스럽게하며 결코 바뀌지 않을 것입니다.

어쨌든, 이것은 귀하의 질문에 대한 좋은 대답이 없다고 생각한다는 대답에 불과하지만, 나보다 더 전문가 코더에 의해 아마도 틀릴 것입니다.

--편집하다--

나는 둘 다 믿을 수 없을만큼 유용하다는 것을 알았 습니다. 다른 사람이 좋아하든 그렇지 않든 바뀌지 않을 것이라고 지적하고 있습니다.

포인터를 처리 할 때 (역 참조 여부에 관계없이) 접미사 애퍼 레이터를 좋아합니다.

p++

보다 자연스럽게 "다음 지점으로 이동"으로 읽습니다.

p += 1

sizeof (* p)! = 1 인 포인터로 처음 사용했을 때 초보자를 혼동해야합니다.

혼란 문제를 올바르게 진술하고 있습니까? 초보자를 혼란스럽게하는 것은 접미사 ++ 연산자가 역 참조 * 연산자보다 우선 순위가 높다는 사실이 아닙니다.

*p++

로 파싱

*(p++)

그리고 아닙니다

(*p)++

일부는 예상 할 수 있습니까?

(그게 나쁘다고 생각하십니까? C 선언 읽기를 참조하십시오 .)

좋은 프로그래밍의 미묘한 요소 중에는 지역화 와 미니멀리즘이 있습니다 .

• 최소한의 사용 범위에서 변수 배치
• 쓰기 액세스가 필요하지 않은 경우 const 사용
• 기타

같은 정신에서 x++의 현재 값에 대한 참조 현지화하는 방법으로 볼 수있다 x적어도 지금은 - - 동안 즉시했습니다 나타내는 여부를 그 값으로 완성하고 (다음으로 이동 유효 할 x인 int또는 포인터 또는 반복자). 약간의 상상력만으로도 x더 이상 필요하지 않은 즉시 이전 값 / 위치가 "범위를 벗어난"상태가되고 새로운 값으로 이동하는 것과 비교할 수 있습니다. 전환이 가능한 정확한 지점은 접미사로 강조 표시됩니다++ . 이것이 아마도 "이전"의 최종 사용이라는 의미 x는 프로그래머가 주변 코드를 스캔 할 때 도움이되는 알고리즘에 대한 귀중한 통찰력이 될 수 있습니다. 물론, 접미사++ 프로그래머가 새로운 가치의 사용에 대한 경계를 세울 수 있습니다. 이것은 새로운 가치가 실제로 필요한시기에 따라 좋을 수도 있고 그렇지 않을 수도 있습니다. 상황에 도움이됩니다.

많은 초보자가 기능으로 인해 혼란 스러울 수 있지만, 장기적인 이점과 균형을 맞출 가치가 있습니다. 초보자는 초보자가 오랫동안 머 무르지 않습니다.

와우, 많은 답변이 무의미한 것입니다 (대담한 경우). 명백한 점을 지적하지 않는 명백한 점을 지적한다면 특히 용서하십시오. (Stroustrup의 관점에서 볼 때) 아직 게시되지 않은 것 같습니다! :)

Postfix x++는 표현식에서 '위쪽'으로 전달되는 임시 변수를 생성하지만 변수 x는 이후에 증가합니다.

접두사 ++x는 임시 객체를 생성하지 않지만 'x'를 증가시키고 결과를 표현식에 전달합니다.

운영자를 아는 사람들에게는 그 가치가 편리합니다.

예를 들면 다음과 같습니다.

int x = 1;
foo(x++); // == foo(1)
// x == 2: true

x = 1;
foo(++x); // == foo(2)
// x == 2: true

물론,이 예제의 결과는 다른 동등한 (그리고 아마도 덜 경 사진) 코드에서 생성 될 수 있습니다.

그렇다면 왜 postfix 연산자가 있습니까? 나는 그것이 혼란스러워 졌음에도 불구하고 지속되는 관용구이기 때문에 추측합니다. 한때 가치가 있다고 여겨지는 레거시 구조이지만,인지 된 가치가 편의성과 같이 성능면에서 그렇게 많이 확신하지는 않습니다. 그 편리함은 잃어 버리지 않았지만 가독성에 대한 인식이 높아져서 운영자의 목적에 의문을 제기했다고 생각합니다.

더 이상 접미사 연산자가 필요합니까? 아마 아닐 것입니다. 그 결과 혼란스럽고 이해력에 장애가됩니다. 일부 훌륭한 코더들은 특히 "PERL-esque"의 아름다움을 가진 곳에서 유용한 곳을 즉시 알 수 있습니다. 그 아름다움의 비용은 가독성입니다.

명시 적 코드가 간결성, 가독성, 이해성 및 유지 관리성에 비해 이점이 있음에 동의합니다. 훌륭한 디자이너와 관리자는 그것을 원합니다.

그러나 일부 프로그래머는 postfix 연산자와 같이 아름답고 단순하게 만들 수있는 코드를 생성하도록 장려하는 특정 아름다움이 있습니다. 그것은 피투성이 임에도 불구하고 더 바람직하지는 않지만 더 아름답게 만드는 어떤 것이 있습니다.

다시 말해서, 어떤 사람들 while (*dst++ = *src++);은 캔버스보다 솔처럼 마치 단순하게 숨을 쉴 수있는 더 아름다운 해결책이라는 것을 알게됩니다. 아름다움을 높이기 위해 언어를 이해해야한다는 것은 그 아름다움에 그치지 않습니다.

Kernighan & Ritchie의 정당성 검증 (Original K & R page 42 and 43)을 보자 :

특이한 측면은 ++와-를 접두사 또는 접미사로 사용할 수 있다는 것입니다. (...) 원하는 값이없는 상황에서 (..) 취향에 따라 접두사 또는 접두사를 선택하십시오. 그러나 하나 또는 다른 하나가 특별히 요구되는 상황입니다.

텍스트는 " 보다 간결한 "코드 를 작성하려는 명백한 목표를 가지고 인덱스 내에서 증분을 사용하는 몇 가지 예를 계속 합니다. 따라서 이러한 연산자의 이유는보다 컴팩트 한 코드의 편의성입니다.

주어진 ( squeeze(), getline()및 strcat()) 세 가지 예는 인덱싱을 사용하는 표현식 내에서 접미사 만 사용합니다. 저자는 포함 된 증분을 사용하지 않는 더 긴 버전과 코드를 비교합니다. 이것은 초점이 컴팩트함에 있음을 확인합니다.

102 페이지의 K & R 하이라이트에서는 포인터 역 참조와 함께이 연산자를 사용합니다 (예 : *--p및 *p--). 더 이상의 예는 제시되지 않았지만 다시 말하지만 이점은 컴팩트 함이 분명합니다.

접두사는 예를 들어 색인 또는 끝에서 쳐다 보는 포인터를 감소시킬 때 매우 일반적으로 사용됩니다.

 int i=0; 
 while (i<10) 
     doit (i++);  // calls function for 0 to 9  
                  // i is 10 at this stage
 while (--i >=0) 
     doit (i);    // calls function from 9 to 0 

나는 전제에 동의하지 않을거야 ++p, p++어떻게 든 읽기 어렵거나 불분명하다. 하나는 "p를 증가시키고 p를 읽는다"를 의미하고, 다른 하나는 "p를 읽고 p를 증가시키는 것"을 의미한다. 두 경우 모두 코드의 연산자는 코드 설명의 정확한 위치에 있으므로 ++의미를 알면 결과 코드의 의미를 알 수 있습니다.

당신은 알아 차리기 힘든 코드를 생성 할 수 있는 구문을하지만, 나는 여기에 케이스를 볼 수 없습니다 p++/ ++p입니다 본질적 를 붙일.

이것은 전기 기술자의 POV에서 온 것입니다.

후입 선출 (LIFO) 스택을 유지하기 위해 사후 증분 및 사전 감소 연산자가 내장 된 프로세서가 많이 있습니다.

다음과 같습니다.

 float stack[4096];
 int stack_pointer = 0;

 ... 

 #define push_stack(arg) stack[stack_pointer++] = arg;
 #define pop_stack(arg) arg = stack[--stack_pointer];

 ...

나는 몰라,하지만 그것이 접두사와 접두사 증가 연산자를 모두 볼 것으로 예상되는 이유입니다.

컴팩트성에 대한 Christophe의 요점을 강조하기 위해 V6의 코드를 모두 보여주고 싶습니다. 이것은 http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/c/c00.c 의 원본 C 컴파일러의 일부입니다 .

/*
 * Look up the identifier in symbuf in the symbol table.
 * If it hashes to the same spot as a keyword, try the keyword table
 * first.  An initial "." is ignored in the hash.
 * Return is a ptr to the symbol table entry.
 */
lookup()
{
    int ihash;
    register struct hshtab *rp;
    register char *sp, *np;

    ihash = 0;
    sp = symbuf;
    if (*sp=='.')
        sp++;
    while (sp<symbuf+ncps)
        ihash =+ *sp++;
    rp = &hshtab[ihash%hshsiz];
    if (rp->hflag&FKEYW)
        if (findkw())
            return(KEYW);
    while (*(np = rp->name)) {
        for (sp=symbuf; sp<symbuf+ncps;)
            if (*np++ != *sp++)
                goto no;
        csym = rp;
        return(NAME);
    no:
        if (++rp >= &hshtab[hshsiz])
            rp = hshtab;
    }
    if(++hshused >= hshsiz) {
        error("Symbol table overflow");
        exit(1);
    }
    rp->hclass = 0;
    rp->htype = 0;
    rp->hoffset = 0;
    rp->dimp = 0;
    rp->hflag =| xdflg;
    sp = symbuf;
    for (np=rp->name; sp<symbuf+ncps;)
        *np++ = *sp++;
    csym = rp;
    return(NAME);
}

이것은 좋은 스타일의 교육으로 samizdat에 전달 된 코드이지만 오늘날 우리는 결코 그렇게 쓰지 않을 것입니다. 부작용 if과 while조건 이 얼마나 많이 포함되어 있는지 , 반대로 for루프 본문에서 수행되므로 두 루프에 증분식이없는 방법을 살펴보십시오 . 꼭 필요한 경우 블록을 중괄호로만 묶는 방법을 살펴보십시오.

이것의 일부 는 오늘날 컴파일러가 우리를 위해 할 것으로 예상되는 종류의 수동 미세 최적화였습니다. 그러나 컴퓨터에 대한 전체 인터페이스가 단일 80x25 유리 tty 일 때 코드 를 원한다는 가설을 제시합니다. 최대한 밀도가 높아져 더 많은 내용을 볼 수 있습니다.

(모든 것에 글로벌 버퍼를 사용하는 것은 아마도 어셈블리 언어로 치아를 자르는 것에서 숙취 일 것입니다.)

아마도 화장품에 대해서도 생각해야합니다.

while( i++ )

논란의 여지없이 "더 좋아 보인다"

while( i+=1 )

어떤 이유로 증분 후 운영자는 매우 매력적으로 보입니다. 짧고 달콤하며 모든 것을 1 씩 증가시킵니다. 접두사와 비교하십시오.

while( ++i )

"거꾸로 본다"그렇지 않습니까? 누군가 긍정적 인 것 ( +0또는 이와 유사한 것) 을 지정하는 것이 어리석은 경우를 제외하고는 수학에서 더하기 부호 FIRST가 표시되지 않습니다 . 우리는 OBJECT + SOMETHING을 보는 데 익숙합니다.

채점과 관련이 있습니까? A, A +, A ++? 나는 처음에 파이썬 사람들 operator++이 그들의 언어에서 제거되었다는 사실에 대해 매우 치즈를 입었다 고 말할 수 있습니다!

9에서 0까지 거꾸로 계산 :

for (unsigned int i=10; i-- > 0;)  {
    cout << i << " ";
}

또는 동등한 while 루프.