거기에서 1.mqh 의 B()는 인라인이어야 합니다. 모두 함께 - 정상적으로 컴파일되지 않고 개별적으로만 있습니다. 호출의 모호성을 언급한 ServiceDesk는 문제의 본질을 깊이 파고들지 않고 다른 방식으로 프로젝트를 구성할 것을 권장했습니다. 다른 방법은? .mqh에서 .ex5로 B() 구현을 제거하는 경우에만 모든 것이 작동합니다. 그러면 인라인 형식은 무엇입니까?
그건 그렇고, MQL4에서 해당 예제는 오류 없이 작동하지만 B()는 본질적으로 인라인이 아니지만 형식은 인라인입니다.
"같은 매개변수로 오버로드된 함수에 대한 모호한 호출"과 같은 오류를 제거할 수 없었습니다. 별도의 .ex5에 배치된 경우에만 발생하지 않았습니다.
소스 코드 수준에서 근본적으로 인식할 수 없는 재귀가 있습니다. 컴파일러는 여전히 장점에 대해 당신에게 소리쳤습니다. 컴파일하는 것과 동일한 포함이 정의된 포함에 lib를 연결하려고 합니다. 글쎄, 당신이 원하는 것은 무엇입니까? 당신이 컴파일러라면 무엇을 하시겠습니까?
이것은 뉴스가 될 수 있지만 DLL로 작성된 인라인 함수 는 이 DLL 외부 에서 매크로로 사용할 수 없습니다. // 런타임에 소스 코드가 더 이상 존재하지 않습니다.
분명히 당신을 위한 두 번째 뉴스: mql(4, 5)의 모든 라이브러리가 동적으로 연결됩니다. 그것은 사실 DLL입니다.
전체적으로 우리는 다음 중 하나를 시도했습니다.
동의합니다. 모든 것이 이의 없이 컴파일된 다음 lib 실행 중에 메모리가 소진될 때까지 재귀적으로 자체 로드를 시도하면 훨씬 더 나쁠 것입니다.... :))
?
이것이 C/C++에 인라인 키워드가 있는 이유입니다.
그런 이유는 전혀 아닙니다. 링크의 예제는 C++에서 컴파일되지 않을 것이라고 확신합니다.
// 확인하기에는 너무 게으르다. 그것은 단지 비논리적입니다. 재귀적으로 구성된 소스를 작성하는 방법이 명확하지 않으면 컴파일러도 이해하지 못할 것입니다.
거기에서 1.mqh 의 B()는 인라인이어야 합니다. 모두 함께 - 정상적으로 컴파일되지 않고 개별적으로만 있습니다. 호출의 모호성을 언급한 ServiceDesk는 문제의 본질을 깊이 파고들지 않고 다른 방식으로 프로젝트를 구성할 것을 권장했습니다. 다른 방법은?
그는 스스로 이렇게 대답했습니다.
.mqh에서 .ex5로 B() 구현을 제거하는 경우에만 모든 것이 작동합니다. 그러면 인라인 형식은 무엇입니까?
인라인이 정상입니다. 문제는 B()의 타자성이 아니라 재정의에 있다. 둘 중 하나가 DLL이기 때문에 1.mqh를 재컴파일하는 동안 여기에 포함된 포함자(해당 이름)에 대한 정보가 이미 누락되어 있습니다(첫 번째 컴파일은 lib 형성 중에 이루어짐). 따라서 포함자가 컴파일될 때 재정의된 또한 함수 B()가 감지되고 매개변수가 동일하기 때문에 컴파일러는 이를 함수를 다시 로드하려는 잘못된(잘못된) 시도로 간주합니다. 모든 권리가 있습니다. 아주 정중하게, 나는 나쁜 언어를 보낼 수 있었다.
A100 : 맞습니다. C/C++는 이것이 재정의가 아니라는 것을 이해하지만 MQL5는 이해하지 못합니다.
С/С++는 정적 라이브러리를 컴파일할 때만 이것을 이해할 수 있습니다. 소스 이름에 대한 정보는 오브젝트 파일에 저장되기 때문에(정확하게 재컴파일 인식을 위해).
동적으로 연결된 라이브러리에서는 이 번호가 작동하지 않습니다. 그렇다면 재컴파일 인식 때문이 아니라 현재 소스의 이름과 DLL이 일치하는 경우 "우선 순위 규칙"이 있기 때문입니다. 일부 언어에서는 이러한 규칙이 정의됩니다(특히, 델파이에서는 일부 C/C++ 컴파일러에서도 가능합니다).
예, 감사합니다. 소스 코드를 단순화할 때 실수를 했습니다. 이제 다른 방식으로 실수를 다시 작성했습니다.
혼란을 피하기 위해 이전 것을 삭제했습니다.끔찍해 정말 맹세합니다. 얼마나 끔찍한 삶인가...
--
소문, 도대체 당신에게 무엇입니까? 비밀이 아니라면.
당신은 Lisp에서 고문을 작성합니까? 물론 모자를 벗지만 여전히 Haskell로 전환하는 것이 좋습니다.
;-)
소문, 도대체 당신에게 무엇입니까? 비밀이 아니라면.
MQL5에는 인라인 함수(형식별)가 없고 대신 매개변수 매크로를 사용한다는 것입니다.
예, 저도 사용합니다. 그런 끔찍한 둥지가 아닙니다. )))
참고: mql5는 모든 작은 기능을 인라인 대체로 변환합니다. 다시 말해, "inline" 키워드가 기본적으로 모든 사용자 정의 함수에 있다고 가정할 수 있습니다.
매크로를 대체하거나 함수로 컴파일하는 결정은 궁극적으로 컴파일러에 의해 이루어집니다(그런데 C++과 마찬가지로). 따라서 이런 식으로 속도를 높이는 것은 의미가 없습니다. 모든 간단한 기능은 이미 인라인되어 있습니다.
// 그건 그렇고 - 유형 제어로! :)
참고: mql5는 모든 작은 기능을 인라인 대체로 변환합니다. 다시 말해, "inline" 키워드가 기본적으로 모든 사용자 정의 함수에 있다고 가정할 수 있습니다.
https://www.mql5.com/ru/forum/1111/page1013#comment_520221
거기에서 1.mqh 의 B()는 인라인이어야 합니다. 모두 함께 - 정상적으로 컴파일되지 않고 개별적으로만 있습니다. 호출의 모호성을 언급한 ServiceDesk는 문제의 본질을 깊이 파고들지 않고 다른 방식으로 프로젝트를 구성할 것을 권장했습니다. 다른 방법은? .mqh에서 .ex5로 B() 구현을 제거하는 경우에만 모든 것이 작동합니다. 그러면 인라인 형식은 무엇입니까?
그건 그렇고, MQL4에서 해당 예제는 오류 없이 작동하지만 B()는 본질적으로 인라인이 아니지만 형식은 인라인입니다.
그리고 나는 속도를 위한 것이 아니라 편의를 위한 것입니다. 실제로 인라인일 수 있지만 형식(!)이 아닙니다.
그리고 양식을 주셨습니다.
"Studebaker는 누구입니까? 이 사람은 당신의 사촌 Studebaker입니까? 당신의 아버지 Studebaker입니까?" (c) Ostap Ibragimych
.mqh에서 인라인을 정의한 다음 여러 .ex5에서 사용하면 문제가 발생합니다.
합병증이 없습니다. 논리적 오류를 범하지 않고 컴파일러가 어떻게 작동하는지 올바르게 이해한다면. // 특별히는 아니지만 일반적으로. 이해해야 할 일반 원칙.
링크를 찾아봐야겠습니다
https://www.mql5.com/en/forum/1111/page1013#comment_520221
여기서 본질적으로 함수 B() 인라인
"같은 매개변수로 오버로드된 함수에 대한 모호한 호출"과 같은 오류를 제거할 수 없었습니다. 별도의 .ex5에 배치된 경우에만 발생하지 않았습니다.
소스 코드 수준에서 근본적으로 인식할 수 없는 재귀가 있습니다. 컴파일러는 여전히 장점에 대해 당신에게 소리쳤습니다. 컴파일하는 것과 동일한 포함이 정의된 포함에 lib를 연결하려고 합니다. 글쎄, 당신이 원하는 것은 무엇입니까? 당신이 컴파일러라면 무엇을 하시겠습니까?
이것은 뉴스가 될 수 있지만 DLL로 작성된 인라인 함수 는 이 DLL 외부 에서 매크로로 사용할 수 없습니다. // 런타임에 소스 코드가 더 이상 존재하지 않습니다.
분명히 당신을 위한 두 번째 뉴스: mql(4, 5)의 모든 라이브러리가 동적으로 연결됩니다. 그것은 사실 DLL입니다.
전체적으로 우리는 다음 중 하나를 시도했습니다.
동의합니다. 모든 것이 이의 없이 컴파일된 다음 lib 실행 중에 메모리가 소진될 때까지 재귀적으로 자체 로드를 시도하면 훨씬 더 나쁠 것입니다.... :))
?
이것이 C/C++에 인라인 키워드가 있는 이유입니다.
그런 이유는 전혀 아닙니다. 링크의 예제는 C++에서 컴파일되지 않을 것이라고 확신합니다.
// 확인하기에는 너무 게으르다. 그것은 단지 비논리적입니다. 재귀적으로 구성된 소스를 작성하는 방법이 명확하지 않으면 컴파일러도 이해하지 못할 것입니다.
그건 그렇고, MQL4에서 해당 예제는 오류 없이 작동하지만 B()는 본질적으로 인라인이 아니지만 형식은 인라인입니다.
난 믿지 않아. .. 재로딩하는 함수가 없기 때문에 컴파일러는 잘못된 재로딩을 암시하지 않을 수 있습니다. 반복되는 정의를 어리석게 무시합니다.
B() 전에 인라인으로 작성하면 MQL4(!) 및 C/C++ 모두에서 컴파일됩니다.
재귀가 전혀 없습니다. 실제로 있습니다.
int A( int ) 및 #define B() A( 0 )
모든 것이 매우 간단합니다. 게으름이 아니라면 - 새로운 마음을 보세요. 함수의 선언과 구현을 분리하면 됩니다. :)
거기에서 1.mqh 의 B()는 인라인이어야 합니다. 모두 함께 - 정상적으로 컴파일되지 않고 개별적으로만 있습니다. 호출의 모호성을 언급한 ServiceDesk는 문제의 본질을 깊이 파고들지 않고 다른 방식으로 프로젝트를 구성할 것을 권장했습니다. 다른 방법은?
.mqh에서 .ex5로 B() 구현을 제거하는 경우에만 모든 것이 작동합니다. 그러면 인라인 형식은 무엇입니까?
그는 스스로 이렇게 대답했습니다.
인라인이 정상입니다. 문제는 B()의 타자성이 아니라 재정의에 있다.
맞습니다. C/C++는 이것이 반복되는 정의가 아니라는 것을 (inline 키워드를 통해) 이해하지만 MQL5는 컴파일된 모듈의 이름과 #import에 지정된 이름을 구별할 수 있지만 이해하지 못합니다. MQL4가 어떻게 이해하는지 모르겠습니다.
요컨대, .mqh에서 함수의 구현을 정의하고 .ex5에서 문제 없이 사용하는 것은 불가능합니다.
맞습니다. C/C++는 이것이 재정의가 아니라는 것을 이해하지만 MQL5는 이해하지 못합니다.
С/С++는 정적 라이브러리를 컴파일할 때만 이것을 이해할 수 있습니다. 소스 이름에 대한 정보는 오브젝트 파일에 저장되기 때문에(정확하게 재컴파일 인식을 위해).
동적으로 연결된 라이브러리에서는 이 번호가 작동하지 않습니다. 그렇다면 재컴파일 인식 때문이 아니라 현재 소스의 이름과 DLL이 일치하는 경우 "우선 순위 규칙"이 있기 때문입니다. 일부 언어에서는 이러한 규칙이 정의됩니다(특히, 델파이에서는 일부 C/C++ 컴파일러에서도 가능합니다).