15,993,836 members
Sign in
Sign in
Email
Password
Forgot your password?
Sign in with
home
articles
Browse Topics
>
Latest Articles
Top Articles
Posting/Update Guidelines
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
quick answers
Q&A
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Javascript questions
View Visual Basic questions
View .NET questions
discussions
forums
CodeProject.AI Server
All Message Boards...
Application Lifecycle
>
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Work Issues
Design and Architecture
Artificial Intelligence
ASP.NET
JavaScript
Internet of Things
C / C++ / MFC
>
ATL / WTL / STL
Managed C++/CLI
C#
Free Tools
Objective-C and Swift
Database
Hardware & Devices
>
System Admin
Hosting and Servers
Java
Linux Programming
Python
.NET (Core and Framework)
Android
iOS
Mobile
WPF
Visual Basic
Web Development
Site Bugs / Suggestions
Spam and Abuse Watch
features
features
Competitions
News
The Insider Newsletter
The Daily Build Newsletter
Newsletter archive
Surveys
CodeProject Stuff
community
lounge
Who's Who
Most Valuable Professionals
The Lounge
The CodeProject Blog
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
help
?
What is 'CodeProject'?
General FAQ
Ask a Question
Bugs and Suggestions
Article Help Forum
About Us
Search within:
Articles
Quick Answers
Messages
Comments by marcus obrien (Top 4 by date)
marcus obrien
26-Jan-17 6:57am
View
Thanks Stefan for the link, I can see the option now inside VS where you can right click (context menu) on the .cpp, then properties, C++, Preprocessor, Process to file -> Yes. Then go to output folder and examine the .i file
Its better than nothing, at least I can see what the translation unit looks like, and I don't have to -I any options (as they are already setup in the .vcproj). I'll write the extraction macro myself later but for now like I said it's better than Nothing ! Thanks again (and no, I still don't care about name clashes :-)
marcus obrien
26-Jan-17 6:48am
View
Hi, I don't have any clashing name symbols,so again I dont care about this at all. I have never mentioned anywhere that I want to check to see if names clash anywhere. Again I want to put all the #define pre-processor names in a single file. I am not adding any, or changing any existing behaviour, Iam testing the value of the #defines. And no I do not want any system files (again I never mentioned this). So what I want is to go through all the code (not just header files), that we have written (so excluding all system code and code that comes with C++), and copy all the #define <THIS VAR> intos a single file (so not changing any source - so no problem with name clashes - as I am not changing anything), and TEST the value ie #ifdef <the_var> #pramga message "THE VAR IS ON" #else #pramga message "THE VAR IS OFF" #endif. So no problem with any name clashes anywhere (As I wont be extracting the name of std::valarray::min() or std::valarray::max() as they are not #defines), and no problem with the millions of system defines (as I will only be searching inside the folders we have created from the checked out repository.
marcus obrien
26-Jan-17 4:13am
View
Hi, Naming clashing is by no means what I am interested in. All the code I work on is contained in namespaces, so this is not an issue I am bothered about. I think you missed the point of what I am asking, what I want is a way to tell what pre-processor defined code will be included in the current build config.
The results would be totally sensible, and exactly what I want. I do want to know every pre-processor variable's state, in order to ascertain what the compiler will build. The code in this solution is written this way due to it being a huge project with 400 projects in various languages, assembler, C, C++, C#, and scripts etc. It has to compile on 9 different platforms, and can be both native and cross compiled, so it relies heavily on code gen and platform specific code that is controlled by the pre-processor. I am asking if there is a tool that exists that would grep for all the #define, then create a fiel to dump them in using the generic macro of #ifdef <pre-proc directive> #pragma message("VAR" state is blah #else #prgma message <pre-proc dir> NOT defined #endif. I'm sure other people when they see a line of code like this #if (define MONKEY) && !(define DOG) || RELEASE || (DEBUG && FOG) || NO_TRACE && GOAT etc.
marcus obrien
24-Jan-17 17:47pm
View
That sounds reasonable, it would be great to have script/feature in VS that would grep through the code, output all the defined pre-proc directives to a file with the pragma code above wrapped around each one, automatically, then one could compile the source and see the values of every define in the code base. I'm working on a VS sln with over 300 projects in it. Maybe I could generate a script, unless anyone has got one already ?