Re: export

From: David B. Held (dheld_at_codelogicconsulting.com)
Date: 08/28/04 

Date: 28 Aug 2004 07:03:12 -0400
To: (Usenet)

Hyman Rosen wrote:
> David B. Held wrote:
>> the albatross mandated by the standard with virtually no noticeable
>> demand from the market.
>
> The standard mandated lots of things not demanded by the market, such as
> STL.

And yet, compiler and library vendors did not find it unduly difficult
to implement, and the value thereof was apparent to most. On the other
hand, export has had critics more or less from its very inception.

> Export is no albatross.

Did you read N1426? What are your rebuttals to the numerous claims
made therein?

> From the user point of view, it presents a perfectly simple concept -
> put your declarations in a header file and your code in an
> implementation file, and compile. It's the inclusion model which is
> nasty and broken and counter-intuitive.

Only when you think of templates as functions. And that's exactly why
export doesn't work. Because it lulls the programmer into thinking
that "separate compilation" means "like you have for functions", when,
in fact, it really means "like you have for metafunctions". That's
because templates are not functions, they are metafunctions, or
function-generators. You don't compile them to object code, you compile
them to meta-object code. Or, if you're EDG, you don't even do that.
You just compile-on-demand, because meta-object-code is too big to be
useful. You can make libraries of functions and object files, but you
cannot make libraries of metafunctions and meta-object files with any
product on the market. Nobody thinks of a "compiled macro library",
but templates are really just glorified macros, right? They are code
generators, and it is perfectly normal for us to include macros
wherever they are needed. So from that perspective, the inclusion
model makes perfect sense and gives no false analogy to real functions.

> [...]
> I find it hard to believe that writing export is harder than doing
> all the unwinding correctly when an exception is thrown.

Take it up with EDG. They're the ones that say how hard it is to
implement export, saying that it took as long as "any three other
features in C++ combined"...no exceptions mentioned (such as exception
handling).

> The reason vendors haven't implemented export is that users can muddle
> along with the inclusion model, so there's no pressure on them to get it
> working.

It's worse than that...[from N1426]

      John Spicer notes: “Any program written using export can be
      rearranged trivially into a program that doesn’t use export.”

Not only that, but export literally changes language semantics, and was
so poorly understood that many issues were left unspecified in the
standard, so EDG basically had to make up a reasonable set of rules,
which no other vendor is technically obliged to respect.

> The only reason templates are in as good a shape as they are is
> _Modern C++ Design_ - that library drove enough user demand that
> implementors felt that they had to get this part of the standard
> implemeneted. Otherwise they just can't be bothered. For God's sake,
> until the recent version 7, Microsoft's exception handling was totally
> broken. Maybe that was an albatross too?

I think the fact that other vendors did a better job of exception
handling in the mean time speaks volumes. While MC++D was surely
influential in making template support a priority, I would argue that
templates were becoming more popular on several fronts as people began
to see their utility in metaprogramming. On the other hand, supporters
of export are less busy demonstrating the utility of export as they are
apologizing for why it does not do what the naive programmer thinks it
ought to. I mean, c'mon! The convener of the C++ committee is lobbying
against it! What other feature has that ignominious honor?

I think that export is ill-conceived because it confuses metaprogramming
with programming. You can only compile meta-source code to meta-object
code, and C++'s template mechanism doesn't lend itself to a nice,
concise meta-object file format. Part of that is because the template
engine was not conceived as a first-class metaprogramming facility.
That is not to disparage its design, since it was certainly cutting
edge in some respects. But what we do have is more like a glorified
type-safe macro system, which is why the inclusion model is so natural
to implement. I think "export" is a feature that belongs in a different
language...a language that has fundamental support for metaprogramming
and does not even inadvertently convey the expectation that metacode
can be treated like concrete code.

Dave

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]