Earlier I was using gtest for my project. For the time being I am using gmock and when I have provided the path for gmock.lib, gmock_mock.lib and ..\..\include too. Then the control is not at all going into the code.
Suppose previously it was like e.g.
main()
{
printf("Hello world"); //Kept the breakpoint here, control comes here
}
Now after adding .lib and include paths it is not at all executing just strats debug and ends without going anywhere...
Please help me.
Google test lets you write unit tests using the TEST macro. It is not intended for use with normal programs that already have a main(). If you want to use google test you should create another project.
Related
I'm evaluating ginkgo at the moment - I very much like the BDD style.
However I'm unable at the moment to get the VS Code debugger to work with the framework. The official VS-Code extension provides test-by-test debugging for native go tests using CodeLens. With other languages and frameworks (eg Typescript/Mocha), I've been able to debug individual test files by setting up launch.json appropriately, but have been unable to find suitable examples for go.
Does anybody have any examples of any launch.json setups for debugging ginkgo tests (or go code invoked from any other framework)?
Thanks!
After a bit of playing around I found a way forward which perhaps should have been obvious. In case it isn't I'll leave the question and this answer here:
For a package foo, a foo_suite_test.go file is generated by the gingko bootstrap command. This contains a top-level test called TestFoo which runs the rest of the tests within the package.
This does have a CodeLens run test | debug test section above it which you can use to debug the entire suite.
It's not quite as convenient as the individual CodeLens entries which appear over each native go test, but it's easy enough to isolate specific tests to run using the Gingko F prefix.
I am hacking around a problem we've created for ourselves. What I would like to do is log a warning in our TFS builds for any code that is instantiating a specific class. I don't want a run time warning (I've got one in place already), I want a build time warning that ProjectX is using BadClass.cs. The idea being it will give us an additional place to see things that need to be fixed once our hack is no longer needed.
So something like this:
public class BadClass
{}
public class OkClass
{}
public class MyBadService
{
var a = new BadClass(); <-- Logs a warning to the build output
}
public class MyOkService
{
var a = new OkClass(); <-- Does not log a warning
}
Edit:
I do not like the idea of using Obsolete; its a misnomer. We've already got code with Obsolete attributes and this would get lost in the noise. I don't want a generic warning that I can't control the message for. I want bright neon signs with klaxons firing and a thousand exclamation points in the message. Basically everything I can do short of failing the build. I'm using the #warning precompiler directive right now and its mostly doing what I want but it requires a human to remember to add the warning. I'm looking for something more automagic. I've seen third party libraries do stuff like this so I know its possible.
Why not just use the Obsolete attribute? It can generate a build warning for you:
https://learn.microsoft.com/en-us/dotnet/api/system.obsoleteattribute?view=netframework-4.8
You can even make it emit an error too if you want.
The answer could be negative I think.
It seems that you use or call msbuild.exe to build your C# projects. But as far as I know, MSBuild in fact calls csc.exe to build C# projects in build time.
So actually what you want is logging a warning when the compiler compile the C# code if it recognize somewhere in your code uses the BadClass in build time.
If you have the source code of BadClass in the same solution, add a project reference format to the xx.csproj which contains BadClass, and set a #warning in the BadClass it may generate the warning in build time.
But I think the scenario you're in is something like: You developed one Assembly and distribute it to your user, so you want it generates a warning when the user calls one BadClass in your assembly and builds his own project to remind him of taking care when using this bad class. If so, this is impossible for msbuild AFAIK. If I misunderstand anything, feel free to know me know :)
Update:
As Daniel and Johnson said, ObsoleteAttribute is enough to do this. Though no valid way to generate warnings from msbuild aspect directly, but msbuild will call C# compiler during build process, so generates a compiler warning can output to build output window.
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.
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.