Digital Mars - c++ - [bug] DMC++ goes ga-ga when given different unions with similar definitions inside extern "C"

↑ ↓ ← → "Matthew" <matthew hat.stlsoft.dot.org> writes:

 "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

Dec 25 2005

↑ ↓ ← → "Walter Bright" <newshound digitalmars.com> writes:

"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.

Dec 26 2005

↑ ↓ ← → "Matthew" <matthew hat.stlsoft.dot.org> writes:

"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


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


 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


 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


 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


 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.

Dec 26 2005