Re: CodeWarrior vs Xcode issues
Re: CodeWarrior vs Xcode issues
- Subject: Re: CodeWarrior vs Xcode issues
- From: "Andy O'Meara" <email@hidden>
- Date: Tue, 07 Jun 2005 16:41:22 -0400
>> I'm not convinced Apple is looking out for devs who aren't gcc
>> gurus (but need a also demand a lot from their compiler).
>
> You rarely have to bother which compiler works in the background.
Agreed, but I was referring to enable/disable certain compiler features but
having to know and fiddle all the textual gcc flags, etc in order to do it
(when a GUI would be the right solution).
>
>> My small company develops performance graphics stuff for win32 as
>> well as mac
>> os x, so it's been very effective over the years to use codewarrior to
>> target CFM carbon, mach-o, and win32.
>
> Are you targetting Classic Mac OS or are you bothering about
> performance? If you do the latter, you might want to have a look for
> IBM's xlc which is known to produce quite fast executables.
>
No, we're all done with CFM--I was making the point about having all those
diverse targets under one roof.
Interesting tip about xlc, but of course no that ppc is denounced dead for
mac in two years, there's no desire to go this route. Also, the performance
aspect I/we seek is practical/low-hanging IDE/compiler options, not making
separate altivec code, etc.
Don't get me wrong--I'm totally thrilled that xcode/gcc is finally pulling
ahead of CW in things like auto vectorization support.
>> I got to keep all our cross-platform code in a DLL and .bundle
>> project, and
>> that was damn nice
>
> Now you have a directory of code files with two project files inside
> it. A Xcode one and some Windows one. Using a file with one IDE
> doesn't stop you to use it in another one as well.
I was just referring to the fact that our source files were in a single
project. But, yes, what you're saying is of course the way to do things
once you have to maintain two projects.
>
>
>> - Codewarrior has great warning control and suppression support.
>
> Why do you switch warnings on if you suppress them afterwards?
>
> To control warnings in Xcode, go to the build settings panel(s) and
> play with the checkboxes. Selecting a line in the table there puts
> you the related part of the man page at the bottom. What else would
> you expect?
There are certain warnings that get produced that do not appear to be
suppressible via any WYSIWIG means. If you're asking what warning could
possibly be benign, once example is the " '/*' within comment" warning. One
of our code bases is a C-like compiler, so we also have a preprocessor, so
there's lots of comments that talk about finding a /* here and there.
Another example is assigning a character inline long (ex, 'ab') to an
int/long. Clearly, those are cases were there's zero danger, so the
warnings only end up being a huge distraction (and I've lost too much time
missing "real" warnings b/c I didn't notice one mixed in with the spam
warnings).
So if your response is, well just disable x, y, and z with flags, I'll
certainly do that and I'll be on my way. However, the thrust of my original
post is that xcode needs to GUIize this stuff if I'm to buy into the fact
that it really is the best thing since sliced bread. It's just been tough
to become very learned for a single compiler when you're trying to run a
startup company. I made some of the points about a better GUI wrapper to
make a point to apple folks, that there's devs like me out there.
>
>> I realize the gcc has many warning-related features, but I don't
>> have the
>> resources/interst/patience to become a gcc options and flags guru
>> (when
>> there's two other compilers that I have to manage as well).
>
> So, switch all warnings off and gcc will allow you to write sloppy
> code without complaining with a single line of output.
Before you bash me, I'd appreciate it you'd consider the warnings I
mentioned above beforehand.
>
>> Currently, my cross-platform code base
>> compiles like a champ, but there's certain warnings that come up
>> that are a
>> horrible distraction from real warnings that I may need to know about
>
> You are right. gcc doesn't have a how-does-my-developer-feel-about-
> this-warning sensor built in. It doesn't get tired to point out every
> possible occurence of mistyped code. If you don't want to see them,
> switch them off or fix your code. It's not that hard to switch a lot
> of warnings on but to have compliations free of warnings anyways, btw.
>
>
See above.
>> 1) Syntax/editor features. Again, Apple beats the
>> cocoa-and-xcode-is-superior drum, but how impressed can I be when
>> Apple
>> doesn't seem to have matched (or surpassed) codewarrior's editor in
>> full?
>
> 1) As you note later, you're coding in C++ which isn't adressed by
> this drum. Cocoa is Objective-C.
I was referring to the xcode-is-superior drum. Given that that Steve Jobs
left us with yesterday that xcode is our only option for Mac OS development
into the future, given the intel shift, that means you need to use xcode for
C/C++ if you want to use it on a mac.
>
> 2) Sounds like you consider the codewarrior editor to be the state of
> the art editor others have to measure with. So, why don't you
> continue to use it? Xcode supports external editors.
>
This is not possible in this case--as I described, I'm looking for the
editor to do method/instance variable name coloring.
> 3) Instead of investing time with improving the code editor, Apple
> focusses on making it more obsolete. See Key Value Coding, see
> Bindings, see Core Data, see ...
>
Again, see above--I develop cross platform software (and you have most
likely used it unknowingly).
Please consider the fact that not everyone who uses xcode is making cocoa,
carbon, frameworks, or anything closely tied to mac os. Consider that cross
platform developers just want a nice IDE so that they can develop with all
the conveniences of using a mac os as their work environment.
Andy
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden