orderSelect가 실패하면 마지막으로 선택한 주문 의 매직 번호 또는 메모리에 남아 있는 것과 일치할 수 있는 항목을 얻을 수 있습니다. 항상 확인하십시오.
항상 카운트 다운해야 합니다. 위치 3에서 작업하는 동안 위치 0이 닫혔다고 가정합니다. 작업하려는 다음 순서는 위치 4였지만 positionIndex를 4로 반복하고 증가시키면 위치 3이 됩니다. 이제 하나를 놓쳤습니다. 카운트다운을 하면 같은 주문을 두 번째로 처리할 수 있지만 놓치는 일은 없습니다.
orderSelect가 실패하면 마지막으로 선택한 주문의 매직 번호 또는 메모리에 남아 있는 것과 일치할 수 있는 항목을 얻을 수 있습니다. 항상 확인하십시오.
항상 카운트다운을 해야 합니다. 위치 3에서 작업하는 동안 위치 0이 닫혔다고 가정합니다. 작업하려는 다음 순서는 위치 4였지만 positionIndex를 4로 반복하고 증가시키면 위치 3이 됩니다. 이제 하나를 놓쳤습니다. 카운트다운을 하면 같은 주문을 두 번째로 처리할 수 있지만 놓치는 일은 없습니다.
1- 누가 그런 말을 했습니까? 그리고 어떤 기억에 대해 이야기하고 있습니까?
2- 나는 카운트 다운 또는 업에 대해 언급하지 않았습니다. 제공된 코드 자체는 카운트다운되지 않습니다.
OrderMagicNumber() 및 기타 항목은 항상 무언가를 반환합니다. OrderSelect()가 실패하면 이전에 성공한 선택에서 남은 임의 의 쓰레기, 아마도 마지막으로 닫힌 주문의 값, 레지스터에 있는 것 등을 얻을 수 있습니다. 삭제된 개체에 대한 포인터를 역참조하려고 시도한 적이 있습니까? 메모리, 그것은 회로 기판의 작은 검은색 칩입니다. 이 시도
int start(){ Print (Whatever()); }
double Whatever(){
for (i= 0 ; i< 10 ; i++) double tmp=Close[i];
// no value returned
}
일부 출력을 게시하십시오.
"제공된 코드 자체가 카운트다운되지 않는다"는 것을 알고 있습니다. 그게 바로 문제 야. 항상 카운트 다운! 감소는 작동하지 않으며 잠재적인 무한 루프입니다.
OrderSelect가 주문을 선택하지 못하면 어떻게 됩니까?
OrderMagicNumber==MagicNo 조건은 절대 참이 아닙니다. 따라서 OrderSelect의 결과를 확인 하고 잘못된 경우 계속할 필요가 없습니다.
루프 변수를 줄이려면 OrderSelect를 확인하는 것이 좋습니다. 예시:
1- 누가 그런 말을 했습니까? 그리고 어떤 기억에 대해 이야기하고 있습니까?
2- 나는 카운트 다운 또는 업에 대해 언급하지 않았습니다. 제공된 코드 자체는 카운트다운되지 않습니다.
코딩한 특별한 이유가 있습니까?
대신에 (?)
일부 코딩 표준에서는 이것이 금지된 것으로 간주된다는 것을 알고 있습니다. 더 나은 성능을 제공합니까 아니면 단지 선호도입니까?
코딩한 특별한 이유가 있습니까?
대신에 (?)
일부 코딩 표준에서는 이것이 금지된 것으로 간주된다는 것을 알고 있습니다. 더 나은 성능을 제공합니까 아니면 단지 선호도입니까?
코딩한 특별한 이유가 있습니까?
대신에 (?)
일부 코딩 표준에서는 이것이 금지된 것으로 간주된다는 것을 알고 있습니다. 더 나은 성능을 제공합니까 아니면 단지 선호도입니까?
루프 내에서 이것은 정확히 동일합니다. 원하는 것을 선택하십시오.
코딩한 특별한 이유가 있습니까?
대신에 (?)
일부 코딩 표준에서는 이것이 금지된 것으로 간주된다는 것을 알고 있습니다. 더 나은 성능을 제공합니까 아니면 단지 선호도입니까?
if(orderselect(......)) 이것을 실행 //---돌아가지 않음
if(!orderselect(.......))continue // 돌아가서 확인
if(orderselect(.......)) 이것을 실행 //---돌아가지 않음
if(!orderselect(.......))continue // 돌아가서 확인