1) 강조 표시됩니다. 다음 줄만 확인))) 예에서 작성자는 둘 중 하나를 정반대로 먼저 확인하고 캐스팅) 2) 후임자가 JSONObject 에 나타나면 왜 넘어야 합니까?
1) 사실, 이 주제의 프레임워크 내에서 동일한 코드가 며칠 동안 논의되었습니다: here , here , here . 사용자가 라이브러리를 사용하는 예 중 하나에서 문제를 발견했다는 사실 - 잘했습니다. 감사합니다. 그런데 라이브러리를 통째로 사용하는 논리에 문제가 있다고 말씀하셨는데, 실제로는 특정 예와 관련된 문제임이 밝혀졌습니다.
2) 무엇인가가 떨어져야 한다는 진술을 어디서 보았습니까? 아니요, 훨씬 더 나쁠 수 있습니다. 코드는 제대로 작동하지만 잘못된 결과를 생성합니다.
물론 IMHO이지만 라이브러리에 있는 경우 기본 클래스에 대한 포인터로 개체에 액세스할 때 정의되지 않은 동작이 발생하면 이는 라이브러리 설명서에 반영되어야 하지만(있나요?) 그렇게 하지마)
다시 스물 다섯, 포인터와 비포인터, 매뉴얼 등과 무슨 관계가 있습니까? ? 귀하의 예에서 논리의 일부, 즉 jv.isObject() 검사가 함수에서 제외됩니다. 이 논리는 dynamic_cast를 통한 검사로 대체되었습니다. 현재 버전의 라이브러리에서는 모든 것이 정상이지만 이론적으로 JSONObject 를 기본 클래스로 사용하는 다음 버전에 새 클래스가 나타나면 예제가 올바르게 작동할 수 있다는 사실이 아닙니다. .
다시 스물 다섯, 포인터와 비포인터, 매뉴얼 등과 무슨 관계가 있습니까? ? 귀하의 예에서 LOGIC의 일부는 함수, 즉 jv.isObject() 검사에서 제외됩니다. 이 논리는 dynamic_cast를 통해 확인하여 대체되었습니다. 현재 버전의 라이브러리에서는 모든 것이 정상이지만 이론적으로 JSONObject 를 기본 클래스로 사용하는 다음 버전에 새 클래스가 나타나면 예제가 올바르게 작동할 수 있다는 사실이 아닙니다. .
동의합니다)) 이것은 플러스에 대한 저입니다)))
여기에 쓰는 동안 모든 것이 어떻게 전개되었는지
저것들. 긍정적이지는 않지만 mucl에서는 이전 옵션이 올바르게 작동합니까?
여기에 쓰는 동안 모든 것이 어떻게 전개되었는지
저것들. 긍정적이지는 않지만 mucl에서는 이전 옵션이 올바르게 작동합니까?
이 옵션은 예
암시적 dynamic_casts가 두 개뿐입니다.1) 강조 표시됩니다. 다음 줄만 확인))) 예에서 작성자는 둘 중 하나를 정반대로 먼저 확인하고 캐스팅)
2) 후임자가 JSONObject 에 나타나면 왜 넘어야 합니까?
1) 사실, 이 주제의 프레임워크 내에서 동일한 코드가 며칠 동안 논의되었습니다: here , here , here .
사용자가 라이브러리를 사용하는 예 중 하나에서 문제를 발견했다는 사실 - 잘했습니다. 감사합니다.
그런데 라이브러리를 통째로 사용하는 논리에 문제가 있다고 말씀하셨는데, 실제로는 특정 예와 관련된 문제임이 밝혀졌습니다.
2) 무엇인가가 떨어져야 한다는 진술을 어디서 보았습니까?
아니요, 훨씬 더 나쁠 수 있습니다. 코드는 제대로 작동하지만 잘못된 결과를 생성합니다.
2) 무엇인가가 떨어져야 한다는 진술을 어디서 보았습니까?
아니요, 훨씬 더 나쁠 수 있습니다. 코드는 제대로 작동하지만 잘못된 결과를 생성합니다.
물론 IMHO이지만 라이브러리에 있는 경우 기본 클래스에 대한 포인터로 개체에 액세스할 때 정의되지 않은 동작이 발생하면 이는 라이브러리 설명서에 반영되어야 하지만(있나요?) 그렇게 하지마)
아니요, 훨씬 더 나쁠 수 있습니다. 코드는 제대로 작동하지만 잘못된 결과를 생성합니다.
내 예는 기본 클래스의 메서드이고 JSONObject *는 실행 결과이고 이것은 파서에 대한 포인터이며 상속자 메서드의 json 구문 분석은 수신된 포인터와 함께 발생합니다. 앞서 언급한 내 질문
꽤 많은 검사가 있습니다. 제안된 예제에는 3개의 pcs가 있고 파생 클래스 에서 getInt()에 대한 각 호출은 검사와 함께 getDouble() 메서드가 발생합니다.
물론 IMHO이지만 라이브러리에 있는 경우 기본 클래스에 대한 포인터로 개체에 액세스할 때 정의되지 않은 동작이 발생하면 이는 라이브러리 설명서에 반영되어야 하지만(있나요?) 그렇게 하지마)
다시 스물 다섯, 포인터와 비포인터, 매뉴얼 등과 무슨 관계가 있습니까? ?
귀하의 예에서 논리의 일부, 즉 jv.isObject() 검사가 함수에서 제외됩니다.
이 논리는 dynamic_cast를 통한 검사로 대체되었습니다.
현재 버전의 라이브러리에서는 모든 것이 정상이지만 이론적으로 JSONObject 를 기본 클래스로 사용하는 다음 버전에 새 클래스가 나타나면 예제가 올바르게 작동할 수 있다는 사실이 아닙니다. .
다시 스물 다섯, 포인터와 비포인터, 매뉴얼 등과 무슨 관계가 있습니까? ?
귀하의 예에서 LOGIC의 일부는 함수, 즉 jv.isObject() 검사에서 제외됩니다.
이 논리는 dynamic_cast를 통해 확인하여 대체되었습니다.
현재 버전의 라이브러리에서는 모든 것이 정상이지만 이론적으로 JSONObject 를 기본 클래스로 사용하는 다음 버전에 새 클래스가 나타나면 예제가 올바르게 작동할 수 있다는 사실이 아닙니다. .
따라서 다른 옵션도 사용할 수 없습니다)
UB가 없으며 mql 캐스트 에는 dynamic_cast도 포함되어 있습니다. 잘못된 포인터의 경우 모든 것이 떨어질 것입니다.
그렇습니까? dynamic_cast의 경우 결과를 NULL로 확인하면 아무 것도 떨어지지 않습니다. 일반 캐스트로 즉시 떨어집니다. 아니면 내가 그것을 이해하지 못했습니까?
물론 IMHO이지만 라이브러리에 있는 경우 기본 클래스에 대한 포인터로 개체에 액세스할 때 정의되지 않은 동작이 발생하면 이는 라이브러리 설명서에 반영되어야 하지만(있나요?) 그렇게 하지마)
그리고 당연히 그렇습니다))) 베이스에서 후계자로 직접 캐스팅할 수 없습니다. 이것은 UB( UNDEFINED BEHAVIOR )입니다.
플러스 측면에서는 일반적으로 우리에게 친숙하고 편리한 표준 캐스트 연산자를 통해 링크(위 또는 아래)를 캐스팅하는 것이 위험합니다.