사소한 조건문이 루프의 초기화 섹션으로 이동해야합니까?

stackoverflow.com 의이 질문 에서이 아이디어를 얻었습니다.

다음과 같은 패턴이 일반적입니다.

final x = 10;//whatever constant value
for(int i = 0; i < Math.floor(Math.sqrt(x)) + 1; i++) {
  //...do something
}

내가 만들려고하는 요점은 조건문이 복잡하고 변경되지 않는다는 것입니다.

루프의 초기화 섹션에서 선언하는 것이 더 낫습니까?

final x = 10;//whatever constant value
for(int i = 0, j = Math.floor(Math.sqrt(x)) + 1; i < j; i++) {
  //...do something
}

이것이 더 명확합니까?

조건식이 다음과 같은 단순한 경우

final x = 10;//whatever constant value
for(int i = 0, j = n*n; i > j; j++) {
  //...do something
}

내가하는 일은 다음과 같습니다.

void doSomeThings() {
    final x = 10;//whatever constant value
    final limit = Math.floor(Math.sqrt(x)) + 1;
    for(int i = 0; i < limit; i++) {
         //...do something
    }
}

솔직히 루프 헤더에 초기화 j(현재 limit)를 넣는 유일한 이유 는 올바르게 범위를 유지하는 것입니다. 문제가 아닌 것이 좋은 밀폐 범위라는 것을 확인하는 데 필요한 모든 것.

나는 빠른 욕망에 감사 할 수 있지만 진정한 이유없이 가독성을 희생하지는 않습니다.

물론 컴파일러가 최적화하여 여러 변수를 초기화하는 것이 합법적 일 수 있지만 루프는 디버그하기가 어렵습니다. 인간에게 친절하십시오. 이것이 실제로 우리 속도를 늦추는 것으로 판명되면 그것을 고칠만큼 충분히 이해하는 것이 좋습니다.

좋은 컴파일러는 두 가지 방법으로 동일한 코드를 생성하므로 성능을 원한다면 중요한 루프에 있고 실제로 프로파일 링하여 차이를 발견 한 경우에만 변경하십시오 . 컴파일러가 최적화 할 수 없더라도 사람들이 함수 호출 사례에 대한 의견에서 지적했듯이 대다수의 상황에서 성능 차이는 너무 작아 프로그래머가 고려할 가치가 없습니다.

하나...

우리는 코드가 주로 인간 간의 의사 소통 수단이라는 것을 잊지 말아야합니다. 두 옵션 모두 다른 사람과 잘 소통하지는 않습니다. 첫 번째는 매 반복마다 표현식을 계산해야한다는 인상을주고, 초기화 섹션에있는 두 번째는 루프 내 어딘가에 업데이트되어 실제로는 일정하다는 것을 의미합니다.

실제로 루프에서 꺼내어 final코드를 읽는 사람에게 즉시 그리고 풍부하게 명확하게하기를 원합니다 . 변수의 범위를 넓히기 때문에 이상적이지는 않지만 둘러싸는 함수에는 그 루프보다 많은 것이 포함되어서는 안됩니다.

@Karl Bielefeldt의 답변에서 언급했듯이 이것은 일반적으로 문제가 아닙니다.

그러나 한때 C와 C ++의 일반적인 문제였으며 코드 가독성을 줄이지 않고 문제를 회피하는 트릭이 생겼 습니다0 .

final x = 10;//whatever constant value
for(int i = Math.floor(Math.sqrt(x)); i >= 0; i--) {
  //...do something
}

이제 모든 반복의 조건은 모든 >= 0컴파일러가 1 또는 2 개의 어셈블리 명령어로 컴파일하는 것입니다. 지난 수십 년 동안 이루어진 모든 CPU에는 이와 같은 기본 점검이 있어야합니다. 내 x64 컴퓨터에서 빠른 검사를 수행하면 예상대로 cmpl $0x0, -0x14(%rbp)(long-int-comare value 0 vs. 레지스터 rbp offsetted -14) 및 jl 0x100000f59(2nd-arg에 대해 이전 비교가 참이면 루프 뒤의 명령으로 점프 함 ) <1 차 인수”) .

+ 1에서 Math.floor(Math.sqrt(x)) + 1;를 제거했습니다 . 수학이 운동하기 위해서는 시작 값이이어야합니다 int i = «iterationCount» - 1. 또한 반복자에 서명해야합니다. unsigned int작동하지 않으며 컴파일러 경고가 발생합니다.

~ 20 년 동안 C 기반 언어로 프로그래밍 한 후 앞으로 색인 색인을 작성해야하는 특별한 이유가없는 한 역 색인 색인 루프 만 작성합니다. 조건부에서 간단한 확인 외에도 역 반복은 종종 반복적 인 배열 돌연변이 동안 문제가 될 수있는 것을 회피합니다.

Math.sqrt (x)가 Mymodule.SomeNonPureMethodWithSideEffects (x)로 바뀌면 재미 있습니다.

기본적으로 내 modus operandi는 다음과 같습니다. 무언가가 항상 같은 값을 줄 것으로 예상되면 한 번만 평가하십시오. 예를 들어 List.Count와 같이 루프 작동 중에 목록이 변경되지 않으면 루프 외부의 카운트를 다른 변수로 가져옵니다.

이러한 "카운트"중 일부는 특히 데이터베이스를 처리 할 때 놀랍도록 비쌀 수 있습니다. 목록을 반복하는 동안 변경되지 않아야하는 데이터 세트에서 작업하는 경우에도 마찬가지입니다.

제 생각에는 이것은 언어마다 매우 다릅니다. 예를 들어 C ++ 11을 사용하는 경우 조건 검사가 constexpr함수 인 경우 컴파일러는 매번 동일한 값을 생성한다는 것을 알고 여러 실행을 최적화 할 가능성이 매우 높습니다.

그러나 함수 호출이 아닌 라이브러리 함수 인 경우 constexpr 경우 컴파일러는 인라인이 아니기 때문에 순수하게 추론 할 수없는 한이를 추론 할 수 없으므로 모든 반복에서 거의 확실히 그것을 실행할 것입니다.

Java에 대해서는 잘 알지 못하지만 JIT 컴파일 된 컴파일러는 런타임에 조건을 인라인하고 최적화하기에 충분한 정보가 런타임에 있다고 생각합니다. 그러나 이것은 좋은 컴파일러 디자인에 의존 할 것이며,이 루프를 결정하는 컴파일러는 우리가 추측 할 수있는 최적화 우선 순위였습니다.

개인적으로 가능하다면 for 루프 안에 조건을 넣는 것이 약간 더 우아하다고 생각하지만 복잡하다면 constexpror 또는 inline함수에 작성하거나 함수가 순수하고 최적화 가능하다는 것을 암시하는 언어 로 작성합니다 . 이것은 읽을 수없는 거대한 선을 만들지 않고 의도를 명확하게하고 관용적 루프 스타일을 유지합니다. 또한 독자적인 기능인 경우 조건 점검에 이름을 부여하므로 독자는 복잡한 경우 읽지 않고 점검 내용을 논리적으로 즉시 볼 수 있습니다.