[snip] >It's not about making things easy. It's about not making things hard. >The two are very different. It's the same argument as not writing all >your code in x86 assembler. Writing in C/C++ isn't a good idea because >it makes a PPC port easier but because it doesn't make a port *harder*. >Remember the original subject of my e-mail: how not to *actively I don't think that the two compare. Writing in C/C++ makes coding faster, more bug free and easier. Putting _EXPORT in front of some (but not all) of your classes and/or functions makes coding slower. >prevent* a ppc port. Not only that, _EXPORT makes code more readable. There is no evidence to support this at all. At the very most, this would be an issue of opinion. >It seperates the external API from the internal support environment and >marks what can and cannot be changed without breaking compatibility. >All too often in the OBOS code I've seen, this distinction has become >blurred. We have a wonderful guide to this - the BeBook. >> I agree, here. But there are a very small number of people with PPCs >> that can help. >> And the trouble of adding *stuff* to the code to support a 5 year old >> compiler/proprietary >> file format combination just doesn't seem worthwhile to me. > >It's not to support PEF/mwcc. It's too avoid writing code that uses * >GCC-only extensions*. The world out there is bigger than x86/gcc, and >we should code with that in mind. Excuse me? Maybe I missed something. PPC/ELF doesn't require _EXPORT. Secondly, not using _EXPORT is ***NOT*** a GCC-only extension. Solaris Forte, as a counterpoint, doesn't require them. Windows has them, Macs have them, but that is not sufficient to make it a standard. In fact, anything that starts with an _[A-Z] is reserved for implementation specific "stuff". (Draft Standard 2.10.2). So, I guess I can agree with you - the world IS bigger than any particular compiler and we should avoid compiler specific issues. So, no, _EXPORT is *STILL* not required. Or even encouraged.