Boxing warning Follow
Hi!
Just started using Ryder for Unity3D dev, so far very happy.
One question - I'm getting a red-underline warning for naive string concat with a long along the lines of...
String foo = "my string" + longValue;
...with the tip "Boxing allocation: conversion from value type 'long' to reference type 'object'". My guess is there are a couple of recommendations for this sort of thing, maybe something along the lines of a printf or a different kind of conversion, maybe using a static utility method somewhere?
What's the "ideal" way of doing this in Unity3D/C#?
Thanks,
-Will
P.S. Visual Studio Code didn't complain about this, and I'm not doing it in a performance intensive way. Only thing I found was this Unity3D blog post. https://blogs.unity3d.com/2016/08/11/il2cpp-optimizations-avoid-boxing/ - so part of why I'm posting here is because Ryder is the first place I'm seeing the advice. Red-underline no less! ;)
Please sign in to leave a comment.
Yup, it (was) installed. I just went ahead and turned it off for now.
Is there a preferred way to do the conversion in C# to avoid boxing?
Also, I have no idea why I thought it was spelled Ryder and not Rider. Did it used to be called Ryder?
Hello,
You can avoid boxing in this case by explicitly calling .ToString() on the value type. Using earlier example:
String foo = "my string" + longValue.ToString();
Note that code analysis will suggest removing the redundant .ToString() call. This is a known issue you can track and vote for here.
Let me know if this helps.
Hi William,
Thank you for the request,
Could you please check if Heap Allocations Viewer plugin is disabled (File | Settings | Plugins -> Installed).
I have the same problem :/ Any help JetBrains?
Same or at least similar problem when implementing interfaces or abstract classes (i.e.MarkupExtension) with methods returning type object. Return type can't be changed because the definition is part of the framework. Having a value type in the effective implementation, what would you suggest as the correct way of implementation or at least how can I prevent the warning, except by deactivating the Heap-Allocation-Viewer plugin? Would be nice, if a suggested solution wouldn't result in another warning or hint, that suggest removing the workaround (little bit of topic but because of the note by Kirill Filin: there are quite some of these hints, suggesting a 'better' solution that result in another hint suggesting something else which (probably after some more steps) result in the initial way of implementation, on which we got the first hint.)
Hi A Schloss!
Could you please add some code samples/screenshots/screencast or sample project on how it works on your side and what do you expect?
Thank you in advance.
Hi Alexandra Guk,
Sorry, didn't thought it could be difficult to image a use case. Would have supplied one right away, otherwise. So here is a very simple one:
Imagine you want to provide a value converter for use in a WPF binding. That converter should convert between values of an enum type and, let's say, boolean values (just like the well known BooleanToVisibilityConverter does). It could look like this:
Because the interface defines the return types as object, your implementation must adhere to that. So the question is, how prevent a warning in this case?
Hope, this made it a little bit more understandable.
Hi A Schloss!
Thank you for the sample code. You can disable this warning for a current case.
However, the best way is to report this issue directly to the Plugins Developers on Github.