Re: Naming structs with a variable

Chris Nahr <christoph.nahr@xxxxxxxxxxxxx> wrote:
I wouldn't even say that though. If you have two types which each have
20 instance fields (all ints for the sake of argument). The only
difference between them is that one is a class and one is a struct. You
need to use these types as parameters and return values frequently. Now
which feels like a heavyweight type and which feels lighter?

Practical experience with a given struct has no bearing on what I
said. Structs exist for the purpose of being more lightweight than
classes, and that purpose is reflected in their implementation.

Except when you use them as parameters, return values, or use
assignment.

I would agree if you'd just said that structs are lighter weight
allocation and release, and can use less memory when a single value is
only used in one place. However, just calling them "lightweight
classes" implies (to me at least) that they're lighter *in general*
which clearly isn't true in reality. There are plenty of ways in which
using them is "heavier" than using classes, so the generalisation isn't
accurate IMO.

Where exactly is "lightweight class" defined in the first place? It's
not in the C# spec as far as I'm aware - the C# spec gives details
instead of relying on inappropriately brief descriptions.

First, a literal reference from an authoritative source:

MSDN Library, "C# Programming Guide":
"A struct can be considered a lightweight class, ideal for creating
data types that store small amounts of data, and does not represent a
type that might later be extended via inheritance."
http://msdn2.microsoft.com/en-us/library/ms173109.aspx

Are, MSDN - that authoritative source which claimed for a long time
that System.Decimal was a fixed-point number type.

It's even wrong about saying its "ideal for creating data types that
store small amounts of data" - again, that ignores the whole value
semantics vs reference semantics which is surely at the heart of the
differences between structs and classes. If you want reference
semantics, you should use classes even if there's only a small amount
of data.

Interestingly, C++/CLI uses the keywords "value class" as opposed to
"ref class" = reference type.

The CLI spec uses different terminology for various things. This
shouldn't come as much of a surprise, although it occasionally causes a
lot of confusion.

<snip>

And here are a number of references that call structs "lightweight"
although they avoid the term "class" since it's already used as a
synonym for "reference type" in the context of the explanation:

<snip>

I could give plenty of examples of early Java textbooks which claimed
that Java passed objects by reference - that wouldn't make them any
less confusing or any more accurate.

So I hope we can agree that structs are, in fact, commonly introduced
as lightweight types in the literature. The motivation is in fact to
have a type that is less expensive than a reference type.

I agree that they're commonly introduced as lightweight types. Now, do
you want me to find you a similar number of posts from people who have
been confused by that terminology? Just because lots of people use a
certain description doesn't make it accurate or useful. Heck, lots of
people talk about ASCII as if it had 256 characters in it. Are they
right too, just because there are lots of them?

I don't think it's particularly helpful to use terminology which you
*know* causes confusion on the grounds that people should learn more
about the subject so as to avoid being confused. We get the situation
where there are two types of reader: those who don't already know what
a struct is (who will be confused by your description) and those who do
(who won't gain anything by your description). Where exactly is the
benefit?

Like the cited authors, I don't share your opinion that readers who
don't already know about structs will invariably be confused about the
"lightweight" moniker. Again, I think it's accurate and helpful.

It's accurate when the "lightweight" bit is qualified to allocation.
It's possibly helpful when it's in the context of a wider description.
On newsgroups, however, it's often left as the *whole* of the
description of structs, which is what I really object to.

When I was learning C# I found this characterisation appropriate and
useful in forming a mental concept of the purpose and implementation
of structs. The copy-on-pass semantics are always highlighted in the
vicinity of such an introduction, so I never had a problem with that.

No, those semantics *aren't* always highlighted - that's the problem.
Often structs are *just* described as "lightweight classes", and that's
where people get confused.

Frankly, I don't see why we should give any regard to people who run
off and implement something (badly) after seeing a single adjective-
noun pair, as if that would explain everything! Of course it doesn't,
but what kind of programmer would assume that it does?

So you're happy to confuse people by using an overly simplistic
description, knowing that some people *will* take that as sufficient
evidence to base decisions on? I prefer to do my utmost to make sure I
won't leave people with the wrong impression.

--
Jon Skeet - <skeet@xxxxxxxxx>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
.

Relevant Pages

  • Re: Structs vs. Classes
    ... Classes are created on heap while structs are created on stack. ... different from "Bob Smith, customer #1234". ... reference to that customer in your entire program see that change. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Naming structs with a variable
    ... elaborate explanations I'd rather they crash and burn with their hasty ... Smaller structs may be less expensive, ... the term "lightweight" already implies that this construct is ...
    (microsoft.public.dotnet.languages.csharp)
  • Beware CS1612 when dealing with "Point" (its not really a structure like most of us think of)
    ... modify a Point, which I had made have a property. ... like 'int' or 'nullable' types, and does not really have 'member ... allow you to return a reference to a value type. ... The only issue I have with the way that structs are implemented ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Naming structs with a variable
    ... assignment. ... Smaller structs may be less expensive, ... the term "lightweight" already implies that this construct is ... newsgroup posts that fail to highlight the quirks and costs of ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Reference to a struct inside its definition
    ... But the more general issue here is that you've got a data type that you expect to be stored as a reference on a regular basis, making it more appropriate as a reference type than a value type. ... Generally speaking, classes are reference types, while structs and primitive types are value types. ... If you assign a value type to a variable that's of type object, or pass it as a parameter of type object, etc. the compiler will generate code that creates an object instance that contains the value type you've used. ... If you box the same value instance multiple times, you get multiple instances, each with a new copy of the value type. ...
    (microsoft.public.dotnet.languages.csharp)
Loading