CODEWITHSUNDEEP
c++11macros
idanshmu
idanshmu

Reputation: 5271

C++ Executable sizes increases depending on a macro definition

So I have the following class:

#define SINGLETON Singleton::GetInstance()

//#define MY_MACRO(X) Singleton::RunS(X) 
//#define MY_MACRO(X) SINGLETON->Run(X)

class Singleton;
using Singleton_ptr = std::shared_ptr < Singleton > ;

class Singleton
{
public:

    static Singleton_ptr GetInstance();
    static wstring  RunS(__in const wstring& strSource) { return SINGLETON->Run(strSource); }

public:

    void Run(__in const wstring& strSource);

private:

    static Singleton_ptr ms_Instance;
    Singleton();
};

You can see that the I have two different ways of defining MY_MACRO.

  1. #define MY_MACRO(X) Singleton::RunS(X). AKA - def1
  2. #define MY_MACRO(X) SINGLETON->Run(X). AKA - def2

MY_MACRO macro is used ~2000 times in my entire solution.

It appears that the way I'm defining MY_MACRO has a significant impact on my executable sizes. def2 generate much bigger executables (increase by 120KB) then def1.

Questions

  1. Can anyone explain why this simple difference in the macro definition change the excusable sizes?
  2. Is there an optimal way of defining MY_MACRO to minimize executables sizes?

Upvotes: 0

Views: 334

Answers (1)

Michael Burr
Michael Burr

Reputation: 340316

With your def2 macro definition the compiler will add code to create and destroy a std::shared_ptr < Singleton > at each macro call site. With def1 the std::shared_ptr < Singleton > is created/destroyed only in the Singleton::RunS() function code.

I kind of doubt that that would account for the entire size difference, so I suspect that there might be other causes for the increased amount of code. For example, if you're compiling with GCC and including symbols, the debugging information is included in the executable and the additional function calls in def2 might account for some additional debugging information being added to the binary.

Upvotes: 2

Related Questions