I am getting an error "the system cannot find the file specified" in Visual Studio C++ when I try to run my program.
You pressed F5 to start the program.
The code was compiled.
The linker failed because it couldn't find int main()
This means there was no program to run.
To fix it you need to define a function called main* that will look like this:
int main (void)
{
// Call the function that you think starts your program, i.e.
Bob();
wprintf(L"Press enter to exit\n");
return fgetc(stdin);
}
The press F7 to make sure it compiles.
Once it has compiled you can use F5 again.
*All C, C++ programs have to have a function called main its the first user visible function that is called. All your code will be called from within main.
Some times main is 'hidden', such as wmain of MFC GUIs, etc.
I can only guess, because you have not given enough information.
Nevertheless, at first I would check the compiling options of the solution and projects for any wrong or missing paths.
If that would not fix the issue, I would check if I have access to all the directories.
Besides, I would avoid using space in any names or paths, because those can cause issues too. I would use camel case notation instead.
Related
I have written a Fortran code for being compiled as a '*.DLL' file.
The program which reads that file is a Finite Elements Method software named Plaxis, I already achieved to generate the '*.DLL' file in Visual Studio and Plaxis recognizes my model but the model does not work fine.
I would like to evaluate all the variables involved in my code and the procedure that Plaxis is using to read them, but when I use commands like "write(*,*) 'variable'" Plaxis does not show me what I asked in the source code.
Probably you want to open a file and write to that for debug logging, because presumably Plaxis doesn't run with standard output connected to anything useful. Or maybe it would if you just ran Plaxis from a command line window?
It's not going to create a dialog box for you.
But anyway, another option would might be attach to Plaxis with a debugger, and set a breakpoint in a function in your DLL. Then you can single-step your code as called by Plaxis.
Or you can write your own test callers and write unit tests for your functions, making them easy to debug. This could work well if your function just gets an array + size as args.
If instead it passes some wrapped object that you need to call special functions to deal with, then maybe make another version of your function that does just take an array so you can call it from a simple test caller.
I have a problem. When the program reads a text file, it always get out of the line and crashed.
var f:text;
i,j,cs:byte;
a:array[0..10,0..10] of int64
begin
assign(f,'anything.txt');
reset(f);
cs:=0;
while eoln(f)=false do
begin
read(f,a[0,cs]);
inc(cs);
end;
close(f);
end.
Here is the content of anything.txt:
2 4 8 16
exitcode=201
You have not told us which compiler you are using.
In Delphi and Turbo Pascal which preceded it, run-time error 201 means "range check error". I don not still have Turbo Pascal installed but your program compiles and runs as a "console application" correctly in Delphi with only one minor change, namely to insert a semi-colon (';') after int64. It runs correctly whether the compiler has range-checking turned on or not.
It also runs correctly in FreePascal + Lazarus.
So, unless you are using a different compiler which also happens to have a run-time error code 201, your problem seems to be caused by something you have not included in your question. In any case you should learn to debug this kind of problem yourself. So:
Look up how to use use the debugger in your Pascal compiler. Place a breakpoint on the line inc(cs) e.g. by pressing F5and run the program. When it stops at the BP, place debug watches (using Ctrl-F5 in Delphi/TP) on the values of cs and a and observe the values carefully. Press F8 repeatedly to single step the program, and see if you can see where and why it goes wrong.
One possibility for what is causing your problem is that you are not reading the copy on anything.txt you think you are: because you don't include a path to the file in assign(f Windows will use the copy of anything.txt, if any, in whatever it thinks the current directory is. To avoid this, include the path to where the file is, as in
assign(f, 'C:\PascalData\Anything.Txt');
Also btw, you don't need to compare a boolean function (or expression) againt true or false as in
while eoln(f)=false do
Instead you can simply do
while not eoln(f) do
I couldn't find this in any searches and have been fighting with these scripts this past week, trying to learn how NSIS' scripting works from scratch in the process. Cutting to the chase, here's what I'm encountering and take note I'm working with another person's scripts in the process:
Initial state of the scripts:
Fails to enable the program's functionality (which is to present an easy to use .exe to call in the command line that may then be followed by other commands in relation to another file to extract its contents).
Presents warnings that AddEnvVar and un.RemoveFromEnvVar functions are not called.
Add calls to the functions in the .nsi file in the appropriate sections.
Installer compiles, but when run presents an Installer Corrupted: Invalid Opcode error.
Okay...Not sure why that's happening. There's another script called EnvVarUpdate present, maybe that's it. Add a line in the .nsi to include it. Then I run into this:
Error: Function named "StrStr" already exists. Error in macro
STRFUNC_FUNC on macroline 16 Error in macro FUNCTION_STRING_StrStr on
macroline 1 Error in macro _IncludeStrFunction on macroline 2
!include: error in script: "EnvVarUpdate.nsh" on line 50
Okay. Try commenting out those lines to get it through...And I hit this:
!insertmacro: macro "FUNCTION_STRING_StrStr" requires 0 parameter(s),
passed 3! Error in macro EnvVarUpdate on macroline 84
I have no idea if EnvVarUpdate needs to be included to begin with (since it wasn't originally included in the .nsi script I'm at a loss for what it's even doing there) and I can't figure out why the calls to AddEnvVar and un.RemoveFromEnvVar are corrupting the installer. It seemed logical to me that for since these files were published with the intent being easy compilation that all the files would be necessary, but with the function calls missing and the exclusion of one of the scripts in the .nsi file rendering the compiled installer dysfunctional, I'm led to believe he may have made some mistakes in the process.
My guess is since he also published a compiled installer that works hosted on his own site, he incidentally left the open files a little broken as he figured out the right way to do it. However, personally, I'd still like to repair them if I can figure out how to enable others to manually compile the installers if they like.
If it might help, here's a link to the fellow's code on GitHub.
AddToPath.nsh contains two functions that manipulate %path% (AddToPath and un.RemoveFromPath) and two generic functions that can manipulate any environment variable (AddToEnvVar and un.RemoveFromEnvVar) but those two functions are never used so you get a warning.
To remove the warnings you can just comment out those two unused functions.
EnvVarUpdate.nsh uses the StrStr that is a part of NSIS so you get a problem because it is already defined in AddToPath.nsh
A common pattern for utility functions like these is to put the function inside a macro and then allow the .nsi to select the functions it uses by inserting the macro (And the macro creates the function at that point):
!macro Foo un
Function ${un}Foo
MessageBox mb_ok "Hello from Foo"
FunctionEnd
!macroend
...
!insertmacro Foo "" ; Use function Foo in installer?
#!insertmacro Foo "un." ; Use function Foo in uninstaller?
Section
call Foo
SectionEnd
I'm currently in a Python interactive interpreter session. I have a function that I know is doing something funky, so I want to step through it in a debugger session. I know the file name and line number of the function.
Is there any way for me to now set a breakpoint in the start of that function, then run it and step through it? Without having to open an editor, locate the file, locate the function, manually insert import pdb; pdb.set_trace(), saving the file, then go back to the interpreter, reload the module the function came from and running it? Not to mention that if I forgot to remove the pdb trace that'd spell trouble later.
Summarizing the question: If I'm in a normal Python interpreter session (or iPython), is it possible to set a breakpoint somewhere and start debugging, without having to actually edit in the code pdb.set_trace() somewhere?
I can't believe I missed this, but I just glanced over the pdb documentation a second time and realized that all the run* functions do pretty much exactly what I want. They don't let me set a specific line as a breakpoint, but I can pass the function and the arguments I want to use, and it will break on the first line of the function:
import pdb
pdb.runcall(my_wonky_function, "arg1", "arg2", *myargs)
Well actually it broke at a mystical location called "EOF":
(Pdb) list
[EOF]
and I had to step twice before I got to the first line of the function, but that's hardly a problem.
I use /opt:ref /VERBOSE option on a Visual Studio 2012 besides having activated "Whole Program Optimization - > Use Link Time Code Generation". /opt:ref is supposed to remove unused functions although I had the impression that specifying "Use Link Time Code Generation" was supposed to remove unused functions by default.
In my test program I use a test function that I expect to be removed from the final executable and VS output seems to confirm that:
Discarded "int __cdecl testMe(int)" (?testMe##YAHH#Z) from Test.obj
But looking over the *.asm file generated with /FAs I can see the function listed:
; Function compile flags: /Ogtp
; File c:\users\g.m\documents\visual studio 2012\projects\Test.cpp
; COMDAT ?testMe##YAHH#Z
_TEXT SEGMENT
?testMe##YAHH#Z PROC ; testMe, COMDAT
...
So, is it removed or not from the final image ?
EDIT:
trivial code to be optimized out
static int testMe(int i)
{
return i + 1;
}
int main()
{
auto res = testMe(0);
}
What I find quite suspicious is even in the case function is "static" it still appears in the *.asm file
What seems to be happening here is that the compiler has not fully optimised out the function at the time it generates the assembly (though you haven't posted the full listing, nor the original function, so it's hard to be sure), but the linker is able to see that it is unreferenced, and has discarded it.
Linking happens after assembly generation, so anything the linker does is not indicated by the intermediate assembly output.
You would know for sure only by looking at the final executable, but I suspect the linker is telling the truth, and has removed your function.
Update:
Testing your code locally confirms my suspicion. The compiler does not optimise out the dead code, but the linker does.