I have C++ code in a project which behaves differently with Visual Studio 2010 and VS 2015.
if(return_val != 0)
{
ACE_OS::set_errno_to_last_error ();
result->set_error(errno);
}
return_val is the the return value of a prior function which has failed. So the next step is to capture error value.
In VS 2010
When result->set_error(errno) is called, while debugging, the control goes to the function _errno() , defined in source \VC\crt\src\dosmap.c.
In VS 2015
The source dosmap.c is not found.
The macro expansion for errno must be in a different place I suppose. But the behaviour should be same
Do I need to make any change in the VS settings for 2015?
Any help would be useful.
I think you have not installed the source files for the library. This would explain why it can't find the file.
errno is a strange variable, and is thread-local, and macro'ed in both platforms. What is happening in ACE_OS::set_errno_to_last_error ();?
If the function is not setting the errno value, that would explain the behavior differences.
Related
I have observed the following phenonem in the VS 2017 debugger:
if there are two static variables of the same name and type in different files, it confuses the two.
pseudo code of variable declarations
file A:
static char msg[2048];
file B:
static char msg[64];
if I debug file B the debugger shows the contents of file A's msg.
My guess would be that the case of equally named static variables was not foreseen when the debugger was developed and which variable it shows depends on the compilation order.
Question:
how can the VS 2017 debugger be "forced" to access the static variables of the currently debugged file without changing the code that is being debugged?
The trivial advice of renaming the variables is not an option for me and IMHO also not in the spirit of static variables.
This is the same issue reported under VS2019 Debugger Confused by multiple variables with same name, and fixed in VS 2019 version 16.8 back in Nov '20.
Unfortunately, there is no current or planned backport of the fix to VS 2017, per this MSFT reply.
One workaround proposed in another comment for VS 2017 is to lookup the memory address of the target variable, then watch it with the appropriate cast.
I am trying to compile the following piece of code in Visual Studio 2015 (Community version) but encountering the error shown further down below.
/*****Source Code Start*******/
constexpr char const* GetStatusAsCString(Status compute)
{
switch (compute)
{
case armnn::Status::Success: return "Status::Success";
case armnn::Status::Failure: return "Status::Failure";
default: return "Unknown";
}
}
/*****Source Code End*******/
Error message:
> Error (active) a constexpr function must contain exactly one return
> statement ArmNN_MnistTF_64b c:\armnn\armnn-devenv\armnn\include\armnn\TypesUtils.hpp 22
Note that i have made sure of the following settings:
Set the compiler front end as Clang in VS 2015:
I have set the C++ standard as C++14.
Can anyone please advise me on what else am I missing? Been struggling with this error for sometime now.
Visual Studio 2015 does not fully implement C++14 even as of VS 2015 Update 3 although it has a lot of it.
Specifically, N3652 Extended constexpr is not implemented until VS 2017. You should upgrade to the latest VS 2017 Community edition update (which at this point is 15.7)
See Visual C++ Language Conformance
I am trying to build a DLL from source-code from the Crysis Wars SDK, and have successfully done so in the past on previous versions of Visual Studio (namely 2005, 2008, and 2010).
My specific problem is this:
Error 4 error LNK2019: unresolved external symbol "struct CTypeInfo const & __cdecl
TypeInfo<char>(char *)" (??$TypeInfo#D##YAABUCTypeInfo##PAD#Z) referenced in function
"void __cdecl SwapEndian<char>(char *,unsigned int)" (??$SwapEndian#D##YAXPADI#Z)
G:\Noctis\Mods\Noctis\Code\GameCVars.obj GameDll
I have attempted to clean the code in Visual Studio and rebuild it on the off-chance this'll work, but this has not changed anything.
Am I missing something here, or has something changed from C++03 to C++11 that means that this code is no longer compilable without reverting to an older version of C++?
I have successfully compiled this code on Visual Studio 2010 in both 64 bit and 32 bit, so it must be some issue related to migrating the project to Visual Studio 2015.
Compilation on 2012, 2013, and 2015 versions of Visual Studio reproduce this error but not 2010, so it seems that the change to trigger this problem was introduced in C++11.
What am I doing wrong?
Reading the answer to mem-fun is not a member of std, it could just be that I need to include a standard library that I didn't need to include in earlier versions of Visual Studio.
If this is true, which library would I need to #include?
I have also created a GitHub repository containing only the original unmodified code provided from the SDK, for testing purposes (in the event I myself made a typo, which doesn't seem to be the case here but I've put the link here as it may be helpful).
If it matters, I'm using Visual Studio 2015 Enterprise edition on Windows 10 Professional x64.
What does the error mean?
The error message hints towards a classic "declared but not defined" scenario.
TypeInfo<char>(char*) is declared in TypeInfo.h (through some macros) and declared in AutoTypeInfo.cpp in project CryCommon.
Usually you would just make sure the CryCommon project is built correctly and linked into your final GameDll project properly and that's it.
But it turns out here that the CryCommon project has not been built for a long time - it references many other Crytek libraries etc. So the problem must be that something now needs these TypeInfo<> definitions and previously it did not.
What is referencing the TypeInfo<> code?
In your project it's function CmdHelp() in Aurora/Code/GameCVars.cpp, precisely this line:
nRead = gEnv->pCryPak->FRead( buf, BUFSZ, f );
The implementation of the FRead() method is in CryCommon/ICryPak.h:
template<class T>
size_t FRead(T *data, size_t elems, FILE *handle, bool bSwap = true)
{
size_t count = FReadRaw(data, sizeof(T), elems, handle);
if (bSwap)
SwapEndian(data, count);
return count;
}
As you can see, if bSwap is true (the default), SwapEndian() is invoked there.
Why hasn't this manifested before?
Perhaps the compiler was indeed behaving differently.
Or, more likely, you have been always compiling the project as Release before. The whole byte-swapping functionality is enabled only on big-endian systems (and your target is most probably not one of those) or during debug - then the bytes are actually swapped twice to test the related code (see CryCommon/Endian.h).
What can be done to fix it?
You have several options now:
Keep compiling as release only (probably as before). Perhaps you will never be debugging the code in a debugger anyway.
Just comment the swap call in FRead() code out. You are using it to load a text file anyway, no point in swapping the characters around.
...
FWIW, other things I had to do to make your code compile:
Check out the earlier commit before "Broken"
Load Mods\Aurora\Code\Aurora.sln
Remove non-existing .vcprojx projects
Add all 3 .vcproj files again, let them be converted to VS2015 ones
For GameDll project, add preprocessor definition _SILENCE_STDEXT_HASH_DEPRECATION_WARNING
For GameDll project, set enabled C++ exception handling /EHsc
Comment out the code above
I was under impression Visual C++ 10 had built-in static_assert. However when I compile the following
void test()
{
static_assert( sizeof( char ) == 1, "" );
}
I get
error C3861: 'static_assert': identifier not found
What am I doing wrong and how do I use static_assert in Visual C++ 10?
I was under impression Visual C++ 10 had built-in static_assert.
It indeed does and this compiles perfectly fine for me:
int main(){
static_assert( sizeof( char ) == 1, "" );
}
Do you have any other errors in your code? Maybe this error is a result of the chain of other erros.
The reason was Visual Studio was set up to use Visual C++ 9 compiler (the one which is shipped with Visual Studio 2008). I don't know how it happened, perhaps the wizard configuring Visual Studio imported paths to the previous version.
The settings is changed in project properties - on "VC++ Directories" pane. The easy way to check which compiler is invoked is to add -Bv option to the compiler command line which will make the compiler report its version.
I am getting run time crash in the following piece of code and not able to debug also. Please review and let me know what's going on.
// CppConsole.cpp : Defines the entry point for the console application.
//#include "stdafx.h"#include <iostream>#include <assert.h>
class Test : public std::tr1::enable_shared_from_this<Test>
{
public:
Test():x(0),y(0),z(0){};
int x;
float y;
double z;
};
int _tmain(int argc, _TCHAR* argv[])
{
std::tr1::shared_ptr<Test> t1(new Test);
std::tr1::shared_ptr<Test> t2 = t1->shared_from_this();
return 0;
}
I have include all the headers and the program is compiling fine. This is the error i am getting:
CppConsole.exe - Entry Point Not Found The procedure entry point
?_Xweak#tr1#std##YAXXZ could not be located in the dynamic link
library MSVCP90D.dll
If I comment out this line
std::tr1::shared_ptr t2 = t1->shared_from_this();
the program runs without crashing.
Update: Question can be closed for now. I will try to install VS feature pack and see weather the program executes without any crashes.
Googled it (The procedure entry point ?_Xweak),found this : http://blog.nilretain.org/
EDIT : I Build and Run it successfully on my msvc 2008 on xp-sp3 ,which has later version of msvcp90d.dll.
Maybe you can download and install the latest redist-version of msvc90 and rebuild.
EDIT: your dependencies says something is missing. check this out :
http://answers.yahoo.com/question/index?qid=20090623140325AAInugo
You need a template argument:
std::tr1::shared_ptr<Test> t1(new Test);
std::tr1::shared_ptr<Test> t2 = t1->shared_from_this();
The compiler should report an error if it is not present. (Visual C++ 2010 does)
It appears that your compiler is not linking against a DLL with the needed runtime functions. For instance, if you added the headers to your include path, but don't link to the latest version of the C++ runtime (check your project's settings), or installing the Visual C++ 2008 feature pack didn't work, or you installed the feature pack but then tried to compile from Visual Studio 2005, etc.
Basically the "process the source code (including headers)" step is working fine, but the "link all the DLLs" step is failing. And it's failing because the runtime you're linking against doesn't have the needed functions for shared_ptrs or weak_ptrs.
I had this problem when developing under M$ Windows SP3 with M$ Visual Studio 2008. I tried and combined many hints that I could find on the web. To no avail. The solution was simple, I had to install SP1 pack for M$ Visual Studio 2008!
The thing is that my external DLLs used C++ TR1 functions that I was not aware of. The M$ Visual Studio 2008 without SP does not have the right runtime DLLs.
So, just make sure you have that SP1 for your M$ Visual Studio 2008 first before trying any other solution.