[openbeos] Re: Teams
- From: Clay Vincent Schentrup <cvs@xxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 07 Aug 2002 11:29:47 -0500
Well, I've completed algorithmic problem solving I and II in C++, a SCHEME
class, an assembly language class using a Motorola 68HC11 to make, among other
things, a graphics card. I've written C++ code to interface with custom made
USB devices, as well as created the drivers for those devices in Windows. I
have a pretty good idea about programming. Maybe you are misunderstanding my
question.
>Clay... while I'm glad that you are interested in helping with the
>project, you are a very confused puppy about a lot of basic programming
>concepts:
>a) you don't need to use "low-level" instructions or code in assembly
>to get object code. You get object code from the compiler. Write a C or
>C++ program and them compile it -- voila, you have object code.
But someone has to write the object code for the compiler to know what to
do with the source code. You can't have functions and classes just calling
other functions and classes to infinity. At some point, the most basic
functions (say ioctl()) have to have actual "hand-written" object files so that
a compiler can have a "degenerative case".
>That's what compilers are for -- they allow us to avoid having to write
>machine specific code.
How do you think a compiler knows how to turn source code into assembly?
>For your work, you
>should never need worry about this. You just write code in C or C++ and
>the compiler will take care of the machine code for you.
If my classes/functions just call other classes and functions, then THOSE
class and functions have to be defined in assembly, or the functions and
classes _they_ call wall have to be written in assembly. Somewhere down the
hierarchy, everything has to get to source code.
>b) libraries don't have to be "objectified".. they aleady are. That's
>essentially what libraries are -- collections of object code.
Okay, that makes sense and is basically what I was wanting confirmation
of. But who is going to do all of this library writing in ASM?
>They also include a little bit of information about the calling interface of
the
>functions within the library. But mostly, a library is just a big list
>of pre-compiled object code.
That's exactly what I wanted to hear. :)
>c) you asked in another email about the trail of calls, and doesn't it
>lead to assembly (or object code) at some point? No, every call in a
>trail of calls is already object (machine) code or it wouldn't be
>running.
I think you are contradicting yourself now..or maybe misunderstanding what
I asked. Above, you just _stated_ that libraries _are_ object code. That
means that when the compiler is crunching away, it eventually breaks all
commands like "myBNetEndPoint->Receive(blah, foo, x);" into assembly. No,
this command is not machine code; and it's not "running"..it's just getting
compiled. I think there is some kind of huge confusion between how we are
explaining this.
>Computers don't run C or C++, they run machine code.
That's entirely my point!
>That's why you use a compiler to generate it for you.
But a compiler can't know what to do with
ifstream din;
din.open('pr0n_clip_12');
Unless the ".c" for iofstream.h is already object code; or uses functions
and classes that are themselves already linked to an object code file. You
talk a compiler is some sort of intelligent entity that can just convert source
code to machine code without specificiations (ie object code files).
Clay
Other related posts:
