Re: Why export templates would be useful
On Apr 2, 11:08 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
In article <a13442c0-53d6-4873-aa2b-af48e13d3561
@j21g2000yqh.googlegroups.com>, james.ka...@gmail.com says...
[ ... ]
While you're right that exported templates could sometimes
provide some benefit, the benefit really was fairly
minimal and the cost really was quite high.
Since when is improved encapsulation a "minimal" benefit.
First of all, I qualified that, saying "fairly minimal", not
just "minimal". Second, I started out by saying that they
sometimes provide some benefit.
So, the question basically comes down to how often the
encapsulation that's available without export is inadequate,
but with export it is adequate. At least in my experience, the
answer to that is, "not very often".
Only in cases where you might want to use templates for
something other than very stable basics.
At present, we have a chicken and egg problem. Without export,
you can't really use templates for anything but the most stable
basics. So you don't try, and you don't know whether it would
be really useful in your application or not.
And from a user point of view: I get the benefit, but the
cost is paid by the compiler vendor. (I know that that's
somewhat simplified, but you get the idea.)
I'd say it's simplified to the point of being dead wrong. The
notion that the vendor pays instead of the consumer paying is
just plain nonsensical. The best you hope for is that the cost
can be amortized over a lot of consumers so individually you
can get away with paying only a fraction of the cost.
You mean like in the case of g++:-).
Seriously, development cost is a negligible part of most modern
compilers (g++ excepted). Far outweighed by commercialization
and distribution. And support---adding export would probably
reduce support costs slightly. (Making templates behave by
default as if they had been declared export would reduce them
significantly, but that wouldn't be conform.)
If it was easy to go out and hire the talent to implement
"export", that would be a reasonable viewpoint -- but we both
know that's not the case at all.
I know that EDG actually offered to help other implementors, and
provide the knowledge they had acquired doing the first
implementation. I also know that companies like Microsoft and
Sun already have some very qualified people working for them;
the fact that they choose to use these people for things like
CLI or Java is a separate problem.
In reality, the people to work on the compiler will usually be
the limiting factor -- which means compiler features tend to
be pretty much a zero-sum game. Consumers can reasonably
choose _which_ features get the most effort, but effort spent
on one feature almost inevitably takes away from the effort
that can be put into other features.
Yes and no. What other features have been added to, say Visual
Studios, since version 7. Some important bug fixes, perhaps,
but the basic compiler hasn't changed that much.
Therefore, as a consumer my interest is in finding the
features that provide me with the highest benefit to effort
ratio. If I were to write a list based on that, I don't think
"export" would make it into the first 10 items -- and quite
possibly not even the first 10 pages.
Funny. I would have put it very close to the top of the
unimplemented features. It's lack severely handicaps my use of
templates.
[ ... ]
Something better has already been proposed, but not adopted,
for lack of time. Perhaps if as much effort had been put
into it as was put into getting rid of export. (Had the
proposal been to replace export with something better, I'd
not be opposed.)
I, for one, would certainly _prefer_ a "make before break"
change -- but I think it's unrealistic. I'd say a large part
of the reason time wasn't found for Daveed's module proposal
was precisely because export was present -- and I think almost
any other such proposal would have been treated the same was
as long as export remained in the standard.
As far as I can tell, most, if not all vendors had dropped
export long before Daveed's proposal. (It's curious to note
that Daveed is also the only person to have actually implemented
export. I have no idea if that signifies anything, but it's
vaguely possible that his experience with implementing export
gave him a better perception of what could or could not be
done.)
--
James Kanze