Where do you put your Visual Studio preprocessor directives?
-
Context: I've been busy trying to get a very stable and old solution to build in VS2008. It's a mess of code and 40+ projects accumulated over the years - mostly MFC stuff - this means stdafx.h. Over the years, multiple developers (myself included) tended to slap preprocessor definitions in stdafx.h and I suspect other places; it's always fine until someone gets hurt. In this case, sometimes my solution will build and sometimes not. I started the general trend to put the definitions in the IDE properties window. I'm thinking this was a mistake, as sometimes the definitions propagate and sometimes not. Part of the problem of specifying directives using the IDE is that Microsoft's IDEs do rude stuff to project files. I see this all the time comparing SVN commits in an attempt to determine what has changed. The IDE has no issue with re-ordering things. So, what is your preference or practice in managing your preprocessor directives?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Context: I've been busy trying to get a very stable and old solution to build in VS2008. It's a mess of code and 40+ projects accumulated over the years - mostly MFC stuff - this means stdafx.h. Over the years, multiple developers (myself included) tended to slap preprocessor definitions in stdafx.h and I suspect other places; it's always fine until someone gets hurt. In this case, sometimes my solution will build and sometimes not. I started the general trend to put the definitions in the IDE properties window. I'm thinking this was a mistake, as sometimes the definitions propagate and sometimes not. Part of the problem of specifying directives using the IDE is that Microsoft's IDEs do rude stuff to project files. I see this all the time comparing SVN commits in an attempt to determine what has changed. The IDE has no issue with re-ordering things. So, what is your preference or practice in managing your preprocessor directives?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
We have one symbol that may be defined in our project files:
ENGINEERING. We have build configurations that define the symbol and can be used in source code for engineering-specific builds. These are used for experiments or prototyping logic before a production implementation. We avoid defining symbols in project files otherwise, since it's easy to lose a definition when changing configurations. Ourstdafx.hfiles#defineconditional compilation values likeWINVERand#include'fixed' header files for the C++ runtime, MFC, and so on. These are files where using precompiled headers improve compile times. It will also#includea file that defines the application version and build number, software title, copyright and trademark statements, and so on. This ensures that every executable file, DLL or EXE, gets the same information in the version resource. Conditional compilation symbols and manifest constants tend to be defined centrally. For a class, that's in the header file for the class. If the element is built from several classes in separate source files, they're in a separate header for the element. If a value is used throughout the project, it will typically be instdafx.h.Software Zen:
delete this; -
Context: I've been busy trying to get a very stable and old solution to build in VS2008. It's a mess of code and 40+ projects accumulated over the years - mostly MFC stuff - this means stdafx.h. Over the years, multiple developers (myself included) tended to slap preprocessor definitions in stdafx.h and I suspect other places; it's always fine until someone gets hurt. In this case, sometimes my solution will build and sometimes not. I started the general trend to put the definitions in the IDE properties window. I'm thinking this was a mistake, as sometimes the definitions propagate and sometimes not. Part of the problem of specifying directives using the IDE is that Microsoft's IDEs do rude stuff to project files. I see this all the time comparing SVN commits in an attempt to determine what has changed. The IDE has no issue with re-ordering things. So, what is your preference or practice in managing your preprocessor directives?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Never in the project file. I've been bitten in my behind too many times by symbols that were or were not defined in different project/configurations that I'll never do that again. If the project has more than a few global defines, they go to a file called
defs.h.Mircea
-
Context: I've been busy trying to get a very stable and old solution to build in VS2008. It's a mess of code and 40+ projects accumulated over the years - mostly MFC stuff - this means stdafx.h. Over the years, multiple developers (myself included) tended to slap preprocessor definitions in stdafx.h and I suspect other places; it's always fine until someone gets hurt. In this case, sometimes my solution will build and sometimes not. I started the general trend to put the definitions in the IDE properties window. I'm thinking this was a mistake, as sometimes the definitions propagate and sometimes not. Part of the problem of specifying directives using the IDE is that Microsoft's IDEs do rude stuff to project files. I see this all the time comparing SVN commits in an attempt to determine what has changed. The IDE has no issue with re-ordering things. So, what is your preference or practice in managing your preprocessor directives?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Okay, so I had another thought to dig into this deeper. I agree and understand what has been said, especially the part about avoiding stdafx.h changes. However, there are times when changes must happen, especially when building for CE and WEC7. The part that bothers me is that in my solution I have 60+ stdafx.h files - one for every project. Obviously, for a given build they should all be the same. Because of this problem, it sort of makes sense to push some settings to a prop file or something (I've been reading). Under no circumstances should application defines be in the project settings unless target related, and even that I might be able to work around.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Context: I've been busy trying to get a very stable and old solution to build in VS2008. It's a mess of code and 40+ projects accumulated over the years - mostly MFC stuff - this means stdafx.h. Over the years, multiple developers (myself included) tended to slap preprocessor definitions in stdafx.h and I suspect other places; it's always fine until someone gets hurt. In this case, sometimes my solution will build and sometimes not. I started the general trend to put the definitions in the IDE properties window. I'm thinking this was a mistake, as sometimes the definitions propagate and sometimes not. Part of the problem of specifying directives using the IDE is that Microsoft's IDEs do rude stuff to project files. I see this all the time comparing SVN commits in an attempt to determine what has changed. The IDE has no issue with re-ordering things. So, what is your preference or practice in managing your preprocessor directives?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I've had no end of issues with Microsoft and C++, whether it was their compiler being weird or Visual Studio causing me headaches. In the end I moved over to VS Code and I build my own "project files" (which are not project files but rather CMake build scripts but they do what I need) Sorry I can't be more help. I eventually gave up on the approach you took with your project.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
I've had no end of issues with Microsoft and C++, whether it was their compiler being weird or Visual Studio causing me headaches. In the end I moved over to VS Code and I build my own "project files" (which are not project files but rather CMake build scripts but they do what I need) Sorry I can't be more help. I eventually gave up on the approach you took with your project.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
Context: I've been busy trying to get a very stable and old solution to build in VS2008. It's a mess of code and 40+ projects accumulated over the years - mostly MFC stuff - this means stdafx.h. Over the years, multiple developers (myself included) tended to slap preprocessor definitions in stdafx.h and I suspect other places; it's always fine until someone gets hurt. In this case, sometimes my solution will build and sometimes not. I started the general trend to put the definitions in the IDE properties window. I'm thinking this was a mistake, as sometimes the definitions propagate and sometimes not. Part of the problem of specifying directives using the IDE is that Microsoft's IDEs do rude stuff to project files. I see this all the time comparing SVN commits in an attempt to determine what has changed. The IDE has no issue with re-ordering things. So, what is your preference or practice in managing your preprocessor directives?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
oh it gets better. So one part of my solution has a project with 15 subprojects. If I build each subproject separately, no errors. Build the project as a whole? Nope, issues out the kazoo. I feel I'm getting closer though.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
