[Bug c++/12427] Compiler misses error, gets lost. big time

["igodard at pacbell dot net" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12427


igodard at pacbell dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


------- Additional Comments From igodard at pacbell dot net  2003-09-27 08:11 -------
Not the way I read it. Inc() and Dec() are the implicit null constructors of *class* Inc and Dec respectively, not function pointers. The function would be called Inc(*)() as you point out.

Hence Inc() and Dec() are temporary objects, not types. The syntax "type id(object1, object2)" can't be a function declaration, because that would require "type1 id(type2, type3)". Consequently it has to be a declaration of id as a type1 object with a constructor taking object1 and object2. But there is no such constructor, so there should have been an error.

The Standard says that ambiguity between a declaration and an expression is always broken by assuming declaration. But that rule doesn't apply here, because both of our interpretations have this as a declaration of r3 - the only difference is in the type of r3 as declared. The rule also doesn't apply to Inc() and Dec(), because neither of these are declarations: they are either constructor calls (me) or function type specifications (you).

Moreover, if we assume that your interpretation is right, then the corrected line with the additional 0 argument should not have compiled without error because "type id(0, type?, type?)" is certainly not a function declaration. Of course, I suppose that in that case the constructor would have been found and the function pointer interpretation rejected.

Also later on, what is the idea of the warning that an object has an *address* that always has the value *true*? That makes no sense to me, whether or not line 38 should have been reported. Is the compiler lost, or does this actually have some meaning?

Please re-examine.