alsu : 일반적으로 OOP는 프로그램 코드를 줄이고 데이터 표시가 아닌 프로그램의 논리를 디버깅하는 데 대부분의 시간을 소비하는 방법입니다.
그리고 여기에 데이터 표현에 대한 프로그램의 논리가 있습니까? 이러한 것들은 관련이 없습니다.
프로그램의 논리는 모든 입력 데이터에 대한 산술 연산이며 데이터의 표현은 하나 또는 다른 형식의 데이터일 뿐입니다.
그리고 객체에 대한 외부 포인터가 직접 액세스가 아닌 내부 데이터(함수 및 변수)에 액세스하는 것처럼 보이기 때문에 OOP의 프로그램 코드는 정의에 의해 축소될 수 없습니다. 그러나 포인터를 계산하고 메모리에 액세스하는 것은 매우 느린 작업이므로 그에 따라 성능이 저하됩니다.
3. 나는 악의적 인 차단기이며 모든 전략은 MT4의 무의미하고 유해한 기능을 기반으로합니다. 그러나 MT4에 표시된 시장은 MT5와 전혀 같지 않으며 근본적으로 다른 시장으로, 하나는 돈을 벌 수 있는 시장(MT4)이고 다른 하나는 돈을 벌 수 없는 시장(MT5)이라고 저는 확신합니다.
가정 또는 사실?
C-4 :
...
4. 나는 OOP를 좋아하지도 싫어하지도 않는다. 나는 그를 알지 못하며 믿을 수 없을 정도로 가난하지만 매우 단순한 MQL4가 있는데 왜 사람들이 OOP를 선택하는지 진심으로 이해하지 못합니다. 너무 간단하고 형편없어서 "Hello forex!"와 같은 프로그램을 작성하는 것이 매우 쉽습니다. 이는 자동으로 다중 통화/다중 시간 프레임/다중 시스템 Expert Advisors를 작성하는 것이 무성한 순무보다 쉽다는 것을 의미합니다.
모든 아름다움은 단순함에 있습니다.
C-4 :
...
5. 수년간의 경험에도 불구하고 나는 여전히 이해하지 못합니다 ...
나는 나쁜 시각으로 보지 않기 위해 그러한 진술을 쓰지 않을 것입니다.
일반적으로 귀하의 게시물에서 귀하는 내 방향에 대한 주장이 있는 것 같습니다. 충분한 근거가 있는 개인에서 논의할 것입니다.
MT5에서 우리는 많은 것을 박탈당했습니다. 이러한 박탈은 본질적으로 근본적입니다. MT5에서 우리의 눈은 기능에 가려졌습니다. 그들은 차트에 버튼과 그림을 표시할 수 있는 기회를 주었습니다. 상상의 나래를 펼쳤습니다. 모든 외환 프로그램 은 수학적이어야 하며 계산 및 분석이 가능해야 합니다. MT4와 MT5는 수학 연산 자체가 변경되지 않기 때문에 계산 측면에서 동일합니다. 거래 옵션은 다르지만 개인적으로 프로그래밍 언어와 거래 측면에서 MT4에 만족합니다.
mql4.com이나 5개의 포럼에서 누가 무엇을 알고 누가 무엇을 성취했는지 부를 수 있지만 이것이 작업 해결의 본질입니다.
mql5를 몰라서가 아니라 MQL4에서 문제를 해결하려고 노력하고 있지만 MQL4에 대한 사랑 때문에 MQL4에 대한 마지막 찬사로 간주될 수 있습니다. 이 프로그래밍 언어에는 아직 솔루션이 없기 때문입니다. 모든 함정과 한계를 우회합니다. 나는 그것을 끝내고 큰 소리로 말하고 싶습니다. 4 명이 이것을 할 수 있다면 왜 5에 더 많은 돈을 지불해야합니까?
몇 년 동안 나는 다중 통화 전략 테스터를 구현한다는 아이디어에 주기적으로 괴로워했습니다.
이 아이디어에 대한 포럼 회원들의 생각이 흥미롭습니다. 아마도 이 스레드에서 개발에 사용될 자료가 수집될 것입니다. 당신이 조언하는 것.
여기에서 유용할 수 있습니다.
이 낙서는 다중 통화 거래를 포함한 가상 거래의 라이브러리로 사용할 수 있습니다. 그것은 결코 작동하지 않는 프로젝트 의 일부로 생성되었으며 주석이 풍부하고 코드베이스에서 파악할 수 있습니다. 불완전하기 때문에 게시하지 않았습니다. 창백한 희망의 유령이 보이면 저를 개인적으로 때리면 참여할 수 있습니다.
OOP는 다른 장소에 흩어져 있는 더 많은 코드를 작성하는 동시에 프로세서에 더 많은 부하를 가하는 방법에 불과한 일시적인 홍보 스턴트입니다. :)
이는 거의 동일한 최종 성능으로 소프트웨어 및 하드웨어 리소스의 가격 상승을 촉진합니다. 그러나 물론 그들은 바보가 아니며 OOP에서 프로그램을 작성하지 않습니다. :)
머리로 (음, 음식을 두는 곳) - 다 괜찮습니까?
계속합시다 - 이웃 사냥, 다음은 구조화 프로그래밍에 대한 전문가 (당신입니다)의 의견이라고 생각합니다.
프로그래머가 OOP를 사용할 때 단순함이 무엇인지 이해하기 위해 약간 추가하겠습니다.
- 아주 오래 전인 1995년에 터보 파스칼로 프로그램을 작성했습니다. 모든 것이 정상이지만 지금은 정말 정상적인 인터페이스를 원했습니다. , 그 다음 초기 데이터가 입력되는 창을 그린 다음 결과를 표시할 몇 개의 창이 필요한 것 같으며 그 다음에는 그래픽 모델을 표시해야 하고 텍스트 창을 저장해야 하는 것 같으며, 그런 다음 마우스로 창을 움직여야한다는 것이 밝혀졌습니다. 크기를 줄이거 나 늘리고 싶었고 내가 만들고있는 괴물이 인터페이스 코드의 80 %로 구성되기 시작했음을 보았을 때 , 그리고 나머지 20%는 계산 자체였고 인터페이스는 겨우 Norton Commander에 달렸고, 나는 OOP의 생생한 예에 관심을 갖게 되었습니다. 이것은 Turbo Vision 입니다. 내가 3주 이상 어지럽혀 왔던 프로젝트에 대해 계속해서 작업할 예정이며 프로그래밍 언어에서 OOP를 작성할 수 있게 된다면 OOP용 코드를 확실히 다시 작성하겠습니다 - 죄송합니다. 스레드, 하지만 나는 생각해내지 않았다: "시간은 돈이다" - 진지한 프로젝트의 OOP는 시간을 절약합니다
일반적으로 OOP는 프로그램 코드를 줄이고 데이터 표시가 아닌 프로그램의 논리를 디버깅하는 데 대부분의 시간을 소비하는 방법입니다.
그리고 여기에 데이터 표현에 대한 프로그램의 논리가 있습니까? 이러한 것들은 관련이 없습니다.
프로그램의 논리는 모든 입력 데이터에 대한 산술 연산이며 데이터의 표현은 하나 또는 다른 형식의 데이터일 뿐입니다.
그리고 객체에 대한 외부 포인터가 직접 액세스가 아닌 내부 데이터(함수 및 변수)에 액세스하는 것처럼 보이기 때문에 OOP의 프로그램 코드는 정의에 의해 축소될 수 없습니다. 그러나 포인터를 계산하고 메모리에 액세스하는 것은 매우 느린 작업이므로 그에 따라 성능이 저하됩니다.
...
3. 나는 악의적 인 차단기이며 모든 전략은 MT4의 무의미하고 유해한 기능을 기반으로합니다. 그러나 MT4에 표시된 시장은 MT5와 전혀 같지 않으며 근본적으로 다른 시장으로, 하나는 돈을 벌 수 있는 시장(MT4)이고 다른 하나는 돈을 벌 수 없는 시장(MT5)이라고 저는 확신합니다.
...
4. 나는 OOP를 좋아하지도 싫어하지도 않는다. 나는 그를 알지 못하며 믿을 수 없을 정도로 가난하지만 매우 단순한 MQL4가 있는데 왜 사람들이 OOP를 선택하는지 진심으로 이해하지 못합니다. 너무 간단하고 형편없어서 "Hello forex!"와 같은 프로그램을 작성하는 것이 매우 쉽습니다. 이는 자동으로 다중 통화/다중 시간 프레임/다중 시스템 Expert Advisors를 작성하는 것이 무성한 순무보다 쉽다는 것을 의미합니다.
모든 아름다움은 단순함에 있습니다.
...
5. 수년간의 경험에도 불구하고 나는 여전히 이해하지 못합니다 ...
나는 나쁜 시각으로 보지 않기 위해 그러한 진술을 쓰지 않을 것입니다.
일반적으로 귀하의 게시물에서 귀하는 내 방향에 대한 주장이 있는 것 같습니다. 충분한 근거가 있는 개인에서 논의할 것입니다.
MT5에서 우리는 많은 것을 박탈당했습니다. 이러한 박탈은 본질적으로 근본적입니다. MT5에서 우리의 눈은 기능에 가려졌습니다. 그들은 차트에 버튼과 그림을 표시할 수 있는 기회를 주었습니다. 상상의 나래를 펼쳤습니다. 모든 외환 프로그램 은 수학적이어야 하며 계산 및 분석이 가능해야 합니다. MT4와 MT5는 수학 연산 자체가 변경되지 않기 때문에 계산 측면에서 동일합니다. 거래 옵션은 다르지만 개인적으로 프로그래밍 언어와 거래 측면에서 MT4에 만족합니다.
mql4.com이나 5개의 포럼에서 누가 무엇을 알고 누가 무엇을 성취했는지 부를 수 있지만 이것이 작업 해결의 본질입니다.
mql5를 몰라서가 아니라 MQL4에서 문제를 해결하려고 노력하고 있지만 MQL4에 대한 사랑 때문에 MQL4에 대한 마지막 찬사로 간주될 수 있습니다. 이 프로그래밍 언어에는 아직 솔루션이 없기 때문입니다. 모든 함정과 한계를 우회합니다. 나는 그것을 끝내고 큰 소리로 말하고 싶습니다. 4 명이 이것을 할 수 있다면 왜 5에 더 많은 돈을 지불해야합니까?
몇 년 동안 나는 다중 통화 전략 테스터를 구현한다는 아이디어에 주기적으로 괴로워했습니다.
이 아이디어에 대한 포럼 회원들의 생각이 흥미롭습니다. 아마도 이 스레드에서 개발에 사용될 자료가 수집될 것입니다. 당신이 조언하는 것.
여기에서 유용할 수 있습니다.
이 낙서는 다중 통화 거래를 포함한 가상 거래의 라이브러리로 사용할 수 있습니다. 그것은 결코 작동하지 않는 프로젝트 의 일부로 생성되었으며 주석이 풍부하고 코드베이스에서 파악할 수 있습니다. 불완전하기 때문에 게시하지 않았습니다. 창백한 희망의 유령이 보이면 저를 개인적으로 때리면 참여할 수 있습니다.
여기에서 유용할 수 있습니다.
공부합시다, 감사합니다.
나는 연구 결과에 대해 개인적으로 노크 할 것이며 그러한 문제에 대한 밝은 머리는 아프지 않을 것입니다.
OOP는 다른 장소에 흩어져 있는 더 많은 코드를 작성하는 동시에 프로세서에 더 많은 부하를 가하는 방법에 불과한 일시적인 홍보 스턴트입니다. :)
이는 거의 동일한 최종 성능으로 소프트웨어 및 하드웨어 리소스의 가격 상승을 촉진합니다. 그러나 물론 그들은 바보가 아니며 OOP에서 프로그램을 작성하지 않습니다. :)
머리로 (음, 음식을 두는 곳) - 다 괜찮습니까?
계속합시다 - 이웃 사냥, 다음은 구조화 프로그래밍에 대한 전문가 (당신입니다)의 의견이라고 생각합니다.
프로그래머가 OOP를 사용할 때 단순함이 무엇인지 이해하기 위해 약간 추가하겠습니다.
- 아주 오래 전인 1995년에 터보 파스칼로 프로그램을 작성했습니다. 모든 것이 정상이지만 지금은 정말 정상적인 인터페이스를 원했습니다. , 그 다음 초기 데이터가 입력되는 창을 그린 다음 결과를 표시할 몇 개의 창이 필요한 것 같으며 그 다음에는 그래픽 모델을 표시해야 하고 텍스트 창을 저장해야 하는 것 같으며, 그런 다음 마우스로 창을 움직여야한다는 것이 밝혀졌습니다. 크기를 줄이거 나 늘리고 싶었고 내가 만들고있는 괴물이 인터페이스 코드의 80 %로 구성되기 시작했음을 보았을 때 , 그리고 나머지 20%는 계산 자체였고 인터페이스는 겨우 Norton Commander에 달렸고, 나는 OOP의 생생한 예에 관심을 갖게 되었습니다. 이것은 Turbo Vision 입니다. 내가 3주 이상 어지럽혀 왔던 프로젝트에 대해 계속해서 작업할 예정이며 프로그래밍 언어에서 OOP를 작성할 수 있게 된다면 OOP용 코드를 확실히 다시 작성하겠습니다 - 죄송합니다. 스레드, 하지만 나는 생각해내지 않았다: "시간은 돈이다" - 진지한 프로젝트의 OOP는 시간을 절약합니다
OOP는 프로그래머가 작업하지 않는 복잡한 프로젝트에 필요합니다. 다른 사람의 코드를 이해하는 것은 매우 어렵지만(시간이 지나면 자신의 코드에서도) OOP에서는 모든 것이 통합되고 투명합니다. 작은 문제에 OOP를 적용 하는 것은 비효율적입니다.
작은 문제에 OOP를 적용하는 것은 비효율적입니다.
효율성(속도가 아님)의 관점에서 OOP는 FP보다 열등합니다. 아마도 프로젝트 의 100분의 1 정도일 것입니다.
OOP는 다른 장소에 흩어져 있는 더 많은 코드를 작성하는 동시에 프로세서에 더 많은 부하를 가하는 방법에 불과한 일시적인 홍보 스턴트입니다. :)
이는 거의 동일한 최종 성능으로 소프트웨어 및 하드웨어 리소스의 가격 상승을 촉진합니다. 그러나 물론 그들은 바보가 아니며 OOP에서 프로그램을 작성하지 않습니다. :)
__________________________________________________________
OOP 규칙, 그리고 아마도 이 주제로 충분할 것입니다. 주제가 다릅니다.
효율성(속도가 아님) 면에서 OOP는 FP보다 열등합니다. 아마도 프로젝트의 100% 정도일 것입니다.
경험에 의해 :) 내뿐만 아니라. 거짓말을 조금 했을 수도 있지만 순수한 FP는 지난 세기입니다.