www.digitalmars.com Home | Search | C & C++ | D | DMDScript | News Groups | index | prev | next
Archives

D Programming
D
D.gnu
digitalmars.D
digitalmars.D.bugs
digitalmars.D.dtl
digitalmars.D.dwt
digitalmars.D.announce
digitalmars.D.learn
digitalmars.D.debugger

C/C++ Programming
c++
c++.announce
c++.atl
c++.beta
c++.chat
c++.command-line
c++.dos
c++.dos.16-bits
c++.dos.32-bits
c++.idde
c++.mfc
c++.rtl
c++.stl
c++.stl.hp
c++.stl.port
c++.stl.sgi
c++.stlsoft
c++.windows
c++.windows.16-bits
c++.windows.32-bits
c++.wxwindows

digitalmars.empire
digitalmars.DMDScript

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

↑ ↓ ← "Matthew" <matthew hat.stlsoft.dot.org> writes:
This one's a major Ouch! for recls (and for recls/D, if that makes a
difference <g>)
Dec 23 2005
↑ ↓ "Walter Bright" <newshound digitalmars.com> 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.
Dec 23 2005
↑ ↓ "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
↑ ↓ → "Walter Bright" <newshound digitalmars.com> writes:
"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++.
Dec 26 2005