Boost Workshop at OOPSLA 2004

[Daveed Vandevoorde]

[...]
I contend that, all other things being equal, export templates are more
pleasant to work with than the equivalent inclusion templates. That by
itself is sufficient to cast doubt on your claim that the feature is "broken
and useless."

What are your comments on N1426, given that you and the rest of EDG are
thoroughly quoted as being against export?

(Sorry for the delay in answering. I have been busy lately.)

I'm not particularly happy about that paper. It makes it look
like EDG supports its points of view, when in fact that isn't
the case. (I agree neither with the technical aspects nor with
the nontechnical arguments of the paper.)

That said, EDG opposed export at its introduction (I wasn't at
EDG at the time, and I was somewhat sympathetic toward export;
obviously I wasn't a compiler writer at all ;-). If I remember
correctly, EDG's main arguments at the time were that the export
proposal was too poorly understood and almost certainly very
hard to implement.

Daveed

 

[kanze]

True, but only relevant if the header file with the template in it is
not yet stable. I doubt that this is true for many uses of templates
in large scale applications.

It's obviously not true -- in a large scale application, you avoid
templates other than very simple or very standard things (like
std::vector), because you can't afford the dependencies.

But that's circular reasoning: we don't fix the problem, because the
case in question doesn't occur in real code, and the reason it doesn't
occur in real code is because the problem isn't fixed.

I don't know how relevant templates at the application level will be in
the future. Today, they aren't used, because of the dependencies they
introduce. And we do get by without them. However, in an earlier time,
we got by without templates at all, and when I see some of the work of
Andrei and others, I see things which might be relevant in application
level code, if not now, then in the future.

FWIW: I actually had the problem once. It turned out that one of the
"stable" functions was a real performance bottleneck, and had to be
tuned. Tuned, by experimenting with different variations, and running
the results through the profiler. The actual function was called from
exactly one module in the program, but the template was used in about
20. And each time I modified the template, make recompiled all 20
modules. I'll admit that it is an extreme case, but it did actually
occur.

 

[David Abrahams]

Compilers that require fewer workarounds
get ported [to Boost] much more quickly.

Its more function of compiler popularity than its quality.
/Pavel

True. That said, for some compilers there are practically no
workarounds. Porting to those goes very quickly ;-)

 

[Gabriel Dos Reis]

(e-mail address removed) (Daveed Vandevoorde) writes:

[...]

| (Note that two-phase name lookup predates export by quite
| a bit. ADL was the result of a generalization for the
| sake of export, and that affected the details of two-phase
| name lookup when export was added to the language. However,
| the gist of two-phase name lookup was already described in
| D&E back in 1994.)

Thanks for hammering this point again. There have been some myths
about two-phase name lookup as a consequence of "export", even from
some "old timer" C++ experts. I would complement your answer by
providing a link to one of the first, publically available mailings,
that was already discussing two-phase name lookup:

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1992/N0209.pdf

That paper has the date "November 1992" and states

Most of the background of this paper is derived from a lengthy
discussion by the authors in May 1992, and subsequent electronic
communication which discussed and reworked the original summary of
that meeting.

 

[Hyman Rosen]

I don't know how relevant templates at the application level will be in
the future. Today, they aren't used, because of the dependencies they
introduce.

That's a pretty categorical claim. I know that it's your experience,
but I doubt that it's universal.

 

[kanze]

Compilers that require fewer workarounds
get ported [to Boost] much more quickly.

Its more function of compiler popularity than its quality.
/Pavel

True. That said, for some compilers there are practically no
workarounds. Porting to those goes very quickly ;-)

I wonder if the ambiguity was intentional. Did you mean that there
are compilers for which practically no workarounds are needed? (Porting
to them should go pretty quickly.) Or did you mean those for which no
practically workarounds exist? (Porting to them goes very quickly,
too. Just a line "not supported" in the documentatino.)

 

[David Abrahams]

:
Compilers that require fewer workarounds
get ported [to Boost] much more quickly.
Its more function of compiler popularity than its quality.
/Pavel

True. That said, for some compilers there are practically no
workarounds. Porting to those goes very quickly ;-)

I wonder if the ambiguity was intentional. Did you mean that there
are compilers for which practically no workarounds are needed? (Porting
to them should go pretty quickly.)
Yes.

Or did you mean those for which no practically workarounds exist?
(Porting to them goes very quickly, too. Just a line "not
supported" in the documentatino.)

That would be true if it weren't for the fact that people are trying
to port despite the difficulty. Incidentally, the efforts for HP have
gone a lot better than those for Sun recently.

 

[James Kanze]

|> (e-mail address removed) (Daveed Vandevoorde) writes:

|> [...]

|> | (Note that two-phase name lookup predates export by quite a bit.
|> | ADL was the result of a generalization for the sake of export, and
|> | that affected the details of two-phase name lookup when export was
|> | added to the language. However, the gist of two-phase name lookup
|> | was already described in D&E back in 1994.)

|> Thanks for hammering this point again. There have been some myths
|> about two-phase name lookup as a consequence of "export", even from
|> some "old timer" C++ experts.

I'm curious about this, because I've never heard the claim that
two-phased lookup was a consequence of "export". A lot of us missed its
initial introduction, for I really don't know what reasons.

Of course, the real problem is that most compilers don't, or until very
recently didn't implement either. And that while there was a good deal
of discussion concerning export, very little was said about the fact
that their name lookup wasn't conform.

|> I would complement your answer by providing a link to one of the
|> first, publically available mailings, that was already discussing
|> two-phase name lookup:

|> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/1992/N0209.pdf

|> That paper has the date "November 1992" and states

|> Most of the background of this paper is derived from a lengthy
|> discussion by the authors in May 1992, and subsequent electronic
|> communication which discussed and reworked the original summary
|> of that meeting.

No one not in the standards committee would have seen the paper, and
those not involved in the extensions group probably wouldn't have read
it. It's hardly a reference for the casual user.

Of course, I would expect anyone actually implementing a compiler to
have seen it. Which sort of makes one wonder -- in Noverber 1992, there
weren't that many implementations which actually supported templates.
That CFront didn't take this paper or the discussions which preceded it
into account is quite understandable, but what is the excuse of the
other implementors.

Because, of course, the biggest single reason we have such a problem
with two phase lookup is that it is different from what we are used to,
and what we have been using for the past eight or ten years.

 

[James Kanze]

|> (e-mail address removed) wrote:
|> > I don't know how relevant templates at the application level will
|> > be in the future. Today, they aren't used, because of the
|> > dependencies they introduce.

|> That's a pretty categorical claim. I know that it's your experience,
|> but I doubt that it's universal.

And like most categorical claims, it is a blatant simplification. Like
everything else, the real question is one of a price/benefits trade-off.
The problem is that with current template implementations, the price
rapidly becomes very high, as soon as the code is non-trivial.

Consider two extreme cases. You're implementing Microsoft Office --
probably a couple of million lines of code. Do you really think
something like:

int
main()
{
Application< wchar_t > app ;
app.run() ;
}

would be doable, with everything else a template on the character type?
At the other extreme, I've a class which could have been put at the
application level. The only template involved is the constructor, and
all it does is use the two iterators to initialize a local std::vector.
I'd be hard put to say that something like that can't be used.

Somewhere between the two cases is a cut-off. My experience would
suggest that it is very low, quite close to the second case. For
several reasons, in fact, but at least partitially because of the
dependencies that using templates imposes. Such dependencies ARE a
reason for avoiding unnecessary templates. Not the only reason, but in
many cases, an important one.

 

[kanze]

(e-mail address removed) writes:

That would be true if it weren't for the fact that people are trying
to port despite the difficulty.

I would have imagined that once it was known that the current version of
the compiler didn't work, the efforts would be dropped. Basically: new
version of Boost: no effort, new version of compiler: a lot of effort.

At some point, there's no point in butting your head against a stone
wall. The wall usually wins.

Incidentally, the efforts for HP have gone a lot better than those for
Sun recently.

That stands to reason. As you might guess, the most important compiler
for my right now is Sun CC.

 

[David Abrahams]

I would have imagined that once it was known that the current version of
the compiler didn't work, the efforts would be dropped. Basically: new
version of Boost: no effort, new version of compiler: a lot of effort.

Every so often, some Sun^H^H^Hpoor user comes along who really wants a
particular library, so they start hacking at the library hard and
sometimes they even come up with the neccessary workarounds. There's
never any effort unless some volunteer cares about the
platform/compiler.

At some point, there's no point in butting your head against a stone
wall. The wall usually wins.

Doesn't stop ambitious people from trying, I guess.

That stands to reason. As you might guess, the most important
compiler for my right now is Sun CC.

Of course ;-)