[openbeos] Re: PPC versions
- From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 09 Apr 2002 22:12:50 EDT (-0400)
> [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.
By how much? Oh yes, hardly anything. If you forget occasionally, some
minion like me will see the linker error and go back and add it.
> >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.
See below.
> >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.
Yeah, right. Look at the network code (I've had the most experience
here recently). There are something like 60 (maybe more) exported
functions. Maybe five are in the Be Book. The Be Book is not
everything, especially if you want to share internal APIs (like add-on
APIs) between components of your kit, add a class, a couple functions
here or there.
> >> 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.
Does Solaris use ELF? I'll bet it does.
> 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.
I'm not quite sure what to say to this. How about "de facto standard"?
BeOS has them too. They are eminently ueful, and improve understanding
of code by demarcating public entrypoints and private support code.
-Nathan
--
Fortune Cookie Says:
"I had to hit him -- he was starting to make sense."
Other related posts:
