I have to link the video related, but I will also add the code below.
How does this code builds without any error?
#define INTEGER Cherno
INTEGER Multiply(int a, int b){
INTEGER result = a * b;
return result;
}
When he hits Ctrl+F7 and builds the code in visual studio, it builds without any error. What do I miss?
Thanks.
p.s : I know this code won't(at least should not) compile, I just wondered why it does in the case of the video owner.
you are returning INTEGER, not result. Even in the video as linked, he is returning result.
after the edit
In that video, he has a system with a preprocessor that adds additional includes at build-time to his code. He goes over this a few seconds after that link. Cherno must be defined somewhere in that included file.
Related
I'm seeing something weird happening with Visual Studio 2015 Community. Code that worked perfectly in VS2012 crashes at startup when ported to VS2015, before main is invoked: the classic symptoms of some static initialization mess. I have a few static variables, but used properly, with the standard "Construct On First Use" pattern, e.g.:
const int& i()
{
static int *v = new int(1);
return *v;
}
The code above causes an assert from the runtime while initializing the program (see image http://i.stack.imgur.com/nsQGS.png). Pressing retry simply quits the program: no call stack, no information whatsoever.
The code below however works flawlessly:
const int& i()
{
static int *v = nullptr;
if (v == nullptr)
v = new int(1);
return *v;
}
It seems to me that VS2015 is doing what looks like some (illegal) optimization (even in a debug build), by executing the static variable initialization code during program initialization, and not the first time that the function is called, as the C++ standard requires.
I tried several variations of the code above: class methods, free functions, different objects (std::vector, cv::Mat), always with the same result: the static pointer has to be initialized to null or the program doesn't start.
So... am I missing something or is VS2015 actually messing up badly?
UPDATE:
I spent some time trying to find the minimal setup that shows the problem, and this is what I got:
create a project using the "CLR empty project" template.
add a cpp file, containing just the offending function and main(). Main can be empty, it doesn't matter: the bug occurs BEFORE it is even reached.
add 'main' as entry point (or you get a link error).
The x86 version works, but the x64 doesn't.
For comparison, a project with the identical code but created as "Win32 console application" doesn't have the problem, even after adding the /CLR option. I can see differences in the vcxproj files, but none justifies the error, although one or more of them clearly IS the cause.
Is there a way to upload a zip with the project?
Well, #bogdan got it right. My project had a mix of settings that was neither /SUBSYSTEM:CONSOLE nor /SUBSYSTEM:WINDOWS. Once I fixed that, everything started to work as expected. My test projects had the same problem, I blame Microsoft for not having a clear "CLR windows app" C++ template any more in VS2015 (they want to push you to use C# for that, which makes sense most of the times, but not always).
I found this page particularly useful in explaining all the different settings that have to be consistent (it's not just /SUBSYSTEM...).
I wish I could mark #bogdan's comment as answer, but I can't see anything to do that.
Thanks Bogdan!
I'm updating a c++ routine to move files that was written in visual studio express 2008/2010. I'm now running VS Express 2012
Obviously there are changes to the compiler because string functions have to be upgraded to strcpy_s etc. No problem. This is a console app. I never extended my C++ knowledge past C++ to C# etc. as I need little more than to be able to write small utils to do things on the command line. Still I'm able to write somewhat complex utilities.
My issue is movefile() function always fails to move with either error 2 or 123. I'm working in C:\users\alan\downloads folder so I know I have permission. I know the file is there. Small snippet of code is:
char source=".\\test.txt"; // edited for clarity.
char dest=".\\test.txt1";
printf("\nMove\n %s\n to %s\n",source,dest); // just to see what is going on
MoveFile((LPCWSTR) source, (LPCWSTR) dest);
printf("Error %u\n",GetLastError());
output is :
Move
.\test.txt
to .\test.txt1
Error 2
All of my strings are simple char strings and I'm not exactly sure, even after reading, what LPCWSTR was type def'd for and if this is the culprit. So to get this to compile I simply typedef'd my strings. And it compiles. But still it won't move the files.
The code is more complex in developing the source & dest variables but I've reduce it to a simple "just append a 1 to the file name" situation to see if I can just simply rename it. I thought C:\xxx\yyy\zzz\test.txt was maybe wrong in some fashion but that idea fell though with the above test. I've done it with and without the .\ same issue. I'm running out of ideas other than making my own fileopen read/write binary function to replace movefile(). I'm really against that but if I have to I will.
EDIT: I pasted the printf from original code that used FullPathName, I've corrected the snippet.
The fact that you are casting your arguments to LPCWSTR suggests that you are compiling your program with UNICODE defined, which means you are calling MoveFileW and the compiler warned about an argument type mismatch.
Inserting a cast does not fix that. You are telling the compiler to stop complaining, but you haven't actually fixed the problem (the underlying data is still wrong).
Actual solutions:
Use WCHAR as MoveFileW expects (or TCHAR/LPTSTR and the _T macro).
Explicitly call MoveFileA
Compile without UNICODE defined.
Thanks Andrew Medico. I used MoveFileA and the program seems to work now.
I'm not sure I turned off unicode, but I did change one item in the properties.
I'll need to read up on the compiler about unicode/ansi settings. But for now the issue is fixed and I'm sure I've got the idea of what I need to do. "research"!!!!
I'm trying to run a c++ script from IDL using the CALL_EXTERNAL function. I've been able to get it to work without arguments, but when I try to add an arg, such as a single IDL LONG INT, IDL crashes. with the error:
% CALL_EXTERNAL: Error loading sharable executable.
Symbol: main, File = /home/inspired/workspace/TestCode/main.
so
/home/inspired/workspace/TestCode/main.so: wrong ELF class:
ELFCLASS64
% Execution halted at: TEST_EXTERNAL 7
/home/inspired/IDLWorkspace/Analyze Data/test_external.pro
% $MAIN$
The test code I'm using is as follows.
The C++ code:
#include <iostream>
int main(int argc, char *argv[]) {
int temp = (int) strtod(argv[1], NULL);
std:cout<<temp;
return temp;
}
The IDL code:
pro test_external
c= call_external('/home/inspired/workspace/TestCode/main.so','main', long(2), /AUTO_GLUE)
print,c
end
This code is of course practice code, but if I can't get this to work, then there's no way I'll be able to pass a mixture of arrays, and values.
I am aware that IDL passes everything by reference unless stated otherwise. So I've tried both treating the passed argument as a pointer in the C++ code, and setting the /ALL_VALUE keyword to pass the arg as a value. Neither works resulting in the same error as above. I've read about "glue functions" but I have not been able to find a guide to making them (despite every source indicating that it's 'easy for most programmers'" >.>
Anyway, my options are as follows, and if you can help me with any, I'd be eternally grateful:
Get this CALL_EXTERNAL function to work
Have the C code grab the data it needs from memory somehow
Rewrite everything in C++ (you don't need to help with this one)
Thanks in advance.
I think you are trying to mix 32-bit and 64-bit code. It looks like you are compiling your code as 64-bit, but you are running 32-bit IDL. To check this, IDL prints it when it launches or you can check manually:
IDL> print, !version.memory_bits
64
I have an issue with my code that has some very strange symptoms.
The code is compiled on my computer with the following versions:
a. GCC Version: 4.4.2
b. CMAKE verson: 2.8.7
c. QNX (operating system) version: 6.5.0
And the code has a segfault whilst freeing some memory and exiting from a function (not dying on any code, just on the exit from a function).
The weird things about this are:
The code does it in release mode but not debug mode:
a. The code is threaded so this indicates a race condition.
b. I cannot debug by putting it in debug mode.
The code when compiled on a workmates machine with the same versions of everything, does not have this problem.
a. The wierd things about this are that the workmates code works, but also that the binary created from compiling on his machine, which is the same, is about 6mB bigger.
Now annoyingly I cannot post the code because it is too big and also for work. But can anyone point me along a path to fixing this.
Since I am using QNX I am limited for my debug tools, I cannot use Valgrind and since it is not supported in QNX, GDB doesn't really help.
I am looking for anyone who has had a similar/same problem and what the cause was and how they fixed it.
EDIT:
Sooo... I found out what it was, but im still a bit confused about how it happened.
The culprit code was this:
Eigen::VectorXd msBb = data.modelSearcher->getMinimumBoundingBox();
where the definition for getMinimumBoundingBox is this:
Eigen::VectorXd ModelSearcher::getMinimumBoundingBox();
and it returns a VectorXd which is always initialised as VectorXd output(6, 1). So I immediately thought, right it must be because the VectorXd is not being initialised, but changing it to this:
Eigen::VectorXd msBb(6, 1); msBb = data.modelSearcher->getMinimumBoundingBox();
But this didn't work. In fact I had to fix it by changing the definition of the function to this:
void ModelSearcher::getMinimumBoundingBox(Eigen::MatrixXd& input);
and the call to this
Eigen::VectorXd msBb(6, 1); data.modelSearcher->getMinimumBoundingBox(msBb);
So now the new question:
What the hell? Why didn't the first change work but the second did, why do I have to pass by reference? Oh and the big question, how the hell didn't this break when my co-worker compiled it and I ran it? Its a straight out memory error, surely it shouldn't depend on which computer compiles it, especially since the compiler and all the other important things are the same!!??
Thanks for your help guys.
... the binary created from compiling on his machine, which is the same, is about 6mB bigger
It's worth figuring out what the difference is (even if it's just the case that his build hides, while yours exposes, a real bug):
double-check you're compiling exactly the same code (no un-committed local changes, no extra headers in the include search path, etc.)
triple-check by adding a -E switch to your gcc arguments in cmake, so it will pre-process your files with the same include path as regular compilation; diff the pre-processor output
compare output from nm or objdump or whatever you have to for your two linked executables: if some system or 3rd-party library is a different version on one box, it may show up here
compare output from ldd if it's dynamically linked, make sure they're both getting the same library versions
compare the library versions it actually gets at runtime too, if possible. Hopefully you can do one of: run pldd, compare the .so entries in /proc/pid/map, run the process under strace/dtrace/truss and compare the runtime linker activity
As for the code ... if this doesn't work:
Eigen::VectorXd ModelSearcher::getMinimumBoundingBox();
// ...
Eigen::VectorXd msBb(6, 1); msBb = data.modelSearcher->getMinimumBoundingBox();
and this does:
void ModelSearcher::getMinimumBoundingBox(Eigen::MatrixXd& input);
// ...
Eigen::VectorXd msBb(6, 1); data.modelSearcher->getMinimumBoundingBox(msBb);
you presumably have a problem with the assignment operator. If it does a shallow copy and there is dynamically-allocated memory in the vector, you'll end up with two vectors holding the same pointer, and they'll both free/delete it.
Note that if the operator isn't defined at all, the default is to do this shallow copy.
You said you have to change from:
void ModelSearcher::getMinimumBoundingBox(Eigen::MatrixXd& input);
What was it before?
If it was:
void ModelSearcher::getMinimumBoundingBox(Eigen::MatrixXd input);
and the copy constructors / assignment operators weren't implemented properly it might have caused the problem.
Please do check how they are both implemented. Here's some info that might help.
This works fine:
std::vector<int> v;
v.push_back(123);
but this throws a std::length_error:
std::vector<uint32_t> v;// or vector<unsigned __int32>
v.push_back(123);
It seems to be triggered by resizing, because
std::vector<uint32_t> v;
v.reserve(2);
triggers a debug assertion "iterator not dereferencable".
This occurs on Visual Studio 2008, but the same code works fine on Mac and Linux. Can anyone suggest a way to narrow down the search for an explanation?
UPDATE:
The rat's nest of static and dynamically linked dependencies in this project made it too time-consuming to find the offending library. I gave up and rebuilt every dependency from source. I lost two days of my life and still don't know exactly where the problem was, but the app runs! Thanks for your help.
This
#include <iostream>
#include <vector>
int main()
{
std::vector<unsigned __int32> v;
v.reserve(2);
std::cout << v.capacity() << '\n';
return 0;
}
runs without any hiccups for me in VS 2008. It prints 2.
What does this do for you? If it works, too, then my first few guesses are:
You invoked undefined behavior somewhere before. By the time execution gets to the code you showed, all bets are off.
This is across DLL boundaries and you linked together DLLs/EXE built with different settings.
The way to find out about this is to distill it down to the smallest possible test case exhibiting the behavior. (That shouldn't contain more than 50LoC, ideally, it's 10.) If you don't find the problem while doing so, append the example to your question.
Since the sample code is working, your sample must be wrong :-)
Try to get closer to the problem by making your sample more like the real code in small steps. At some point it should stop working and then you can identify the culprit.
Can you check if your implementation has two or more typedefs of uint32_t? Especially under different namespaces? (I know the chances are pretty slim, but it might be worth it - in the quest for platform compatibility, different libraries try to map a specific memory size to a type, and one of them might have slipped up).
VC++ 2008 does not provide an ISO C99 header, so you must have provided the definion somehow; perhaps the definition is flawed.