Metrowerks CodeWarrior Best Version and Updates

[bribri]

I don't know what I am losing out by not using Pro 4. I would be interested in hearing if you discover the benefits.

I played around with CodeWarrior 11 for a while before updating to Pro 4, mainly because I thought 11 was the last version, what with 11 being bigger than 4. (And then I realized they changed their naming scheme part way through.)

Looks like Pro 4 has quite a few improvements and features. It allows multiple targets in a project (debug, release, profilig, etc.), more C language options (though sadly still no C99 support), better optimization I think, or at the very least more optimization settings, and probably a few other things here and there that I'm forgetting. It certainly feels more mature.

I'm currently using Pro 4 for the CodeWarrior version of my game project, since as you observed, it compiled 68k just fine in Basilisk II, and right now I'm firmly in the 68k world so I don't need PPC compilation. I figure I may was well use the best classic 68k dev environment available, and that *seems* to be Pro 4.

Also worth mentioning I used CodeWarrior back in the day, when developing my old mac projects. I don't recall precisely which version, though, and at what point I switched from Symantec to CodeWarrior.

 

[David Cook]

better optimization I think, or at the very least more optimization settings

I just looked at the release notes, and indeed those are improvements that they noted. I'll be interested in your experience as you use it.

 

[joevt]

I think you can get some C99 features by enabling the C++ compiler?

 

[lobust]

I think you can get some C99 features by enabling the C++ compiler?

The C++ compiler is always enabled, but it's only used for .cpp/cp files - the option forces it to be always used instead of the C compiler.

The option that toggles "future" features is to have "ANSI Strict" turned off, and it is off by default anyway.

In my VS 2019 project that I mentioned earlier, the only things I had to do to make it compile in Pro 4 were:

• Rewrite range based for loops as conventional for loops
• Rewrite lambdas as standard functions
• Modify typing of some constructor parameters (eg double instead of float) before I could instance those classes with std::vector:ush_back
• Remove direct array elements from initialiser lists, and set them normally inside the constructor instead
• Some specific (but not all) uses of auto had to be explicitly typed instead.

I forget some of the details, and there were probably other little things I had to tweak, but those were the things that stood out.

 

[bribri]

A few C99 features that CodeWarrior Pro 4 apparently does not have is variadic macros and compound literals, which is too bad because they're quite useful.

 

[lobust]

A few C99 features that CodeWarrior Pro 4 apparently does not have is variadic macros and compound literals, which is too bad because they're quite useful.

I havent tried variadic macros, but some limited testing indicates that compound literals work fine, as long as "ANSI Strict" is turned off...

for example, both of the following compile and run:

struct Test
{
   int b, c, d;
};

void output(struct Test a)
{
   cout << a.b << " " << a.c << " " << a.d << endl;
}
 
int main()
{
   output((struct Test){2, 4, 8});
 
   return 0;
}

void main()
{
   int *i = (int[]){2,4,8};

   cout << i[0] << " " << i[1] << " " << i[2];
   return 0;
}

edit: I thought I was being clever by using the quote format for code snippets, but apparently it strips whitespace in unpredictable ways so I'll not do that again...

edit again: fixed formatting thanks to @cheesestraws

 

[cheesestraws]

edit: I thought I was being clever by using the quote format for code snippets, but apparently it strips whitespace in unpredictable ways so I'll not do that again...

there's a specific code block under the "..." in the editor (or use the CODE bbcode tag)

 

[lobust]

there's a specific code block under the "..." in the editor (or use the CODE bbcode tag)

So there is, thanks for the tip!

 

[lobust]

The C++ compiler is always enabled, but it's only used for .cpp/cp files - the option forces it to be always used instead of the C compiler.

The option that toggles "future" features is to have "ANSI Strict" turned off, and it is off by default anyway.

In my VS 2019 project that I mentioned earlier, the only things I had to do to make it compile in Pro 4 were:

• Rewrite range based for loops as conventional for loops
• Rewrite lambdas as standard functions
• Modify typing of some constructor parameters (eg double instead of float) before I could instance those classes with std::vector:ush_back
• Remove direct array elements from initialiser lists, and set them normally inside the constructor instead
• Some specific (but not all) uses of auto had to be explicitly typed instead.

I forget some of the details, and there were probably other little things I had to tweak, but those were the things that stood out.

Updating this for the sake of accuracy as I revisited it this evening. I guess I never had this fully compiling before, although it does now and runs with exactly the same output as the VS original.

The parameter typing was my misunderstanding/misreading the compiler errors. The real issue was that many of my classes did not have an explicit default constructor and the implementation of std::vector in Pro 4 apparently requires classes to have a default constructor with no parameters in order to instance them with push_back(), regardless of which overloaded constructor you actually call it with.

The failed uses of auto were all where I was using it for iterators. Iterators must be explicitly typed in Pro 4. Also, objects passed to a function as const must use const_iterator, which makes sense but was somehow not necessary in MSVC...

The constructor with array elements being initialised in the initialiser list was not used anywhere in my code so I deleted it. I guess I left it in there early on and forgot about it. However, I had several other class constructors where their member class objects were intialised in the initialiser list, and while that compiled just fine it didn't actually work, so I had to move that inside the constructor in those cases. Need to do a little more investigation on that...

 

[adespoton]

Also worth mentioning I used CodeWarrior back in the day, when developing my old mac projects. I don't recall precisely which version, though, and at what point I switched from Symantec to CodeWarrior.

I switched from Borland to CodeWarrior at CW8, and then after 11, had a demo version of CWP4 which I found immensely frustrating for PPC work on my 68k Mac, at which point I switched to MPW and its dependable if obtuse toolchain. After getting into emulation, I eventually set up a dev environment on CWP8 on SheepShaver and back to CW11 on BII, as I found this worked better than trying to do everything on CWP6, which didn't have the features I was used to from CWP8 AND had changed a bunch of stuff I had been comfortable with in CW11. Easier to just run two environments since I rarely write fat apps.

 

[bribri]

I'm pretty sure that by the time I was using CodeWarrior and making phat apps (and also FAT apps) I was already on PPC. I wish I remembered which version of CodeWarrior I was on back then, and still had those old projects. Sadly the SyQuest disk with all of my old stuff got lost somewhere along the line.