Tools for Analyzing C++ Class Code Generation?

Milo_Mindbender submits this query: "I've got a midsize Linux project which uses a lot of STL and other C++ template code. Even considering this, I end up with a lot bigger text (generated code) segment than expected. I know the information about the amount of code generated for each class is in the objdump, but prying it out by hand is a problem when you get five line long template invocations and hundreds of methods to wade through. Can anyone can recommend some tools that analyze binary or objdump output and summarize the amount of code generated for each class, including each unique template or STL class?"

Comments

This article should have been called

[GigsVT]

"Why you shouldn't use OOP for anything important."

Re:This article should have been called

[be-fan]

Too bad that C++ templates have nothing to do with OOP, but rather procedural programming. And while they have lots of problems (like code bloat) they are also phenomenally powerful for certain things (generic data structures). Even if you write nothing about procedural code, you could benifet from templates.

Me Too!

[kzadot]

Our large corporation also has a project, a client has requested that we implement BubbleSort, QuickSort, ShellSort, and one other sort that we learnt in cl^H^H^H^H^H^H^H^H^H err, discussed in a business meeting. The err, client also requests a 1 page analysis comparing and contrasting the differences between the searches.

Can code generation do this? It could really increase my chances of a good mar^H^H^H err profit yeah.

Very cheap visualization tool

[Mr. Darl McBride]

There's a very cheap STL project visualization tool, made by a company called "Prince." Their fine visualization tools are available in the pasta aisle of your favorite grocer. Simply bring water to boiling, stir in the Visualization Tool, and soon you'll have a representation of the calling methods employed by the average STL application.

For each additional programmer involved in the project, double the contents by stirring in a random different kind of Visualization Tool.

If you're targeting multiple architectures with different STL implementations, the Visualization Tool can be enhanced by having the lead of each platform boil their own pot of Visualization Tool, and then throwing the still-boiling contents at the other chefs^W developers.

If you aren't clear as to where I'm headed, I'll next recommend a more painful exercise: Go ahead and try debugging somebody else's template-heavy code.

Uhhh, perl or python?

[ComputerSlicer23]

Uhhh, use your favorite scripting language. Doing the demangle might be a bit tricky, but nm or obj dump should do either of those for you. Then just parse the class names.

Use a map or a hash. Oh, and lastly, move all the code in headers out into the .cxx/.cpp file, your code will compile faster, and probably run nearly as fast, with the exception of a handful of performance critical classes (finding them is important).

Kirby

OpenC++

[angel'o'sphere]

Search at source forge for Open C++ or OpenCPP, not sure how it is written.

That is a programmable source to source transformer for C++.

It spits out one singel file of c++ for every compiled C++ unit, removing the includes, by expanding them into the output.

That way yo can source level debug the processed c++ code, not exactly what you want but likely more powerfull in the long run anyway.

Your request varies far to heavy from compiler to compiler.

angel'o'sphere

John Lakos

[sohp]

If you do not already have a copy of Large-Scale C++ Software Design by John Lakos, get it. I realize this isn't a tool per se, but he has a terrific section in chapter 10 on Using C++ Templates in Large Projects.

Turn off inlining

[Anonymous Coward]

This is more of a suggestion than a debugging tool but...

You didn't say which compiler you were using but, for example, with a recent g++, try turning off some of the inlining and turn on -frepo. This will make sure that, for example, there is only ever one copy of map::find.

I don't know; maybe the latest g++ does a good job of this already.

Reducing template bloat

[mattgreen]

Enough uninformed comments already. Most STL code bloat can be controlled pretty easily. What you do is make a wrapper over an STL class. For example if you're using std::vector you'd make a Vector class:

template<typename T>
class Vector
{
public:
//ctors as necessary
Vector();

T get(size_t i)
{
return static_cast<T>(vec[i]);
}

void insert(T item)
{
vec.push_back(static_cast<void*>(item));
}

pri vate:
std::vector<void*> vec;
};

You may wish to provide the exact functionality of the container you're wrapping, or you may wish to change the semantics. It's up to you.

It is kinda ugly for what it does but it works. Only one instantiation of std::vector is made, it is void*. Putting the member function definitions in the header file ensures they will be inlined if necessary.

I think Scott Meyers came up with this tip first.

Re:Reducing template bloat

[saurik]

If your data type really can be static_cast'd to a void * then there's probably a much better solution to this problem in almost 90% of the cases: it's called a "better compiler". I don't know what compiler you are using, but Visual Studio .NET finds functions whose assembly code generated the same and merges them (or whatever you want to call it: links all usages to the same implementation) at link time.

So if you have a vector of int * and a vector of long * and a vector of MyObject * and a vector of unsigned long they should all generate the same assembly code and you should only end up with a single set of these in your resulting binary.

Re:Reducing template bloat

[angel'o'sphere]

All modern C++ compilers do this, but at LINK time not at compile time. So the *.obj files are still big.
Also, probably gcc doesn't do it, no idea.
angel'o'sphere

Re:Reducing template bloat

[Daleks]

I think you mean

T get(size_t i)
{
return *static_cast<T*>(vec[i]);
}

void insert(T item)
{
vec.push_back(static_cast<void*>(new T(item)));
}

You also need a destructor that walks the vector and calls delete() on each pointer-to-void.

Re:Reducing template bloat

[uid8472]

If your data type really can be static_cast'd to a void * then there's probably a much better solution to this problem in almost 90% of the cases: it's called a "better compiler".

Alternately, it's called a vector implementation that has a partial specialization for pointers, like the example in Stroustrup.

STL: that bad?

[cronie]

Just wanted to bring your kind attention to this amazing fact: everyone tries to handle STL code bloat, is looking for a (inexistent) STL debugging tool, suggests to completely re-design compiling principles just to make STL compile a bit better, writes books about good STL coding (how to make your binary 3 times smaller), rends the air by saying "do you know what 'S' means in STL????" (one of slashdot postings)...

So why use it at all? Just because it is standard? Then go program with Fortran or Ada, they are pretty standardized, yet almost completely useless/impractical. And so STL.

(Ah... forgot this: IMO, IMO, IMHO, IMVHO, IMVVHO)

Huh? No?

Re:STL: that bad?

[bmac]

Yup, STL is *partly* responsible for C++ being mostly worthless, but let's not forget the other big nail in C++'s coffin: multiple-inheritance. The ol' diamond of death means compiler-determined (and not in any kind of spec, that I know of, tho I may be wrong) implementation, which is an auto-no-go in my book. Then again, I've *never* seen a practical reason to use multiple inheritance. Most books just use some assinine example like animals, mammals, and cows. WTF?! I use C because it's deterministic, and the implementation offers no surprises, except for bugs in the linked libs, of course :-)

Even in C# (which I use for rad development as a transition to straight C + win32/bsd), the Hashtable collection is totally fscked. After a certain number of elements it just goes to the weeds. Totally ridiculous. Some of the bugs in the *$2000* .NET IDE are so absurd that you wonder if Micro$oft isn't try to screw developers from being able to write sophisticated programs at all.

Oh well, crappy software means I still have an market :-)

Peace & Blessings,
bmac

Yes, but...

[Nicolay77]

I've seen template bloat in a lot of places, but MI bloat?

Just because something can be done in the language doesn't mean everybody just goes and uses it. You're right that MI is too prone to mistakes, and it can be replaced most of the time by java-like interfaces.

I use C++ because is deterministic, can be used to really big proyects, when it runs is fast as hell (can be faster than C when using inline functions), and because I don't use every shitty feature of the language just because it's there. The right tool for the job can be a subset of C++.