Slashdot Mirror


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?"

6 of 48 comments (clear)

  1. Re:This article should have been called by be-fan · · Score: 4, Informative

    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.

    --
    A deep unwavering belief is a sure sign you're missing something...
  2. Nope by joto · · Score: 1, Informative
    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.

    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 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?

    I wish I did. But most likely, I think you are fucked. Without an understanding of the code, it's hard to debug template problems. Find out where the bloat is by analysing the source code, not the binary.

  3. John Lakos by sohp · · Score: 3, Informative

    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.

  4. Reducing template bloat by mattgreen · · Score: 5, Informative
    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.
    1. Re:Reducing template bloat by angel'o'sphere · · Score: 2, Informative

      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

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    2. Re:Reducing template bloat by uid8472 · · 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.