|
![](/i/fill.gif) |
Warp wrote:
> For example, if you create your own class or struct which has a few
> member variables, and then you instantiate a vector of that type, it will
> be quite space-optimal: Every element in the vector will only consume as
> much memory as the size of the object. There is no ancillary data needed.
C# does that. Of course, it's generating bytecodes not machine code.
> Of course the second efficiency advantage is that the compiler will be
> able to inline code and to perform type-specific optimizations (for example,
> sorting a vector of ints will be very efficient because the compiler will
> be able to inline the element comparisons directly into the sorting routine
> as a machine code register comparison opcode).
C# can do this too, but of course that's because it's not completely
compiled until you run the code.
The place C# lacks compared to C++ is that again *because* you're not
recompiling the declaration each time you use it, you have to make
guarantees at the compile time of the generic. So you can't write a generic
that would work on "any object that has a function X taking a single integer
and returns a float". The things you instantiate have to have particular
declarations as required by the generic. This is something I'd take from Go
perhaps - there doesn't seem to be any technical reason the language
couldn't be improved to support this sort of thing. The language already
knows hen you compile the generic if you're making calls you haven't
supported, and it knows when you instantiate the generic what calls are
supported by the class you're instantiating it with, so it would probably
just be an extension of the metadata.
> On the other hand, it's not technically impossible, and it has been done,
I had read that the guys who did it said basically it's impossible to do
right according to the standard, but you can get close. Not being an expert
on the esoteric details of C++ compiler implementation, I might have been
misunderstanding their conclusions. But sure, it can be done, but I'm not
sure what the benefit would be per se? Why does anyone care? Is it just to
hide (in a commercial sense) the source code for the template library?
> As far as I understand "generics" do not handle things "inline" and
> "by value", but instead simply handle references, and basically the only
> thing they do is that they allow you to skip doing explicit upcasting.
That's Java. In C#, they actually changed the object code format (which Java
couldn't afford to do) to support actual generics. So a list of points
doesn't have any pointers in it internally, and your example of
vector<Point> with two definitions of Point works fine too. That's why XNA
(for example) can build a model full of vertexes and not be absolutely
bogged down even on an implementation where the GC is
stop-the-work-mark-and-sweep sucky.
> Generics do not allow things like template metaprogramming, template
> specialization, and such.
Yes, specialization is another thing that (I think) C# lacks that I would
have liked to have on several occasions.
--
Darren New, San Diego CA, USA (PST)
"How did he die?" "He got shot in the hand."
"That was fatal?"
"He was holding a live grenade at the time."
Post a reply to this message
|
![](/i/fill.gif) |