Q. Does the UPROPERTY macro have any benefit for things that don't need it?
08-11-2017, 11:04 AM
I've heard vaguely that things declared to be UPROPERTY can be handled by the engine's garbage collector, but I'm having trouble understanding the practical application.
If I have a variable that is only used on the C++ side, do I gain anything from making it a UPROPERTY? Does the answer change if it's a pointer?
UPROPERTY 매크로는 필요하지 않은 것에 이점이 있습니까?
UPROPERTY로 선언 된 것들이 엔진의 가비지 컬렉터에 의해 처리 될 수 있다고 막연하게 들었지만 실용적인 응용 프로그램을 이해하는 데 문제가 있습니다. C++ 측에서만 사용되는 변수가 있으면 그것을 UPROPERTY로 만드는 것으로부터 무엇을 얻을 수 있습니까? 포인터인 경우 대답이 변경됩니까?
A.
08-11-2017, 11:49 AM
Yep, aside the fact that UPROPERTIES has a lot of configs for your variables including network capabilities, also special functionality between your classes and the editor, some pointers lives forever if you don't take care in your code, making those UPROPERTIES is a easy way to handle that. You might take a look of the documentation, there is a lot of stuff you can do with metadata.
네, UPROPERTIES에는 네트워크 기능, 클래스와 편집기 사이의 특수 기능을 포함하여 변수에 대한 많은 설정이 있다는 점 외에도 코드에서주의를 기울이지 않으면 영원히 살 수있는 포인터가있어서 UPROPERTIES는 쉽습니다. 그걸 처리하는 방법. 설명서를 살펴보면 메타 데이터로 수행 할 수있는 많은 작업이 있습니다.
1 cool example I have in mind right now:
내가 지금 염두에 둔 멋진 1 가지 예 :
UPROPERTY(EditAnywhere, Category = "IDS", Meta = (InlineEditConditionToggle, MakeEditWidget = true))
uint32 bOverrideLightMapRes : 1;
UPROPERTY(EditAnywhere, BlueprintReadOnly, Category = Lighting, meta = (ClampMax = 4096, EditCondition = "bOverrideLightMapRes"))
int32 OverriddenLightMapRes = 64;
I did this when I created a new static mesh component, and I wanted to override the light map resolution, this allow me modify my int based on my bool, like a toogle, there is a lot of examples like this, UPROPERTIES are very useful
나는 새로운 스태틱 메시 컴포넌트를 만들었을 때 이것을했다. 라이트 맵의 해상도를 오버라이드하고 싶다. 이것은 내 부울을 기반으로 내 int를 수정할 수있게 해준다. 예를 들어, 이처럼 많은 예제가있다. UPROPERTIES는 매우 유용하다.
UHT will generate a bit more code (insignificant increase in executable size) and that will translate to a very slight increase in runtime memory allocation for the associated entry in the reflection data structures (again, insignificant).
UHT는 조금 더 많은 코드 (실행 파일 크기에서 무시할 수 있는 증가)를 생성 할 것이고, 이는 Reflection 데이터 구조에서 관련된 엔트리에 대한 런타임 메모리 할당이 약간 증가하는 것으로 해석 될 것입니다 (다시, 중요하지 않음).
The main thing to be aware of is that if you make something UPROPERTY() without any specifiers, then it will default to being serialized. So if the property is on an actor or asset class, you're adding a bit of processing time and storage space usage. It would rarely make sense for something to be serialized if not editable though anyway.
중요한 점은 지정자없이 UPROPERTY ()를 작성하면 기본적으로 직렬화됩니다. 따라서 속성이 액터 나 자산 클래스에 있으면 처리 시간과 저장 공간 사용량이 약간 늘어납니다. 어쨌든 편집 할 수없는 경우에는 직렬화 할 내용이 거의 없습니다.
Anyway, if there's no reflection functionality you need, then just don't make it a UPROPERTY. There's nothing wrong with using non-reflected variables.
어쨌든, 당신이 필요로하는 반영 기능이 없다면, 단지 그것을 UPROPERTY로 만들지 마십시오. 반영되지 않은 변수를 사용할 때 아무 문제가 없습니다.
내린 결론 : 포인터를 사용하거나 메타데이가 필요한 변수가 아니라면 굳이 UPROPERTY 매크로를 쓰지 않아도 좋다.