비탈리, 문제는 피터가 기억의 거인이라는 점이다. 그는 자신이 가지고 있는 인덱스, 의미, 연결 및 위치를 잊지 않습니다.
OOP 종소리와 휘파람과 같은 세련된 메모리는 추가 제스처에 불과하며 일부 성능 저하입니다. 왜 그래?
OOP는 일주일 만에 왜 변수가 이 곳에서 변경될 수 있지만 다음 곳에서는 변경되지 않는지 더 이상 기억하지 못하는 사람들을 위한 것입니다. 캡슐화, 공개, 보호 및 비공개 클래스 섹션, 가상 인터페이스, 다형성 ... 그리고 컴퓨터와 같이 메모리에 모든 것이 있을 때 OOP 추가 기능 없이 각 개체에 직접 액세스하는 것이 훨씬 쉽습니다. .
Peter에게 객체를 전달할 때 참조 수를 고려한 스마트 포인터 클래스를 제공하고 아무도 참조하지 않으면 삭제됩니다! Peter는 각 개체가 생성된 시간, 개체의 사용자 수, 개체의 존재 기간 및 삭제 시간을 잘 기억하고 놀랐습니다. 그것들을 사용하는 요점은 무엇입니까?
아니요, 그것도 가능합니다. 질문이 하나 있습니다 - 누구를 위해? Peter는 "이러한 사용자 계층을 만들 것"이라고 주장합니다. 글쎄, 글쎄... 보자.
좋은 기억력은 확실히 좋은 것 같아요 :) 하지만 기억력은 나이가 들수록 악화되거나 선택적으로 변하는 성질이 있습니다. 당신은 무언가를 아주 잘 기억하지만 중요하지 않다고 생각하는 것이 즉시 머리에서 날아갑니다. :)
Peter, 네, 문제의 사실은 거기에 사용할 것이 아무것도 없다는 것입니다. 모든 창은 단지 장식이거나 대화의 지점입니다. 대화의 요점은 이 대화의 필요성을 의미합니다.
여기에서 당신이 상인이고 프로그램이 당신에게 무언가를 묻는다고 상상해보십시오. 그녀는 당신에게서 알아야 합니다. 그녀는 무엇에 대해 질문할 수 있으며 버튼이나 양식으로 이 질문에 답할 수 있습니까? 나는 이 문제에 대한 당신의 의견에 진지하게 관심이 있습니다.
그리고 두 번째 상황: 프로그램 작업에 개입할 필요가 있다고 생각합니다. 이 작업을 효과적으로 수행할 수 있는 버튼/형식은 무엇입니까?
나는 활동의 자동화가 이 활동을 자동화하는 사람들의 작업이라는 것에 전적으로 동의하지만 당신은 이 분야에서 인간-기계 인터페이스를 개발하기 위한 툴킷의 작성자라고 주장합니다. 버튼과 양식의 인터페이스 또는 모든 MT 그래픽 개체에 대한 본격적인 작업을 허용하는 일반 GUI 개체 인터페이스 또는 인터럽트도?
당신은 표준을 만든다고 주장합니다. 나는 무언가를 자동화하고 내가 생성한 그래픽을 사용하는 모든 작업 또는 거의 모든 작업이 인터페이스에서 허용되는 척합니다. 그렇지 않으면 서로가 필요하지 않습니다.
거래는 시간과 돈의 낭비라고 생각합니다. 그러나 다른 사람들이 생각하는 것은 그들의 일입니다. 무슨 상관이야? 프로그램의 작업을 방해하는 것이 필요하다고 믿는 사람들과 필요하지 않다고 믿는 사람들이 항상 있을 것입니다. 왜 이러한 질문으로 머리를 채우십니까? 1차, 2차 프로그램을 만들어 판매하는 것이 좋습니다.
나는 거래가 시간과 돈의 낭비라고 생각합니다. 그러나 다른 사람들이 생각하는 것은 그들의 일입니다. 무슨 상관이야? 프로그램의 작업을 방해하는 것이 필요하다고 믿는 사람들과 필요하지 않다고 믿는 사람들이 항상 있을 것입니다. 왜 이러한 질문으로 머리를 채우십니까? 1차, 2차 프로그램을 만들어 판매하는 것이 좋습니다.
사람들은 이익을 추구합니다. 이 퀘스트에서 그들은 같은 테스터의 성배에 집착하게 되었습니다. 즉, 테스터의 증언을 바탕으로 풍성함을 약속하는 프로그램입니다. 모두. 다음은 막다른 골목입니다.
영원히 지속될 것인가? 그들은 항상 테스터를 신뢰할 것입니까? 그들은 수만 대의 "죽은" 로봇을 보고 결코 실망하지 않을 것입니까?
왜 "죽었다"???
모든 로봇에는 수익 기간이 있습니다. 어느. 내 리그에서 가장 나쁜 TC라도 수입이 짧은 기간이 있습니다. 그래서 - 그들은 "죽은"이라고 부를 수 없습니다.
옷과 같습니다. 물론 반바지, 슬리퍼, 파나마는 아르한겔스크 어느 곳에서도 생활하기에 적합하지 않습니다. 그러나 당신은 그것이 "죽은 옷"이라고 주장하지 않을 것입니다! 게다가 어떤 날에는 아르한겔스크에서도 입을 수 있다.
그리고 그 반대의 경우도 마찬가지입니다. 흑해 연안에서는 여름에 양가죽 코트와 모피 부츠가 바보처럼 보입니다. 그러나 때로는 흑해 연안에서 매우 필요합니다.
로봇도 마찬가지입니다. 각 시장에는 자체 로봇이 있습니다. 그리고 상인의 임무는 현재 시장과 일치하는 로봇을 정확히 선택하는 것입니다. 그렇기 때문에 반바지와 파나마에 실망할 사람이 없고, 양가죽 코트에 실망할 사람이 없듯이 '국민이 실망할 것이다'라고 말할 수는 없다. 더울 때 첫 번째 옷을 입고 추울 때 두 번째 옷을 입어야 합니다.
테스터는 장애가 아니며 만병 통치약도 아닙니다. 그는 최근 시장 상황에 대해 이야기하고 그에 맞는 차량을 선택할 수 있도록 합니다. 그러나 이것이 앞으로 시장이 변하지 않고 차량이 그에 상응하는 것을 중단하지 않을 것이라는 의미는 아닙니다. 그럼에도 불구하고 역사를 새긴 로봇보다는 역사를 통해 이익을 본 로봇이 낫다.
반면에 수동 거래는 방대한 경험이 있어야만 지속적으로 수익을 올릴 수 있습니다. 언제 어떤 기술을 적용해야 하는지 이해하기 위한 것입니다. 많은 사람들이 가지고 있다고 생각합니까?
비탈리, 문제는 피터가 기억의 거인이라는 점이다. 그는 자신이 가지고 있는 인덱스, 의미, 연결 및 위치를 잊지 않습니다.
OOP 종소리와 휘파람과 같은 세련된 메모리는 추가 제스처에 불과하며 일부 성능 저하입니다. 왜 그래?
OOP는 일주일 만에 왜 변수가 이 곳에서 변경될 수 있지만 다음 곳에서는 변경되지 않는지 더 이상 기억하지 못하는 사람들을 위한 것입니다. 캡슐화, 공개, 보호 및 비공개 클래스 섹션, 가상 인터페이스, 다형성 ... 그리고 컴퓨터와 같이 메모리에 모든 것이 있을 때 OOP 추가 기능 없이 각 개체에 직접 액세스하는 것이 훨씬 쉽습니다. .
Peter에게 객체를 전달할 때 참조 수를 고려한 스마트 포인터 클래스를 제공하고 아무도 참조하지 않으면 삭제됩니다! Peter는 각 개체가 생성된 시간, 개체의 사용자 수, 개체의 존재 기간 및 삭제 시간을 잘 기억하고 놀랐습니다. 그것들을 사용하는 요점은 무엇입니까?
아니요, 그것도 가능합니다. 질문이 하나 있습니다 - 누구를 위해? Peter는 "이러한 사용자 계층을 만들 것"이라고 주장합니다. 글쎄, 글쎄... 보자.
좋은 기억력은 확실히 좋은 것 같아요 :) 하지만 기억력은 나이가 들수록 악화되거나 선택적으로 변하는 성질이 있습니다. 당신은 무언가를 아주 잘 기억하지만 중요하지 않다고 생각하는 것이 즉시 머리에서 날아갑니다. :)
묘한 경쟁심을 가지고 계시네요 :)
여기에 관심을 갖고 GUI를 사용하여 이러한 프로그램의 유사체를 만들 수 있습니다.
이 프로그램은 2013년에 두 달 만에 작성되었으며 다른 병렬 프로젝트가 아직 구현 중이었습니다.
2014년에 마지막으로 작성된 프로그램으로 사건사고가 발생할 수 있습니다 :)
교환 상품에서 프로그램을 실행하는 것이 좋습니다.
중재자를 위한 설명: 이 프로그램은 시장에 없습니다.
멋지고 강력한 GUI. 역학의 85%는 생성자를 사용하여 재현할 수 있습니다. 나는 또한 "드래그 앤 드롭", 동적 창을 가지고 있습니다. 나머지는 프로그램의 작업입니다( 함수라고 하는 셀의 깜박이는 숫자).
지침이 있는 창의 경우 - 이것도 재현 가능합니다. 간단히 말해서 내 버전에서는 모양이 약간 다르지만 기능은 거의 동일합니다.
그러나 규모와 숫자는 나를 위해 구현되지 않습니다. 그리고 스케일링이 없습니다.
그러나 이 GUI와 달리 내 그래픽이 더 이쁠 것입니다. 그라디언트, 아이콘, 예쁜 프레임, 그림자... 요소는 모두 손으로 그린 것입니다.
그러나 현대 시장에서 귀사의 제품은 매우 강력합니다. 아마도 가장 강력한 것 중 하나일 것입니다.
그리고 소수의 사람들이 그것을 샀다는 사실 - 테스터 성배에 감사드립니다. 자신을 제외한 모든 제품을 무의미하게 만들었습니다.
그리고 왜 이것이 새로운 스타일입니까?
그들은 30-100 개의 주문에 대해 패널 개발을위한 하나의 주문이 있다고 썼습니다. 더 자주 발생하지 않고 덜 자주 발생합니다.
프리랜서가 되려면 https://www.mql5.com/en/search#!keyword=%D0%BF%D0%B0%D0%BD%D0%B5%D0%BB%D1%8C&module= 를 찾으세요. mql5_module_jobs
그것이 모든 요구 사항이며 거래 패널이 필요하며 아무도 패널의 분석 및 캘린더에 관심이 없습니다.
추신: 찾기 힘든 Joe에 대한 농담을 들었습니까? 당신의 GUI는 훌륭하지만 관심이 있는 사람은 거의 없습니다. 적은 노력으로 dll을 사용하여 어떤 결과도 얻을 수 있고, 사용자가 필요하다고 생각하는 패널을 만들고 시장에서 한 달 안에 통계가 나올 것입니다.. .
추신: 저는 C# .Net을 다루고 싶지 않았지만 개발자들이 지원했기 때문에 양식 디자이너인 SharpDevelop(14Mb)과 Google에서 . dll, 모든 것이 작동하며 문자 그대로 손으로 작성한 코드 자체인 "회전"입니다. 3줄 !!!
MQL 개발자는 C#에서 .dll로 간단한 작업을 수행했고 완성된 dll을 라이브러리 폴더에 던지고 전문가의 첫 번째 줄에 .dll 이름을 썼습니다.
그것은 당신이 이해하고 싶지 않은 것입니다. 무슨 상관이야? 귀하의 버전은 대중을 위한 것이 아닙니다.
사람들은 이익을 추구합니다. 이 퀘스트에서 그들은 같은 테스터의 성배에 집착하게 되었습니다. 즉, 테스터의 증언을 바탕으로 풍성함을 약속하는 프로그램입니다. 모두. 다음은 막다른 골목입니다.
영원히 지속될 것인가? 그들은 항상 테스터를 신뢰할 것입니까? 그들은 수만 대의 "죽은" 로봇을 보고 결코 실망하지 않을 것입니까?
나는 그 난국에서 벗어날 방법을 제안한다. 사용자가 자신의 행동을 책임지는 반자동 프로그램.
아무도 필요하지 않다고 생각하십니까? 당신은 잘못.
Peter, 네, 문제의 사실은 거기에 사용할 것이 아무것도 없다는 것입니다. 모든 창은 단지 장식이거나 대화의 지점입니다. 대화의 요점은 이 대화의 필요성을 의미합니다.
여기에서 당신이 상인이고 프로그램이 당신에게 무언가를 묻는다고 상상해보십시오. 그녀는 당신에게서 알아야 합니다. 그녀는 무엇에 대해 질문할 수 있으며 버튼이나 양식으로 이 질문에 답할 수 있습니까? 나는 이 문제에 대한 당신의 의견에 진지하게 관심이 있습니다.
그리고 두 번째 상황: 프로그램 작업에 개입할 필요가 있다고 생각합니다. 이 작업을 효과적으로 수행할 수 있는 버튼/형식은 무엇입니까?
나는 활동의 자동화가 이 활동을 자동화하는 사람들의 작업이라는 것에 전적으로 동의하지만 당신은 이 분야에서 인간-기계 인터페이스를 개발하기 위한 툴킷의 작성자라고 주장합니다. 버튼과 양식의 인터페이스 또는 모든 MT 그래픽 개체에 대한 본격적인 작업을 허용하는 일반 GUI 개체 인터페이스 또는 인터럽트도?
당신은 표준을 만든다고 주장합니다. 나는 무언가를 자동화하고 내가 생성한 그래픽을 사용하는 모든 작업 또는 거의 모든 작업이 인터페이스에서 허용되는 척합니다. 그렇지 않으면 서로가 필요하지 않습니다.
모든 창에는 몇 가지 가능한 기능이 있을 수 있습니다.
모든 창에는 몇 가지 가능한 기능이 있을 수 있습니다.
이유와 정답이 있습니다!
좋은 기억력은 확실히 좋은 것 같아요 :) 하지만 기억력은 나이가 들수록 악화되거나 선택적으로 변하는 성질이 있습니다. 당신은 무언가를 아주 잘 기억하지만 중요하지 않다고 생각하는 것이 즉시 머리에서 날아갑니다. :)
당신은 그런 기억을 가지고 있습니다(글쎄요, 저도 그렇습니다).
Peter's는 완전히 다르며, 고급 와인처럼 시간이 지날수록 더 좋아집니다. 베드로는 자신이 쓴 모든 것, 어떻게, 왜, 무엇을 동시에 생각했는지 항상 기억합니다. 그래서 그는 정말로 OOP가 필요하지 않습니다.
피터의 기억이 부럽다.
역학의 85%는 생성자를 사용하여 재현할 수 있습니다.
의심의 여지가 있습니다 :) 창, 버튼, 컨트롤 만 있다면 ... 그러나 이것은 최소한의 것입니다.
인터페이스는 DOM 트래픽을 처리할 수도 없으며 여러 지표도 그려야 합니다.
예, 이것은 gui-library의 첫 번째 버전으로, 캔버스를 최소한으로 사용합니다. 이제 텍스트 입력을 제외한 모든 것이 이미 캔버스에 구현되었습니다.
사람들은 이익을 추구합니다. 이 퀘스트에서 그들은 같은 테스터의 성배에 집착하게 되었습니다. 즉, 테스터의 증언을 바탕으로 풍성함을 약속하는 프로그램입니다. 모두. 다음은 막다른 골목입니다.
영원히 지속될 것인가? 그들은 항상 테스터를 신뢰할 것입니까? 그들은 수만 대의 "죽은" 로봇을 보고 결코 실망하지 않을 것입니까?
왜 "죽었다"???
모든 로봇에는 수익 기간이 있습니다. 어느. 내 리그에서 가장 나쁜 TC라도 수입이 짧은 기간이 있습니다. 그래서 - 그들은 "죽은"이라고 부를 수 없습니다.
옷과 같습니다. 물론 반바지, 슬리퍼, 파나마는 아르한겔스크 어느 곳에서도 생활하기에 적합하지 않습니다. 그러나 당신은 그것이 "죽은 옷"이라고 주장하지 않을 것입니다! 게다가 어떤 날에는 아르한겔스크에서도 입을 수 있다.
그리고 그 반대의 경우도 마찬가지입니다. 흑해 연안에서는 여름에 양가죽 코트와 모피 부츠가 바보처럼 보입니다. 그러나 때로는 흑해 연안에서 매우 필요합니다.
로봇도 마찬가지입니다. 각 시장에는 자체 로봇이 있습니다. 그리고 상인의 임무는 현재 시장과 일치하는 로봇을 정확히 선택하는 것입니다. 그렇기 때문에 반바지와 파나마에 실망할 사람이 없고, 양가죽 코트에 실망할 사람이 없듯이 '국민이 실망할 것이다'라고 말할 수는 없다. 더울 때 첫 번째 옷을 입고 추울 때 두 번째 옷을 입어야 합니다.
테스터는 장애가 아니며 만병 통치약도 아닙니다. 그는 최근 시장 상황에 대해 이야기하고 그에 맞는 차량을 선택할 수 있도록 합니다. 그러나 이것이 앞으로 시장이 변하지 않고 차량이 그에 상응하는 것을 중단하지 않을 것이라는 의미는 아닙니다. 그럼에도 불구하고 역사를 새긴 로봇보다는 역사를 통해 이익을 본 로봇이 낫다.
반면에 수동 거래는 방대한 경험이 있어야만 지속적으로 수익을 올릴 수 있습니다. 언제 어떤 기술을 적용해야 하는지 이해하기 위한 것입니다. 많은 사람들이 가지고 있다고 생각합니까?
의심의 여지가 있습니다 :) 창, 버튼, 컨트롤 만 있다면 ... 그러나 이것은 최소한의 것입니다.
인터페이스는 DOM 트래픽을 처리할 수도 없으며 여러 지표도 그려야 합니다.
예, 이것은 gui-library의 첫 번째 버전으로, 캔버스를 최소한으로 사용합니다. 이제 텍스트 입력을 제외한 모든 것이 이미 캔버스에 구현되었습니다.
생성자는 범용 솔루션을 위해 설계되었습니다. 귀하의 프로그램은 특정 작업에 맞게 조정되었습니다.
생성자에서 유리를 만들고 실행할 수 있으며 작동합니다. 그러나 지표를 그리는 것은 아직 생성자의 작업의 일부가 아닙니다.
이것은 사용자가 자신의 프로그램에서 수행할 수 있습니다.
그리고 유리 트래픽이 당기지 않는다는 사실에 대해:
사진을 클릭하시면 gif를 보실 수 있습니다. 위에서 볼 수 있듯이 테이블 요소를 다시 그리는 속도는 DOM 트래픽을 끌어올 만큼 충분히 높습니다(더 많은 셀이 있습니다).
그리고 유리 트래픽이 당기지 않는다는 사실에 대해:
사진을 클릭하시면 gif를 보실 수 있습니다. 위에서 볼 수 있듯이 테이블 요소를 다시 그리는 속도는 DOM 트래픽을 끌어올 만큼 충분히 높습니다(더 많은 셀이 있습니다).
렌더링 속도가 아니라 GUI와 사용자 프로그램 간의 트래픽(교환)에 대해 이야기한 것입니다.
물론 모든 프로그램은 특정 작업에 맞게 조정되지만 예를 들어 표준 라이브러리 의 도움으로 애니메이션 개체를 창에 추가할 수 있지만 GUI에는 추가할 수 없습니다.