This one's a major Ouch! for recls (and for recls/D, if that makes a
difference <g>)

The problem is you've given "C" linkage to two different constructors.
Constructors should NOT be extern "C", because name mangling is used to
distinguish them, and C linkage turns off name mangling.

So you're saying that other compilers are wrong to deduce that, being a
constructor of a nested class, it is appropriate to implicitly apply "extern
"C++"" to the method, which, being a constructor, cannot be anything but
"extern "C++""?
Without more info, I can accept that. However, I'd argue that DMC++,
assuming it is indeed doing the right thing, achieves nothing by being more
pedantic in this than its peers. If the error message given was more (or,
indeed, at all) meaningful, then I could perhaps be persuaded otherwise, but
as it stands it's like talking to a teacher who tells you you've done
something wrong but refuses to tell you what it is. (I had one of these,
stupid creature, and hers was the only class I failed in school, since I
couldn't bring myself to join in her silly game of control and abuse.)
Cheers
Matthew

So you're saying that other compilers are wrong to deduce that, being a
constructor of a nested class, it is appropriate to implicitly apply
"extern
"C++"" to the method, which, being a constructor, cannot be anything but
"extern "C++""?

In my reading of the standard, it is not at all clear what the compiler is
required to do here.

Without more info, I can accept that. However, I'd argue that DMC++,
assuming it is indeed doing the right thing, achieves nothing by being
more
pedantic in this than its peers.

The problem with implementing unspecified behavior is that:
1) it will wind up being inconsistent from implementation to implementation
2) it will close the door on some potential future modification to C++ that
may involve a different meaning to that construct.
For example, suppose we have the statement:
a = (b + c;
The programmer has forgotten the closing ). Let's say that it's obvious that
a ) was required, so why should the compiler report an error, shouldn't it
insert the missing ) and compile the code anyway? Shouldn't a compiler *be*
pedantic in implementing the language, making sure every i is dotted and
every t is crossed?

If the error message given was more (or,
indeed, at all) meaningful, then I could perhaps be persuaded otherwise,
but
as it stands it's like talking to a teacher who tells you you've done
something wrong but refuses to tell you what it is. (I had one of these,
stupid creature, and hers was the only class I failed in school, since I
couldn't bring myself to join in her silly game of control and abuse.)

The problem with giving meaningful error messages in C++ is that the
compiler must be able to guess what you meant. In order to do that
successfully, the language must have redundancy in it. C++ does not have
much redundancy in it (i.e. what does f() mean?), so giving error messages
based on a guess at what the user meant to do is notoriously difficult.
There's always room for improvement in error messages, it's more art than
science (which is why YACC parsers usually have absolutely terrible error
messages).
P.S. the:
a = (b + c;
is an example where there is sufficient redundancy in the language that the
compiler can reasonably say "missing )" and get it right most of the time.

So you're saying that other compilers are wrong to deduce that, being a
constructor of a nested class, it is appropriate to implicitly apply
"extern
"C++"" to the method, which, being a constructor, cannot be anything but
"extern "C++""?

In my reading of the standard, it is not at all clear what the compiler is
required to do here.

Fair enough.

Without more info, I can accept that. However, I'd argue that DMC++,
assuming it is indeed doing the right thing, achieves nothing by being
more
pedantic in this than its peers.

The problem with implementing unspecified behavior is that:
1) it will wind up being inconsistent from implementation to

implementation

2) it will close the door on some potential future modification to C++

that

may involve a different meaning to that construct.
For example, suppose we have the statement:
a = (b + c;
The programmer has forgotten the closing ). Let's say that it's obvious

that

a ) was required, so why should the compiler report an error, shouldn't it
insert the missing ) and compile the code anyway? Shouldn't a compiler

*be*

pedantic in implementing the language, making sure every i is dotted and
every t is crossed?

This analogy is bogus. First, it's wrong, because the statement is, both to
common sense and (I hope!) to the standard, wrong. Given that, how is this
unspecified behaviour? Second, it's an extreme exaggeration: the two cases
have almost nothing in common beyond the fact that they share the same
limitless plane of "unspecified behaviour".
In the case of a non-static method of a class defined within an "extern "C""
function, there's no ambituity in common sense, since the method has to be
"extern "C++"". There is nothing else it could be. The fact that the
standard does not explicitly state this is certainly not good, but should
there be a corrective clause added, it's only going to say what we know, by
common sense, to be right. That's completely different from the case of your
example given above.

If the error message given was more (or,
indeed, at all) meaningful, then I could perhaps be persuaded otherwise,
but
as it stands it's like talking to a teacher who tells you you've done
something wrong but refuses to tell you what it is. (I had one of these,
stupid creature, and hers was the only class I failed in school, since I
couldn't bring myself to join in her silly game of control and abuse.)

The problem with giving meaningful error messages in C++ is that the
compiler must be able to guess what you meant. In order to do that
successfully, the language must have redundancy in it. C++ does not have
much redundancy in it (i.e. what does f() mean?), so giving error messages
based on a guess at what the user meant to do is notoriously difficult.

Sounds like a good argument, were it not for the fact that most/all other
compilers do give a lot more information than DMC++.

There's always room for improvement in error messages, it's more art than
science (which is why YACC parsers usually have absolutely terrible error
messages).
P.S. the:
a = (b + c;
is an example where there is sufficient redundancy in the language that

the

compiler can reasonably say "missing )" and get it right most of the time.

I disagree. It could just as easily be
a = *b + c;
or
a = (b) + c;
as
a = (b + c);
Again, there's no similar ambiguity of the non-static local class method's
linkage. It can only be one thing.