static inline delegates

[Salcalitarhana]

I’ve set up a system using static delegates to automatically register an ASpline actor to a list in a subsystem (a spline manager).

DECLARE_MULTICAST_DELEGATE_OneParam(FOnSplineInitialized, ASpline*);

UCLASS(Blueprintable, ClassGroup=(Custom), meta=(BlueprintSpawnableComponent))
class COUNTERSTRIKE55_API ASpline : public AActor
...
	static inline FOnSplineInitialized OnSplineInitialized;

and my spline manager has:

void USplineManager::Initialize(FSubsystemCollectionBase& Collection)
{
	Super::Initialize(Collection);
	ASpline::GetOnSplineInitialized().AddUObject(this, &USplineManager::AddStartingSpline);
}

I broadcast this delegate in the PostInitialize of ASpline, ensuring that every spline registers itself with the spline manager. However, some AI tools have warned me against using static delegates, citing garbage collection issues and other potential pitfalls. Is this approach wrong?

[MagForceSeven]

It’s one of those cases where they’re not entirely wrong or right. Yes there would be issues with GC, but the delegates handle those cases and there are plenty of static delegates throughout the engine so it shouldn’t be a huge worry.

@Salcalitarhana

Is this approach wrong?

Hard to say. Is the Spline Manager the only thing that’s going to register with that delegate? The Actor and Manager feel like two parts of a whole and so I wouldn’t see any problem with your ASpline calling into USplineManager directly instead of trying using a delegate as an intermediary. Either way they are coupled, it just depends on which direction that dependency needs to go.

[Salcalitarhana]

Spline manager is the only thing binded to that delegate for now. I wanted to make sure it wouldn’t break the game.

[SupportiveEntity]

Hey there @Salcalitarhana! Garbage collection is a legitimate concern if you plan to be working with lots of splines over longer play sessions, but I’d assume the scale would have to be rather extreme for it to matter. I agree with Mag that it’s most likely fine.