Реter Konow : 이봐, 난 너의 무례한 말투에 몸을 굽히고 싶지 않아. 나는 이것을 말할 것입니다 - 결과가 움직입니다. 물론 수많은 이론이 유용하지만 실습은 모든 것을 있는 그대로 보여줍니다. 당신은 연습과 결과의 측면에서 나와 경쟁합니다. 그리고 나서, 당신의 방대한 마음은 하나의 이론을 추진하고 추진합니다.
전문가 Peter님 말씀이 맞습니다. 그는 당신에게 아주 명확하게 대답했고 나는 "무례한 어조"를 보지 못했습니다.
그리고 그 결과에 관해서도 - 그것은 어떤 방식으로 측정할 것인가? 어떤 전문가에 따르면 결과는 당신보다 더 많을 것입니다.
전문가 Peter님 말씀이 맞습니다. 그는 당신에게 아주 명확하게 대답했고 나는 "무례한 어조"를 보지 못했습니다.
그리고 그 결과에 관해서도 - 그것은 어떤 방식으로 측정할 것인가? 어떤 전문가에 따르면 결과는 당신보다 더 많을 것입니다.
조지, 대결을 계속하지 맙시다. 결과 때문에. 뭐니뭐니해도 라이브러리보다 뛰어난 마크업 언어와 그래픽을 만들었습니다. 복잡성 수준을 이해하고 있다면(불행히도 아닐 수도 있음) 먼저 Anatoly Kozharsky의 라이브러리를 살펴보십시오. 크기, 복잡성, 투자된 노동력을 추정합니다. 인상적이죠? 다음 단계는 무엇입니까? 캔버스에 그리기 및 작업 요소가 있는 마크업 언어.
동시에 Anatoly는 1. OOP, 2. Standard Library (Canvas 클래스)에 의존했고 초기 기반 없이 오로지 나만의 접근 방식으로 모든 작업을 수행했습니다. 이것들은 내 업적입니다.
원래 플러딩 및 트롤링을 목적으로 생성된 주제에서 플러딩 및 트롤링이란 무엇입니까? Peter, 인정합니다. 왜냐하면 당신이 OOP를 배우기 위해서가 아니라 당신이 어레이의 멋진 사용자임을 보여주기 위해 주제를 만들었기 때문입니다. 당신과 같은 똑똑한 펑크))))
당연히이 주제에는 범람과 트롤링 외에는 아무것도 없습니다. 그리고 여기에 진지하게 글을 쓰는 사람들은이 모든 것이 이미 베드로에게 두 번 이상 이야기되었음을 명심하십시오.
드미트리, 나는 그렇게 모호하지 않을 것입니다. 제 생각에 Peter는 OOP가 왜 그렇게 좋은지 이해하고 싶어합니다. 그러나 메가 메모리를 사용하는 OOP는 실제로 카트의 핍스 휠처럼 보입니다. Peter는 "어셈블러" 방식으로 주장합니다. 그리고 어셈블러에는 OOP 종소리와 휘파람이 없으며 순전히 명령과 메모리 주소가 있습니다 ... 여기에서 Peter는 필요한 모든 변수에 액세스 할 수있는 "빠른 꼬마"라고 생각하고 필요에 따라 사용합니다. "불필요한" 실체가 없는 시간의 순간.
나는 같은 기간을 어떻게 보냈는지 아주 잘 기억합니다. 나는 어셈블러로 글을 썼고 아이러니하게도 FoxPro에서 글을 쓰는 사람들을 보았습니다(그들은 그 사무실에서 썼습니다). 더욱이, 전적으로 어셈블러로 작성된 내 양식 입력이 표준 "fox ask" 입력보다 훨씬 빠르게 작동하고(또한 당시 CGA 모니터에서 "눈"도 제거됨) 이것이 모든 사람에게 인정될 때 좋았습니다...
그러나 이 기간은 컴퓨터의 힘의 증가와 프로젝트 규모의 증가로 다소 빨리 끝났습니다. 먼저 C 코드에서 어셈블러 삽입으로 전환하고 어셈블러로 작성된 링크 가능한 라이브러리 함수로 전환한 다음 라이브러리 함수를 위해 어셈블러 삽입을 포기했습니다...
그런 다음 - 우리는 Sun 시스템을 설치했고 우리 프로그램이 작동하는 것이 필요했습니다 ... 일반적으로 모든 모듈이 Sun 아키텍처에 대해 실질적으로 변경 사항 없이 재컴파일되었지만 여기에서 모든 라이브러리 기능이 적합하지 않았습니다. 음, 라이브러리 어셈블러 기능은 C로 다시 작성해야 했습니다(그래도 여전히 "플러스" 없음).
여기에서 어셈블러에 대한 나의 관심이 끝나고 캡슐화에 대해 점점 더 감사하게 되었습니다. 곧 최초의 C ++ 컴파일러와 OOP 패러다임이 제때에 도착했고 나는 큰 기쁨을 누렸습니다.
조지, 대결을 계속하지 맙시다. 결과 때문에. 뭐니뭐니해도 라이브러리보다 뛰어난 마크업 언어와 그래픽을 만들었습니다. 복잡성 수준을 이해하고 있다면(불행히도 아닐 수도 있음) 먼저 Anatoly Kozharsky의 라이브러리를 살펴보십시오. 크기, 복잡성, 투자된 노동력을 추정하십시오. 인상적이죠? 다음 단계는 무엇입니까? 캔버스에 그리기 및 작업 요소가 있는 마크업 언어.
동시에 Anatoly는 1. OOP, 2. Standard Library (Canvas 클래스)에 의존했고 초기 기반 없이 오로지 나만의 접근 방식으로 모든 작업을 수행했습니다. 이것들은 내 업적입니다.
엑스퍼트가 뭔가 더 만들었다면 나는 고개를 숙인다.
예, 복잡성 수준은 분명합니다. "어셈블러에서"라고 생각한다고 두 번 이상 말했습니다. 어셈블리 언어 코드가 특히 OOP 기술을 사용하여 고급 언어를 사용하여 작성된 것만큼 항상 좋을 것이라고 주장하는 사람은 아무도 없습니다. 그러나 정당하지 않은 비용은 너무 커서 어셈블러로 작성합니다. 모든 작업을 직접 수행했으며 Anatoly가 표준 라이브러리에 의존했다는 사실은 Anatoly의 장점일 뿐입니다.
내일은 컴파일러에 심각한 변화가 있을 것이며 Anatoly보다 훨씬 더 많은 코드를 삽질해야 할 것입니다.
당신의 업적은 많은 기네스 세계 기록 보유자들의 "성취"와 비슷합니다. 그러나 이러한 챔피언은 현대적인 수단을 사용하여 동일한 작업을 수행하는 사람들에게 "여기, 어떻게 되어야 하는지"라고 말하지 않을 것이라고 생각합니다. Offhand - 기록이 있습니다 - 어떤 강한 남자가 여러 대의 철도 차량을 10 미터 끌었습니다. 그가 모든 사람에게 "내 업적을 보라. 손으로 차를 끌 수 있는데 왜 기차를 이용하는지 모르겠다"고 말하면 - 당신은 그에게 무엇이라고 대답할 것입니까? 결국, 사실, 전기 기차에는 전기도, 디젤 엔진에는 연료도 없을 것이고 자동차를 움직여야 한다고 상상해 보십시오. 이것이 바로 이 강한 사람의 경험과 그의 "성취"가 편리합니다. 그러나 전기와 디젤 연료 없이 자동차를 혼자 움직여야 하는 상황이 얼마나 현실적입니까? 그래서 당신의 이 마크업과 그래픽 언어가 ... 맞습니다. 많은 작업이 있고 모든 것이 작동합니다. 하지만 왜?
예, 복잡성 수준은 분명합니다. "어셈블러에서"라고 생각한다고 두 번 이상 말했습니다. 어셈블리 언어 코드가 특히 OOP 기술을 사용하여 고급 언어를 사용하여 작성된 것만큼 항상 좋을 것이라고 주장하는 사람은 아무도 없습니다. 그러나 정당하지 않은 비용은 너무 커서 어셈블러로 작성합니다. 모든 작업을 직접 수행했으며 Anatoly가 표준 라이브러리에 의존했다는 사실은 Anatoly의 장점일 뿐입니다.
내일은 컴파일러에 심각한 변화가 있을 것이며 Anatoly보다 훨씬 더 많은 코드를 삽질해야 할 것입니다.
당신의 업적은 많은 기네스 세계 기록 보유자들의 "성취"와 비슷합니다. 그러나 이러한 챔피언은 현대적인 수단을 사용하여 동일한 작업을 수행하는 사람들에게 "여기, 어떻게 되어야 하는지"라고 말하지 않을 것이라고 생각합니다. Offhand - 기록이 있습니다 - 어떤 강한 남자가 여러 대의 철도 차량을 10 미터 끌었습니다. 그가 모든 사람에게 "내 업적을 보라. 손으로 차를 끌 수 있는데 왜 기차를 이용하는지 모르겠다"고 말하면 - 당신은 그에게 무엇이라고 대답할 것입니까? 결국, 사실, 전기 기차에는 전기도, 디젤 엔진에는 연료도 없을 것이고 자동차를 움직여야 한다고 상상해 보십시오. 이것이 바로 이 강한 사람의 경험과 그의 "성취"가 편리합니다. 그러나 전기와 디젤 연료 없이 자동차를 혼자 움직여야 하는 상황이 얼마나 현실적입니까? 그래서 당신의 이 마크업과 그래픽 언어가 ... 맞습니다. 많은 작업이 있고 모든 것이 작동합니다. 하지만 왜?
당신의 논리는 강화 콘크리트입니다, 조지.)) 당신은 논쟁할 수 없습니다. 그리고 "왜?"라는 질문에 추측으로만 대답할 수 있습니다. 이뿐만이 아닐 가능성이 있습니다. 한편으로 이것은 나의 "마케팅"입니다. 한편 훈련․ 세 번째는 아마도 위대한 발명의 서곡일 것입니다. 결국 그래픽을 떠나 AI에 접근하고 싶지만 이미 만들어진 라이브러리가 없고 엄청난 '힘'이 필요하다.
Во время учебы белорусская художница Надя Матиевская получила задание нарисовать картину грудью. Ей понравился этот эксперимент, и теперь она использует для творчества собственный бюст, по крайней мере, столь же часто, как обычные кисти. Посмотрите, что у нее получается!
OOP 전문가는 일반적인 추세 추종 거래 시스템을 어떻게 보고 있습니까? 그리고 우선 - 잠재적 이익을 추출하기 위한 구성 및 주요 기능.
"리그 TS" 분기를 열고 시스템을 살펴봅니다. 이름에 Trend라는 단어가 있는 것은 모두 트렌드에 따라 작동하는 시스템입니다. 그 중에는 오랜 기간 데모 계정 을 운영해 수익을 내고 있는 이들도 있다.
이것이 그들이 보는 방식입니다. 시스템 구성은 3페니 정도로 간단합니다. CodeBase에는 이러한 원칙에 대해 작업하는 무료 전문가가 있습니다.
그러나 내 리그에서는 모든 것이 OOP 스타일로 매달려 있습니다. 심지어 차량의 인터페이스만 요청하면 누구나 사용할 수 있는 소프트웨어 모듈을 출시할 예정이었습니다. 바로 건설의 OOP 원칙 때문입니다.
이봐, 난 너의 무례한 말투에 몸을 굽히고 싶지 않아. 나는 이것을 말할 것입니다 - 결과가 움직입니다. 물론 수많은 이론이 유용하지만 실습은 모든 것을 있는 그대로 보여줍니다. 당신은 연습과 결과의 측면에서 나와 경쟁합니다. 그리고 나서, 당신의 방대한 마음은 하나의 이론을 추진하고 추진합니다.
전문가 Peter님 말씀이 맞습니다. 그는 당신에게 아주 명확하게 대답했고 나는 "무례한 어조"를 보지 못했습니다.
그리고 그 결과에 관해서도 - 그것은 어떤 방식으로 측정할 것인가? 어떤 전문가에 따르면 결과는 당신보다 더 많을 것입니다.
전문가 Peter님 말씀이 맞습니다. 그는 당신에게 아주 명확하게 대답했고 나는 "무례한 어조"를 보지 못했습니다.
그리고 그 결과에 관해서도 - 그것은 어떤 방식으로 측정할 것인가? 어떤 전문가에 따르면 결과는 당신보다 더 많을 것입니다.
조지, 대결을 계속하지 맙시다. 결과 때문에. 뭐니뭐니해도 라이브러리보다 뛰어난 마크업 언어와 그래픽을 만들었습니다. 복잡성 수준을 이해하고 있다면(불행히도 아닐 수도 있음) 먼저 Anatoly Kozharsky의 라이브러리를 살펴보십시오. 크기, 복잡성, 투자된 노동력을 추정합니다. 인상적이죠? 다음 단계는 무엇입니까? 캔버스에 그리기 및 작업 요소가 있는 마크업 언어.
동시에 Anatoly는 1. OOP, 2. Standard Library (Canvas 클래스)에 의존했고 초기 기반 없이 오로지 나만의 접근 방식으로 모든 작업을 수행했습니다. 이것들은 내 업적입니다.
엑스퍼트가 뭔가 더 만들었다면 나는 고개를 숙인다.
원래 플러딩 및 트롤링을 목적으로 생성된 주제에서 플러딩 및 트롤링이란 무엇입니까? Peter, 인정합니다. 왜냐하면 당신이 OOP를 배우기 위해서가 아니라 당신이 어레이의 멋진 사용자임을 보여주기 위해 주제를 만들었기 때문입니다. 당신과 같은 똑똑한 펑크))))
당연히이 주제에는 범람과 트롤링 외에는 아무것도 없습니다. 그리고 여기에 진지하게 글을 쓰는 사람들은이 모든 것이 이미 베드로에게 두 번 이상 이야기되었음을 명심하십시오.
드미트리, 나는 그렇게 모호하지 않을 것입니다. 제 생각에 Peter는 OOP가 왜 그렇게 좋은지 이해하고 싶어합니다. 그러나 메가 메모리를 사용하는 OOP는 실제로 카트의 핍스 휠처럼 보입니다. Peter는 "어셈블러" 방식으로 주장합니다. 그리고 어셈블러에는 OOP 종소리와 휘파람이 없으며 순전히 명령과 메모리 주소가 있습니다 ... 여기에서 Peter는 필요한 모든 변수에 액세스 할 수있는 "빠른 꼬마"라고 생각하고 필요에 따라 사용합니다. "불필요한" 실체가 없는 시간의 순간.
나는 같은 기간을 어떻게 보냈는지 아주 잘 기억합니다. 나는 어셈블러로 글을 썼고 아이러니하게도 FoxPro에서 글을 쓰는 사람들을 보았습니다(그들은 그 사무실에서 썼습니다). 더욱이, 전적으로 어셈블러로 작성된 내 양식 입력이 표준 "fox ask" 입력보다 훨씬 빠르게 작동하고(또한 당시 CGA 모니터에서 "눈"도 제거됨) 이것이 모든 사람에게 인정될 때 좋았습니다...
그러나 이 기간은 컴퓨터의 힘의 증가와 프로젝트 규모의 증가로 다소 빨리 끝났습니다. 먼저 C 코드에서 어셈블러 삽입으로 전환하고 어셈블러로 작성된 링크 가능한 라이브러리 함수로 전환한 다음 라이브러리 함수를 위해 어셈블러 삽입을 포기했습니다...
그런 다음 - 우리는 Sun 시스템을 설치했고 우리 프로그램이 작동하는 것이 필요했습니다 ... 일반적으로 모든 모듈이 Sun 아키텍처에 대해 실질적으로 변경 사항 없이 재컴파일되었지만 여기에서 모든 라이브러리 기능이 적합하지 않았습니다. 음, 라이브러리 어셈블러 기능은 C로 다시 작성해야 했습니다(그래도 여전히 "플러스" 없음).
여기에서 어셈블러에 대한 나의 관심이 끝나고 캡슐화에 대해 점점 더 감사하게 되었습니다. 곧 최초의 C ++ 컴파일러와 OOP 패러다임이 제때에 도착했고 나는 큰 기쁨을 누렸습니다.
그러나이 "즐거움"을 위해서만 첫 번째 "어셈블러"단계가 필요했습니다.
Peter는 아직 이 단계를 통과하지 못했습니다. 우리는 기다리고 있습니다...
조지, 대결을 계속하지 맙시다. 결과 때문에. 뭐니뭐니해도 라이브러리보다 뛰어난 마크업 언어와 그래픽을 만들었습니다. 복잡성 수준을 이해하고 있다면(불행히도 아닐 수도 있음) 먼저 Anatoly Kozharsky의 라이브러리를 살펴보십시오. 크기, 복잡성, 투자된 노동력을 추정하십시오. 인상적이죠? 다음 단계는 무엇입니까? 캔버스에 그리기 및 작업 요소가 있는 마크업 언어.
동시에 Anatoly는 1. OOP, 2. Standard Library (Canvas 클래스)에 의존했고 초기 기반 없이 오로지 나만의 접근 방식으로 모든 작업을 수행했습니다. 이것들은 내 업적입니다.
엑스퍼트가 뭔가 더 만들었다면 나는 고개를 숙인다.
예, 복잡성 수준은 분명합니다. "어셈블러에서"라고 생각한다고 두 번 이상 말했습니다. 어셈블리 언어 코드가 특히 OOP 기술을 사용하여 고급 언어를 사용하여 작성된 것만큼 항상 좋을 것이라고 주장하는 사람은 아무도 없습니다. 그러나 정당하지 않은 비용은 너무 커서 어셈블러로 작성합니다. 모든 작업을 직접 수행했으며 Anatoly가 표준 라이브러리에 의존했다는 사실은 Anatoly의 장점일 뿐입니다.
내일은 컴파일러에 심각한 변화가 있을 것이며 Anatoly보다 훨씬 더 많은 코드를 삽질해야 할 것입니다.
당신의 업적은 많은 기네스 세계 기록 보유자들의 "성취"와 비슷합니다. 그러나 이러한 챔피언은 현대적인 수단을 사용하여 동일한 작업을 수행하는 사람들에게 "여기, 어떻게 되어야 하는지"라고 말하지 않을 것이라고 생각합니다. Offhand - 기록이 있습니다 - 어떤 강한 남자가 여러 대의 철도 차량을 10 미터 끌었습니다. 그가 모든 사람에게 "내 업적을 보라. 손으로 차를 끌 수 있는데 왜 기차를 이용하는지 모르겠다"고 말하면 - 당신은 그에게 무엇이라고 대답할 것입니까? 결국, 사실, 전기 기차에는 전기도, 디젤 엔진에는 연료도 없을 것이고 자동차를 움직여야 한다고 상상해 보십시오. 이것이 바로 이 강한 사람의 경험과 그의 "성취"가 편리합니다. 그러나 전기와 디젤 연료 없이 자동차를 혼자 움직여야 하는 상황이 얼마나 현실적입니까? 그래서 당신의 이 마크업과 그래픽 언어가 ... 맞습니다. 많은 작업이 있고 모든 것이 작동합니다. 하지만 왜?
예, 복잡성 수준은 분명합니다. "어셈블러에서"라고 생각한다고 두 번 이상 말했습니다. 어셈블리 언어 코드가 특히 OOP 기술을 사용하여 고급 언어를 사용하여 작성된 것만큼 항상 좋을 것이라고 주장하는 사람은 아무도 없습니다. 그러나 정당하지 않은 비용은 너무 커서 어셈블러로 작성합니다. 모든 작업을 직접 수행했으며 Anatoly가 표준 라이브러리에 의존했다는 사실은 Anatoly의 장점일 뿐입니다.
내일은 컴파일러에 심각한 변화가 있을 것이며 Anatoly보다 훨씬 더 많은 코드를 삽질해야 할 것입니다.
당신의 업적은 많은 기네스 세계 기록 보유자들의 "성취"와 비슷합니다. 그러나 이러한 챔피언은 현대적인 수단을 사용하여 동일한 작업을 수행하는 사람들에게 "여기, 어떻게 되어야 하는지"라고 말하지 않을 것이라고 생각합니다. Offhand - 기록이 있습니다 - 어떤 강한 남자가 여러 대의 철도 차량을 10 미터 끌었습니다. 그가 모든 사람에게 "내 업적을 보라. 손으로 차를 끌 수 있는데 왜 기차를 이용하는지 모르겠다"고 말하면 - 당신은 그에게 무엇이라고 대답할 것입니까? 결국, 사실, 전기 기차에는 전기도, 디젤 엔진에는 연료도 없을 것이고 자동차를 움직여야 한다고 상상해 보십시오. 이것이 바로 이 강한 사람의 경험과 그의 "성취"가 편리합니다. 그러나 전기와 디젤 연료 없이 자동차를 혼자 움직여야 하는 상황이 얼마나 현실적입니까? 그래서 당신의 이 마크업과 그래픽 언어가 ... 맞습니다. 많은 작업이 있고 모든 것이 작동합니다. 하지만 왜?
TV에서 인터넷을 뒤집어서 fishnet을 읽으십시오.
Во время учебы белорусская художница Надя Матиевская получила задание нарисовать картину грудью. Ей понравился этот эксперимент, и теперь она использует для творчества собственный бюст, по крайней мере, столь же часто, как обычные кисти. Посмотрите, что у нее получается!
1. 앗, 투자자들 앞에서 웅덩이에 앉지 않으려고 가르치러 갔다. 동시에 투자자들은 OOP에 대한 나의 지식이 아니라 나의 접근 방식으로 얻은 결과에 관심을 보였습니다.
2. 이 유치원에서 벗어나 개인으로 전환합니다.
Peter, 이 주제뿐만 아니라 전체 주제는 한 사람에 대한 토론에 전념하고 있습니다. 모든 주제에 빨간 선처럼 흐르는 "외부 보기"를 읽으십시오.
스스로에 대한 찬사를 아끼지 않는 사람들 - 그 아이들과 트롤, 그리고 기뻐하고 매료된 사람들 - "영원한 친구"입니까?
"뻐꾸기가 뻐꾸기를 칭찬하기 때문에 수탉을 칭찬한다"?
추신. 투자자는 프로그래밍 방법이 아니라 거래가 필요합니다. 그들은 그것에 대해 전혀 신경 쓰지 않습니다. 따라서 Stanislavsky에서 그들에 대해.
TV에서 인터넷을 뒤집어서 fishnet을 읽으십시오.
그녀는 자신의 흉상의 자화상을 판매합니까? 그러면 매우 편리합니다! :)
Peter, 이 주제뿐만 아니라 전체 주제는 한 사람에 대한 토론에 전념하고 있습니다. 모든 주제에 빨간 선처럼 흐르는 "외부 보기"를 읽으십시오.
스스로에 대한 찬사를 아끼지 않는 사람들 - 그 아이들과 트롤, 그리고 기뻐하고 매료된 사람들 - "영원한 친구"입니까?
"뻐꾸기가 뻐꾸기를 칭찬하기 때문에 수탉을 칭찬한다"?
이것이 당신의 비전입니다. 그것은 OOP와 나의 접근 방식에 관한 것이었습니다. 내가 나를 칭찬한 곳을 인용하라.
여기에서 내 ID로 전환했습니다. https://www.mql5.com/en/forum/320813/page18
그 전에 대화는 순전히 기술적인 것이었습니다.