템플릿 매개변수가 있는 컴파일러 버그 = void* - 페이지 18

새 코멘트
 
Igor Makanu :

나에게 지금 평범한 작업은 .dll의 VS를 우아한 방식으로 MT5로 고정하고 싶습니다.)) - 클래스의 버튼 클릭 핸들러를 래핑하고 포인터 배열을 우회하여 호출하고 싶습니다. 핸들러 함수, 그리고 VS에서와 같이 기본 EA 코드에서 이름 f를 일대일로 쓰는 기능을 얻고 싶습니다. button2_Click() ....button2_Click()

추신: EOP 영역의 작업)))

실례가 되지는 않았지만 많은 생각을 하게 했습니다.


하나
 
Ilya Malev :

- 동적 OOP 내에서 자동 구조 생성은 넌센스

저것들. 스택 객체: myclass obj; - 넌센스? 그래서 저는 핸디맨입니다 :)

 
pavlick_ :

저것들. 스택 객체: myclass obj; - 넌센스? 그래서 저는 핸디맨입니다 :)

작업이 다릅니다. 오랫동안 수사학을 연습 할 수 있습니다. 특정 작업을 설명하지 않으면 무엇이든 올 수 있습니다 ...

예, "스택"(자동을 의미합니까?) 객체는 대부분 말도 안됩니다. 내 겸손한 의견으로는 결코 진실이 아니며 최후의 수단으로는 더욱 그렇습니다 ...
 
광대는 OOP의 주요 기능을 수행하지 않는 개체가 필요합니다 - 다형성 의 속성? 내용에 따라 다른 속성을 갖는 이러한 변수에는 어떤 개체도 할당하지 않습니다. 목록의 이 "변수"를 다른 개체와 일치시킬 수 없습니다. 그렇다면 일반적으로 객체가 필요한데 구조에 국한되는 것이 더 나을 수 있습니까? µl의 구조가 자신에 대한 참조를 반환할 수 없기 때문에 ... 그리고 그들과 함께 지속적인 생성-파괴-자체 복사 등으로 어두운 찌꺼기가 시작됩니다.
 
Ilya Malev :
광대는 OOP의 주요 기능을 수행하지 않는 개체가 필요합니다 - 다형성 의 속성? 내용에 따라 속성이 다른 개체를 이러한 변수에 할당하지 않습니다. 목록의 이 "변수"를 다른 개체와 일치시킬 수 없습니다. 그렇다면 일반적으로 객체가 필요한데 구조에 국한되는 것이 더 나을 수 있습니까? µl의 구조가 자신에 대한 참조를 반환할 수 없기 때문에 ... 그리고 그들과 함께 지속적인 생성-파괴-자체 복사 등으로 어두운 찌꺼기가 시작됩니다.

다형성 없이 사는 법 ... 그리고 90% 이상의 경우에서 다형성이 생략될 수 있다고 말하면? 여기에서 "SOLID 종속성 반전 원칙"을 취하면 우리가 괜찮은 프로그래머라면 모든 곳에서 추상화, 가상 메서드(물론 높은 오버헤드를 수반함)를 만들어야 한다고 말합니다. C# 숙련자는 https://pro-prof.com/forums/topic/dependency-inversion-principle 과 같이 작성합니다. 또는 템플릿을 사용하여 다음과 같이 작성할 수 있습니다.

class Lamp {
public:
    void activate();
    void deactivate();
};
template <typename T>
class Button {
    Button(T& switchable)
        : _switchable(&switchable) {
    }
    void toggle() {
        if (_buttonIsInOnPosition) {
            _switchable->deactivate();
            _buttonIsInOnPosition = false;
        } else {
            _switchable->activate();
            _buttonIsInOnPosition = true;
        }     
    }
private:
   bool _buttonIsInOnPosition{false};
   T* _switchable; 
}
int main() {
   Lamp l;
   Button<Lamp> b(l)

   b.toggle();
}


버튼은 또한 다형성 및 인터페이스 없이 세부 사항에 의존하지 않습니다. 다형성에는 자체 틈새 시장이 있지만 그들이 말하는 것보다 훨씬 좁습니다.

추신: 글쎄요, 아무도 금지하지 않습니다. 

derived1 obj1;
baseclass *p1 = &obj1;
derived2 obj2;
baseclass *p2 = &obj2;
pass_through_generalized_algoritm(p1);
pass_through_generalized_algoritm(p2);
 
물론 다형성 없이는 할 수 있습니다. 이 경우에만 단순한 구조 를 사용하는 것이 훨씬 더 정직하고 논리적입니다. 물체가 아닌 경우에는 현미경으로 못을 망치질합니다. 보다 정확하게는 μl5의 경우 비객체 구조의 전체 사용을 허용하지 않는 "구현 기능"을 우회합니다(객체와 달리 해당 구조에 대한 포인터 전달 불가능). 이것은 완전히 다른 작업이며 더 이상 OOP가 아니라 OP입니다.
 
pavlick_ :

추신: 글쎄요, 아무도 금지하지 않습니다.

모든 종류의 목발과 계획이 나오는 것을 금지하는 사람은 아무도 없습니다. 그런데 그 이유는 무엇입니까? 예를 들어, 당신의 자동차 객체가 당신이 전혀 예상하지 못한 순간에 갑자기 나타나 스스로 파괴된다면 재미있을 것입니다. 그렇죠?

 
OOP의 요점은 템플릿이나 함수 포인터를 통해 구현할 수 있는 버튼을 누르는 선택한 방법을 사용하는 것이 아니라 목록과 같은 방법을 시스템 개체에 적용하여 스스로 구성할 수 있도록 하는 것입니다. 구조를 나열하고 CArrayObj 등과 같은 목발 없이 적시에 임의의 선택 항목을 만듭니다. Select, Query, Compare, Sort 등과 같은 오버로딩 방법을 통한 관련 치질 (예, 동일한 복제/복사일지라도 각 개체가 귀하의 참여 없이 목록/배열에 배치하기 위해 복사해야 하는지 여부를 결정할 수 있을 때, 그리고 복사된다면 어떻게)
 
Ilya Malev :

모든 종류의 목발과 계획이 나오는 것을 금지하는 사람은 아무도 없습니다. 그런데 그 이유는 무엇입니까? 예를 들어, 당신의 자동차 객체가 당신이 전혀 예상하지 못한 순간에 갑자기 나타나 스스로 파괴된다면 재미있을 것입니다. 그렇죠?

그런 다음 스택 개체가 힙( 메모리 할당 )의 개체보다 훨씬 빠릅니다. 자폭? - 이것은 새로운 것입니다 :). 그러나 때로는 필요합니다. 예를 들어 개체 수는 런타임에만 알 수 있습니다.

추신: 그렇지 않으면 더 편안할 수 있습니다. 개인적인 문제입니다.

 
Ilya Malev :
OOP의 요점은 템플릿이나 함수 포인터를 통해 구현할 수 있는 버튼을 누르는 선택한 방법을 사용하는 것이 아니라 목록과 같은 방법을 시스템 개체에 적용하여 스스로 구성할 수 있도록 하는 것입니다. 구조를 나열하고 CArrayObj 등과 같은 목발 없이 적시에 임의의 선택을 생성합니다. Select, Query, Compare, Sort 등과 같은 오버로딩 방법을 통한 관련 치질 (예, 동일한 복제/복사일지라도 각 개체가 귀하의 참여 없이 목록/배열에 배치하기 위해 복사해야 하는지 여부를 결정할 수 있을 때, 그리고 복사된다면 어떻게)

나는 썼습니다- 다형성 에는 자체 틈새가 있습니다. 나는 논쟁하지 않습니다. 그러나 연습은 그것이 그렇게 중요하지 않다는 것을 보여줍니다(최소한 개인적으로 내 것입니다). 템플릿 문제를 훨씬 더 자주 해결합니다.

1...11121314151617181920
새 코멘트