마운드에서 OOP에 대해 이야기하기 - 페이지 17

 
나는 누군가의 거룩하고 의로운 믿음을 훼손하고 싶지 않지만, 여기에서 OOP의 우스꽝스럽고 순진한 선전을 듣는 것은 어리석은 일입니다. 운 좋게도 사용을 금했다”…
 

그건 그렇고, 아직 OOP를 알지 못하는 사람은 이미 오래 전입니다. 멀티 코어 프로세서의 경우 오버 헤드가 너무 높고 병렬 처리가 매우 열악하기 때문에 처음에는 적용되지 않습니다 ...

컴파일러가 최적화 중에 이 모든 쓰레기를 버리는 방법을 이미 배웠다는 것은 좋은 일입니다. 순수한 절차적 논리를 남겨두지 않으면 이 진행 상황이 어떻게 될지 알 수 없습니다. 즉, 성능 저하가 실제로 발생하게 됩니다...

 
Andrei :

그건 그렇고, 아직 OOP를 알지 못하는 사람은 이미 오래 전입니다. 멀티 코어 프로세서의 경우 오버 헤드가 너무 높고 병렬 처리가 매우 열악하기 때문에 처음에는 적용되지 않습니다 ...

컴파일러가 최적화 중에 이 모든 쓰레기를 버리는 방법을 이미 배웠다는 것은 좋은 일입니다. 순수한 절차적 논리를 남겨두지 않으면 이 진행 상황이 어떻게 될지 알 수 없습니다. 즉, 성능 저하가 실제로 발생하게 됩니다...


선구적인 코딱지를 하지 않고 명확하게 질문에 답하십시오.

1. 개인적으로 어떤 병렬화 기술을 사용하셨습니까? 일반적인 삐걱 거리는 소리가 아니라 기술 및 언어의 특정 이름입니다.

1.1 OOP 버전이 어디에서 실패했습니까?

----------

추신: 하루 이상 OOP 과정을 진행했는데 진행자가 이 시간 동안 10명을 차단하고 약 200개의 어리석은 게시물을 문질렀다고 썼습니다! 그는 여기에서 40-50명의 사람들이 동시에 영구적으로 당신을 읽고 있으며, 그 주제가 필요하다고 말합니다. 메뉴를 만들어야 합니다. 언제든지 도와드리겠습니다.

 
Andrei :

그건 그렇고, 아직 OOP를 알지 못하는 사람은 이미 오래 전입니다. 멀티 코어 프로세서의 경우 오버 헤드가 너무 높고 병렬 처리가 매우 열악하기 때문에 처음에는 적용되지 않습니다 ...

컴파일러가 최적화 중에 이 모든 쓰레기를 버리는 방법을 이미 배웠다는 것은 좋은 일입니다. 순수한 절차적 논리를 남겨두지 않으면 이 진행 상황이 어떻게 될지 알 수 없습니다. 즉, 성능 저하가 실제로 발생하게 됩니다...


누구야?

 
Alexey Volchanskiy :


----------

추신: 하루 이상 OOP 과정을 진행했는데 진행자가 이 시간 동안 10명을 차단하고 약 200개의 어리석은 게시물을 문질렀다고 썼습니다! 그는 여기에서 40-50명의 사람들이 동시에 영구적으로 당신을 읽고 있으며, 그 주제가 필요하다고 말합니다. 메뉴를 만들어야 합니다. 언제든지 도와드리겠습니다.

몸조심하지마...
 
Алексей Тарабанов :
몸조심하지마세요...

왜, 아주 편안합니다. 모든 슬래그는 나에게 순수한 지식만 있는 중재자에 의해 인수됩니다. 여기 같지 않습니다. 그런 다음 그가 나를 얼마나 싫어하는지 증오 편지를 보내기 시작합니다. 그리고 나서 여자들은 그를 좋아하지 않는다는 것이 밝혀졌습니다.

글쎄요, 많은 사람들이 저를 좋아하지도 않습니다. 나는 모두가 사랑하는 레몬 벅스가 아니다))

--------------

여기에 진지한 주제가 없다는 것이 슬프다. 낮에는 모든 것이 흩어져 있고 수십 개의 슬래그 메시지로 막힐 것입니다. 그리고 그것은 웅덩이에 영원히 떨어질 것입니다.

MQ는 슈퍼 채팅의 형식을 변경하지 않을 것이므로 여기 내 삶과 여성에 대한 이야기가 있습니다. 여전히 최대 일주일이며, 그 다음 섬프에서 죽음

------------------

아마도 공유 프로젝트에서 코스를 복제하려고 할 것입니다. 최소한 무언가가 거기에 저장되고 쓰기 액세스 측면에서 다이버를 제거할 수 있습니다.

-----------

그러나 전반적으로 모든 포럼을 포기하고 돈을 버는 데 모든 노력을 기울일 필요가 있습니다.))

 
Andrei :
나는 누구의 거룩하고 의로운 믿음을 훼손하고 싶지 않지만, 여기에서 OOP의 우스꽝스럽고 순진한 선전을 듣는 것은 어리석은 일입니다. 운 좋게도 사용을 금했다”…

여기는 유치원이 아닙니다.

유사한 "독립적 금지"가 삶의 많은 영역에 존재합니다.

"여울을 모른다 - 머리를 물에 찌르지 마십시오"라는 문구는 무엇입니까? "그는 강을 건너기로 결정했지만 자신이 그것을 하지 못하게 했다"와 같이?

그리고 "들어 가지 마세요 - 당신을 죽일 것입니다"라는 표시가 무엇입니까? 너 뭐야, 못 들어가? 그러나 자신의 안전을 위해 해서는 안 됩니다.

보호된 메모리 액세스 모드 - 들어 보셨습니까? 다시 한 번 - 자신의 이익을 위해 한 프로세스가 실수로 다른 프로세스에 맞지 않도록 수행됩니다.

OOP에서는 동일합니다. 누가 객체의 모든 변수를 public으로 정의하지 못하도록 막습니까? 그러나 대규모 프로젝트를 작성하기 시작하는 사람은 누구나 개인 메모리 영역이 있고 제한된 인터페이스를 통해 액세스를 구성하는 것이 매우 편리하다는 것을 빨리 알게 됩니다.

Peter Konov의 순전히 절차적 코드는 시스템의 전체 구조를 메모리에 지속적으로 유지해야 합니다. fxsaber의 코드와 비교하십시오. 거래 주문 의 미묘함을 숨기므로 MT4 또는 MT5에서 작업 중인 플랫폼을 알 필요가 없습니다. 나는 또한 주기적으로 게시하는 내 자신의 코드를 제공할 수 있습니다. 또한 나에게 불필요한 것이 무엇인지 이해할 필요가 없습니다. 어떤 터미널에서 작업하는지 생각조차 하지 않고 거래 프로세서 클래스를 사용하고 가상 인터페이스를 사용합니다.

ENTIRE 시스템이 어떻게 배열되어 있는지 기억할 필요가 없도록 먼저 제한이 필요합니다. 블록이 디버깅되고 작동합니다. 외부의 누구도 액세스할 수 없습니다. 성능을 방해하지 않기 위해서입니다. 기능적 접근에서 이것은 쉽지 않은 일이며, 항상 스스로를 제한하면서 올라갈 수 있는 곳과 올라갈 수 없는 곳을 기억해야 합니다. 당신이 잊어 버릴 것이라는 사실로 가득 차있는 것, 당신이 무엇인가를 바꿀 수있는 곳, 그리고 당신이 할 수없는 곳,

 
Andrei :

그건 그렇고, 아직 OOP를 알지 못하는 사람은 이미 오래 전입니다. 멀티 코어 프로세서의 경우 오버 헤드가 너무 높고 병렬 처리가 매우 열악하기 때문에 처음에는 적용되지 않습니다 ...

컴파일러가 최적화 중에 이 모든 쓰레기를 버리는 방법을 이미 배웠다는 것은 좋은 일입니다. 순수한 절차적 논리를 남겨두지 않으면 이 진행 상황이 어떻게 될지 알 수 없습니다. 즉, 성능 저하가 실제로 발생하게 됩니다...

즉, "잘못된 병렬 처리"는 어떻게됩니까? 그 반대가 사실입니다. OOP 코드는 기능 코드보다 병렬화하기가 훨씬 쉽습니다. 유비쿼터스 캡슐화 때문입니다.

컴파일러의 경우 - OOP도 기능적 접근 방식도 없습니다 - 주소, goto 명령, 레지스터를 사용합니다... 컴파일러의 경우 OOP 접근 방식과 FP 접근 방식 모두 동일하게 이질적입니다.

OOP 접근 방식 - 사람은 개발과 가장 중요한 시스템 지원을 단순화해야 합니다.

 
Alexey Volchanskiy :

왜, 아주 편안합니다. 모든 슬래그는 나에게서 순수한 지식만 중재자가 인수합니다. 여기 같지 않습니다. 그런 다음 그가 나를 얼마나 싫어하는지 증오 편지를 보내기 시작합니다. 그리고 나서 여자들은 그를 좋아하지 않는다는 것이 밝혀졌습니다.

그래서 여성들은 나를 좋아하지 않습니다 ... 그리고 더 많은 ... 일반적인 일입니다, Alexei, 그들은 모두 동물이며 모든 사람이 그들을 훈련시킬 수는 없으므로 많은 부러워하는 사람들이 있습니다.

그러나 당신은 더 나은 나에게 말해 - 당신의 코스는 어디입니까? 저도 한번 보겠습니다...

 

"객체 지향 프로그래밍의 장단점" 주제에 대한 나쁜 기사는 아닙니다.

uni-vologda.ac.ru/oberon/infoart/plus&min.htm

게다가 단점 중 하나는 주로 OOP를 통해 프로그래밍하는 방법을 배우고 추가 라이브러리를 읽는 것이 어렵다는 것입니다.