Re: The Temporary Assignment Problem and Transfer Semantics
Posted: Sep 30, 2005 12:33 PM
> > 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
> > I think it's rather a "mistake" that Java doesn't have
> > (probably in an effort to get a "simple" language; same
> > with not allowing free functions, everything having to
> > a class). In Java, if you want to use a user-defined
> > (class), you immediately take a performance hit from
> > heap allocation, and (unpredictable) garbage
> > Thus, you typically have to choose between efficiency
> > elegance. Whereas in C++, you can have as small and
> > 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
> > 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.).