이제 지표에 있는 모든 관련 버퍼와 함께 이러한 버퍼의 복사를 자동화하려고 합니다. 어렵습니다. 어렵습니다. 참조 부족, 매개 변수가 있는 생성자(RAII는 실현할 수 없음) 등과 같이 끊임없이 벽을 찌릅니다.
그리고 배달에 오는 비슷한 것은 나에게 어울리지 않습니다. 조금도.
솔직히 말해서 나도 똑같이 시도했다. 특별한 것은 없으므로 애지중지합니다. Threw, 급습으로 nifiga는 가치있는 일을 해결하지 못했습니다. 많이 다시 배워야 하거나 OOP를 확장해야 합니다. 어느 쪽도 아직 오지 않았습니다. 일반적으로 나는 갈퀴를 겪었고 내가 그렇게 바보인지 또는 기술 지원에 티켓을 보내야하는지 이해하지 못했습니다. 지금은 모든 점수를 매겼습니다.
몇 가지 요약 매우 예비적인 결과로, 메타 인용구 구현의 OOP는 숙련된 프로그래머라도 허용되지 않는다고 말할 수 있습니다. 구현 때문일 수 있습니다. 아마도 익숙해져야 하고 OOP를 사용하면 더 편리할 것입니다. 그러나 현재로서는 그것이 있습니다. 없는게 더 나은듯. 저것들. 뭔가를 작성하는 것이 가능할 수도 있지만 OOP를 위해서만 가능하고 실용성, 작성 속도가 아니라 코드 자체의 속도에 대해 말하는 것이 아닙니다. 어떤 경우에도 PP에 대해 더 느릴 것입니다.
그러나 OOP에 대한 수요가 정말 그렇게 중요합니까(누가 이 약어의 의미를 이해하는지)? 저에게 있어 트레이더와 프로그래머의 작업을 용이하게 해줄 새로운 트레이딩 및 서비스 기능이 무엇인지, 그리고 얼마나 잘/완전히 구현되는지가 훨씬 더 중요합니다.
자, 이제 지표가 있는 객체를 생성할 수 없는 예(아마도 이미 아팠을 것입니다)를 살펴보겠습니다. 최소한 12개의 MQL5 OOP 표준 준수 인증서를 보여줄 수 있지만 표시기로 개체를 생성 하지 않으면 OOP가 화면에 가장 간단한 텍스트를 표시하는 정교함에서 벗어날 수 없습니다. 또는 다른 예: 차트의 차트 개체, 이 차트 개체에 평범한 눈금도 삽입할 수 없는 경우 OOP를 사용하는 데 자부심이 무슨 소용이 있습니까? 확인란으로 작동하는 버튼과 표준 콤보 상자가 없기 때문에 예를 들어 Expert Advisor에서 계산을 위한 시간 프레임을 선택하고 여러 개체를 하나로 그룹화할 수 있습니다. 플랫폼이 자동 거래를 위해 조정되는 방식 때문에 대화 상자 양식 편집기에 대해 조용합니다... :(
IMHO: MQL5에는 기존 OOP에 내재된 기능의 (강력하게) 잘린 하위 집합만 있습니다. 개발자들은 엄청난 양의 작업을 수행했으며 물론 소스 코드 작성을 크게 고상하고 단순화하지만 이것들은 모두 "체커"이지만 여전히 택시를 원하고 개발자가 MQL6을 곧 시작하지 않기를 바랍니다. 그러나 "정확히 5"조건을 계속 가져올 것입니다.)
간절한 마음으로 여전히 인터프리터인 BASIC에서도 OOP를 찾을 수 있습니다. 응.
지표, Expert Advisors 및 스크립트에서 OOP가 어떻게 수요가 있을지 기다려야 한다고 생각합니다. 그리고 사실, 그것이 실제로 어떻게 되는지를 이미 결정하십시오.
HideYourRichess писал(а) >>
지표, Expert Advisors 및 스크립트에서 OOP가 어떻게 수요가 있을지 기다려야 한다고 생각합니다. 그리고 실제로 그것이 실제로 어떤지 이미 결정했습니다.
이제 지표에 있는 모든 관련 버퍼와 함께 이러한 버퍼의 복사를 자동화하려고 합니다. 어렵습니다. 어렵습니다. 참조 부족, 매개 변수가 있는 생성자(RAII는 실현할 수 없음) 등과 같이 끊임없이 벽을 찌릅니다.
그리고 배달에 오는 비슷한 것은 나에게 어울리지 않습니다. 조금도.
C-4 작성 >>
Z.Y. 대부분의 사람들은 OOP를 특정 C++ 프로그래밍 언어와 연관시킵니다.
그리고 정말 제대로 구현되지 않았습니까? IMHO, 그 자체로도. 다른 일반적인 객체 지향 언어와 마찬가지로.
, MQ5는 OOP,
기회의 측면에서 여기에서만 가난한
OOP는 C에도 존재하지만 어떤 이유로 많은 사람들이 그것에 대해 알지 못합니다. 이는 다시 피상적인 지식을 말합니다.
그러나 이제부터 더 자세히.
이제 지표에 있는 모든 관련 버퍼와 함께 이러한 버퍼의 복사를 자동화하려고 합니다. 어렵습니다. 어렵습니다. 참조 부족, 매개 변수가 있는 생성자(RAII는 실현할 수 없음) 등과 같이 끊임없이 벽을 찌릅니다.
그리고 배달에 오는 비슷한 것은 나에게 어울리지 않습니다. 조금도.
솔직히 말해서 나도 똑같이 시도했다. 특별한 것은 없으므로 애지중지합니다. Threw, 급습으로 nifiga는 가치있는 일을 해결하지 못했습니다. 많이 다시 배워야 하거나 OOP를 확장해야 합니다. 어느 쪽도 아직 오지 않았습니다. 일반적으로 나는 갈퀴를 겪었고 내가 그렇게 바보인지 또는 기술 지원에 티켓을 보내야하는지 이해하지 못했습니다. 지금은 모든 점수를 매겼습니다.
자세히 설명해 주세요:
캡슐화:
struct mail
{
int zipcode;
char adr[50];
char comment[10];
...
}
정적 다형성:
double d=3.12, c;
int i=5;
c= d+i ;
동적 다형성:
void qsort(void *buf, size_t st, size_t s, int (*compare) (const void *, const void *));
계승:
동적 다형성과 같은 예에서 이 경우 qsort 함수는 그대로 compare() 함수 의 속성을 획득합니다.
자세히 설명해 주시겠습니까?
이런 식으로 볼 것으로 예상됩니다. 정적 다형성만 계산됩니다. 나는 이 주제(C의 OOP)에 대한 토론을 계속하는 데 요점이 없다고 생각하며 그렇게 하지 않을 것입니다.
정말 놀라실 거라고 생각했어요.
몇 가지 요약 매우 예비적인 결과로, 메타 인용구 구현의 OOP는 숙련된 프로그래머라도 허용되지 않는다고 말할 수 있습니다. 구현 때문일 수 있습니다. 아마도 익숙해져야 하고 OOP를 사용하면 더 편리할 것입니다. 그러나 현재로서는 그것이 있습니다. 없는게 더 나은듯. 저것들. 뭔가를 작성하는 것이 가능할 수도 있지만 OOP를 위해서만 가능하고 실용성, 작성 속도가 아니라 코드 자체의 속도에 대해 말하는 것이 아닙니다. 어떤 경우에도 PP에 대해 더 느릴 것입니다.
그래서 간다...
그러나 OOP에 대한 수요가 정말 그렇게 중요합니까(누가 이 약어의 의미를 이해하는지)? 저에게 있어 트레이더와 프로그래머의 작업을 용이하게 해줄 새로운 트레이딩 및 서비스 기능이 무엇인지, 그리고 얼마나 잘/완전히 구현되는지가 훨씬 더 중요합니다.
자, 이제 지표가 있는 객체를 생성할 수 없는 예(아마도 이미 아팠을 것입니다)를 살펴보겠습니다. 최소한 12개의 MQL5 OOP 표준 준수 인증서를 보여줄 수 있지만 표시기로 개체를 생성 하지 않으면 OOP가 화면에 가장 간단한 텍스트를 표시하는 정교함에서 벗어날 수 없습니다. 또는 다른 예: 차트의 차트 개체, 이 차트 개체에 평범한 눈금도 삽입할 수 없는 경우 OOP를 사용하는 데 자부심이 무슨 소용이 있습니까? 확인란으로 작동하는 버튼과 표준 콤보 상자가 없기 때문에 예를 들어 Expert Advisor에서 계산을 위한 시간 프레임을 선택하고 여러 개체를 하나로 그룹화할 수 있습니다. 플랫폼이 자동 거래를 위해 조정되는 방식 때문에 대화 상자 양식 편집기에 대해 조용합니다... :(
IMHO: MQL5에는 기존 OOP에 내재된 기능의 (강력하게) 잘린 하위 집합만 있습니다. 개발자들은 엄청난 양의 작업을 수행했으며 물론 소스 코드 작성을 크게 고상하고 단순화하지만 이것들은 모두 "체커"이지만 여전히 택시를 원하고 개발자가 MQL6을 곧 시작하지 않기를 바랍니다. 그러나 "정확히 5"조건을 계속 가져올 것입니다.)
그러나 OOP에 대한 수요가 정말 그렇게 중요합니까(누가 이 약어의 의미를 이해하는지)? 저에게 있어 트레이더와 프로그래머의 작업을 용이하게 해줄 새로운 트레이딩 및 서비스 기능이 무엇인지, 그리고 얼마나 잘/완전히 구현되는지가 훨씬 더 중요합니다.
그렇지. 그리고 관련 부서에서 이것에 대해 많은 이야기를 했습니다. 예를 들어, MK는 오래된 문제를 처리하는 대신 혁신으로 솔루션을 복잡하게 만든 것 같습니다.
나는 지금 OOP에 대해 말하는 것이 아니다. 그러나 이 기회에 소비된 에너지는 정말 유용하고 수요가 많은 무언가에 사용될 수 있습니다.
그렇지. 그리고 관련 부서에서 이것에 대해 많은 이야기를 했습니다. 예를 들어, MK는 오래된 문제를 처리하는 대신 혁신으로 솔루션을 복잡하게 만든 것 같습니다.
나는 지금 OOP에 대해 말하는 것이 아니다. 그러나 이 기회에 소비된 에너지는 정말 유용하고 수요가 많은 무언가에 사용될 수 있습니다.
문제는 일반적으로 쉬운 문제가 아닙니다. 실제로. 우리는 서버에서 변경 사항을 볼 수 없습니다. 인터넷의 단편적인 정보에 따르면 그곳은 이전보다 더 시원한 것 같습니다. 물론 이것은 DC의 경우가 아니지만 일반적으로 서비스가 향상될 수 있습니다.