Caolan McNamara

A puma on the loose apparently ?

Bugzilla for Dublin, hmm…

Don’t cast stl iterators to pointers, they might be pointers in your implementation, but its unportable and evil.

The horror, naturally caffine free coffee

Patiently waiting for my

//start test.cxx
static int testlocal1()
{
return 0;
}

namespace
{
int testlocal2()
{
return 0;
}
}
//end test.cxx

> g++ -fpic -shared -o libtest.so test.cxx
> nm -C libtest.so | grep test
0000069c t testlocal1()
000006a6 T (anonymous namespace)::testlocal2()

should anonymous namesspace stuff instead be ‘t’ for local ?

callcatcher, collects functions/methods defined and functions/methods called or have their address taken (by running the c/++ code through g++ -S and asm-scraping out the info I want).

Subtract used functions from defined and get a list of unused functions. callcatcher currently recognizes virtual methods and ignores them from the unused list (methinks with g++ -S -fvtable-gc that you can get enough information to also include virtuals, but -fvtable-gc has disappeared in 3.4 just when I’ve first seen it).

collects info from everything it compiles into ~/.callcatcher so delete that dir between runs on different projects or if you make changes to the source of the project being analysed

There can be name collisions between different symbols with the same name, so as well as missing virtuals there can be missing unused non-virtuals. But in this context its more important to have no false positives which waste my time, than false negatives.

I give it a whirl over sot and starmath so far, and while I won’t have a full list until those entries are boiled down further by doing a full compile of OOo to get the other projects referencing most of the currently “unused” symbols, first looks are promising, i.e. #i30373#, #i30375#, #i30394# and #i30402#

Could have used objdump -C -d on the final .sos of the projects, which would avoid recompiling, but didn’t see how to detect virtuals in that case.

Using kcachegrind to identify the non-trivial global objects created during OOo startup showed quite a large amount. Under #i29636 I’ve removed the vast majority of them which gives approx 1 sec speedup to get to the splashscreen for me at least. So global objects are bad, don’t do that.

As mark points out, OOo’s lack of stored state for the export dialog is irritating

Advogato is down for way too long now So time to move on…