VC++ command line compiler, linker and librarian options...

I'm currently mid way into making the final transition to C++ for new projects. I nicely hit an interregnum where I can spend a bit of time getting things together.

I've settled upon the VC++ 9.0 compiler supplied as part of the Microsoft Windows SDK (for Win7) and will be building native x86 and x64 code with it. (No .net and no itanium stuff for now...) I have the documentation for the command line arguments to cl.exe, link.exe and lib.exe and I believe I understand most of them well enough to get started... But there's a dangling question I'm hoping the MSVC++ gang can help me with...

In my home-brewed compiler driver I'm trying to decide the best combination of flags for each program to use as a default. I also provide the option of modifying them on a per project basis... but it's the defaults I'm interested in...

So...

1) What is the best default command line for cl.exe?
2) Same question but for link.exe...
3) Again, but this time for lib.exe...

Thanks in advance for your help on this....

I'd strongly advise you to use "CL" as a driver internally even when doing incremental links and creating a shared library.

For C++, the only flags you need are related to exceptions if you are linking with any code built with exceptions enabled. (By default, this includes pretty much every bit of C++ code.) Everything else is a matter of preference, but could probably be fielded with a few separate profiles. (Automatically linking against either debug or release versions of the libraries, enabling the optimizations for a given processor, and generally turning on "Wall" with debug.) A release build example of these for virtually any modern processor would be "/EHsc /MD /O2 /Ob2 /Og /Oi /Ot /Oy /G7 /arch:SSE /Zs:forScope,wchar_t /Wall /TP".

Soma

Oh, big topic. Here's my "can't-do-without-it"

Compile debug builds:
/ZI /nologo /Wall /WX- /Od /Oy- /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /GS /fp:precise /Zc:wchar_t /Zc:forScope /Gd /analyze- /errorReport:queue

Notes:
: /RTCc may be a point of contention. It will depend on your preferences. Check here. Me? I always have it on. Only very very rarely did I have to mask a value I actually intended to truncate. Otherwise this is an excellent setting to grab at runtime those pesky conversions resulting in data loss.

: /RTC1 The visual studio documentation isn't very clear here, so this is the deal: Contrary to what appears from the documentation, RTC1 does not enable /RTCc. It enables /RTCs and /RTCu. So you will want this.

:/Za Disables language extensions. For sure you want /Za unless you are programming in a contained environment like software for a company, or similar situation in which the compiler is guaranteed to stay of the same maker/brand for the life of the project.

: /showincludes probably not necessary if you aren't cross-compiling. If you are I find this useful because of all the conditional compilation that can take place in the #include regions of your code. It can be a wall of text though... but I don't tend to care about that.

Compile Release builds:
/Zi /nologo /Wall /WX- /O2 /Oi /Oy- /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm- /EHsc /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Gd /analyze- /errorReport:queue

Notes for release build:
: I always favor speed over size, as disk space is a cheap commodity these days. On the other hand, size optimizations are usually not meaningful. Program assets, including databases, tend up to become bigger by several magnitudes than any executable you may come up with. So /O2 and /Ot (/GL must also be set) greatly put the bias on speed. But there's one exception. See next notes.

Notes for both builds:
: I tend to use the multithreaded DLL versions of the runtime (/MDd and /MD), which means, for Windows, that MSVCR100.DLL must exist in the user machine where the application is meant to be installed. This means that you may need to ship your project with the C++ Redistributable Package. If you don't like this option, you may use the static versions (/MTd and /MT for the debug and release builds respectively). This frees you of the need to include the C++ redistributable Package in your application setup. It's your choice what you want to do. I do it this way because I control where my applications are installed and can guarantee the presence of the runtime.

: However (I'm that inconsistent) I tend to favor statically linking to many of the other external libraries I may be using, thus avoiding a setup that installs (too many) DLLs. Unless this choice greatly increases the executable size, it's guaranteed I will be statically linking to it. Because I put all the emphasis on speed, and none on size, after linking statically linking for the first time, I make a point of doing a release build and note the new size. If the increase is acceptable, I go with it. However, you may choose to change your bias to support some manner of size if you are statically linking a lot. A good setting is "/O2 /Os". Despite the fact they are contradictory, this works out just fine. You optimize for speed but favor size, meaning not all speed optimizations will take place if the cost in size is too big.

As for the linker, later... I've wrote enough already

Thaks Mario... Printed for reference...

There's a correction you need to do for the release build above. I was copying this from a new project in visual studio since I couldn't possibly remember all the settings, and forgot to set one correctly:

"/O2 /Oi" should read "/O2 /Ot", of course. I speak of that on the next note, but didn't have it set when I copy-pasted for you. That's the full bias on speed, if you want to go that way.

Ok... To give you a slightly better idea what I'm working on... Think of a small applet with a setup dialog that lets me set the minimum default settings for each program. Then, at runtime, I have the chance to add or change the settings before launching the compiler. Thus we have a "global" setting and a "per use" setting. So what I'm really looking for is a barebones configuration that will compile a release build... I'll be adding the optimizations, debug, etc flags on a per project basis. I will also be using cl and link separately so I need the setups for each.

Right now... the only cl flags I'm using are -c and -EHsc ... for link just the machine and subsystem flags.

For my current compiler, it's easy... I know it well enough. But, I'm just getting started with VC++ so I thought I'd ask for expert council before finalizing the project and regretting it later...

No further suggestions?

Never mind ... I got it sorted.