On Aug 26, 2004, at 8:39 AM, David Leimbach wrote:
Note that my perspective here is coming from years of work using
CodeWarrior and porting code from Visual Studio to CodeWarrior. Also,
these notes come specifically from our work moving Knights of the Old
Republic (KOTOR) from CodeWarrior 9.2 to XCode 1.5.
In a few of these cases below other compilers are not being as strict
as g++ about how C++ is supposed to work and I only
see one where gcc isn't doing what it should be. The rest appear to
be problems with extensions and packaging of those that
made you have to expend some effort to get working with Xcode
I fully understand this. It probably wasn't entirely clear from my
original post, but almost all of the code I deal with on a daily basis
is ported code that started life out in other hands on Visual Studio. I
typically work on anywhere from 2-4 game ports in a given year. Given
that, I'm very appreciative of any options that allow me to keep most
of the code intact when it's an issue of ambiguity with the standard.
1. "legacy" for-loop scoping (a variable defined in the for loop
definition has scope outside the for loop) in theory works in gcc,
but in practice breaks when the optimizer is enabled. You have use
the ISO-standard for-loop scoping rules for this to work, i.e. move
the variable declaration outside of the for-loop statement. gcc at
least gives you warnings about this, so you can find and fix them in
your code fairly easily.
I bet if you compiled with the right compiler switches this warning
would be an error [as it should be].
I bet if I made all warnings into errors, you're right. ;-) However,
that only means more long-term pain for me working with ported code.
Is there any reason you aren't using more type-safe techniques for
output like cerr/cout/clog?
This is all ported code, so you'd have to ask the folks who originally
wrote it. ;-)
I'd agree except that it seems CodeWarrior doesn't know how to
recognize bad C++ code very well. At least not with the default
options. I'd say most of your above issues came from the code being
wrong to begin with and you had a compiler that was letting many
issues slide.
As it happens, CodeWarrior would generate warnings for a lot of the
above cases, but would still generate code that works. The only case
that CodeWarrior didn't generate a warning for was when passing non-POD
data to stuff like printf().
--
Brad Oliver
email@hidden
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
