12 replies to this topic

[kyuzo]

hi

My first post was about making some code that was working on vc++6 anf gcc3 work on vc++2005. After a month i'm still there. My program keep crashing at random times. Even if i manage to do my code work on vc2005, i use some libraries wich may have the same problems. So, i would like to ask, it is worth it the pain? Should i continue to try, or go back to vc++6 (i'm not very happy with the idea)?

thanks

[dave_]

kyuzo said:

hi

My first post was about making some code that was working on vc++6 anf gcc3 work on vc++2005. After a month i'm still there. My program keep crashing at random times. Even if i manage to do my code work on vc2005, i use some libraries wich may have the same problems. So, i would like to ask, it is worth it the pain? Should i continue to try, or go back to vc++6 (i'm not very happy with the idea)?

thanks

Is your program crashing at random places or specific places? It would be a good idea to look at the call-stacks and see what the specific problem is.

[kyuzo]

The problem(s) seems to be where i use stl. Looking at the call stack isnt really useful, because it leads me to various places in the source, where i see no errors (they might be there, of course). Its really frustrating to discover that the code one think is working and stable is in fact a falling apart mess.:sad:

[darqSHADOW]

Sounds like a memory problem. More than likely you have this issue in your old code, it just manifests itself differently. A "moving bug" is typically a sign of bad pointer usage in C.

DS

[monjardin]

There is a huge difference in the STL libraries from VC6 to VC7.1 and VC8. VC6 was probably letting you get away with improper usage of the library. Could you post some examples of you STL use that are causing problem?

IMHO, it is definitely worth it to upgrade to the new compiler (or at least VC7.1). If not for your current application, then at least for all new projects. We still maintain legacy applications at my office with VC6 (and earlier), but we don't (usually) start new efforts with it.

You are less likely to have these kinds of portability issues with the newer, more standard compliant, compilers.

[kyuzo]

monjardin said:

There is a huge difference in the STL libraries from VC6 to VC7.1 and VC8. VC6 was probably letting you get away with improper usage of the library.

and gcc too?

monjardin said:

Could you post some examples of you STL use that are causing problem?

well, the whole code is available (http://sourceforge.n...cts/silpentree), if you're a brave soul, you can have a look.

i'll definitely use vc2005 for any new project i'll begin to work on, but for this we're talking about i simply wouldnt kwnow where to start to look. My code got big enough, it use some libs(scintilla, tinyxml, a regex engine); vc2005 says that something corrupted the stack, but it was my code, code from a lib, and where the corruption occured?
can somebody recommend a lib for mem management that would help with these problems, that preferably work on both vc and gcc (mingw)?

thanks.

[monjardin]

They also changed the way variables in for loops are scoped. You might want to look into that too. I mention this because a coworker of mine had stack corruption problems porting an old Mac program to Windows with VC7.1 today. The for loops were causing it.

[zavie]

monjardin said:

They also changed the way variables in for loops are scoped. You might want to look into that too. I mention this because a coworker of mine had stack corruption problems porting an old Mac program to Windows with VC7.1 today. The for loops were causing it.

The difference between C++ and Visual C++... :-(

[baldurk]

zavie said:

The difference between C++ and Visual C++... :-(

rather the difference between the current C++ standard and the C++ standard when vc 6.0 was released. At the time, the for loop variables were scoped correctly, it's just that MS never updated the scoping when the spec changed.

[kingsimba]

The STL library is really different in 2005. For example, istringstream failed to see ',' as a seperator in 2005. So you have to be careful. In my case I use the following code to solve it.

if (_MSC_VER >= 1400)

	std::locale::global(std::locale(std::locale::classic(), new std::ctype<char>));

Or I think you can just use another STL library to solve it. STLport for example.

But I think moving to 2005 is definitely worth it. The performance tool, the new CLR language. They are really helpful.

[eddie]

One problem I had most notably when moving from VC7.1 to VC80, was that VC80's new STL has a lot of safety checks on it.

This manifested itself a lot in it's _orphan() call, where it would (in debug only) attempt to orphan any outstanding iterators (as they were no longer valid).

Does that sound familiar to what you were encountering? Does your program crash in release as well? Or just when _DEBUG/DEBUG is defined?

[Nils Pipenbrinck]

I can verify, that several visual c++ versions where a bit to paranoid when it comes to the "corrupt stack" error. We had such a problem in a game, and after serious investigation it turned out to be no stack corruption, just a runtime library check that did a false alarm. So we just ignored the warnings and disabled them..

I haven't checked the current compiler with the offending code (honestly - I don't have much interest in it anymore), but I'm pretty sure it will now compile and run without problems.

Such things are not really a problem. All compilers have quirks, and it's the job of a programmer to work around them if nessesary. A bug-free compiler does not exit. (also I have to admit, that in 90% of all cases where I blamed the compiler for a bug, it was me and my code who where the root of all evil.)

[kyuzo]

eddie said:

One problem I had most notably when moving from VC7.1 to VC80, was that VC80's new STL has a lot of safety checks on it.

This manifested itself a lot in it's _orphan() call, where it would (in debug only) attempt to orphan any outstanding iterators (as they were no longer valid).

Does that sound familiar to what you were encountering? Does your program crash in release as well? Or just when _DEBUG/DEBUG is defined?

Well, even the gcc built binary crashes sometimes, so i guess that it is my code to blame. One of these days i'll have to hunt the bug down.
Thanks everybody for your replies.