On May 13, 4:34 pm, Paul Pluzhnikov <[EMAIL PROTECTED]> wrote: > "pemo" <[EMAIL PROTECTED]> writes: > > Where is the STL source normally located - can find the vector.h but not the > > cpp? > > You aren't looking for either vector.h or vector.cpp. > > You are looking for 'vector' (and, as I already explained, there > *isn't* a .cpp file, because STL is all templates, which are *not* > compiled into a library). > > Assuming gcc 4.1.1 in default RH installation, the 'vector' would > be found in: > > $ rpm -ql libstdc++-devel | grep 'vector$' > /usr/include/c++/4.1.1/debug/vector # this is internal debug version > /usr/include/c++/4.1.1/vector # this is what client code uses.
Thanks. Could you clarify it's neither a .h/.cpp? The source code behind the vector template has to be compiled, and thus found. Intuitively, I would expect this be be in some include path, i.e., as vector is included in her source, the template boiler plate has also to be 'included' somehow. This seems *not* to be the case however, so I'm curious as to how the code 'arrives' for compilation. > >> Sure: just add '-Wl,-verbose' and it will spit lines like this: > > > Her g++ [4.1.1 20070105 (Red Hat 4.1.1-51)] didn't understand either of > > those switches - not did gcc [should one use gcc rather than g++?] > > There are no "those switches". It's a *single* switch, spelled > *exactly* this way: > > g++ ... -Wl,-verbose Ok, will try this. > >> Note that correct profiling is a bit of "black art", best performed > > -pg seemed to work, but nothing seemed to be generated. running gprof, it > > couldn't find gmon sometimes, or a.out when the app was compiled via gcc. > > You seem to be lacking the necessary skills to help her with > profiling. As I said, it may require a bit of wizardry. Yes I am - used to selecting a simple checkbox to say I'd like to profile some code, and being shown VTune output [I have the Intel compiler for Windows [not that VTune requires that of course]]. > Given that you didn't supply any details, other than "nothing seemed > to be generated", it's hard to tell what may have gone wrong. > > Suggestion: compile a simple application (main with a couple of > functions with time-consuming loops) with '-pg'. Run it to learn > how gprof works, what output to expect, etc. Only then try the real > application. Ok, but can you say whether after doing this [away from her machine at the mo] whether gprof requires some explicit input, e.g. gprof a.out? _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus