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

"Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:doice3$2hve$1@digitaldaemon.com...
> 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.

> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:doice3$2hve$1@digitaldaemon.com...
> > 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

"Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:donorn$1mf6$1@digitaldaemon.com...
> 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.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:dopn8a$fjn$1@digitaldaemon.com...
>
> "Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:donorn$1mf6$1@digitaldaemon.com...
> > 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.

"Matthew" <matthew@hat.stlsoft.dot.org> wrote in message news:doptmr$sim$2@digitaldaemon.com...
> Again, there's no similar ambiguity of the non-static local class method's linkage. It can only be one thing.

Not exactly. In D, for example, one can adjust the linkage of class member functions. So there is an argument that they should not be forced in C++, regardless of the linkage setting, to C++.