On 29 Mar 2012 at 16:14, Kyle Cronan wrote:
> So my question is, why isn't taking the address of some instance of a
> templatized function and passing it to def() enough to require the
> function definition to exist? Should this be considered a usability
> bug in the library, a problem with my compiler, or maybe neither?
No, in that earlier post this behaviour is by design and intent (and
I'm surprised no one said so at the time). When you do this:
class_< field<vect> >("field_vect", init< int >())
.def("getsize", &field<vect>::getsize)
;
... you're telling the compiler to instantiate field<vect>::getsize.
Problem is, the compiler hasn't seen what getsize is supposed to be
because its implementation was declared in a separate compilation
unit. Therefore it can't know how to mangle the symbol for
field<vect>::getsize, and therefore can't resolve the symbol.
Besides the above, you should NEVER declare template implementations
outside a header file. Otherwise it easily leads to violations of the
ODR. The old export keyword was supposed to solve the problem of
having to declare template implementations in headers, but that's
dead as a concept now.
BTW, regarding inlining, there are magic attributes to force never
inlining. Very, very useful for debugging optimised code, and easier
and clearer to use those than obfuscating the code.
HTH,
Niall
--
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
