• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: CodeWarrior to XCode
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CodeWarrior to XCode


  • Subject: Re: CodeWarrior to XCode
  • From: Brad Oliver <email@hidden>
  • Date: Thu, 26 Aug 2004 10:50:34 -0700

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.


References: 
 >CodeWarrior to XCode (From: Brad Oliver <email@hidden>)

  • Prev by Date: Re: Using "Project Find"
  • Next by Date: How to move a view to another window without losing bindings
  • Previous by thread: CodeWarrior to XCode
  • Next by thread: Re: CodeWarrior to XCode
  • Index(es):
    • Date
    • Thread