C / C++ / MFC

27-Sep-06 2:17

Probably a stupid question but this has been bugging me. When a library is added to a project (either .lib or src), there are usuallu many functions contained in the library that are never used. Are these added to the final build?

Is there any way to get VC6 to list all unused functions/code?

Rajesh R Subramanian27-Sep-06 2:30

Rajesh R Subramanian

27-Sep-06 2:30

If you link to a library and if you are using atleast one function that is exported from that library, then of course it goes for the final build. On the other hand, if you are building for "Release" and you have included a library which is absolutely not referred at all, linker warning 4089 will be displayed. And you can choose what to do.

http://vcfaq.mvps.org/ide/7.htm

If your ship doesn't come in, swim out to it. - Jonathan Winters

Waldermort27-Sep-06 2:42

27-Sep-06 2:42

I'm not talking about linking against a library in that manner, but rather about the functions included within the library.

Obviously in the case of a dll, the functions will always be there, but what about static libraries. Are all of the functions within the .lib also included within the .exe, I guess so.

What about a library in src form (.h and .cpp), are all those unused functions added to the exe or can they be optimized in some manner?

Zac Howland27-Sep-06 3:56

Zac Howland

27-Sep-06 3:56

waldermort wrote:
Are all of the functions within the .lib also included within the .exe

No. All functions are compiled, but unreferenced ones are not linked.

If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week

Zac

Maximilien27-Sep-06 2:41

Maximilien

27-Sep-06 2:41

unused functions are removed from the final link.

Maximilien Lincourt
Your Head A Splode - Strong Bad

Waldermort27-Sep-06 2:44

27-Sep-06 2:44

Could you be a little more clear please Cool | :cool:

function from a .lib, src or both?

Mike Dimmick27-Sep-06 4:04

Mike Dimmick

27-Sep-06 4:04

The linker includes everything in a section (called a COMDAT) where any member of that section is referenced, if the /OPT:REF switch is specified (which is the default if /DEBUG is not specified). By default the compiler simply generates one COMDAT per source file, but by specifying the /Gy switch, it will instead generate one COMDAT per function. The combination of /Gy and /OPT:REF can be used to eliminate some dead code.

A library is simply a collection of .obj files; the behaviour will depend on whether /Gy was used to build the .obj files in the library. Import libraries are always reduced to the minimum set referenced.

Note that there are techniques which will prevent /OPT:REF from being able to eliminate otherwise unreferenced functions. If you reference a function in a table of function pointers, for example, and the table itself is referenced, all the functions will be included even if those entries in the table are unused. This can apply to MFC message maps and C++ virtual function tables.

Link.exe can tell you what it did include. Generate a map file (with /MAP). This tells you the address at which every function was generated.

It can be confusing for a new developer to find bits of dead code - I've wasted plenty of time trying to work out how to fix code that wasn't actually being called. Since adopting source control, I now delete code that I discover to be dead and which couldn't fulfil any useful purpose if a class was reused. Sometimes you find routines implemented 'for completeness' that actually aren't used in the project which the class was created for. These should be a red flag because it usually means they weren't tested as thoroughly as the rest of the class.

Stability. What an interesting concept. -- Chris Maunder

Waldermort27-Sep-06 4:50

27-Sep-06 4:50

Thankyou for that excellent explanation.

Close an instance

ayol1212227-Sep-06 1:34

ayol12122

27-Sep-06 1:34

Hi all...
I'm trying to code a tool to navigate some web pages.
I start an instance of IE by this code:

CoInitialize(NULL);
HRESULT hr;
IWebBrowser2* pWebBrowser = NULL;
hr = CoCreateInstance (CLSID_InternetExplorer, NULL, CLSCTX_SERVER, IID_IWebBrowser2, (LPVOID*)&pWebBrowser);

And I destroy it with this:

pWebBrowser->Release();
pWebBrowser = NULL;
CoUninitialize ();

Well...this is Ok...but IE window is not closed after Release and CoUninitialize. And so even if I close my program, IE window is still there open! And its process is not killed. How can i close also IE window???

Thanx Smile | :)

Re: Close an instance

Stephen Hewitt27-Sep-06 1:56

Stephen Hewitt

27-Sep-06 1:56

Just a guess, but you could try the IWebBrowser2::Quit method.

Steve

Re: Close an instance

prasad_som27-Sep-06 1:58

prasad_som

27-Sep-06 1:58

ayol12122 wrote:

And I destroy it with this:
pWebBrowser->Release();pWebBrowser = NULL;CoUninitialize ();

This is not destroying web browser. There are other methods.
you can use ,

long hWnd;
pWebBrowser->get_HWND(&hWnd);
SendMessage(hWnd,WM_CLOSE,0,0);

pWebBrowser->Quit();

Prasad
Notifier using ATL | Operator new[],delete[][^]

Re: Close an instance

ayol1212227-Sep-06 3:31

ayol12122

27-Sep-06 3:31

really really thanx!!
i used quit and everything is ok.
Thanx to both you answered to my question Wink | ;)

error LNK2001

Rems Kris27-Sep-06 1:24

Rems Kris

27-Sep-06 1:24

Hi,

I've created an ActiveX control. The Control class (***Ctl) in it should be derived from a class in another dll (which is also created by me). I want to load the ActiveX control dynamically in a container exe and check if the Ctl class is derived from the base class in the dll (This container is also created by me).

The base class in the dll is called TusMacroOcxBase and it is derived from COleControl.
The Ctl class in the ActiveX control which is derived from TusMacroOcxBase is called CTusSampleOcxCtrl.

I decided to make use of CRuntime class's methods to check the class type information (Since COleControl is already derived from CObject). So I proceeded by using the DECLARE_DYNAMIC/DECLARE_DYNCREATE and IMPLEMENT_DYNAMIC/IMPLEMENT_DYNCREATE macros. I also enabled RTTI in the container exe.

My problem is that when I write IMPLEMENT_DYNCREATE(CTusSampleOcxCtrl, TusMacroOcxBase) in CTusSampleOcxCtrl class's .cpp file, it gives error LNK2001.
The error message is given below.
TusSampleOcxCtl.obj : error LNK2001: unresolved external symbol "public: static struct CRuntimeClass const TusMacroOcxBase::classTusMacroOcxBase" (?classTusMacroOcxBase@TusMacroOcxBase@@2UCRuntimeClass@@B)

Here is the code snippet:

Base class - .h

class _declspec(dllexport) TusMacroOcxBase : public COleControl
{

public:

DECLARE_DYNAMIC(TusMacroOcxBase)
....

Base class - .cpp

IMPLEMENT_DYNAMIC( TusMacroOcxBase, COleControl )

Derived class - .h

class CTusSampleOcxCtrl : public TusMacroOcxBase
{
DECLARE_DYNCREATE(CTusSampleOcxCtrl)
....

Derived class - .cpp

IMPLEMENT_DYNCREATE(CTusSampleOcxCtrl, TusMacroOcxBase)

I can solve the error easily by replacing IMPLEMENT_DYNCREATE(CTusSampleOcxCtrl, TusMacroOcxBase) with IMPLEMENT_DYNCREATE(CTusSampleOcxCtrl, COleControl), but I cant do that since I need to get the exact base class of CTusSampleOcxCtrl in the container exe. If I give COleControl there, I will get the base class as COleControl only.
Is there any other way? I've tried different combinations of DECLARE_DYNAMIC/DECLARE_DYNCREATE and IMPLEMENT_DYNAMIC/IMPLEMENT_DYNCREATE also.

Any help will be greatly appreciated.

Thanks in advance,
Rems.

Rinu_Raj27-Sep-06 1:39

Rinu_Raj

27-Sep-06 1:39

Please check whether you hav added lib path Project|Properties|Linker|Input|Addition
al Dependencies.

Rinu Raj

Rems Kris27-Sep-06 1:48

Rems Kris

27-Sep-06 1:48

Thanks for your response.
I've already added the lib.

Rinu_Raj27-Sep-06 2:04

Rinu_Raj

27-Sep-06 2:04

is that lib available in path ? if not please add the path
what about the header file associated is that compatible with the lib ?

Rinu Raj