I am working on a Visual Studio 2013 C++ project with another programmer, using subversion to control the source. What we need is some way for each programmer to be able to write experimental code that will compile just for them, but not the other. So for me it might be:
#ifdef MATTHEW
CallMyTestFunction();
#endif
and the MATTHEW definition would be only there on my computer, and not theirs, even when we have both checked in and updated the source at any time.
I see there is a vcxproj.user file, but this appears to be unrelated to this task. Given this must be a common requirement, and I'm a newbie too VS2013, I hope that this is an easy one to solve. Thanks.
You are right - it's easy:
Open project properties
Go to: C/C++ --> Preprocessor
At the end of Preprocessor Definitions field add: ;USER_$(USERNAME) or ;USER_$(COMPUTERNAME) - depends on how you want to distinguish users: by username or computer name.
Then in the code:
#ifdef USER_matthew
CallMyTestFunction();
#endif
Related
I don't have formal VS training, and I usually use it to program simple tools for my research. (I'm a faculty member).
I'm currently working on a C++ library for Python using SWIG, so I followed the steps suggested in How to create a DLL with SWIG from Visual Studio 2010?
Step no. 25 says "You can't build the Debug version unless you build a debug version of Python itself", but I thought one should be able to build a debug version of the C++ stuff by writing a main that uses the library from C++ itself, without touching Python or involving Python at all. (Please let me know if I'm wrong.)
A while ago I tried creating two projects in one solution (one for the library, one for a testing app), but I wasn't quite convinced with the result, so I thought it was time to try configurations. I modified the Debug config for my SWIG project following the suggestions in Redifining C/C++ entry point in Microsoft Visual Studio 2015 and the comments (changed configuration type, extension, and entry point, and added additional dependencies vcruntimed.lib and ucrtd.lib, also excluded from build the .i and the _wrap.cxx files).
The project compiles and runs, but the methods/functions in the standard <random> C++ library are returning non-random numbers. Update/clarification: In the following code,
std::normal_distribution<double> rand::distn(0, 1);
std::uniform_real_distribution<double> rand::distu(0, 1);
std::mt19937_64 rand::generator;
void rand::init() {
generator.seed((unsigned long)time(NULL));
}
double rand::u01()
{
return distu(generator);
}
the function u01() returns 0.0 always, while when calling it from Python it works as expected.
I checked the code and the generator is being seeded correctly. Also the library is still working fine from Python, so I tend to think this is not a coding but a configuration issue.
I know this would make a better question if I posted a minimal working example, but before investing time (which I think I don't have) on it I was wandering if there is something obvious I'm missing, that a more knowledgeable VS user could easily spot. Please don't get me wrong, if I'm mistaken and the answer is not so apparent, I'll really try to make the time.
Thanks in advance.
I want to build C++ desktop applications using visual studio and wxWidgets on windows 7. I'm coming from C++ Builder.
I downloaded and built the wxWidgets libraries successfully and I can run the minimal_vc14 solution just fine. Now it comes time to create my Hello World app. I've created a new, empty C++ project and using NuGet added the wxWidgets template. Then I use class wizard to add a new class (Test3) with a base class of wxApp.
I immediately get 45 errors. The first of which is
Severity Code Description Project File Line Suppression State
Error (active) cannot open source file "../../../lib/vc_dll/mswud/wx/setup.h" Test3 c:\wxWidgets-3.1.0\include\msvc\wx\setup.h 121
digging into that file I find the following bit. The last include statement is the problem line identified above, but the problem I think is in the wxConcat6 statement. All of those ../ lead nowhere. Shouldn't that point to $(WXWIN)?
// the real setup.h header file we need is in the build-specific directory,
// construct the path to it
#ifdef wxSUFFIX
#define wxSETUPH_PATH \
wxCONCAT6(../../../lib/, wxLIB_SUBDIR, /, wxTOOLKIT_PREFIX, wxSUFFIX, /wx/setup.h)
#else // suffix is empty
#define wxSETUPH_PATH \
wxCONCAT5(../../../lib/, wxLIB_SUBDIR, /, wxTOOLKIT_PREFIX, /wx/setup.h)
#endif
#define wxSETUPH_PATH_STR wxSTRINGIZE(wxSETUPH_PATH)
#include wxSETUPH_PATH_STR
Also, smaller problem but further up the setup.h file I see that WXUSINGDLL has been defined, but I want to use libs. I can't figure out where that is being set either.
Obviously there is a configuration step I missed somewhere. Please advise.
As usual the answer can be found by reading EVERYTHING.
There are 2 things that need to be configured for this process to work correctly.
After creating the project go to the project properties and set the character set to Unicode. The default is Multi-Byte. My next quest will be to find where to change the default!
After installing the package template (or is it a template package?) go to the project properties and set shared to "statically linked build".
Presto changeo, you are ready to go. Add the following for the absolute minimum to make a compilable application. This is based on the tutorial here:creating-wxwidgets-programs-with-visual-studio-2015
bool MyProjectApp::OnInit()
{
wxFrame* mainFrame = new wxFrame(nullptr, wxID_ANY, L"MyProject");
mainFrame->Show(true);
return true;
}
wxIMPLEMENT_APP(MyProjectApp);
I suggest you make a copy of minimal sample (or widgets, as it uses more controls and links more libs), in the same location, and modify the source file as you need.
When you have played enough with it, for sure you'll find it quite easy to change the project file so that it'll use $(WXWIN) or any other custom settings.
p.s. I don't know what "wxWidgets template" from NuGet contains, but I strongly doubt it is provided by wxWidgets maintainers.
I am using Visual Studio 2013 to write code for AVR. I have been following this tutorial.
Whilst writing the code, I noticed that Visual Studio kept on underlining things like DDRB or PORTB and I keep on getting errors like Error: identifier "PORTB" is undefined, however, the program compiles correctly.
Interestingly enough, upon pressing alt-F12 Visual finds numerous files where they are defined.
Your Makefile runs compiler with an option -mmcu=YOURCHIP. This implicitly defines macro corresponding to your chip. For instance for atmega32u4 the macro is AVR_ATmega32U4. Intellisense is run 'outside' of your compiler so it's not aware of this macro and when parsing standard avr header - like avr/io.hit skips the proper inclusion of header file for your particular MCU. It's something like:
#elif defined (__AVR_ATmega32U4__)
# include <avr/iom32u4.h>
So, if you want to have intellisense support for stuff defined in those headers you might need to define that macro, at the top of your source, like this:
#define __AVR_ATmega32U4__
#include <avr/io.h>
int main() {
char a = PORTB;
}
You may find what macro corresponds to which MCU in the middle of this page
i would suggest to simply use the original IDE as Make-File generator and just call that makefile from the VS2013. This has the overhead for maintaining two different projects (but mostly actions that require changes to makefile are rare) but leaves the comfort of the good VS IDE and leaves you the way back to original IDE for debugging.
you also have to set the include directories in the vs2013 project settings to get the intellisense work.
The problem: My syntax highlighting and IntelliSense are broken. I have a C++ source file like this:
#include "stdafx.hpp"
#ifdef SOMETHING
do_some_stuff;
#endif
where stdafx.hpp (the precompiled header for the project) includes a .h file that says:
#ifdef DEFINE_SOMETHING
#define SOMETHING
#endif
and DEFINE_SOMETHING is defined in the project properties for the project (under C++ / Preprocessor).
Visual Studio is losing track, and displaying do_some_stuff; (which is actually lots of lines of code) in plain grey - I have neither syntax colouring nor IntelliSense.
The question: How can I either make Visual Studio get this right (unlikely) or switch off the fact that it's greying-out code that it thinks is #ifdef'd out?
(Rearranging the code is not an option - it's a large and complex system whose files are built in various environments, Visual Studio being only one of them. I'm using Visual Studio 2005, but I'd be interested to know whether this is fixed or workaroundable in a later version.)
If someone still interested - to turn off graying out #ifdef:
Go to Tools -> Options
Open Text Editor -> C/C++ -> Formatting
Uncheck Colorize inactive code blocks in a different color
In VS19, it's Tools / Options / Text Editor / C/C++ / View / Inactive Code / Show Inactive Blocks.
Following previous answer of aousov I check my VSCode and found this setting:
C_Cpp: Dim Inactive Regions
Controls whether inactive preprocessor blocks are colored differently than active code. This setting has no effect if IntelliSense is disabled or if using the Default High Contrast theme.
in Extensions / C/C++
This may be related to the version you are using (in my case 1.46.1).
Best,
Geoffroy
The problem you describe is par for the course in VS 2005. It is fixed in Visual Studio 2010 and later due to the completely redesigned Intellisense system. This is not directly applicable to your problem, but here's some info on the underlying architecture: http://blogs.msdn.com/b/vcblog/archive/2009/05/27/rebuilding-intellisense.aspx
There are some things you could try, and some project structure changes that can help minimize the problem's frequency, but whatever you do will be hit or miss, and the problem will eventually resurface again regardless. The only real solution is to use a newer IDE.
You can continue to use the VS 2005 build tools by installing VS 2010 along with Daffodil (http://daffodil.codeplex.com), then build your projects with the v80 platform toolset in VS 2010. This makes the migration fairly straightforward, with no need for any source code changes.
Since #define SOMETHING is defined inside stdafx.hpp, indicating that it's always defined since DEFINE_SOMETHING is defined in project configuration, would it be out of the question to also define SOMETHING explicitly in project configuration?
I used to have similar issues in VS2005 and 2008, and redundant explicit definitions sometimes helped.
I fixed this (in VSCode) by changing C_Cpp.default.intelliSenseMode
"C_Cpp.default.intelliSenseMode": "windows-gcc-x64"
I am building an ARM project on a micro-controller. Its not 64 bit either. But this does parse the directives correctly.
For Science I tried Widows-gcc-ARM and that also correctly lit up the regions that are truly active. I also know for a fact that gcc is setup and configured on my windows machine, and while I have clang and msvc, I dont use them and dont know that they work- so it could be why gcc works better for me.
You can experiment with this setting, but I am fairly certain the resolution resides in this option.
I do not know the equivalent VS option, I am sorry.
Is it possible to compile libexif with Visual Studio 2010? I have been trying to do so and have been running into a whole slew of problems. I cannot find any information about whether anybody has successfully done this before. I know I can use MinGW to compile the library, but I am in a situation where I need it to be compiled with Visual Studio and then need to link to it from a Visual C++ app. Is this possible?
To answer your question: Yes it is possible... but it is a bit of a hack. Libexif uses functions that MSVC has chosen not to implement. See my working example VS2010 project below (if you don't like downloading files then skip to my explanation of what needed changing to get it to work below):
https://www.dropbox.com/s/l6wowl8pouux01a/libexif-0.6.21_CompiledInVS2010%2BExample.7z?dl=0
To elaborate, the issues that needed a "hack" (as hinted in the LibExif readme-win32.txt documentation) are:
Libexif uses inline in several places which is not defined in VS for C, only C++ (see this)
Libexif uses snprintf extensively in the code which is not defined in VS (see here)
You need to create the config.h yourself without a ./configure command to help you. You could read through the script but most of it doesn't make sense for Windows VS2010.
You will need to define GETTEXT_PACKAGE because it's probably setup in the configure file. I just choose UTF-8, whether that is correct or not I'm not sure.
There was a random unsigned static * that needed to be moved from a .c file to the .h file as C in VS doesn't allow you to create new variables inside functions in the particular way they were trying to do.
Read the "readme-win32.txt" file. Advice is:
hack yourself a build system somehow. This seems to be the Windows way of doing things.
Don't get your hopes up. The *nix way of doing things is the configuration script that needs to be run first. It auto-generates source files to marry the library to the specific flavor of *nix. The configuration script is almost half a megabyte. Three times as much code as in the actual .c files :) You cannot reasonably get that working without MinGW so you can execute the script. Once you got that done, you've got a better shot at it with a VS solution. As long as it doesn't use too much C99 specific syntax.