왜 넌센스? 원하는 데이터나 함수에 도달하기 위해 얼마나 많은 포인터를 반복해야 하는지 계산하십시오.
계산하는 방법을 알고 있다면. :)
자리잡을래? 무엇을 정리할까요? 어디서 얻을? 클래스의 새 인스턴스를 생성할 때 - 클래스 유형의 변수, 링크 테이블의 복제본이 생성되고 그게 전부입니다.
클래스에 있는 데이터에 대한 액세스, 일반 변수의 속도가 동일함, 클래스(privat, public) 내에서 액세스 권한을 분리하기 위한 모든 설명적 측정은 모두 컴파일러 수준에 있으며, 컴파일된 코드는 물리적 메모리 셀에서만 작동합니다.
글쎄, 교활하게 생성된 다른 클래스에서 교활한 방식으로 즉석에서 생성되는 "복잡한 동적 클래스"가 있다고 가정해 보겠습니다. 그래서 무엇? 결국 모든 것은 특정 기능에 의해 고려될 것입니다. 글쎄, Duc, 그런 서커스 트릭을 위해 정원을 울타리로 만들 가치가 있었습니까?
질병이 진행 중입니까? OOP가 프로그래머를 일상적인 데이터 준비, 데이터 콘텐츠 제어에서 해방시키고 클래스 내부에서 메서드를 구현하거나 타사 함수를 호출하는 방법은 프로그래머에게 달려 있다고 여러 번 들었습니다.
OOP도 과거의 일입니다. 이제 추세는 CUDA와 같은 C에서 주로 사용되는 하드웨어 지향 프로그래밍입니다. GPU가 통합된 프로세서가 출시되면 이 기능이 더욱 향상될 것입니다. 프로세서 회사는 시간이 지남에 따라 범용 프로세서 코어만 생산하는 것을 중단할 계획입니다.
여기서 나는 유능하지 않으며 당신의 입에서 이 정보는 신뢰할 수 없어 보입니다
추신: 내가 글을 쓰는 이유 - 기술 포럼에 말도 안되는 글을 쓰지 마세요 - 지식을 공유할 수 있습니다 - 공유, 지식이 없습니다 - 질문
그리고 여기에 데이터 표현에 대한 프로그램의 논리가 있습니까? 이러한 것들은 관련이 없습니다.
프로그램의 논리는 모든 입력 데이터에 대한 산술 연산이며 데이터의 표현은 하나 또는 다른 형식의 데이터일 뿐입니다.
그리고 객체에 대한 외부 포인터가 직접 액세스가 아닌 내부 데이터(함수 및 변수)에 액세스하는 것처럼 보이기 때문에 OOP의 프로그램 코드는 정의에 의해 축소될 수 없습니다. 그러나 포인터를 계산하고 메모리에 액세스하는 것은 매우 느린 작업이므로 그에 따라 성능이 저하됩니다.
OOP 애플리케이션 개발은 클래스 라이브러리 개발과 동일하지 않습니다. 엄밀히 말하면 라이브러리 개발자는 _일반적으로_ 자신의 라이브러리가 응용 프로그램을 직접 작성하는 사람들이 _구체적으로_ 무엇을 위해 사용할지 신경 쓰지 않아야 합니다. 예를 들어, 망치 제조업체는 못을 박거나 너트를 부수기 위해 제품을 어떻게 사용하는지 전혀 신경 쓰지 않습니다. 그의 임무는 악기를 만드는 것입니다. 또한 OOP에서 클래스는 일반적으로 명확하게 정의된 것과는 거리가 먼 특정 범위의 작업을 해결하도록 설계된 도구입니다.
다시 한 번 반복하겠습니다. OOP의 기본 작업을 결정하는 데는 필요하지 않습니다. 하지만 한편으로는 못을 박고 싶은 사람이 다 스스로 망치를 만들어야 한다고 생각하지 않습니까?
물론 여기에서 함수 라이브러리가 있다고 주장할 수 있습니다. 도대체 왜 더 많은 클래스가 필요했습니까? 그러나 이 경우 상속, 형식 확장, 오버로딩 등의 메커니즘 이 제공하는 편의를 박탈합니다. 대략적으로 말하면 망치로 만든 모터를 손으로 나사로 조여서 원하는 대로 작동하게 할 수 있지만 이를 위해 망치 장치를 이해할 필요는 없습니다. 망치로 못을 박을 수 있다는 것만 알면 됩니다.
따라서 OOP는 응용 프로그램을 작성하는 프로그래머의 삶을 정말로 쉽게 만듭니다. 또 다른 점은 MQL5용 라이브러리의 기능 이 여전히 매우 제한적이지만 이는 시간 문제이며 라이브러리 개발자가 이 문제를 처리한다는 것입니다(물론 동일한 사람일 수 있지만 필수는 아님). 잘 개발된 클래스 라이브러리 시스템을 사용하면 사용자 프로그래머가 "1. 프로그램, 여기에 데이터가 있습니다" "2. 프로그램, 카운트"와 같은 프로그램에서 실제로 어떻게 하는지 궁금해하지 않고 한두 줄만 작성하는 것으로 충분합니다. 그것은 자세하게 작동합니다. 구조 지향 프로그래밍에서는 이를 달성할 수 없습니다.
OOP에 대한 당신의 편견은 당신이 충분히 복잡한 작업을 접하지 않았거나 단순히 게으름이나 어떤 다른 이유로 당신이 그것을 하고 싶지 않다는 사실의 결과인 것 같습니다. 나는 헛되이 말할 것입니다. 그러나 주인은 신사입니다.
1. 그러나 이 경우 상속, 유형 확장, 오버로딩 등의 메커니즘이 제공하는 편의를 박탈합니다. 대략적으로 말하면 망치로 만든 모터를 손으로 나사로 조여서 원하는 대로 작동하게 할 수 있지만 이를 위해 망치 장치를 이해할 필요는 없습니다. 망치로 못을 박을 수 있다는 것만 알면 됩니다.
2. 잘 개발된 클래스 라이브러리 시스템으로 사용자 프로그래머는 "1. 프로그램, 여기에 데이터가 있습니다" "2. 프로그램, 카운트"와 같은 프로그램에서 한 두 줄만 작성하면 충분합니다. 어떻게 작동하는지 자세히 궁금합니다. 구조 지향 프로그래밍에서는 이를 달성할 수 없습니다.
1. OPP를 사용하면 클래스도 처리해야 합니다. 정확히 무엇을 합니까? 일종의 기능인 것처럼 말이다. 그러나 클래스의 경우 전체 체인을 추적하기가 더 어렵기 때문에 일반적으로 동일한 수준의 기능으로 해당 구조를 연구하는 데 더 많은 시간이 소요됩니다.
2. 구조 지향 프로그래밍을 사용하면 이전에 누군가가 이미 수행한 세부 사항에 들어가지 않고도 문제 없이 유사한 작업을 구성할 수도 있습니다.
자, 그럼 더 간단한 질문을 하겠습니다. 1차원 배열과 2차원 배열의 변수에 접근할 때 연산의 수를 비교합니다.
그리고 이제 거의 차이가 없다고 주장할 것입니까?
이것도 OOP 질문인가요?
그렇지 않은 경우: 배열이 정적이면 1차원 배열 또는 2차원 배열에 액세스할 때 성능에 차이가 없습니다.다차원 배열의 데이터는 대략 배열 x[20]과 배열 y[2][10]가 있는 것처럼 메모리에 한 줄씩 저장되며, 데이터 y는 메모리에 기록됩니다. 첫 번째 y[0 ] 그런 다음 y[1], x[20]처럼 물리적으로 위치합니다.
약간의 성능 지연이 있는 경우에는 너무 미미하며 범위를 벗어난 배열의 제어로 인해 발생할 수 있습니다.
배열이 동적인 경우 - 특정 컴파일러 제조업체에 따라 다릅니다. - 메모리 관리자 코드가 얼마나 최적화되었는지(델파이에서는 대부분의 시스템 모듈이 ASM으로 작성됨) 다차원 동적 배열에 대한 메모리 할당이 조금 더 복잡하기 때문에 , 그러나 여기에서 일반적으로 문제는 동적 배열에 있는 것이 아니라 프로그래머에게 있습니다. 정당화되고 종종 동적 배열에 대한 메모리 재할당을 유발하는 한
추신: 의사 소통에 감사드립니다. 그러나 기본적인 사항에 대한 오해에 많은 시간을 할애 할 수 없습니다. 스스로 읽기 시작하십시오.
그렇지 않은 경우: 배열이 정적이면 1차원 배열 또는 2차원 배열에 액세스할 때 성능에 차이가 없습니다. 다차원 배열의 데이터는 대략 배열 x[20]과 배열 y[2][10]가 있는 것처럼 메모리에 한 줄씩 저장되며, 데이터 y는 메모리에 기록됩니다. 첫 번째 y[0 ] 그런 다음 y[1], 물리적으로 x[20]과 같이 위치합니다.
가장 단순한 것을 모르기 때문에 착각하는 것입니다.
모든 배열의 데이터는 메모리에 선형으로 위치합니다. 처음부터 마지막까지 요소 x[15]를 참조하기 위해 이 변수를 계산하려면 배열의 시작 주소에 변수의 주소가 될 오프셋 15를 더한 값을 계산해야 합니다. . 2차원 배열(예: x[2][5])의 경우 먼저 두 번째 행에 대한 오프셋을 계산한 다음 여기에 다섯 번째 요소에 대한 오프셋을 추가해야 합니다. 즉, 두 배의 연산이 필요합니다.
진정해.
왜 넌센스? 원하는 데이터나 함수에 도달하기 위해 얼마나 많은 포인터를 반복해야 하는지 계산하십시오.
계산하는 방법을 알고 있다면. :)
자리잡을래? 무엇을 정리할까요? 어디서 얻을? 클래스의 새 인스턴스를 생성할 때 - 클래스 유형의 변수, 링크 테이블의 복제본이 생성되고 그게 전부입니다.
클래스에 있는 데이터에 대한 액세스, 일반 변수의 속도가 동일함, 클래스(privat, public) 내에서 액세스 권한을 분리하기 위한 모든 설명적 측정은 모두 컴파일러 수준에 있으며, 컴파일된 코드는 물리적 메모리 셀에서만 작동합니다.
글쎄, 교활하게 생성된 다른 클래스에서 교활한 방식으로 즉석에서 생성되는 "복잡한 동적 클래스"가 있다고 가정해 보겠습니다. 그래서 무엇? 결국 모든 것은 특정 기능에 의해 고려될 것입니다. 글쎄, Duc, 그런 서커스 트릭을 위해 정원을 울타리로 만들 가치가 있었습니까?
질병이 진행 중입니까? OOP가 프로그래머를 일상적인 데이터 준비, 데이터 콘텐츠 제어에서 해방시키고 클래스 내부에서 메서드를 구현하거나 타사 함수를 호출하는 방법은 프로그래머에게 달려 있다고 여러 번 들었습니다.
OOP도 과거의 일입니다. 이제 추세는 CUDA와 같은 C에서 주로 사용되는 하드웨어 지향 프로그래밍입니다. GPU가 통합된 프로세서가 출시되면 이 기능이 더욱 향상될 것입니다. 프로세서 회사는 시간이 지남에 따라 범용 프로세서 코어만 생산하는 것을 중단할 계획입니다.
여기서 나는 유능하지 않으며 당신의 입에서 이 정보는 신뢰할 수 없어 보입니다
추신: 내가 글을 쓰는 이유 - 기술 포럼에 말도 안되는 글을 쓰지 마세요 - 지식을 공유할 수 있습니다 - 공유, 지식이 없습니다 - 질문
자리잡을래? 무엇을 정리할까요? 어디서 얻을까? 클래스의 새 인스턴스를 생성할 때 - 클래스 유형의 변수, 링크 테이블의 복제본이 생성되고 그게 전부입니다.
클래스에 있는 데이터에 대한 액세스, 일반 변수의 속도가 동일함, 클래스(privat, public) 내에서 액세스 권한을 분리하기 위한 모든 설명적 측정은 모두 컴파일러 수준에 있으며, 컴파일된 코드는 물리적 메모리 셀에서만 작동합니다.
그런 다음 감정가에게 그런 질문. 세 개의 동적 배열 로 구성된 클래스가 있습니다(컴파일 단계에서는 크기를 알 수 없음).
이제 클래스 내부에 있는 임의의 정적 배열과 동적 배열에 액세스하는 작업의 수를 세고 비교하십시오.
여기서 나는 유능하지 않으며 당신의 입에서 이 정보는 신뢰할 수 없어 보입니다
그리고 여기에 데이터 표현에 대한 프로그램의 논리가 있습니까? 이러한 것들은 관련이 없습니다.
프로그램의 논리는 모든 입력 데이터에 대한 산술 연산이며 데이터의 표현은 하나 또는 다른 형식의 데이터일 뿐입니다.
그리고 객체에 대한 외부 포인터가 직접 액세스가 아닌 내부 데이터(함수 및 변수)에 액세스하는 것처럼 보이기 때문에 OOP의 프로그램 코드는 정의에 의해 축소될 수 없습니다. 그러나 포인터를 계산하고 메모리에 액세스하는 것은 매우 느린 작업이므로 그에 따라 성능이 저하됩니다.
OOP 애플리케이션 개발은 클래스 라이브러리 개발과 동일하지 않습니다. 엄밀히 말하면 라이브러리 개발자는 _일반적으로_ 자신의 라이브러리가 응용 프로그램을 직접 작성하는 사람들이 _구체적으로_ 무엇을 위해 사용할지 신경 쓰지 않아야 합니다. 예를 들어, 망치 제조업체는 못을 박거나 너트를 부수기 위해 제품을 어떻게 사용하는지 전혀 신경 쓰지 않습니다. 그의 임무는 악기를 만드는 것입니다. 또한 OOP에서 클래스는 일반적으로 명확하게 정의된 것과는 거리가 먼 특정 범위의 작업을 해결하도록 설계된 도구입니다.
다시 한 번 반복하겠습니다. OOP의 기본 작업을 결정하는 데는 필요하지 않습니다. 하지만 한편으로는 못을 박고 싶은 사람이 다 스스로 망치를 만들어야 한다고 생각하지 않습니까?
물론 여기에서 함수 라이브러리가 있다고 주장할 수 있습니다. 도대체 왜 더 많은 클래스가 필요했습니까? 그러나 이 경우 상속, 형식 확장, 오버로딩 등의 메커니즘 이 제공하는 편의를 박탈합니다. 대략적으로 말하면 망치로 만든 모터를 손으로 나사로 조여서 원하는 대로 작동하게 할 수 있지만 이를 위해 망치 장치를 이해할 필요는 없습니다. 망치로 못을 박을 수 있다는 것만 알면 됩니다.
따라서 OOP는 응용 프로그램을 작성하는 프로그래머의 삶을 정말로 쉽게 만듭니다. 또 다른 점은 MQL5용 라이브러리의 기능 이 여전히 매우 제한적이지만 이는 시간 문제이며 라이브러리 개발자가 이 문제를 처리한다는 것입니다(물론 동일한 사람일 수 있지만 필수는 아님). 잘 개발된 클래스 라이브러리 시스템을 사용하면 사용자 프로그래머가 "1. 프로그램, 여기에 데이터가 있습니다" "2. 프로그램, 카운트"와 같은 프로그램에서 실제로 어떻게 하는지 궁금해하지 않고 한두 줄만 작성하는 것으로 충분합니다. 그것은 자세하게 작동합니다. 구조 지향 프로그래밍에서는 이를 달성할 수 없습니다.
OOP에 대한 당신의 편견은 당신이 충분히 복잡한 작업을 접하지 않았거나 단순히 게으름이나 어떤 다른 이유로 당신이 그것을 하고 싶지 않다는 사실의 결과인 것 같습니다. 나는 헛되이 말할 것입니다. 그러나 주인은 신사입니다.
그런 다음 감정가에게 그런 질문. 세 개의 동적 배열로 구성된 클래스가 있습니다(컴파일 단계에서는 크기를 알 수 없음).
이제 클래스 내부에 있는 임의의 정적 배열과 동적 배열에 액세스하는 작업의 수를 세고 비교하십시오.
그리고 수업은 어떻습니까? 이것은 동적 또는 정적 배열과 함께 작동하며 동적 배열 을 사용하는 위치는 중요하지 않습니다. 클래스 또는 변수
동적 배열로 작업하는 것이 조금 더 오래 걸린다는 사실은 "생각할 필요가 없습니다" - 범위를 벗어난 배열에 대한 제어가 있으며 종종 동적 메모리 할당 관리자를 호출합니다.
alsu :
1. 그러나 이 경우 상속, 유형 확장, 오버로딩 등의 메커니즘이 제공하는 편의를 박탈합니다. 대략적으로 말하면 망치로 만든 모터를 손으로 나사로 조여서 원하는 대로 작동하게 할 수 있지만 이를 위해 망치 장치를 이해할 필요는 없습니다. 망치로 못을 박을 수 있다는 것만 알면 됩니다.
2. 잘 개발된 클래스 라이브러리 시스템으로 사용자 프로그래머는 "1. 프로그램, 여기에 데이터가 있습니다" "2. 프로그램, 카운트"와 같은 프로그램에서 한 두 줄만 작성하면 충분합니다. 어떻게 작동하는지 자세히 궁금합니다. 구조 지향 프로그래밍에서는 이를 달성할 수 없습니다.
1. OPP를 사용하면 클래스도 처리해야 합니다. 정확히 무엇을 합니까? 일종의 기능인 것처럼 말이다. 그러나 클래스의 경우 전체 체인을 추적하기가 더 어렵기 때문에 일반적으로 동일한 수준의 기능으로 해당 구조를 연구하는 데 더 많은 시간이 소요됩니다.
2. 구조 지향 프로그래밍을 사용하면 이전에 누군가가 이미 수행한 세부 사항에 들어가지 않고도 문제 없이 유사한 작업을 구성할 수도 있습니다.
그리고 수업은 어떻습니까? 이것은 동적 또는 정적 배열과 함께 작동하며 동적 배열을 사용하는 위치는 중요하지 않습니다. 클래스 또는 변수
자, 그럼 더 간단한 질문을 하겠습니다. 1차원 배열과 2차원 배열의 변수에 접근할 때 연산의 수를 비교합니다.
그리고 이제 거의 차이가 없다고 주장할 것입니까?
자, 그럼 더 간단한 질문을 하겠습니다. 1차원 배열과 2차원 배열의 변수에 접근할 때 연산의 수를 비교합니다.
그리고 이제 거의 차이가 없다고 주장할 것입니까?
이것도 OOP 질문인가요?
그렇지 않은 경우: 배열이 정적이면 1차원 배열 또는 2차원 배열에 액세스할 때 성능에 차이가 없습니다.다차원 배열의 데이터는 대략 배열 x[20]과 배열 y[2][10]가 있는 것처럼 메모리에 한 줄씩 저장되며, 데이터 y는 메모리에 기록됩니다. 첫 번째 y[0 ] 그런 다음 y[1], x[20]처럼 물리적으로 위치합니다.
약간의 성능 지연이 있는 경우에는 너무 미미하며 범위를 벗어난 배열의 제어로 인해 발생할 수 있습니다.
배열이 동적인 경우 - 특정 컴파일러 제조업체에 따라 다릅니다. - 메모리 관리자 코드가 얼마나 최적화되었는지(델파이에서는 대부분의 시스템 모듈이 ASM으로 작성됨) 다차원 동적 배열에 대한 메모리 할당이 조금 더 복잡하기 때문에 , 그러나 여기에서 일반적으로 문제는 동적 배열에 있는 것이 아니라 프로그래머에게 있습니다. 정당화되고 종종 동적 배열에 대한 메모리 재할당을 유발하는 한
추신: 의사 소통에 감사드립니다. 그러나 기본적인 사항에 대한 오해에 많은 시간을 할애 할 수 없습니다. 스스로 읽기 시작하십시오.
이것도 OOP 질문인가요?
그렇지 않은 경우: 배열이 정적이면 1차원 배열 또는 2차원 배열에 액세스할 때 성능에 차이가 없습니다. 다차원 배열의 데이터는 대략 배열 x[20]과 배열 y[2][10]가 있는 것처럼 메모리에 한 줄씩 저장되며, 데이터 y는 메모리에 기록됩니다. 첫 번째 y[0 ] 그런 다음 y[1], 물리적으로 x[20]과 같이 위치합니다.
가장 단순한 것을 모르기 때문에 착각하는 것입니다.
모든 배열의 데이터는 메모리에 선형으로 위치합니다. 처음부터 마지막까지 요소 x[15]를 참조하기 위해 이 변수를 계산하려면 배열의 시작 주소에 변수의 주소가 될 오프셋 15를 더한 값을 계산해야 합니다. . 2차원 배열(예: x[2][5])의 경우 먼저 두 번째 행에 대한 오프셋을 계산한 다음 여기에 다섯 번째 요소에 대한 오프셋을 추가해야 합니다. 즉, 두 배의 연산이 필요합니다.