Tools for Analyzing C++ Class Code Generation? 48
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?"
This article should have been called (Score:3, Funny)
Re:This article should have been called (Score:5, Informative)
Re:This article should have been called (Score:2)
Templates and OOP (Score:1)
Templates can be combined nicely with several design patterns, such as observer, visitor, factory, and iterator. Template base classes for each of these design patterns can provide the common behaviors and implementations of these design patterns.
In addition to augmenting traditional OOP, templated classes can still have a
Re:This article should have been called (Score:1)
cat got my tongue (Score:1, Funny)
Unfortunately, I've never used C++ before in my life. (except for a "Hello World!" back in High School)
Me Too! (Score:4, Funny)
Can code generation do this? It could really increase my chances of a good mar^H^H^H err profit yeah.
Re:Me Too! (Score:2)
Very cheap visualization tool (Score:2, Funny)
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 arc
Uhhh, perl or python? (Score:4, Interesting)
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
Re:Uhhh, perl or python? (Score:2)
Re:Uhhh, perl or python? (Score:2)
Re:Uhhh, perl or python? (Score:2)
Nope (Score:1, Informative)
Huh? What did you expect? Templates lead to bloat per definition. That's what they do: a lot of binary code is generated by a small amount of typing. If bloat becomes a problem: redesign.
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
OpenC++ (Score:5, Interesting)
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 (Score:4, Informative)
Re:John Lakos (Score:1)
Turn off inlining (Score:2, Interesting)
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.
Re:Turn off inlining (Score:1)
Reducing template bloat (Score:5, Informative)
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 [Mod Parent Up Please] (Score:1)
Re:Reducing template bloat (Score:4, Interesting)
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 (Score:1)
Re:Reducing template bloat (Score:3, Informative)
Also, probably gcc doesn't do it, no idea.
angel'o'sphere
Re:Reducing template bloat (Score:2, Informative)
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.
Re:Reducing template bloat (Score:3, Interesting)
Re:Reducing template bloat (Score:1)
You also need a destructor that walks the vector and calls delete() on each pointer-to-void.
Calling delete or delete[] on a void pointer is not safe. A void pointer is opaque, and so how would the compiler know which delete function to call? Each class can have its own delete and delete [] operators. You can get around this problem by casting the void pointer to the original type before deleting it.
If you don't have delete and delete [] operators for your classes, but always use the global delete a
Re:Reducing template bloat (Score:1)
delete static_cast <T *> (vec[i]);
Specialization (Score:2)
Re:Reducing template bloat (Score:2)
Re:Reducing template bloat (Score:2)
You'll just be creating multiple instances of Vector for each type. You save nothing. The STL classes are not that large at all. Most of the vector functions are really small and by the time you wrap them all you'll have the same size wrapper class.
Get a better linker. (Score:1)
{} - The empty sig
radical idea and shameless plug :-) (Score:1)
Radical idea: Implementation versus specification (Score:1)
STL: that bad? (Score:2, Insightful)
So why use it at all? Just because it is standard? Then go program with Fortran or Ada, they
Re:STL: that bad? (Score:1)
Re:STL: that bad? (Score:1)
I'm afraid STL is responsible for discrediting the C++ language and for the fact that C is still in wide use novadays, whereas it should have been replaced with its successor, C++. In C vs C++ wars people usually argue just around efficiency. It is obvious (to me at least) that the C++ language itself with good OO design can produce sound code. Only when it comes to STL and templates in general you easily loose control over code generation and also source code porta
Re:STL: that bad? (Score:3, Interesting)
Yes, but... (Score:3, Insightful)
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 r
Re:Yes, but... (Score:1)
I'd still like a clean C++ compiler that
doesn't include all the cruft necessary
to implement templates & MI, tho. I think
that would streamline things even more.
And yes, I do desire the inline directive
for my C code. I mean, c'mon, it has to
be pretty easy, right, especially if they
can do all the MI and template crap, what's
a little parse tree substitution and one
more keyword
Peace & Blessings,
bmac
www.mihr.com -- True peace & happiness
are just a wish away...
Re:Yes, but... (Score:1)
I'd also leave templates, they are useful and potentially powerful, but should be used with great care - that's it.
He-he, so your circumcised compiler gets back to life, almost.
Just don't use STL, and leave the compiler alone
Re:STL: that bad? (Score:2)
STL is incredibly useful, but like many powerful tools it is not 100% intuitive to use effectively at first go. It is e
Re:STL: that bad? (Score:1)
This reminds me the situation with Java: Sun promised to its army of Java fans that there would be hardware Java VM by 2000. Sun failed to implement Java processor but the trick worked and Java is still popular.
So where are those compilers?
You're right!!! (Score:1)
I believe that mastering templates is more complex and long than mastering everything else in the C++ language. And that's their main pitfall, despite being absolutely powerfull and even turing complete (just see some