C/C++

[abowhill]

I am reposting this in freebsd-chat, because a couple of people 
warned me about being off-topic in -questions.

>> The idea that C can be used to do object-oriented programming is 
>> a myth. The C language is not object-oriented or even object-based.
>> The big reason C++ is object-oriented is due to dynamic binding.

>I don't think I buy that.  With that reasoning, couldn't you say that
>any program in any language that does any sort of dynamic binding (for
>example, opening a .so file) "is object-oriented"?

I guess what you are talking about is analagous to polymorphism at a systems level with regard to library versions, but am not sure. 

You probably know all this, but for the sake of people who don't...

Dynamic or late binding refers to the ability of C++ to have "smart pointers" to functions at runtime. As long as any class has a "contract" with a base class to define a function foo(), you can call foo() indirectly through the base class, without ever having to know what the data type is of the object you are running it on.

So, if you create 100 different types of objects that support foo(), 
and 100 different ways of implementing foo(), you don't have to know 
(or care) which object you are acting on. You just make a function call 
to baseclass->foo(), and you are guranteed to have the right foo() called.

For example, suppose I have an abstract base "bar" with the virtual
function value(). Suppose I make two classes that inherit from 
this, "gold" and "soap", and give them each their own value() 
functions, which use different ways to calculate the value of 
each material.

At runtime, I create a bar of soap and a bar of gold, and 
put them on a queue. When I want to tally their values, I pop an 
object from the queue, and execute bar->value(). I do not have to 
know whether I am getting the value of a bar of soap or a bar of gold. 
I can trust the return value to be correct.

I'm not sure how that parallels with your point about *.so since
I haven't dealt with dynamic shared libs in C too much.

>The way I see it is that object-orientation is a methodology, and
>languages aren't methodologies, so it's absurd to say that some language
>"is" or "isn't" object-oriented.  (I mean, we all know that the Bourne
>shell "is object-oriented,"[1] right? :)  The best you can do is to
>describe the degree to which some language supports or enforces
>object-oriented programming.  Incidental to that, C++ provides many
>abstractions which support object-oriented programming, while not
>enforcing them in any way.

I agree with the idea that new methodolgy is at the core of 
object-oriented programming. A very insightfile observation. 
New methodologies give birth to new languages that support them. 

Although the methodologies of object-oriented programming have largely
been defined, they have not been fully resolved. 

There are some OO-languages that try to treat every atom of the language
and data it manipulates as objects. For instance, Ruby treats characters 
as objects. There are probably some languages that try to treat ints as
objects too. 

C++ doesn't go this far, but you can create a class in C++ to make an 
int an object, and use it. In most cases, it would be beyond the 
threshold of reason to do this.

However, to say C++ isn't an "object-oriented language" becuase it 
doesn't support atom as an object would be unfair. It would 
be fairer to say that C++ has a high order of contact with the 
methodologies of object-oriented design, and therefore can be 
casually referred-to as an "object-oriented language".

Likewise, it would be reasonable to say that the mechanisms of C 
have a low order of contact with object oriented methodologies 
by design, and therefore C can't be referred to as an 
object-oriented language.

>But this is getting far off topic for this list; the bare facts remain:

>- much of FreeBSD (kernel, userland) is written in C

Yes. I believe the reason for this is partly historical. But C is 
not necessarily a better language for programming userland utilities.
I really don't know about the kernel, but the thought someone trying to
do it in C++ is kind of scarey to contemplate.

Personally, I would be breaking down the door to participate if someone created another version of BSD to bridge the gap between old-world programming and modern-day methods. 

I love FreeBSD, I have followed it for years. But frankly, it's 
grown a bit stale, from a spectator's viewpoint. The more I 
learn about progamming the less I seem to respect the crufty 
old Unix traditions that nobody wants to break.

Within the past couple of years, I have returned to school 
and am finishing prereq's to get into a CS program at the 
University of Washington. Right now, I'm doing 3rd quarter 
calculus and am bored out of my skull. The reason I am 
writing such long posts, is to avoid working with Taylor's 
formula (urp)

And I still have 2 to 3 more years left...

>- many FreeBSD ports are written in C++
>
>So, as stated several times now, it really depends on what you want to
>work on.

Yep, I agree.

So who wants to create another BSD distro and rewrite userland 
utilities in C++? Any takers? No? 

Just me? uh oh ....

Hahahahaa! :)

--Allan