[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-programming-e
Subject:    Re: [suse-programming-e] Debugging c++ template classes
From:       "Steven T. Hatton" <hattons () globalsymmetry ! com>
Date:       2005-12-01 23:33:18
Message-ID: 200512011833.18445.hattons () globalsymmetry ! com
[Download RAW message or body]

On Thursday 01 December 2005 15:32, Jerry Feldman wrote:
> On Thursday 01 December 2005 2:44 pm, Steven T. Hatton wrote:
> > I don't believe you will be able to do that.  The problem is that
> > templates are actually converted into "regular source code" and then
> > compiled.  The only thing I can think of which might shed some light on
> > things is running `objdump -C ' on the object code.  Depending on your
> > situation, that may, or may not be useful.
>
> Just a stab in the dark. Templates are "inlined" which is the correct
> terminology.

Not all template code is inlined.  The term used for the act of converting a 
template to a regular class or function by replacing template parameters with 
the types or values given as arguments is "instantiation".  The definition 
resulting from template instantiation is called a "specialization". That use 
of the term "instantiation" is distinct from the instantiation of a class 
which means to convert the class definition into an object code 
representation.  That will happen with both regular classes and class 
definitions in the form of template specializations.

Template inlining is governed by the same rules that govern regular function 
inlining.

> The problem is that like preprocessor macros you can't really 
> get to them per se.
> What I am trying to track down is that there are about 1000 instances of
> this function, and I'm trying to find out why a number of them are not
> showing up in an array in the Intel compiler version, but do show up in the
> G++ version. (I also didn't mention that there are also a lot of dynamic
> shared libraries in the mix which makes it even more challenging).

How is the array allocated?  I can't really comment on that situation without 
more information.

> > The difference in behavior between the two compilers is probably a result
> > of the "unspecified behavior" related to program termination.  My guess
> > is, the g++ generated version is trying to execute some cleanup code that
> > is accessing an invalid memory address.  Examine your destructors
> > carfully.
>
> At the moment, I don't really care about the g++ segfault. We only built
> with g++ because we were having other problems with the Intel compiler
> (that was not a problem with the compiler, but with 3rd party libraries).
> The problem I'm focusing on is much earlier.
> What we are doing is a 64-bit proof of concept type of situation. In this
> case, the Intel compiler should generate code that runs about 40% faster
> than the g++ code.

The g++ segfaults probably indicate a flaw in the program.  By determining the 
cause, you may be able to solve your other problem.

Steven

-- 
To unsubscribe, email: suse-programming-e-unsubscribe@suse.com
For additional commands, email: suse-programming-e-help@suse.com
Archives can be found at: http://lists.suse.com/archive/suse-programming-e

[prev in list] [next in list] [prev in thread] [next in thread]