This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/53930] bug in linker


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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID
           Severity|critical                    |normal

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-07-12 09:51:59 UTC ---
(In reply to comment #4)
> Yes, I have two different definitions of "A" struct. But they are defined in
> different cpp files, so actually linker should not have ambiguity, which one to
> pick up, since the names of these structs for linker should be something like
> "file1.A" and "file2.A".

Nonsense, that's not how C++ works.

If that was the case how would you ever use any type (e.g. std::string) in more
than one file, it would be a different type in every file.

> If this rule is broken, then result should be completely anarchy. Suppose we
> have 1000 files in the project - there is no guarantee that all the structs
> defined in cpps have unique names. And rule "which one to puck up is depend on
> link order" or "it could be any random one" are sounds scary to me.

Sorry you find it scary, but that's how it works.  That's why namespaces exist.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]