Weblogs Forum - The Temporary Assignment Problem and Transfer Semantics

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
The Temporary Assignment Problem and Transfer Semantics

12 replies on 1 page. Most recent reply: Sep 30, 2005 12:33 PM by Terje Slettebø

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 12 replies on 1 page

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

The Temporary Assignment Problem and Transfer Semantics (View in Weblogs)

Posted: Aug 30, 2005 11:24 AM

Reply

Summary
In languages like C++, functions return temporary stack allocated values which can be very inefficient. I am using a technique on Heron which I call transfer semantics to provide a work-around.

Advertisement

In Heron and C++ functions return stack allocated temporary values. This means that code like the following ends up being suboptimal:

class MyBigClass 
{
  public 
  {
    // the overloaded = operator
    _eq(self x) 
    {
      delete(m);
      m = new OtherBigClass(x.m);
    }
  }
  fields 
  {
    OtherBigClass^ m; // owner pointer
  }
}

f() : MyBigClass {
  ...
}

g()
{
  MyBigClass x;
  x = f(); // inefficient
}

In Heron return values from a function are a special kind of template called a temporary<T>. This means I can instead write an optimized assign for when assigning from function results which would like the following:

    // = operator, overloaded for temporaries
    _eq(temporary<self> x) 
    {
      delete(m);
      transfer(m, x.m);
    }

The temporary<T> type will behave exactly like T, it simply identifies the value as a temporary so the programmer can write more intelligent code. I call this transfer semantics, but I might be misuing the term. Any thoughts on the approach and terminology?

Michael Brooks

Posts: 1
Nickname: brooksm
Registered: Sep, 2004

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 30, 2005 2:35 PM

Reply

How do transfer semantics relate to the move semantics that are proposed for C++0x?

(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm)

I was baffled by this stuff at the ACCU conference this year, and might not be competent to understand your answer, but I would be interested in trying...

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 30, 2005 2:57 PM

Reply

> How do transfer semantics relate to the move semantics
> that are proposed for C++0x?
>
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1
> 377.htm)
>
> I was baffled by this stuff at the ACCU conference this
> year, and might not be competent to understand your
> answer, but I would be interested in trying...

Apparently these are just two solutions to the same problem. So "move semantics" == "transfer semantics".

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 30, 2005 3:03 PM

Reply

> How do transfer semantics relate to the move semantics
> that are proposed for C++0x?
>
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1
> 377.htm)

Apparently my solution is very close to the one by John Maddock ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm#Alternative move designs )

> I was baffled by this stuff at the ACCU conference this
> year

FWIW I think the paper is a needlessly difficult read.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 30, 2005 3:21 PM

Reply

It seems to me that stack based objects is far and away one of the really big mistakes in the design of C++. Lovely side effects of this feature involve slicing and unexpected copying of things that were never intended to be copied.

Restricting objects to the heap would vastly simplify the semantics of the language and eliminate a large number of gotchas.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 30, 2005 3:55 PM

Reply

> It seems to me that stack based objects is far and away
> one of the really big mistakes in the design of C++.

At least in C++ you have the option of using stack based objects or heap based objects. Java for instance only provides heap-based objects which is IMO a bigger mistake.

> Lovely side effects of this feature involve slicing and
> d unexpected copying of things that were never intended to
> be copied.

I agree that this is a big problem, but I think this is a symptomatic of a widespread mistake of confusing inheritance and subtyping which most OO languages do.

> Restricting objects to the heap would vastly simplify the
> semantics of the language and eliminate a large number of
> gotchas.

Yes it would, but performance takes a hit. You also lose the very powerful RAII technique.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 30, 2005 5:13 PM

Reply

> Yes it would, but performance takes a hit. You also lose
> the very powerful RAII technique.

I think C++ is one of the few languages where something like RAII would seem powerful. In other languages, there are things like closures, call with continuation, method level reflection, variable parent slots.. and people write time critical systems in those languages too.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 31, 2005 2:28 AM

Reply

> > I was baffled by this stuff at the ACCU conference this
> > year
>
> FWIW I think the paper is a needlessly difficult read.

It's a formal proposal, and they tend to be pretty... formal. :)

By the way, "rvalue references" - the essential ingredient of the "move semantics" proposal - was discussed at the Lillehammer C++ standards meeting this spring, and appears to be quite close to becoming accepted for the next version of the standard.

Regarding Todd Blanchard's critisism of stack-based objects in C++, I agree with you that it's a very important feature, and it enables you to get both efficiency _and_ elegance. In my opinion, as you said it, I think it's rather a "mistake" that Java doesn't have it (probably in an effort to get a "simple" language; same with not allowing free functions, everything having to be a class). In Java, if you want to use a user-defined type (class), you immediately take a performance hit from the heap allocation, and (unpredictable) garbage collection. Thus, you typically have to choose between efficiency and elegance. Whereas in C++, you can have as small and simple classes as you like, and they are just as efficient as built-in types.

This, treating built-in and user-defined types the same way, is one of the really nice, coherent things about C++, compared to most other languages, but I'm ranting off topic, so I'll stop. :)

Regards,

Terje

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 31, 2005 6:28 AM

Reply

> Regarding Todd Blanchard's critisism of stack-based
> objects in C++, I agree with you that it's a very
> important feature, and it enables you to get both
> efficiency _and_ elegance. In my opinion, as you said it,
> I think it's rather a "mistake" that Java doesn't have it
> (probably in an effort to get a "simple" language; same
> with not allowing free functions, everything having to be
> a class). In Java, if you want to use a user-defined type
> (class), you immediately take a performance hit from the
> heap allocation, and (unpredictable) garbage collection.
> Thus, you typically have to choose between efficiency and
> elegance. Whereas in C++, you can have as small and simple
> classes as you like, and they are just as efficient as
> built-in types.

I think if it was a problem in Java, the Java people would be complaining about it rather than the C++ people :)

> This, treating built-in and user-defined types the same
> way, is one of the really nice, coherent things about C++,
> compared to most other languages,

Maybe most languages on the C limb of the language tree.. a large number languages do treat them the same also, they make them all dynamic.

In Io, for instance, you can add a method to integers:

Number double := method(self * 2)
2 double == 4

There are quite a few statically type languages which unify built-ins and user-defined as well.

> but I'm ranting off
> topic, so I'll stop. :)

I know. I should stop too.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 31, 2005 6:44 AM

Reply

> Regarding Todd Blanchard's critisism of stack-based
> objects in C++, I agree with you that it's a very
> important feature, and it enables you to get both
> efficiency _and_ elegance.

There's an assumption there that heap based allocation is inefficient. It is in C++ because the allocation is typically malloc in the end and malloc has its issues.

There are significantly more efficient memory management strategies employed in other languages that rival C++ stack based allocation while retaining more flexibility. Such strategies come with garbage collection which can also be more efficient than manual memory management (for instance, rather than using the stack for short lived objects, using a small generational heap that can be thrown away all at once can be about as fast).

For a language claiming to be focused on efficiency, C++ has a lot of inefficient and inflexible mechanisms in it.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Aug 31, 2005 9:14 AM

Reply

> At least in C++ you have the option of using stack based
> objects or heap based objects. Java for instance only
> provides heap-based objects which is IMO a bigger mistake.

Not that it would make any difference, but I think that exposing C-like stack allocation semantics to the programmer is a mistake. It makes the language semantics significantly more complicated (possibly broken/full of nasty holes and gotchas) and it doesn't guarantee efficiency (you can easily end up copying more data - that's what semantic kludges like NRVO (and others) are for).

> Yes it would, but performance takes a hit.

A good compiler can make use of stack allocation even without exposing stack allocation semantics to the programmer. There are several compilers for modern languages that genuinely rival the efficiency of C and C++ (e.g. Stalin (Scheme), Ocaml, MLton (SML)) and the associated languages have no concept of stack allocation.

If you choose to expose nasty stack allocation semantics in your language, they will be with you forever. If you choose not to expose them, you can always improve the optimizer of your compiler to handle important cases.

> You also lose the very powerful RAII technique.

RAII may be powerful in C++, but there are other ways to get similar effects in modern languages. For instance, you can use higher-order functions that perform resource management:

  withInstreamFrom file
    (fn instream => ...use input stream...)

The idea here is that the withInstreamFrom-function provides a facility similar to a scoped pointer: it takes care of opening and closing the file/stream (even in the case of an exception).

Noel Grandin

Posts: 3
Nickname: grandinj
Registered: Sep, 2005

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Sep 5, 2005 5:36 AM

Reply

As a previous commenter noted, stack semantics are an unnecessary distraction for Java.

What Java needs are "value" semantics such that the compiler has enough information to infer when "objects" may be safely stack allocated.

Microsoft does sufficient compile-time data tracking to implement this in their VM - it is pretty expensive, but since they do ahead-of-time compiling, it pays off.

IBM did a paper a year ago about value semantics in Java - they were looking at ways of improving numerical performance.

Terje Slettebø

Posts: 205
Nickname: tslettebo
Registered: Jun, 2004

Re: The Temporary Assignment Problem and Transfer Semantics

Posted: Sep 30, 2005 12:33 PM

Reply

> > Regarding Todd Blanchard's critisism of stack-based
> > objects in C++, I agree with you that it's a very
> > important feature, and it enables you to get both
> > efficiency _and_ elegance. In my opinion, as you said
> it,
> > I think it's rather a "mistake" that Java doesn't have
> it
> > (probably in an effort to get a "simple" language; same
> > with not allowing free functions, everything having to
> be
> > a class). In Java, if you want to use a user-defined
> type
> > (class), you immediately take a performance hit from
> the
> > heap allocation, and (unpredictable) garbage
> collection.
> > Thus, you typically have to choose between efficiency
> and
> > elegance. Whereas in C++, you can have as small and
> simple
> > classes as you like, and they are just as efficient as
> > built-in types.
>
> I think if it was a problem in Java, the Java people would
> be complaining about it rather than the C++ people :)

And I'm not a "Java person"? Personally, I don't describe myself as a "C++ programmer" or "XXX programmer", any more than a carpenter describes himself as a "hammer carpenter" (unless he's exceedingly stupid ;) ). C++ is one language in my "toolbox", and admittably a favourite of mine, but not by far my only one, and there are zillions of other languages and technologies a professional software developer should be comfortable with. If not, you risk pounding a screw with a hammer... :)

Now, I know you know this very well (I've read your excellent book, for one thing, "Working Effectively with Legacy Code", which has really helped me with being more conscious in working with our legacy codebase, and what techniques may be used to reduce risk, and smooth transition to a better structure). Let me then just add that I've also worked with Java (a real project for a real customer), and I experienced exactly this problem: a performance hit from excess heap allocation and garbage collection, so I had to start doing some "object pooling", and some rather ugly workarounds, to get acceptable performance, something that would have been completely unnecessary in a language supporting stack-allocated objects like C++.

I've also heard from others, such as a Java game programmer I've met, that he shied away from the abstractions in Java, for performance reasons.

> > This, treating built-in and user-defined types the same
> > way, is one of the really nice, coherent things about
> C++,
> > compared to most other languages,
>
> Maybe most languages on the C limb of the language tree..

Yes, C does this, as well, but you can't make user-defined types that can be used the same way as built-in types (i.e. no overloaded operators, etc.), and you can do this in C#, with some restrictions.

> a large number languages do treat them the same also, they
> make them all dynamic.
>
> In Io, for instance, you can add a method to integers:
>
> Number double := method(self * 2)
> 2 double == 4
>
> There are quite a few statically type languages which
> unify built-ins and user-defined as well.

Yes, but typically not in widespread use (unlike C, C++. Java, etc.).

Regards,

Terje

Flat View: This topic has 12 replies on 1 page

Previous Topic

Next Topic

Sponsored Links

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use