[openbeos] Re: How not to actively prevent a PPC version of your software and write better code at the same time
- From: "Nathan Whitehorn" <nathan.whitehorn@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 09 Apr 2002 21:58:47 EDT (-0400)
> >> If they are, wonderful. If not, then, depending on the amount of
> > > work
> >> to be
> >> done, it may or may not make sense. Putting in prototypes for
> >> functions is
> >> good coding practice. Non-standard coding extensions to work
> > > around a
> >> compiler that we don't intend to keep is not
> >
> >That's just it: they *are* standard coding extensions. GCC even
> > takes
> >them if you turn off export all (which, IMHO, would be a good thing
> > to
> >do)
>
> Can you point me to a C++ standard that they are in?
No. But every compiler that I've ever seen takes and respects
_declspec(dllexport), whereas only GCC exports all symbols.
> >> >Should we miss the possibility to have both x86 and PPC BeOS
> > > > parts
> >> >replacements simply for a matter of 7 letters?
> >>
> >> Oh, come on. This is just getting silly.
> >
> >Not really. Not exporting symbols *will* preclude the possibility of
> >any PPC parts until everything is running on NewOS.
>
> First off, this is not true, based on what you said before - you
> should be able
> to turn export all on. Secondly, what I was commenting on was the
> trivialization
> of the issue to "seven characters". Thirdly, I don't forsee not
> having PPC version for a few
> (1-9) months as being a huge issue, esp since what we would have
> would be an OLD
> ppc version. If you had deep magic to support every PPC machine out
> there,
> I would be personally adding _EXPORT to everything in source control.
> And conning
> my wife into buying me an iMac. :-)
Actually, export all doesn't work right. You get lots of symbol
collisions in the statically linked runtime libraries, which are also
required. We could also provide .exp files, but I'm not sure that's a
better solution.
> >> Personally I don't think that even trying a port now makes any
> > > sense.
> >> Trying to port code
> >> that is being actively developed and created doesn't make a lot of
> >> sense, to me. Just like
> >> what Nathan and David Reid found today with their almost CVS
> >> collision. It would be far smarter,
> >> I think, for the PPC folks to learn and document their hardware.
> >> Maybe write some drivers. Work
> >> the outsides of the problem, instead of diving through the middle.
> >> Get YellowDog Linux and look
> >> at the drivers and the kernel to learn what Apple *should* be
> > > sharing
> >> with us. Help by writing x86 code
> >> for now. Be found that 99% of their code *just worked* on x86,
> > > coming
> >> from PPC. I will bet that,
> >> with GCC/PPC, we will find the same. When you jump the gun,
> > > sometimes
> >> it goes off.
> >
> >And the one percent, as Be learned as well, was a complete PITA. Nor
>
> Yes, that last one percent can be very problematic. Esp if you have *
> NO* support
> or help. That is what PPC faces in the Mac world. It was hard enough
> with Intel
> engineers helping...
So let's not make it any harder than it needs to be.
> >can we write anything unless we have some code to base it on. Just
> >research? Come on, that's lame.
>
> I don't think that it is lame at all. I spent a couple of weeks
> learning USB before I
> even thought about writing any code. And there was nothing stopping
> me from just
> sitting down and coding like mad. I wanted to understand what I was
> doing and why.
> In professional software (which this is not), it is spec'ing out the
> project. Since I don't
> like writing specs, I just read and thought and planned. But it is
> the same idea. I suspect
> that the PPC folks (Hi, Tony!) have a lot more reading and learning
> and thinking to do
> than coding.
Right. And I've been doing this for 4-5 months now, as have the other
people doing PPC.
-Nathan
--
Fortune Cookie Says:
Fats Loves Madelyn
Other related posts:
