jeffw@cs.tamu.edu (Jeffrey A Waller) (07/14/90)
Three things: #1 <1427@camex.COM> geoff@circus.camex.com (Geoffrey Knauth) responds to article <140@emtek.UUCP> matt@emtek.UUCP (Matt Meola): Matt:: >>Does anyone know why cfront mangles the name catch_sig(int) into >>catch_sig__FiPFve_v ? Geoffrey:: >I believe the extra characters type-encode the function and provide it >a signature. How about this: void catch_sig(int sig,void (*func)(...)) {/* stuff */} catch_sig__FiPFve_v catch_sig is a global function that takes an integer as first parameter and a pointer to a function that takes void,... as parameters and returns void. Is there another catch_sig perhaps??? Or a call to catch_sig with those kind of parameters--type safe linkage yea! #2 <5039@uwm.edu> peter@csd4.csd.uwm.edu (Peter J Diaz de Leon) writes Peter:: >When I try to compile it under Turbo C++ 1.0 I get the error: > > cannot find IntArray::IntArray() to initialize a vector in function main > >on the line in the main program which reads: > > pia = new IntArray[1025]; I think I remember in the 1.2 Stroustrup book that to be an element of a vector, a class must have a constructor with no arguments. IntArray(int sz = ArraySize) should qualify, but apparently TC++ dosen't recognize it, for a quick fix--maybe not much help, redefine IntArray(int sz = ArraySize) as two constructors. IntArray(int sz) and IntArray(), in which sz is set to ArraySize, maybe that will work. #3 A long time ago I posted about some trouble I was having with multiple inheritance. The crux of the problem arouse from cfront's generation of of identifiers including __ptbl as part of the name. These names referred to functions. I haven't read this news group much since then, so this might have already been discussed at length, in which case, sorry. Error: A linker error complaining about some multiply defined symbols each when run back through cfilt indicate a symbol such as classname::__ptbl. No other indication of what this symbol is used for. C code is generated by cfront 2.0. The various files compile without warnings even with +w and +p switches. The same code compiles and links fine on one installation of C++, but not on another. Both C++ compilers are the same version, in fact they were derived from the same tape. The difference in the installations (I think) is that on one installation, the identifier length limit is set to 32. On the other (the one that works), the identifier length limit is set to 256 (or some other big number). Looking at the C code generated by cfront, it looks like the identifier names have been hashed by the cfront generating 32 character identifiers. MY QUESTION IS: What is __ptbl used for anyway, and is it possible that a hashing collision has occured to give the multiply defined symbols error. -Jeff Waller jeffw@cssun.tamu.edu P.S. When are templates likely to be avaliable?
mneerach@c.inf.ethz.ch (Matthias Ulrich Neeracher) (07/16/90)
In article <6570@helios.TAMU.EDU> jeffw@cs.tamu.edu (Jeffrey A Waller) writes: >MY QUESTION IS: > >What is __ptbl used for anyway, and is it possible that a hashing collision >has occured to give the multiply defined symbols error. I think __ptbl's are used for multiple inheritance and virtual members. Every object belonging to a class with virtual members contains pointers to a __vtbl and a __ptbl specific to this class. Now, if somebody calls virtual member #i of this class, __ptbl[i] is added to 'this' and the member function pointed to by __vtbl[i] is called (Actually, it might also be the otherway around). Now, your multiply defined symbol error: I got this from the Apple MPW C++ manuals. C++ has to decide in which file to put the __vtbl and __ptbl of a class, which are static tables, if the class members are scattered across multiple files. Normally these tables are put into the file which contains the definition of the first non-virtual non-inline member or so. If no such member exists, the tables are put into every file that contains member definitions for this class. I don't know of any workaround. On the other hand, you can safely ignore these warnings, as all the conflicting symbols contain identical data. > -Jeff Waller > jeffw@cssun.tamu.edu Matthias *************************************************************************** * Matthias Neeracher * I wouldn't recommend sex, drugs or insanity for * * mneerach@inf.ethz.ch * everyone, but they've always worked for me - HST * ***************************************************************************