I want to create a MFC project in Visual Studio where, on button action to go through various functions(like 'prime'). I don't know where to write these function and also the global variables i need for them(p and flag). I have searched on the internet and tried more methods(like declaring them in .h files and so on, but didn't worked). Take in my mind that i very new to this. Here is my code:
long int p,flag;
void CMFCApplication1Dlg::OnBnClickedClickMe()
{
flag = prime(p);
//more code
}
int prime(long int pr)
{
//code
}
Related
I have a DLL containing multiple functions that can fastly perform arithmetic operations on extremely large integers. My test program runs smoothly in my Visual Studio 2019, as follows.
int main()
{
HINSTANCE myDDL = LoadLibrary(L".\\BigIntDLL.dll");
typedef string (*func)(string a, string b);
func expBigInt = (func)GetProcAddress(myDDL, "expBigInt");
string y= expBigInt("2", "10000");//it can calculate 2^10000 and return it as a string
cout << y;
}
So, I moved the code directly into my Qt project as a part in widget.cpp, and also placed the BigIntDLL.dll and .lib in the same directory of the project. The compilation was successful, but when debugging my interface, the program broke with a Segmentation fault error due to a call to the expBigInt function.
void Widget::on_expButton_clicked()
{
getTextEditNum();
Output=expBigInt(Input1,Input2);//crashed here
writeResult(Output);
}
I am not really sure where the real problem is, but I now suspect that I have not successfully called the functions in this DLL, causing some memory issues.
I'm working on a project for my university, here is a class I have made using C++. Having this class completely breaks Visual Studio compiler. Not including this class will run the program perfectly fine. This is my first time using c++ classes, I'm very familiar with Java OOP programming but this doesn't make sense to me.
#include <vector>
#include <string>
using std::string;
using std::vector;
namespace Studentas {
class Studentas {
private:
string vardas_, pavarde_;
float mediana_, vidurkis_, egzaminas_;
vector<int> pazymiai_;
public:
inline string vardas() const { return vardas_; }
inline string pavarde() {
return pavarde_;
}
inline float mediana() {
return mediana_;
}
inline float vidurkis() {
return vidurkis_;
}
inline float egzaminas() {
return egzaminas_;
}
inline vector<int> pazymiai() {
return pazymiai_;
}
inline void pakeistiVarda(string _vardas) {
this->vardas_ = _vardas;
}
inline void pakeistiPavarde(string _pvd) {
this->pavarde_ = _pvd;
}
inline void pakeistiEgzamina(float _egz) {
this->egzaminas_ = _egz;
}
inline void pakeistiMediana(float _med) {
this->mediana_ = _med;
}
inline void pakeistiVidurki(float _vid) {
this->vidurkis_ = _vid;
}
float skaiciuotiMediana();
};
}
These are the errors I get, I don't believe any of them are relevant as there's 13 errors coming from the compiler.
There are instantly a ton of errors, almost like the compiler doesn't like something. But nothing is marked incorrect visually.
Nothing is wrong with your code, it works fine for me. check this out. Try going to Properties -> Linker -> Debugging -> Generate Debug Info Generate Debug Information optimized for sharing and publishing.
Do you build your project before debugging?
If so, you could go to Project properties->Linker -> Debugging, then set the Generate Debug Info to Generate Debug Information (/DEBUG) or Generate Debug Information optimized for sharing and publishing (/DEBUG:FULL).
For more details I suggest you could refer to the Doc:/DEBUG (Generate Debug Info)
When you specify /DEBUG with no additional options, the linker defaults to /DEBUG:FULL for command line and makefile builds, for release builds in the Visual Studio IDE, and for both debug and release builds in Visual Studio 2015 and earlier versions. Beginning in Visual Studio 2017, the build system in the IDE defaults to /DEBUG:FASTLINK when you specify the /DEBUG option for debug builds. Other defaults are unchanged to maintain backward compatibility.
If you are using vs2107 and above, I suggest you should use / DEBUG: FULL.
I noticed that the auto-complete options like [Cltr + space] in Visual Studio IDE can only paste function names.
Here is an c++ example code:
class TestClass
{
public:
explicit TestClass();
virtual ~TestClass();
void callThisMethod(int a, char ch, string s);
}
// TestClass.cpp file
void TestClass:callThisMethod(int a, char ch, string s){.....}
// main.cpp file:
TestClass tc;
tc.callThisMethod(int a, char ch, string s); // here
So is there any way to bring function calls with all necessary parameters.
The Visual Studio correctly designed for what it does:
The intellisense will make you on the right track by keeping showing the function signature, so that you would know which parameters are actually required. For an instance:
From the example, it can be clearly seen here that as longer as you type and provide the arguments, the popup will help you to go through the function signature.
Thus, it doesn't seems the feature you're asking is currently available, neither it's required due to the intellisense which actually helps you a lot in this situation.
In an app I'm working on (built with Visual Studio 2015), I have the following structure:
Project A -> Native DLL project. This references project B
Project B -> Native static lib project. This references project C.
Project C -> Static lib project with CLR support turned on.
Project A call a function from Project B, which in turn creates an instance of a class from Project C. The instantiated class has a member which is a wrapper around a managed object.
The problem I'm facing is that when I build the code in Release mode, once the code tries to instantiate the class from Project C, it blows up and says that heap has been corrupted. The place where it blows up seems to be the following function from C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\crt\src\vcruntime\pureMSILcode.cpp
[System::Diagnostics::DebuggerStepThroughAttribute]
_CRT_SECURITYCRITICAL_ATTRIBUTE
int __clrcall _initterm_e (
_PIFV * pfbegin,
_PIFV * pfend
)
{
int ret = 0;
/*
* walk the table of function pointers from the bottom up, until
* the end is encountered. Do not skip the first entry. The initial
* value of pfbegin points to the first valid entry. Do not try to
* execute what pfend points to. Only entries before pfend are valid.
*/
while ( pfbegin < pfend && ret == 0)
{
/*
* if current table entry is non-NULL, call thru it.
*/
if ( *pfbegin != NULL )
ret = (**pfbegin)();
++pfbegin;
}
return ret;
}
Now here is the thing ... If I turn Project C into a DLL (rather than a static lib) everything works fine. What's more interesting is that all this used to work fine when I built the code in Visual Studio 2013. With VS2015, I don't get any heap corruption if I build the code in debug, but it blows up in release.
I'm aware that having CLR support in a static lib is not the best idea, however I can't seem to find any good information about the issues in having CLR support in a static lib. Additionally this was working all fine in VS2013.
I can just change Project C to be a DLL (which makes more sense when having CLR support), however I would like to understand what has caused the current settings to blow up when converting to VS2015.
The following is a close representation of the relevant code from each project:
Project C:
Foo.h
class FooA
{
public:
FooA();
private:
struct FooAImpl;
std::unique_ptr<FooAImpl> _impl;
};
Foo.cpp
struct FooA::FooAImpl
{
gcroot<ManagedFoo^> managedFoo;
FooAImpl(ManagedFoo^ managedFoo_) :
managedFoo(managedFoo_)
{
}
};
FooA::FooA()
{
_impl = std::unique_ptr<FooAImpl>(new FooAImpl(gcnew ManagedFoo()));
}
Project B:
FooB.h
class FooB
{
public:
Result GetResult();
};
FooB.cpp
Result FooB::GetResult()
{
FooA fooA;
Result r = ...;
return r;
}
Project A
FooC.h
class FooC
{
public:
void Bar();
private:
std::unique_ptr<FooB> m_pFooB;
};
FooC.cpp
void FooC::Bar()
{
Result r = m_pFooB->GetResult();
}
Hope someone has some information around what issues may occur in having a static lib with CLR support. Hope the information I provided describes the problem well.
The debugger in Visual Studio 2010 is recently pointing at the wrong lines and/or skipping lines and I have no idea why this is. This is a CUDA project and only happens in CUDA files. I've noticed the following:
It always happens at the same part of the program.
The lines it points to are always the same, i.e. not random.
Putting extra code after the culprit lines changes which lines it points to.
It only happens in .cu-files. Moving the code to a .cpp-file does not recreate the problem.
What I have tried:
Clean and rebuilt the solution.
Install SP1 for MSVC10 and do all possible updates via Windows Updates
Set the compiler to not use optimizations in debug mode for both C/C++ and CUDA C/C++
Manually delete all created files and then rebuild from the solution folder.
Deleting the folder C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Recreating the solution only using the source files.
Disabling my extensions.
I've managed to reduce the code to the following which might reproduce the problem. Mind that this code has to be inside a .cu-file and most probably needs to be compiled with the cuda compiler for C/C++. Including boost is not really necessary, but this example does show what problems I'm having. A shorter example is at the back.
#include <boost/numeric/ublas/matrix.hpp>
using boost::numeric::ublas::matrix;
struct foo {
foo() : mat(NULL) {}
matrix<float>* mat;
};
bool func(foo *data) {
bool status; // <- skipped line
status = false;
if (status) {
std::cout << "test\n";
return (status); // <- error reported here
}
int size = data->mat->size1(); // instead of here
return status;
}
int main(int args, char* argv[]) {
func(NULL); // force error by passing NULL pointer
return 0;
}
Does anyone have any idea how to solve this or how this could be happening? It's pretty annoying having to debug this way.
Shorter example only showing the skipping lines. No external libraries necessary.
bool func() {
bool status; // <- skipped line
status = false;
return status;
}
int main(int args, char* argv[]) {
func();
return 0;
}
Since the program only contains CPU instructions and variable declarations of types that have no construction contain no instructions, the debugger will not stop there. It just executes instructions and then uses the debugging information that the compiler provided to find the relevant line of source code.