Roland

This last version of 3DCoat really makes it :lol: I'm selling my ZBrush license.

use this one instead

I can have a look at it

Nice that you found your pipeline. Just finding the right tools that suites your own Karma takes its time. I have been running like a rabbit between different tools for a long time and now I also have found my pipeline.

Okidoki

But then you are forcing users to have Boost installed.

Yes. That one looks cool. Didn't know about it. Thanks

For those who wants to use GCC and still have an nice open source IDE you can have a look at CodeBlocks

So GCC is roughly about 20 times faster than MSVC. Interesting result. I have not used the GCC compiler for some years but in old days GCC used to be slower. Things seems to have changed then.

Yes. This will be great.

In this case the problem had nothing to do with libraries.

std::string period.

For such external source files (c or cpp which you have no control of) added to project you have to select them and go into properties. Change those to "Not using precompiled headers". They do not have the #include "your precompied header file.h" as fist statement and cant be used for this.

Thats nice. And thinking of it, if someone needs to have it as a DLL (C# users) it can be solved by creating a own DLL containing the lib.

As I'm using C++ a static lib would be fine. Specially as you will not have to bother about using memory over a DLL boundary. But the downside would be that the C# users would suffer as the import to C# wrappers must go through a DLL.

Nice. Hello World is a good start

You should always do this in any case. You can preferable use the new way of doing this in all headers #pragma once your code .... .... ... This has nothing to do with compilation speed. This is a way to avoid double declarations in nested includes. Regarding changing headers often while developing you can go this way. Include all your own headers in the pre-compiled header when they are stable. This means that while you are changing things often in a header while working, you should not include this header in the pre-compiled header. Then when your work is more stable and does not change to often you may include the header file in the pre-compiled header. A little religious note about this: ---------------------------------- Making frequent changes in header should not be needed if you have thought things through before hitting the keyboard. When I write code I try to write the headers first with all that should be needed. Then I go into implementing the headers. If I then have to make a change in a header it should be more of an emergency and tell that I did not think enough before starting with the code. Of course this is true in a perfect world and of course I have to change my headers now and then. But in general they should not have to be changed to often. If you have to make changes in the headers often, it may be pointing to the fact that you are creating to big classes. Always try to break things down to as small pieces (classes) as possible and don't fall into the trap of having four of five giants taking care of all. This is my personal notes. Others may think different. But I thought it could be mentioned here as a note about pre-compiled headers. ----------------------------------

Maybe this could help

for small cpp files less than a second

Just great work as usual.

You need one header that is the target for pre-compiling, in our example its the leheader.h. Which headers to be included in the pre-compilation is defined by you when you include other headers in leheader.h. This way you can tell which headers to be pre-compiled and not. The natural thing is to add all system/sdk/stdlib-headers there as the never changes. Then you could add your own headers that you don't change so often. One suggestion is to include the ones that are stable and have the experimental ones not included. Then when the experimental ones become stable you can include them. In previous versions of VS there was an alternative where you could tell to use all headers as precompiled. That options was removed as it did not work well at all (I don't know why as I never used it). Anyway, since the Jura-period they have recommended the method used now. Hope that this helped a bit

No. That's why Pre-Compiled header option exists. This can't be set by default as there is a need to define which file should be used as pre-compile header.

Thats true, but I'm not talking about compiling source files. Here we are speeding up things by using pre-compiled headers (not cpp). Normally the compiler has to pre-compile each included header every time when in compiles a source file. That takes time. The option to use pre-compiled headers makes this pre-compilation only needed when any of the included headers changes. This results in a faster compilation as you normally make changes in the cpp files. The compilation time can be improved a great deal in big projects.

Make one header file that includes most of the system includes and your most common includes. Then include that header file first thing in each source file. Name it anything you want, lets say leheaders.h #pragma once #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <string> #include <vector> #include ..... #include ..... etc etc etc..... Make one leheaders.cpp that contains one statement #include "leheaders.h" In project properties Set C++ settings "Precompiled headers" to "Use" Precompiled Header = leheaders.h Select leheaders.cpp and Properties Set C++ settings "Precompiled headers" to "Create" This will precompile your headers so they don't need to be parsed and compiled on each project compile. The only time precompilation is done is when you change something in the header files included in leheaders.h or if you selects rebuild. You must include leheaders.h as first include in all your sourcefiles. Also check that "C++/Browse Information" is "No" Edit: "C++/Code Generation/Enable Minimal Rebuild" should also be set to "Yes" "C++/General/Debug Information Format" set to "Program Database (/Zi)"

use precompiled headers