The ugliness of properties in structs

[GoogleCodeExporter]

I'm currently in the process of porting my Engine to DX11 and have to rant 
about something that really annoys me: Properties in structs! Especially in 
those *Description structs so common in DX11.
Properties in structs aren't very desireable for several reasons. For example 
performance-wise, as you already noticed when you (thankfully) removed the 
properties from the Vector* types and just made the fields public.
But there is a situation where properties in structs even turn into PURE 
UGLINESS: This is the case if structs contain others structs, just as those 
*Description structs often do.
Let's take a little example. You've got a SwapChainDescription called "swap" 
that is filled with some values. Now you want to change the Width of the mode. 
How would out do it? swap.ModeDescription.Width = 800  ? No, you don't! 
ModeDescription is a property and returns a _copy_ of the internal struct, thus 
you set the Width of the copied struct which afterwards dissipates into 
nothingness. The Width of the ModeDescription in swap hasn't changed at all. 
crap. Only way to get this done is to assign the copied struct returned by the 
ModeDescription property to a local variable, change the Width of it, and 
afterwards write the whole struct back to the property. Thats slow. And ugly.
Another point: Even if you want to read just one single value of the 
ModeDescription the whole struct gets returned by the property. If you just 
want to read the Width of a RenderTarget, the SwapChainDescription gets copied 
and retured (including all contained structs) and then the whole 
ModeDescription struct gets copied and returned a second time. At least the 
second copy is absolutely unnecessary.
Sure, the *Description structs aren't as performance critical as Vector3 or 
something, but it still is an annoyance. My intention was to directly use 
*Description structs in constructors of my engine objects, but as it is right 
now i'll have to wrap them up (again) because i'm too much of a perfectionist 
to live with such ugliness. :/ 
Oh well, i hope you'll reconsider and use public fields instead in future 
releases of SlimDX.

Original issue reported on code.google.com by hazar...@gmx.net on 22 Aug 2010 at 11:09

[GoogleCodeExporter]

We currently use classes in SlimDX 2. I'm not sure the change you're asking for 
is something we'd do for the current version at this point.

Original comment by josh.petrie on 23 Aug 2010 at 4:01

[GoogleCodeExporter]

Original comment by josh.petrie on 28 Aug 2010 at 3:15

• Changed state: Accepted
• Added labels: Priority-Whenever, V2
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I don't see a reason to keep this open. We won't be modifying the current 
source to make such a drastic change, and we'll be carefully reexamining the 
use of structs and classes in V2 already.

Original comment by Mike.Popoloski on 30 Aug 2010 at 3:49

• Changed state: WontFix