작은 소프트웨어에서 이 최신 과시 없이는 가능합니다. 그러나 적어도 Windows와 관련하여 ' 인터페이스 라이브러리 '와 같은 부드럽고 부드러운 기능 없이는 할 수 없습니다. 일반적으로 MT 개발자가 무덤에 대한 흔들리지 않는 충성심으로 작고 부드러운 사람들에게 맹세하고 다른 모든 것에주의를 기울이지 않는 것은 유감입니다. 나는 이미 Vine을 통해 Linux에서 완전히 죄가 없는 MT5를 작동시키는 것이 치질이 될 것이라고 직감합니다. 걱정 마세요. 엄마.
Invini, 심지어 오래된 Java에도 클래스 패키지에 대한 네임스페이스의 유사점이 있습니다. 자, 자바는 MS가 아닙니다. 원한다면 가상을 통한 *nix의 MT5 또는 Mono의 MQL7이든 상관없이 모든 것을 가져올 수 있습니다.
일반적으로 nen은 바로 여기에 있으며 우선 순위는 경쟁자보다 더 강력한 작업 플랫폼입니다. 그러나 이것으로 무엇을 이해하는가는 또 다른 질문입니다.
Invini, 심지어 오래된 Java에도 클래스 패키지에 대한 네임스페이스의 유사점이 있습니다. 자, 자바는 MS가 아닙니다. 원한다면 가상을 통한 *nix의 MT5 또는 Mono의 MQL7이든 상관없이 모든 것을 가져올 수 있습니다.
일반적으로 nen은 바로 여기에 있으며 우선 순위는 경쟁자보다 더 강력한 작업 플랫폼입니다. 그러나 이것으로 무엇을 이해하는가는 또 다른 질문입니다.
예, Haskell로 파이썬을 기억할 수도 있습니다. 나는 다른 것을 의미했습니다. 언어의 의미는 커틀릿이고 특정 OS에 대한 구현은 파리입니다. 동일한 Java, Python, Haskell 등은 Linux에서는 훌륭하게 작동하고 Windows에서는 매우 비뚤어지게 작동합니다. 커틀릿에서 파리를 분리하면 Windows에서 개체에 대한 지원이 추악하다고 말할 수 있습니다. 이는 실제로 놀라운 일이 아니기 때문입니다. Windows는 처음에 예를 들어 Unix와는 완전히 다른 패러다임을 가지고 있었습니다(특히 92-93에서 PC 사용자에서 Windows의 위치와 역할에 대한 BG의 설명과 같이 역사를 회상하면 충분합니다). Winda는 도스에서 자랐고 2000년이 되어서야 그에게서 멀어질 수 있었습니다. 유닉스에서는 객체가 거의 기초부터 존재했기 때문에 객체 모델이 시스템과 병행하여 개발되었으며 Windows와 같이 구부러진 손으로 강제로 도입되지 않았습니다. 사실, Raymond Chen의 팀이 Windows 자체 및 응용 프로그램에 대해 작업하는 동안 여전히 앞뒤가 맞지 않았지만 2001년 Chen이 떠났고 획일적인 무법이 시작되었습니다. 물론 결국 우리는 Linux에서 MT5를 출시할 것입니다. 암이 아니라면 큰 치질을 가진 랍스터일 뿐이며 더 큰 이점으로 사용될 수 있는 많은 노력과 시간이 필요할 것입니다. 그리고 nen은 물론 옳고 일반적으로 마스터는 마스터입니다.
커틀릿에서 파리를 분리하면 Windows에서 개체에 대한 지원이 추악하다고 말할 수 있습니다. 이는 실제로 놀라운 일이 아니기 때문입니다. Windows는 처음에 예를 들어 Unix와는 완전히 다른 패러다임을 가지고 있었습니다(특히 92-93에서 PC 사용자에서 Windows의 위치와 역할에 대한 BG의 설명과 같이 역사를 회상하면 충분합니다). Winda는 도스에서 자랐고 2000년이 되어서야 그에게서 멀어질 수 있었습니다. 유닉스에서는 객체가 거의 기초부터 존재했기 때문에 객체 모델이 시스템과 병행하여 개발되었으며 Windows와 같이 구부러진 손으로 강제로 도입되지 않았습니다. 사실, Raymond Chen의 팀이 Windows 자체 및 응용 프로그램에 대해 작업하는 동안 여전히 앞뒤가 맞지 않았지만 2001년 Chen이 떠났고 획일적인 무법이 시작되었습니다.
글쎄요, 프로그래밍 언어 개체에 대해 이야기하고 있다면 *nix와 Windows는 모두 C/C ++를 기반으로 하며 모든 결과를 낳습니다. 추가 기능(커널, 그래픽, 그놈 등)이 있는 Linux 아키텍처에 대해 이야기하고 있다면 예, Windows가 따라잡는 역할을 합니다. 그러나 Windows에서 개체의 곡률에 관해서는 그다지 동의하지 않습니다. .net 프레임워크, IMHO를 사용하면 정상적으로 설계되어야 합니다(물론 구현이 기존 현실에 압축되어 있지만). 사람/프로그래머, C++/델파이/자바 경험을 고려하지 않고
DRM의 경우 이것은 정치입니다. 내가 MS 신발을 입은 모습을 상상하고 운영 체제 시장에 대한 그들의 범위를 평가했다면 아마 같은 방식으로 행동했을 것입니다. Linux에서는 (아직) 그러한 압력이 없었습니다.
그러나 MQL5의 OOP에 대한 요구에 의해 나는(아마도 순진한 생각에서?) 장난감을 쓰는 것을 의미하지 않았습니다. 그리고 코드베이스에 이미 게시된 프로그램은 OOP를 사용하지 않습니다. 일반적으로 그 유용성에 대해, 특히 MT의 목적을 위해 완전한 감각 장애인만이 그것을 인식하지 못하지만 개발자는 이 사실을 강조했고 대중(포럼에서 판단)은 목이 말랐습니다.
작은 소프트웨어에서 이 최신 과시 없이는 가능합니다. 그러나 적어도 Windows와 관련하여 ' 인터페이스 라이브러리 '와 같은 부드럽고 부드러운 기능 없이는 할 수 없습니다. 일반적으로 MT 개발자가 무덤에 대한 흔들리지 않는 충성심으로 작고 부드러운 사람들에게 맹세하고 다른 모든 것에주의를 기울이지 않는 것은 유감입니다. 나는 이미 Vine을 통해 Linux에서 완전히 죄가 없는 MT5를 작동시키는 것이 치질이 될 것이라고 직감합니다. 걱정 마세요. 엄마.
Invini, 심지어 오래된 Java에도 클래스 패키지에 대한 네임스페이스의 유사점이 있습니다. 자, 자바는 MS가 아닙니다. 원한다면 가상을 통한 *nix의 MT5 또는 Mono의 MQL7이든 상관없이 모든 것을 가져올 수 있습니다.
일반적으로 nen은 바로 여기에 있으며 우선 순위는 경쟁자보다 더 강력한 작업 플랫폼입니다. 그러나 이것으로 무엇을 이해하는가는 또 다른 질문입니다.
Invini, 심지어 오래된 Java에도 클래스 패키지에 대한 네임스페이스의 유사점이 있습니다. 자, 자바는 MS가 아닙니다. 원한다면 가상을 통한 *nix의 MT5 또는 Mono의 MQL7이든 상관없이 모든 것을 가져올 수 있습니다.
일반적으로 nen은 바로 여기에 있으며 우선 순위는 경쟁자보다 더 강력한 작업 플랫폼입니다. 그러나 이것으로 무엇을 이해하는가는 또 다른 질문입니다.
예, Haskell로 파이썬을 기억할 수도 있습니다. 나는 다른 것을 의미했습니다. 언어의 의미는 커틀릿이고 특정 OS에 대한 구현은 파리입니다. 동일한 Java, Python, Haskell 등은 Linux에서는 훌륭하게 작동하고 Windows에서는 매우 비뚤어지게 작동합니다. 커틀릿에서 파리를 분리하면 Windows에서 개체에 대한 지원이 추악하다고 말할 수 있습니다. 이는 실제로 놀라운 일이 아니기 때문입니다. Windows는 처음에 예를 들어 Unix와는 완전히 다른 패러다임을 가지고 있었습니다(특히 92-93에서 PC 사용자에서 Windows의 위치와 역할에 대한 BG의 설명과 같이 역사를 회상하면 충분합니다). Winda는 도스에서 자랐고 2000년이 되어서야 그에게서 멀어질 수 있었습니다. 유닉스에서는 객체가 거의 기초부터 존재했기 때문에 객체 모델이 시스템과 병행하여 개발되었으며 Windows와 같이 구부러진 손으로 강제로 도입되지 않았습니다. 사실, Raymond Chen의 팀이 Windows 자체 및 응용 프로그램에 대해 작업하는 동안 여전히 앞뒤가 맞지 않았지만 2001년 Chen이 떠났고 획일적인 무법이 시작되었습니다. 물론 결국 우리는 Linux에서 MT5를 출시할 것입니다. 암이 아니라면 큰 치질을 가진 랍스터일 뿐이며 더 큰 이점으로 사용될 수 있는 많은 노력과 시간이 필요할 것입니다. 그리고 nen은 물론 옳고 일반적으로 마스터는 마스터입니다.
커틀릿에서 파리를 분리하면 Windows에서 개체에 대한 지원이 추악하다고 말할 수 있습니다. 이는 실제로 놀라운 일이 아니기 때문입니다. Windows는 처음에 예를 들어 Unix와는 완전히 다른 패러다임을 가지고 있었습니다(특히 92-93에서 PC 사용자에서 Windows의 위치와 역할에 대한 BG의 설명과 같이 역사를 회상하면 충분합니다). Winda는 도스에서 자랐고 2000년이 되어서야 그에게서 멀어질 수 있었습니다. 유닉스에서는 객체가 거의 기초부터 존재했기 때문에 객체 모델이 시스템과 병행하여 개발되었으며 Windows와 같이 구부러진 손으로 강제로 도입되지 않았습니다. 사실, Raymond Chen의 팀이 Windows 자체 및 응용 프로그램에 대해 작업하는 동안 여전히 앞뒤가 맞지 않았지만 2001년 Chen이 떠났고 획일적인 무법이 시작되었습니다.
글쎄요, 프로그래밍 언어 개체에 대해 이야기하고 있다면 *nix와 Windows는 모두 C/C ++를 기반으로 하며 모든 결과를 낳습니다. 추가 기능(커널, 그래픽, 그놈 등)이 있는 Linux 아키텍처에 대해 이야기하고 있다면 예, Windows가 따라잡는 역할을 합니다. 그러나 Windows에서 개체의 곡률에 관해서는 그다지 동의하지 않습니다. .net 프레임워크, IMHO를 사용하면 정상적으로 설계되어야 합니다(물론 구현이 기존 현실에 압축되어 있지만). 사람/프로그래머, C++/델파이/자바 경험을 고려하지 않고
DRM의 경우 이것은 정치입니다. 내가 MS 신발을 입은 모습을 상상하고 운영 체제 시장에 대한 그들의 범위를 평가했다면 아마 같은 방식으로 행동했을 것입니다. Linux에서는 (아직) 그러한 압력이 없었습니다.
그래서 MQL5의 첫 번째 프로그램이 나타났습니다.
절차적.
어디, 누가 재미를 위해 또는 시도하거나 자신의 발전과 깨달음을 보여주기 위해 OOP를 사용 했습니까?
그런 프로그램의 예를 보고 싶습니다. 제발.
그래서 MQL5의 첫 번째 프로그램이 나타났습니다.
절차적.
어디, 누가 관심을 위해 또는 단지 시도하거나 자신의 발전과 계몽을 보여주기 위해 OOP를 사용 했습니까?
그런 프로그램의 예를 보고 싶습니다. 제발.
테트리스?
그렇지.
그러나 MQL5의 OOP에 대한 요구에 의해 나는(아마도 순진한 생각에서?) 장난감을 쓰는 것을 의미하지 않았습니다. 그리고 코드베이스에 이미 게시된 프로그램은 OOP를 사용하지 않습니다. 일반적으로 그 유용성에 대해, 특히 MT의 목적을 위해 완전한 감각 장애인만이 그것을 인식하지 못하지만 개발자는 이 사실을 강조했고 대중(포럼에서 판단)은 목이 말랐습니다.
그래서 어디?
Svinozavr писал(а) >>
그래서 어디?
나는 직위와 오더 매니저를 쓸 계획이다. 그러나 거래 기능에 대한 문서가 공개되기 전에 시작할 이유가 없습니다.
나는 또한 객체에 대한 래퍼를 작성할 계획이지만 이것은 조금 나중입니다.
나는 직위와 오더 매니저를 쓸 계획이다. 그러나 거래 기능에 대한 문서가 공개되기 전에 시작할 이유가 없습니다.
나는 또한 객체 주위에 래퍼를 작성할 계획이지만 이것은 조금 나중입니다.
흥미롭게 볼 수 있습니다. 비밀이 아니라면 거래 기능을 사용하지 않는 지표를 작성하는 데 걸림돌이 되는 것은 무엇입니까? 아니면 작업할 가치가 없는 것입니까? 아니요, 죄송합니다. 어쨌든 다시 작성해야 합니다. OOP 없이 계획 중이신가요?
비밀이 아니라면 거래 기능을 사용하지 않는 지표를 작성하는 데 걸림돌이 되는 것은 무엇입니까?
전혀 없습니다 :) 당신은 심지어 반대 라고 말할 수도 있습니다. :). 지금까지 OOP가 없습니다.
그리고 조만간 지표에 대한 글을 쓸 예정입니다.
전혀 없습니다 :) 당신은 심지어 반대 라고 말할 수도 있습니다. :). 지금까지 OOP가 없습니다.
그리고 조만간 지표에 대한 글을 쓸 예정입니다.
네. 오히려 나는 이미 당신의 이익과 관심을 가지고 연구했습니다. 그러나 왜 "지금까지 OOP 없이"입니까? 인형을 놀라게하고 싶지 않습니까?))) 글쎄, 왜 당신 자신을 위해서가 아니겠습니까?
기사가 필요합니다. 기다릴게. 예, 모두가 기다리고 있습니다. 내가 이해하는 것처럼 거기에만 "현재"입니다.)))