Date: Thu, 13 Nov 2003 20:47:01 -0800 From: "abowhill" <abowhill@blarg.net> To: <freebsd-chat@freebsd.org> Subject: C/C++ Message-ID: <20031114044623.C119838124@mail.blarg.net>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031114044623.C119838124>