From owner-freebsd-hackers Tue Feb 4 16:07:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA25901 for hackers-outgoing; Tue, 4 Feb 1997 16:07:59 -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 QAA25882; Tue, 4 Feb 1997 16:07:55 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id RAA13528; Tue, 4 Feb 1997 17:05:28 -0700 From: Terry Lambert Message-Id: <199702050005.RAA13528@phaeton.artisoft.com> Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta To: chat@freebsd.org Date: Tue, 4 Feb 1997 17:05:28 -0700 (MST) Cc: jmacd@CS.Berkeley.EDU, hackers@freebsd.org In-Reply-To: <199702041516.KAA08583@chai.plexuscom.com> from "Bakul Shah" at Feb 4, 97 10:16:25 am 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 > Since Terry responded to something I had posted, I feel obliged to > respond. > > His use of `clearly' made his erroneous response a bit amusing so I > didn't mind it at all! Terry made a mistake. Big deal. We all do > (like my mixing up his response with someone else's). Urg. As always, if it can be proven to my satisfaction that I have actually made a mistake, I will post a retraction; now you have me wondering, since you are generally reliable as a sanity-check... 8-(. Are you saying that there is a condition in which the linker will not be able to find a symbol that is really there? I was under the impression that if the template declaration was in scope, the function implementation would be instanced in scope: "C++ Primer Plus, Second Edition" Stephan Prata _Waite Group Press_ ISBN 1-878739-74-3 Pg. 580 Templates provide _parameterized types_, that is, the capability of passing a type name as an argument to an algorithm for building a class or a function. By feeding the type name _int_ into a queue template, for example, you can get the compiler to construct a queue class for queueing _int_s. Note: ..."get _the compiler_ to construct a queue class"... Pg. 581 When a template is invoked, _Type_ will be replaced with a specific type value, such as _int_ or _String_. I was under the impression that "invocation" was not possible at runtime. If it were possible (it is, in theory, if you pass around void instances of the object and explicity invoke the copy constructors, etc., of the base type), it would require a working RTTI implementation, IMO, as well as the cooperation of the linker, aw well as compiler cooperation in treating a template definition as a two pass declaration, since RTTI only works for classes with pure virtual functions. The compiler would have to implictly provide it's own abstract interface type. Pg. 582 Because the templates aren't functions, they can't be compiled seperately. Templates have to be used in conjunction with requets for particular instantiations of templates. The simplest way to make this work is to place all of the template information in a header file and to include the header file in the file that will use the templates. Which would, of course, cause the template definition to be in scope at the time the instantiation occurs, causing (in the base case) an _actualization_ (also Pg. 582) of the template to be created in scope at compile time. Now unless the compiler is performing some form of "Type" magic, where it converts references to pointers and provides a stub class for you, and casts to void for a singe instantiation of a given template class, I don't think I've made a mistake. If it is, tell me, and I will admit the mistake. Then I will point out that this probably requires the cooperation of the linker, and that the FreeBSD a.out linker is not being (very) actively maintained... and, as was pointed out, it works with John Polstra's "ELFKit"... consider upgrading. Otherwise, it's unreasonable to expect the "magic" to work elsewhere, so it's poor style, no matter how you cut it. > The bad news is that it segfaults on even simple Verilog > module definitions. So for now this mini project has been ^Z'ed > (put on hold). Thanks to all the people who responded with helpful > hints (even if wrong:-). I have been implementing COM and DCOM objects using pure abstract virtual base classes for interface definitions, using the FreeBSD g++ compiler in -current. If you could give a code fragment which triggers the error, I might be able to help out. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.