From owner-freebsd-hackers Tue Feb 4 17:37:51 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA08856 for hackers-outgoing; Tue, 4 Feb 1997 17:37:51 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA08850 for ; Tue, 4 Feb 1997 17:37:48 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA13752; Tue, 4 Feb 1997 18:34:51 -0700 From: Terry Lambert Message-Id: <199702050134.SAA13752@phaeton.artisoft.com> Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta To: chuckr@glue.umd.edu (Chuck Robey) Date: Tue, 4 Feb 1997 18:34:51 -0700 (MST) Cc: terry@lambert.org, jmacd@CS.Berkeley.EDU, hackers@freebsd.org In-Reply-To: from "Chuck Robey" at Feb 4, 97 07:40:51 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Terry, I'm not sure you're right. The virtual tables show up (using nm on > the obj files) as "t" objects, not "T", meaning local text objects. The > way I understand from JW Eaton, under Linux (where he wrote it natively) > the symbols in the obj files for these virtual tables instatiated for > templates are global, not local. There is one of these tables made for > each template type, correctly, but they're coming up local. This seems to > be to point to an error source in the compiler, not the linking process. > > FWIW, the symbols make it into the library, but as local symbols, not > global. Am I confused about this? Well... you are, or I am. 8-). Riddle me this: if the compiler makes a 't' reference to a real 'T' somewhere... how can it generate the real 'T'? It can't just pick one of the files at random an put it there. I might be compiling incrementally. EXAMPLE: Say I have TFifoQ.h: template struct FifoQueueElement { friend class FifoQueue; private: const Type *m_pItem; FifoQueueElement *m_pNext; }; template class FifoQueue { private: FifoQueueElement *m_head; FifoQueueElement *m_tail; public: void Insert( const Type *pItem); Queue() { head = tail = NULL; } }; template void FifoQueue::Insert( const Type *pItem) { FifoQueueElement *pQE = new FifoQueueElement; pQE->m_pItem = pItem; pQE->m_pNext = NULL; if( m_tail == NULL) m_head = pQE; else m_tail->pNext = pQE; m_tail = pQE; } and I have foo.cc: #include "TFifoQ.h" // instantiate global int queue using template... Queue foointqueue; ... stuff ... and I have fee.cc: #include "TFifoQ.h" // instantiate global int queue using template... Queue feeintqueue; ... stuff ... ...do you expect the code to implement the Insert method for a FifoQueue of int to go into foo.o or fee.o? Here's what I expect: a.out: --------- Personally, I expect it to be generated static in *both* of them, with no global reference, in the a.out case. Anything else is an error. If you run a new g++ with the a.out ld for FreeBSD, it's pilot error. Alternately, you could have a compiler flag that was applied to fee.. that said "don't generate code for templates" so it only made a reference, and you would *not* use that flag when compiling foo.cc so it would generate the real thing. Then, when you linked, there would be one instance and multiple references. If you used the flag on everone who actualized the template class by instantiating it, you wouldn't get a real instance of the code. Again, you'd be guilty of pilot error. ELF: --------- In the ELF case, I expect it will either do waht a.out does, OR if they were clever and used ELF for what it is good for, it will generate the template instance for an queue of integers in *both* fee.o and foo.o, *BUT* in different ELF segments than the rest of the code in foo.o and fee.o, and then when it links, it will bring in only once (probably from whichever is first in the linker argument list). Alternately, you *could* have the same compiler flag for ELF, too, and have the same possibility for pilot error, while creating only a single instantiation at compile time. Godlike compiler writer magic: --------- If, on the other hand, they were truly *godlike*, they would provide a method of implementing a precompiled template instantiation, and generate one of those an an object file. Inside, it would use RTTI (run time type identification) to decide what kind of object it was referring to, and the compiled template code would not enforce the object type. The compiler would compile fee.cc and foo.cc, and *not* generate the code for the template. But it would rigidly enforce *at compile time* type checking *as if it had*. Then, when it generated any references for the "FifoQueue of int's" public member functions or data, it would generate them *without* the linker glue for link time type checking, and rely solely on the RTTI to enable the class to "do the right thing". I find this last one extremely unlikely. But if they are doing it, then the symbols are right, I am wrong. And it's still pilot error, since if ther pilot did the right thing, there would be: (1) an object module with the type-stripped class instance, (2) multiple object modules with refernces to the type stripped references, and (3) an RTTI interface, which I don't believe currently exists in a form suitable for use in doing this sort of thing by hacking up the compiler for the special case where it is compiling a template file to generate an object with type-non-specific 'this' and private member data references. --------- If I'm wrong (the declaration didn't need to be in scope), then it's probably that they are incorrectly applying the "don't generate template" flag when they shouldn't be, not creating a template instance object seperate from the rest of their objects, like they should be, or relying on linker tricks which require multiple instantiations to be coalesced to a single instance, which the a.out linker is too stupid to do, and the ELF linker is probably currently too stupid to do, even though ELF could support it. Feel free to correct me, though... I'd rather know the right answer than just think I knew the right answer. If there's another way for me to be wrong, let me know. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.