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

새 코멘트
 
Alexey Navoykov :

그리고 나는 이것을 할 것입니다 :

저는 이런 스타일이 불편합니다. 저것들. 우리는 모든 것을 "펠트 펜"으로 줄입니다.

 
fxsaber :

그래서 여전히 경고가 필요합니까? 어떤 종류의 이중 잣대: 두 곳 모두에서 행동이 모호하지 않지만 대괄호를 사용하면 경고에 반대하지만 여기 - FOR?

또한 미묘한 실수를 하지 않도록 경고도 필요합니다. 따라서 난이도는 주관적인 평가입니다. 여기 대괄호를 사용하면 실수하지 않지만 여기서는 할 수 있습니다. 그리고 저에게는 그 반대입니다.

그렇다면 경고 발령 규칙을 조정해야 하는 사람은 누구입니까?

당신은 정말로 요점을 이해하지 못하는 것 같습니다. 동적 캐스팅은 항상 EXPLICIT 전용 작업이어야 합니다. 모든 일반 언어, C ++, C #, Java, 심지어 다른 OOP 언어조차도 그러한 코드는 컴파일되지 않습니다. 이것이 신뢰할 수 있는 OOP의 기반입니다. 그러나 여기에서 그들은 웬일인지 잊어 버렸습니다. 대괄호와 비교하는 것이 여기에서 적절할 것이라고는 생각하지 않았습니다.

 
Alexey Navoykov :

신뢰할 수 있는 OOP의 기반이 됩니다.

기본은 독창성입니다.

 
Ilya Malev :

(표준 라이브러리를 사용하지 않지만) 참조로 코드의 요점을 볼 수 없습니다. 배열에 개체를 배치하는 데 복사본 생성이 포함되는 경우 이 클래스에서 할당 메서드 또는 복사 생성자를 명시적으로 선언하고 설명해야 합니다. 그렇지 않으면 래퍼가 도움이 되지 않습니다. 배열의 객체에 대한 참조만 넣어야 하는 경우 래퍼가 필요하지 않습니다(갑자기 왜?)

그러한 배열은 무엇을 위한 것입니까? 결국 이것은 더하기 벡터와 거의 유사하며 vector<int>, vector<class_name>, vector<class_name*>과 같이 작동해야 합니다. µl을 사용하여 래퍼 없이 구현할 수 있다면 - 잘한 일입니다(나는 당신이 할 수 없다고 생각합니다). 배열을 반복하고 소멸자( _data[i].~Destr() )를 호출할 수 있는 방법이 없으며 부분적인 특수화도 없고 SFINAE 트릭도 없습니다. 그리고 그러한 래퍼를 사용하면 예를 들어 vector<int>로 작업하는 기능을 중단하지 않고 힙의 개체에 대한 포인터에 적합한 배열을 만들 수 있습니다.

vector<unique_ptr<my_class>> v1;

vector<my_class> v2;

vector<int> v3;

추신: 내가 말할 수 있는 것은, vector<class_name*>이(가) 플러스(벡터 수명이 끝날 때 소멸자를 호출함)에서도 예상대로 작동하지 않으며 래퍼도 필요합니다.
 
pavlick_ :

추신: 내가 말할 수 있는 것은, vector<class_name*>은(는) 플러스(벡터 수명이 끝날 때 소멸자를 호출)에서도 예상대로 작동하지 않으며 래퍼도 필요합니다.

괜찮아? )

 template < typename T>
void del(T par){ printf ( "%s не удаляем" , typename (T));}

template < typename T>
void del(T *par){ printf ( "%s удаляем" , typename (T)); delete par;}

class A{ public : void ~A( void ){ printf ( "удаляем %i" ,& this );}};

void OnStart ()
 {
   int var1;
  A *var2= new A;
  del(var1);
  del(var2);
 }

추신 유추하면 void 대신 함수가 무엇이든 반환할 수 있으며 SFINAE가 필요하지 않습니다.

 
네, 그럴 것입니다. 하지만 래퍼는 여전히 필요합니다. 결국 범용 배열이 필요합니다. 즉, 삭제해야 할 포인터가 있을 때도 있고 그렇지 않을 때도 있습니다(바보 같은 포인터 집합은 다른 배열에서 무언가를 검색한 결과입니다. 정렬).
 
pavlick_ :

플러스 측면에서 void*를 제거하는 것은 UB입니다.

그건 그렇고, 나는 전에 그것에 대해 생각조차하지 못했습니다. 팁 주셔서 감사합니다. 이 경우 삭제는 free()와 유사합니다. 좋은 점은 이것이 금지되어야 합니다. 결국, 삭제는 객체에 대해 특별히 배치되며 여기서 메모리는 규칙을 우회하여 간단히 해제됩니다.

이제 MQL에서도 이것을 고려할 것입니다. 여기서 소멸자가 호출되지만 코드를 C++로 이식하면 문제가 발생할 수 있습니다.

 
pavlick_ :
네, 그럴 것입니다. 하지만 래퍼는 여전히 필요합니다. 결국 범용 배열이 필요합니다. 즉, 삭제해야 할 포인터가 있을 때도 있고 그렇지 않을 때도 있습니다(바보 같은 포인터 집합은 다른 배열에서 무언가를 검색한 결과입니다. 정렬).

음, 배열을 생성할 때 추가 옵션을 전달하는 것을 금지하는 사람은 아무도 없습니다. 삭제 여부와 관계없이 요소를 삭제하고 기본적으로 (취향에 따라) 켜거나 끌 필요가 있습니다. 그리고 결국, 당신이 그것을 삭제할 필요가 있는지 여부를 추측하지 않을 것입니다.))

추신 그건 그렇고, 포인터를 배열에 배치하기 전에 "래퍼"로 포인터를 래핑한다는 사실에서 배열을 삭제할 때 기본 개체를 삭제할 필요가 있는지 여부에 대한 질문은 어떤 식 으로든 지워지지 않습니다))
 
fxsaber :

추가하다. 괄호는 언어 우선 순위의 영향을 완전히 제거했습니다. 모든 것이 완전히 명확해집니다. 덕분에 100% 신뢰성이 나타나며 다음 빌드 후에 이 위치에서 아무 것도 깨지지 않을 것입니다.

이를 염두에 두고 요약하자면 다음과 같습니다.


A100
 개발자
 fxsaber
괄호
 필수 불가결한 경우에만 필요
 MQL4의 이전 버전과 다른 경우에도 필요할 수 있습니다.
 어디에나 필요한
불필요한 경고
 필요하지 않음
 MQL4에서 이전과 다른 경우에만 필요합니다.
 어디에나 필요한
우선 순위
 필요한
 필요한
 원칙적으로 필요하지 않음(대괄호로 대체되기 때문에)

내가 잘못 기술했다면 - 정정해 주세요 - 괄호에 관한 경고가 필요한 곳에 제 개념을 간략하고 명확하게 명시했습니다.

 
Ilya Malev :

음, 배열을 생성할 때 추가 옵션을 전달하는 것을 금지하는 사람은 아무도 없습니다. 삭제 여부와 관계없이 요소를 삭제하고 기본적으로 (취향에 따라) 켜거나 끌 필요가 있습니다. 그리고 결국, 당신이 그것을 삭제할 필요가 있는지 여부를 추측하지 않을 것입니다.))

일반적으로 예, 할 수 있습니다.

추신 그건 그렇고, 포인터를 배열에 배치하기 전에 "래퍼"로 포인터를 래핑한다는 사실에서 배열을 삭제할 때 기본 개체를 삭제할 필요가 있는지 여부에 대한 질문은 어떤 식 으로든 지워지지 않습니다))


래퍼가 없으면 삭제되지 않고 래퍼가 있으면 삭제되며 모든 것이 매우 깨끗합니다.

추신: 하지만 그렇게 했다면 표준 플러스 라이브러리(이름, 동작 등)와 최대한 비슷하게 했을 것이므로 선택의 여지가 없습니다. 모든 것이 이미 작성되어 있는데 왜 다른 사양을 생성합니까?

1234567891011121314...20
새 코멘트