Hi, I experienced a strange bug in my engine, and my conclusion is that it could come from a VC6++ compiler bug... (sp6, in release mode optimization on Maximize speed). The bug happens when I try to register more than 68 object methods in one function. When I add a 69th, the compiler seems to "stop" to pass the method adress to the RegisterObjectMethod() from about 30 registered methods (seen by steping in produced optimized code). To be more accurate, compiler don't make the asMemCopy() anymore, that is, it don't call the asMethod::Convert() as if method had a zero size length!!... - If I split my registering function in two smaller functions, it works fine - If I turn optimization on 'Minimize speed', it works fine too Did someone already experienced this ? Lbas

I haven't experienced the exact same problems, but I have experienced other problems with optimize for Maximize Speed with VC6, especially with the pre and post increment operators. With the optimizer the compiler sometimes switches the order of the operations, so that the result is incorrect.

Someone once mentioned that he had problems with registering objects with many methods, though I never could reproduce it. It's possible that he had encountered the same problem that you have.

I'll have to take note of this, so that if someone else has the same problem I'll be able to explain what's happening. Thanks.

Regards,
Andreas

I encountered a problem using VC 2005 regarding source control I didn't succeeded to circumvent. The problem is that you must have sources+headers files in the same directory (or in a sub-directory) than the solution files, and our projects are structured in other way (sources & header in different directories and project files in a sub-directory). I didn't investigate a lot on this problem, but it's very annoying... I'll have a look at the newly released SP1 of VC 2005 to see if they fixed this problem (I'll let you know).

BTW, I'm still very satisfied with VC6, even if I agree it's very old now :)

Regards,
Lbas

VC++ 6.0 doesn't compile C++, it compiles some language that looks like C++. Maybe what you say is a language feature. [wink]

Quote:Original post by Lbas
I encountered a problem using VC 2005 regarding source control I didn't succeeded to circumvent. The problem is that you must have sources+headers files in the same directory (or in a sub-directory) than the solution files, and our projects are structured in other way (sources & header in different directories and project files in a sub-directory). I didn't investigate a lot on this problem, but it's very annoying... I'll have a look at the newly released SP1 of VC 2005 to see if they fixed this problem (I'll let you know).

BTW, I'm still very satisfied with VC6, even if I agree it's very old now :)

Regards,
Lbas

No, you're quite wrong. Just like all other IDEs, you just have to tell MSVC2005 which other directories you're using. Like so:

Tools -> Options -> VC++ Directories -> hit the browse button and choose the directories where your files are. (Make sure you're under "Include Directories" and/or "Source Directories", not "Executable Directories" or others).

Simple. And don't confuse that with source control. That deals with versioning. This is project structure. I have most of my work-in-progress library in a completely different directory than all the projects that use it. It's a set-and-forget sort of thing. Very very easy. It... uhm... doesn't say much about your google-fu. :D

Oh, by the way, MSVC6 has this feature too. It's pretty hard to use IDEs without it. Maybe Linux guys could, but not sane people. :P

Hope that helps.

I think I didn't explain clearly the problem encountered, sorry for that.

_goat: No, I don't confuse source control with custom directories :), but thanks anyway for your point of vue.

Spoonbender: I'm using Perforce. Let me try to explain a bit better (I hope :)). I have many (many many) libraries in dev, where files are structured like this :

- include\lib1\lib1_header_files.h
- include\lib2\lib2_header_files.h
- lib\ output binary .lib
- sources\lib1\Make\lib1 make files (dsp, solutions, makefiles, etc.)
- sources\lib1\lib1_files.cpp
- sources\lib2\Make\lib2 make files (dsp, solutions, makefiles, etc.)
- sources\lib2\lib2_files.cpp
...

When I tried to configure source control in Visual2005, it refused to get (nor checkin/checkout of course) project files (for example for the solution file located in sources\lib1\Make\lib1.sln, source control didn't take care of sources\lib1\files.cpp and include\lib1\files.h) because these project files are not in the same directory tree of .sln file (at least that's what it reported). As I previously said, I didn't have many time to investigate on this (and don't have now), but I'll try later and let you know.

Thanks for your comments,

[Edited by - Lbas on January 4, 2007 2:13:52 AM]