어떤 품질의 코드가 "컴파일러가 이를 최적으로 빗어 낼 것"을 기반으로 작성하면 여기에 부정적인 영향이 있지 않습니까?
내 예제 - 글쎄, 그것은 거의 품질이 아닙니다. 이것들은 전형적인 구조입니다 - 나는 오랫동안 github에서 소스를 비교 해 왔습니다. tst1은 무엇입니까, tst2 예제는 무엇입니까, 둘 다 프로그래머가 적극적으로 사용합니다
따라서 컴파일러 개발자는 오랫동안 일반적인 코드 구성을 연구했으며 이는 컴파일러에 문제가 되지 않는다고 생각합니다.
부정적인 영향 - 여기에 @TheXpert 가 위에서 쓴 것처럼 코드 설계에 대한 회사 의 요구 사항이 있지만 요구 사항은 일반적으로 동일합니다. 코드는 방금 도착했다 ....
fxsaber :
한 가지 스타일로 작성하면 컴파일러가 올바른 작업을 수행한다는 것을 확실히 알 수 있습니다. 다른 하나는 컴파일러가 더 똑똑하기를 바랍니다.
예, 지금 더 똑똑한 것은 컴파일러가 아니지만 프로세서 자체인 IMHO, 여전히 고성능 코드에 대해 이야기하고 있다면 주요 성능 비용은 함수 호출이 아니라 메모리 읽기(메모리 액세스)에 있습니다. 데이터/가변 저장 장치를 계산된 작은 값으로 바꿀 수 있습니다. 그러면 (프로세서 마이크로 명령어의 최적화 수준에서) 작은 이득을 얻을 수 있습니다.
... 그리고 나머지, IMHO, 사악한 것))))
추신 : 컴파일러 수준의 코드 최적화도 있습니다. 거의 읽지 않습니다. 모든 것이 추측 수준에 있습니다. 정기적으로 PC 하드웨어에 대해 읽습니다. 오랫동안 읽었습니다. 제 의견을 썼습니다.
fxsaber :
크로스 플랫폼, 다른 컴파일러 등을 고려하여 코드에서 수행 중인 작업에 대한 인식을 선택합니다.
그런 다음 옵션이 없습니다. 간단히 말해서 "나는 예술가입니다. 그렇게 봅니다.")))), 나는 상처받지 않았 으면합니다.
제목의 기사와 관련하여 - 올바른 전제(코드는 가능한 한 결정적이어야 함)가 완전히 어리석은 방식으로 사용되었습니다. 예를 들어 더하기 연산과 누적 연산을 비교한 것입니다. 그리고 덧셈 연산은 결정적이며 항상 하나의 결과를 반환하지만 결과가 항상 다르기 때문에 누적은 그렇지 않다고 결론지었습니다.
하지만... 이것들은 다른 연산이며, 두 경우 모두 결과가 절대적으로 정확하며 각각 더하기와 누적에서 예상되는 결과입니다!
난수 생성기의 예도 난수 구성 요소를 사용한 작업이라고 생각하면 "비결정적"이라고 할 수 없습니다.
내가 보기에 모든 비결정론은 작성자가 코드에서 의도한 것과 완전히 다른 것을 코드에서 기대한다는 사실에 있는 것 같습니다.
음, 두 번째 요점은 코드의 가독성입니다. 나는 작업 "질문"이 매우 해롭고 이해하기 어렵다고 생각합니다. "질문 질문"을 조건 연산자로 대체하면 정확히 동일한 효율성을 가진 실행 코드가 제공됩니다. 동시에 소스 텍스트가 눈에 띄게 더 방대해졌지만 그만큼 더 명확해졌습니다. 큰 장점이라고 생각합니다.
저는 항상 수많은 논리적 표현 을 중간 결과를 가진 여러 개별 작업으로 분해하기 위해 노력합니다. 그러한 코드가 덜 효율적인 실행 코드를 생성하더라도 더 나은 이해를 통한 이득이 훨씬 더 중요하다고 생각합니다.
voidOnStart ()
{
if (condition)
{
if (other_condition)
{
for (loop_stmt)
{
if (wtf)
{
while (repeats)
{
if (oh_shit)
{
if (really_fck)
{
deep_nesting();
}
}
}
}
}
}
}
}
99% 확실하게 프로세서 수준에서 이러한 코드는 사이클까지 동일한 속도로 실행될 것이라고 생각합니다. 프로세서에는 여전히 최적화, 병렬화 및 xs가 있습니다.
어떤 품질의 코드가 "컴파일러가 이를 최적으로 빗어 낼 것"을 기반으로 작성하면 여기에 부정적인 영향이 있지 않습니까?
한 가지 스타일로 작성하면 컴파일러가 올바른 작업을 수행한다는 것을 확실히 알 수 있습니다. 다른 하나는 컴파일러가 더 똑똑하기를 바랍니다.
크로스 플랫폼, 다른 컴파일러 등을 고려하여 코드에서 수행 중인 작업에 대한 인식을 선택합니다.어떤 품질의 코드가 "컴파일러가 이를 최적으로 빗어 낼 것"을 기반으로 작성하면 여기에 부정적인 영향이 있지 않습니까?
내 예제 - 글쎄, 그것은 거의 품질이 아닙니다. 이것들은 전형적인 구조입니다 - 나는 오랫동안 github에서 소스를 비교 해 왔습니다. tst1은 무엇입니까, tst2 예제는 무엇입니까, 둘 다 프로그래머가 적극적으로 사용합니다
따라서 컴파일러 개발자는 오랫동안 일반적인 코드 구성을 연구했으며 이는 컴파일러에 문제가 되지 않는다고 생각합니다.
부정적인 영향 - 여기에 @TheXpert 가 위에서 쓴 것처럼 코드 설계에 대한 회사 의 요구 사항이 있지만 요구 사항은 일반적으로 동일합니다. 코드는 방금 도착했다 ....
한 가지 스타일로 작성하면 컴파일러가 올바른 작업을 수행한다는 것을 확실히 알 수 있습니다. 다른 하나는 컴파일러가 더 똑똑하기를 바랍니다.
예, 지금 더 똑똑한 것은 컴파일러가 아니지만 프로세서 자체인 IMHO, 여전히 고성능 코드에 대해 이야기하고 있다면 주요 성능 비용은 함수 호출이 아니라 메모리 읽기(메모리 액세스)에 있습니다. 데이터/가변 저장 장치를 계산된 작은 값으로 바꿀 수 있습니다. 그러면 (프로세서 마이크로 명령어의 최적화 수준에서) 작은 이득을 얻을 수 있습니다.
... 그리고 나머지, IMHO, 사악한 것))))
추신 : 컴파일러 수준의 코드 최적화도 있습니다. 거의 읽지 않습니다. 모든 것이 추측 수준에 있습니다. 정기적으로 PC 하드웨어에 대해 읽습니다. 오랫동안 읽었습니다. 제 의견을 썼습니다.
크로스 플랫폼, 다른 컴파일러 등을 고려하여 코드에서 수행 중인 작업에 대한 인식을 선택합니다.
그런 다음 옵션이 없습니다. 간단히 말해서 "나는 예술가입니다. 그렇게 봅니다.")))), 나는 상처받지 않았 으면합니다.
5년 후에는 코드가 인코더에서 이해할 수 있어야 하고, 이해할 수 없다면 나쁜 코드가 되어야 한다는 규칙이 있습니다.
그리고 그것이 다른 사람들에게 분명하다면 아주 좋습니다.
5년 후에는 코드가 인코더에서 이해할 수 있어야 하고, 이해할 수 없다면 나쁜 코드가 되어야 한다는 규칙이 있습니다.
그리고 그것이 다른 사람들에게 분명하다면 아주 좋습니다.
여기 (그리고 여기 )는 아주 좋은 코드입니다. 하지만 나는 그를 이해하지 못한다. 지능은 오래 전에 성장을 멈췄습니다.
여기 (그리고 여기 )는 아주 좋은 코드입니다. 하지만 나는 그를 이해하지 못한다. 지능은 오래 전에 성장을 멈췄습니다.
주제가 복잡합니다. 모든 사람이 이해할 수 있는 것은 아닙니다.) 코드가 마음에 들지 않습니다.
오, 주제가... 그리고 내가 없으면... 무질서... 우리는 목소리를 내야 합니다.
제목의 기사와 관련하여 - 올바른 전제(코드는 가능한 한 결정적이어야 함)가 완전히 어리석은 방식으로 사용되었습니다. 예를 들어 더하기 연산과 누적 연산을 비교한 것입니다. 그리고 덧셈 연산은 결정적이며 항상 하나의 결과를 반환하지만 결과가 항상 다르기 때문에 누적은 그렇지 않다고 결론지었습니다.
하지만... 이것들은 다른 연산이며, 두 경우 모두 결과가 절대적으로 정확하며 각각 더하기와 누적에서 예상되는 결과입니다!
난수 생성기의 예도 난수 구성 요소를 사용한 작업이라고 생각하면 "비결정적"이라고 할 수 없습니다.
내가 보기에 모든 비결정론은 작성자가 코드에서 의도한 것과 완전히 다른 것을 코드에서 기대한다는 사실에 있는 것 같습니다.
음, 두 번째 요점은 코드의 가독성입니다. 나는 작업 "질문"이 매우 해롭고 이해하기 어렵다고 생각합니다. "질문 질문"을 조건 연산자로 대체하면 정확히 동일한 효율성을 가진 실행 코드가 제공됩니다. 동시에 소스 텍스트가 눈에 띄게 더 방대해졌지만 그만큼 더 명확해졌습니다. 큰 장점이라고 생각합니다.
저는 항상 수많은 논리적 표현 을 중간 결과를 가진 여러 개별 작업으로 분해하기 위해 노력합니다. 그러한 코드가 덜 효율적인 실행 코드를 생성하더라도 더 나은 이해를 통한 이득이 훨씬 더 중요하다고 생각합니다.
그리고 여기 트리 지향 프로그래밍의 영역이 있습니다 :-)
그리고 여기 트리 지향 프로그래밍의 영역이 있습니다 :-)
조건에 짧은 표현이 있으면 상당히 합리적입니다. 그러나 기능으로 나눌 수 있습니다.
음, 그런 경우 뒷괄호 안에는 항상 여는 괄호의 제목을 주석으로 넣어 명확하게 합니다.
한 가지 스타일로 작성하면 컴파일러가 올바른 작업을 수행한다는 것을 확실히 알 수 있습니다. 다른 하나는 컴파일러가 더 똑똑하기를 바랍니다.
이 작업을 수행하는 데 차이가 없습니다.
이:
return ( a() || b() );나는 쉽게 읽을 수 있고 디버깅 가능한 코드.
이 작업을 수행하는 데 차이가 없습니다.
이:
나는 쉽게 읽을 수 있고 디버깅 가능한 코드.
나는 이 디자인이 가독성과 어수선함 면에서 전혀 마음에 들지 않는다.