|
The point the other two posters were making is that there are two exe files created. One in the debug folder and one in the release folder. Both are application folders. The one in the debug folder should work just like the IDE launch.(I'm not sure breakpoints are reccognized outside the IDE. I seem to remember not without linking to the mapping file. Don't remember the file type, but if you map to it and blow up, the IDE is brought up for you and your local environment at the time of blowing up is available for viewing. I read how to do this in 2005, very useful at the time, got away from programming for a while so don't remember how that is done)
So, you KNOW you are double-clicking the DEBUG folder's version of the code and it doesn't work? Do you know how to bring up the IDE from a double-click?
Earlier, you said the drive letter you started from is causing the problem. From that, I assumed you started the app from a cmd file. Since you are double-clicking, are you navigating to the drive causing the problem in the app? If not, how do you know it is a drive permission problem?
|
|
|
|
|
Your environment may be different when you run the debugger verses just launching the exe file. Check "PATH" when executing both. Also, as I use to do, kill the program with print statements. You can do a "binary search" with print statements. One at the beginning, one in the middle and one at the end of the program. See which one prints and move them around accordingly.
THE OLE HACK
|
|
|
|
|
Did you try compile your code with other IDE?
|
|
|
|
|
Vasily Tserekh wrote:
yes I know but at least in managed languages you
get a nice error message not a blank error messsage, thats why I hate c++
You "hate" C++ because you don't understand it.
To be clear, in .NET languages like C# and VB.NET (and similarly in Java), when there is a unhandled fault, the end user is presented with a exception that includes a stack trace. Generally you would never want a end-user to see a stack-trace.
You can get exactly the same thing in C++ if you choose to, but it requires additional work that is done for you in a managed environment. Generally stack traces are available in a debugger.
/* Charles Oppermann */
http://weblogs.asp.net/chuckop
|
|
|
|
|
I don't like C++ either, but it's because I rarely use it and I like the pampering you get with managed code. I do like the IDE and I definitely don't completely understand it.
I have to agree with you, that I don't like it when something goes wrong and I don't understand what is happening to cause the problem.
It's worse when I don't understand what it is that I need to understand.
I have to admit to berating the perpetrator after I've traced the source of the problem. For some reason, I don't take it personally when I'm berating myself. (Why is that? How more personal can you get? )
|
|
|
|
|
Chris is right - and it isn't even just software. A couple of times I have had problems with complex hardware prototypes not working - until you put an oscilloscope probe in the right place to monitor what the software is doing to it, and the problem goes away... That, my friend is when the nightmares start.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
OriginalGriff wrote: That, my friend is when the nightmares start.
[grimmace]
Ahh, many a time in frustration have I yelled in agony suggested we ship a scope with each piece of hardware when god awful delightful scenario occurs.
[/grimmace]
|
|
|
|
|
Ahh, a Heisenbug
Another good one is a race condition between threads where sometimes one and sometimes the other thread 'wins' the race.
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
That “uncertainty” sure shows up in a lot of places. One time I didn't have an IDE, and I'm getting duplicates. Comb over the code, can't find the logic problem. Insert write statements. Problem disappears. I'd had this happen in the past and the problem reappeared when I took out the write statements. This time, the problem remained gone and has stayed gone since.
It's frustrating I'll never know what caused the problem or exactly what I did that fixed it. When it reappeared that earlier time, I think it took a week to find the single line of code that was a problem, and about the 20'th time re-reading that line.
|
|
|
|
|
I remember fixing unstable hardware by putting a probe onto the right place.
|
|
|
|
|
All you guys let that one go?!
|
|
|
|
|
The boy is already trouble with CPP and you are threatening him with oscilloscope
How about forgetting to connect your circuit board with ground and your embedded device is not running at all
|
|
|
|
|
Too simple. How can you overlook that you have no power at all?
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
do you think i spent all day? not at all, i found it right away. but can i blame micro-controller for this?
|
|
|
|
|
Yes, of course you can. It will not help very much and you will not find out very much that way, but if it makes you feel better...
At least artificial intelligence already is superior to natural stupidity
|
|
|
|
|
That's happened to me a few times (occasionally with C++ Builder too!). In each case it has been a variation on:
Different memory (especially heap space) allocations between the debug and live environment (even on the same machine). Debugger initialising memory to something sensible, thus hiding an uninitialised variable somewhere in my code, debugger locating the program in a different area of physical memory, thus avoiding a faulty patch of RAM that - by coincidence - wasn't used by the OS normally either, and so on
In other words, this type of problem is almost always memory related in some way, or possibly due to uninitialised use of a physical device or internal queue in some that way the debugger covers up when it sets up the debug environment.
One technique that can sometimes help catch this is to use a remote debugging session run from a second machine - often the remote debug stub will not do as much pre-execution setup as an integrated debugger, thus leaving the problem undisturbed, or at least different.
I remember one particular problem porting a program from C++ builder to Linux, where the C++ Builder program loader initialised class memory to 0 before starting the program, whereas GNU C++ didn't - took me a while to spot that, as the program only failed when loaded without gdb (which placed it in an area of memory that was, by chance, all 0s!)
Oh, happy days...
8)
|
|
|
|
|
|
There is nothing to hate about C++. C++ doesn't written for winning prize for "Standards". It came to solve real world problem and solving it very well, since long time.
Happy Programming
|
|
|
|
|
As a C/C++ coder who started as a .NET coder, I hated C++ to start with. I can honestly say that over the last few years it has really grown on me. I am forced to agree that a well-done c++ application is a thing of beauty. I am still more productive using .Net though, as it generally requires less code to get stuff done.
|
|
|
|
|
If you wanted to teach a monkey how to code you wouldn't use C/C++.
You'd use VB or C#
|
|
|
|
|
code_junkie wrote: If you wanted to teach a monkey how to code... Is that right after it writes out the entire works of Shakespeare on a typewriter?
Uhh, do you know what a typewriter is?
|
|
|
|
|
That's nothing. It happened to me twice, in different environments (one using MSVC and one using gcc): the binary runs flawlessly when compiled in debug mode, and fails highly reproductibly when compiled in optimized mode. Both times the culprit was some smartass programmer who controlled what code gets compiled depending on build type in some libraries.
|
|
|
|
|
I can sympathize (in terms of trying to find some elusive “error”).
The other day, I could not compile a new C# COM server I was building … kept getting errors like: “expecting this …” or “expecting that …”. I counted brackets; braces; everything lined up, but it still wouldn’t compile. (I should mention that some of the code was copied from MSDN).
So, I started refactoring. If I typed it out, it would compile; if I copied and pasted snippets, the compile would fail.
In the end, it turned out to be a “subtract” (i.e. “ - “) in a math statement.
The code I had copied contained an “unprintable” character after the “-“ (which happened to be at the end of a line due to a copied MSDN statement that spanned multiple lines) … retyping the “-“ made the problem go away. You could only “see” the problem if you hit “End” on that particular line because the cursor would land over one extra position.
|
|
|
|
|
When 19 people (at least until now) vote you 1 it's time to accept you are either mistaken or plain different.
What you are doing is to blame a language for problems that are caused maybe by a compiler, the way you wrote the code, 3rd party library, ... . I bet you don't hate C++ but the whole set of tools that you are using to write code in C++. Then to talk back to people when you don't seem to know about release and debug versions it doesn't look well.
I hate a tiny bit C++ but I hate it for what really belongs to it: the "*", the "&" and the "->". It is brutal to understand C++ code sometimes. That's why C# came as a blessing for me.
Stop being frustrated and revisit your code, you'll make it better and learn in the process.
Cheers.
giuchici
|
|
|
|
|