Re: What's the easiest and/or simplest part of Linux Kernel?
On 8/29/2013 8:25 PM, Joel Rees wrote:
On Thu, Aug 29, 2013 at 8:49 PM, Jerry Stuckle <jstuckle@attglobal.net> wrote:
On 8/29/2013 12:45 AM, Joel Rees wrote:
(I really don't have time to do this.)
On Thu, Aug 29, 2013 at 12:17 PM,
[Somebody replied to somebody, arguing that C can't do objects.]
The syntax does become obtuse, unfun, cluttered, etc., but it can be done.
I didn't say C can't do objects. I said it can't do Object Oriented
Programming. Two entirely different things.
End of argument, if you could just see what you just said.
Yep, because you obviously don't understand the difference between
objects and object oriented programming.
(To get the neurons connecting, think about early objective-C, when
the "object" stuff was done with a special purpose pre-processor.
Shoot. Don't forget that C++ itself was once a pre-processor for C.)
That's like saying C is a preprocessor for assembler. Sure, the original
C++ tools were preprocessors. However, they were preprocessors which
provided the tools necessary to do OOP.
The originals were pretty primitive. The current state is somewhat
improved, but incomplete.
Admittedly, the "object" syntax becomes a separate syntax and language
from the C part when you do OOP in unadorned C. You have to leave the
basic operators (+-*/%, etc.) out of the object-oriented language and
syntax. (Which is part of the reason it becomes unfun.)
Please show how you can do inheritance and polymorphism in C.
You do understand that "in C" can be read two or three ways.
But do you understand that not everyone agrees that the assertion of
"within the unadorned syntax of C" is the important one?
Not going as far as writing the compilers (or the
compilers-by-pre-processing) in C, there is still a way of using
unadorned C to induce a metalanguage of objects on C.
Again, please show how you can do inheritance and polymorphism in C.
And why do
you need to leave the basic operators out? They are inherent to both
languages.
I'm not talking about using an unadorned C compiler to compile either
C++ or objective-C.
I'm talking about programming OOP in C. The OOP operators might look like this:
obj1->plus( obj2->neg() );
plus() and neg() would be the operators, and the OOP language is
projected onto C function call syntax.
If you have complaints about calling methods operators, do you
understand Lisp? (or FORTH, ...)
Then show how to do inheritance and polymorphism in C. And yes, I did
FORTH in the early 80's and Lisp a bit later. Haven't used either for
years, though.
You have to use #include skillfully, and you have to explicitly put
function pointers in structures. It kind of turns things upside down,
a bit, and a little inside-out. It'll make even seasoned C programmers
seasick. And the syntax is not as flexible as C++.
Again, please show how to do inheritance and polymorphism in C.
If you understand what I mean by using function pointers in
structures, you should be able to see that inheritance and
polymorphism are simply matters of providing certain functionality in
support libraries, and adding appropriate pointers in the structures
that define the objects.
Then you should easily be able to show how to do inheritance and
polymorphism in C.
Which is all why C++ was written as a separate language.
But it can be done.
Once again, please show how to do inheritance and polymorphism in C.
You're going to have to intuit the libraries that I am implicitly
inferring have been written and are being linked in, appropriate
headers being included, etc., and not even trying to provide any
syntactic sugar:
----------------------------
struct my_object_s
{
pfii_f constructor, destructor;
pfiv_o inherited_context, local_context; /* local_context is for
polymorphism. */
pfam_f method1;
pfam_f method2;
...
} my_object_o;
---------------------
I assume you will complain that I'm just talking about providing the
functionality without the syntax of objects, and you'd be sort of
right. And you should complain that the convention of ending method
type declarations with "_f" and object type declarations with "_o" is
unenforceable (and ask whether the convention is anywhere explicitly
documented).
That is neither inheritance nor is it polymorphism. It is simply a set
of pointers to functions within a structure.
By the way, mathematically speaking, objects are machines.
Maybe mathematically speaking, but we're talking programming here.
Is programming somehow independent of mathematics?
In
programming, variables have state. Functions have behavior. Objects have
both state and behavior.
And that is different from mathematical automata how?
In programming, objects are not machines. About the only "machine"
concept I can think of is the old "state machine" from the 70's.
OOP is a paradigm, a set of rules for projecting certain aspects of
automata onto existing programming tools. The paradigm has a lot of
implicit rules that are not well documented. If you understand the OOP
class of paradigms, you may use the tools effectively. Or not
effectively. Or not at all.
I think I understand the paradigms, but I find myself feeling like I'm
in a straitjacket when trying to use them. Most of the programs I
write do not project well onto the OOP paradigm. I suppose that may
have something to do with being spoiled by an early introduction to
assembler and FORTH, and with learning C at the same time as I was
learning m4 and lisp.
None of which has anything to do with the simplest part of the Linux
kernel for a C newbie to try to drown in.
--
Joel Rees
No, OOP is quite well documented. I understand them well - been doing
(and teaching to corporate programmers) OOP for over 25 years now.
For your education - OOP consists of four basic principles:
1. Encapsulation: making internal variables (states) and possibly some
messages unavailable to the external world. In C++, this is done with
the "private" keyword; "protected" is an extension to the OO paradigm.
This part can be emulated in C, but it's awkward.
2. Message passing: Telling the object to perform some action
(behavior). In C++ this is done mostly with member functions; however
due to language restrictions the language also includes "friend"
functions. This can also be emulated in C, but is awkward.
3. Inheritance: the ability to extend an existing class, to provide
additional or different functionality via additional messages in the
derived class. Inheritance takes advantage of the similarities in the
base an derived classes. The base class has no knowledge of the derived
class and, in fact, may not even know it is being used as a base class.
Additional classes can be derived from the original base and derived
classes with no change to the existing code. This cannot be done in C.
4. Polymorphism: the ability to send messages to a derived class object
when you believe you have an object of the base class. This allows
functions to operate on any class in the derived hierarchy, while only
having to worry about the messages defined in the base class. This also
cannot be done in C.
As I said - you can emulate Object Based programming in C, although it
is messy. You cannot create Object Oriented programs in C.
And one other thing - when properly done (and understood), OOP is not a
"straightjacket". Rather, it creates better code by encapsulating (not
to be confused with encapsulation) code in well-defined modules which
have a defined interface and behavior. One does not need to know what
goes on in the object to use it.
The best example I can give of an object programmers use every day in C
is a float (or double). Internally, it is stored as base and mantissa
(IEEE 754). It has messages - addition, subtraction, assignment, etc.
But you don't need to know the internal format of the variable, and in
fact cannot access individually the base or mantissa. At any time the
internal representation can change - the code for the messages would
have to change also, but nothing using variables of the type need to be
changed; only a recompile need be done.
The same is true for objects. You can change the private area of an
object, and you can change the code in the message processing. But as
long as you don't change the public interface, nothing needs to be
changed in the program using it; only a recompile may need to be done.
Jerry
Reply to: