Share via

The Value of a Value Class

  • Article

A reader questions the nature of the value type when he writes,

 

Sender: Slawomir Lisznianski
=====================================
1) Lack of support for SMFs makes value classes unnatural to use. An example in the C++/CLI spec at page 33 is incorrect, as it uses constructors with value classes. In fact, quite a few value class examples in the specification contradict with paragraph 21.4.1.

SMF, for the uninitiated, means special member functions, and in this case refers to the constraint on a value class that it cannot declare a default constructor, copy constructor, copy assignment operator, or destructor.

 

Mechanically, the reason these special member functions are not supported, I am told, is because there exists conditions during run-time in which it is not possible for the compiler to insert the appropriate invocations, and thus it is not possible to guarantee the semantics associated with these member functions. And so their support has been withdrawn completely. I suspect that the examples were written before the withdrawal of the default constructor, and the authors of the spec simply overlooked removing them.

 

There are a number of negative responses one can have to this: Disbelief, disgust, savage anger are a few that come to mind.

 

Another way of looking at this is to consider the why and when these special member functions are not required.  We do not need a copy constructor nor a copy operator when the aggregate type supports bitwise copy. Similarly, we do not need a destructor when the state of the aggregate type exhibits value semantics. Finally, if the runtime zeros out all state by default, then we do not require a default constructor. (In C++, primitive data types are not automatically zeroed out, and so most of our default constructor use – but granted, not all – is used to put the object in an uninitialized state.)

 

That is, a value type in the philosophy of the CLI unified type system is a blitable entity with no internal plumbing, so to speak. That is all it naturally supports.

 

You put a pointer in it, you got troubles – there are no special member functions to provide deep copy semantics or to free the resource addressed prior to the end of its lifetime. Let's not even consider attempting to declare complex member types. That's not what you do with value classes.

 

I will claim that they are not unnatural. What is unnatural, but understandable presuming that you have a C++ background, are the sophisticated uses you think to put these rather unsophisticated types. When you think value class, think integer. Then things will begin to click for you.

 

I will address your second question in a subsequent blog: So what's the rationale for trackable references ... ?

Comments

  • Anonymous
    July 24, 2004
    <Stan Lippman> When you think value class, think integer. Then things will begin to click for you. </Stan Lippman>

    Doesn't int provide any copy constructor(s)and overloaded assignment operator? The following code snippet illustrates the contrary side of the story.

    int a = 2.0; // copy ctor
    char ch = 'a';
    a = ch; // assignment

    It would be interesting to see how one can implement an int value class that behaves the exactly same way as the built-in int type.

  • Anonymous
    July 24, 2004
    no -- you're not thinking blitable, and you are not thinking value. you are thinking class, and you will be disappointed with the union ...

  • Anonymous
    July 25, 2004
    May be "value class" should change into "value blitable"? ;-)

    Well, it looks to me that the originally legitimate idea of introducing a lightweight value class met unanticipated implementation difficulties. Usage constraints were introduced and we ended up with yet another language artifact of limited value.

  • Anonymous
    July 26, 2004
    well, value types are the odd fellow out in all dynamic programming models.

    i would not agree with your characterization. the `original idea' is the CLI value type -- which is valuable when contrasted with a heap based object.

    you are looking at it from a C++ perspective, and are dissatisfied that the value class does not have x, y, and z characteristics, which you would expect in a native C++ class.

  • Anonymous
    July 26, 2004
    The comment has been removed

  • Anonymous
    July 26, 2004
    The comment has been removed

  • Anonymous
    November 25, 2007
    PingBack from http://feeds.maxblog.eu/item_1128423.html

  • Anonymous
    November 25, 2007
    PingBack from http://feeds.maxblog.eu/item_1230810.html

  • Anonymous
    June 15, 2009
    PingBack from http://einternetmarketingtools.info/story.php?id=22241