Re: Why We Use C Than C++...

sonugeetha@xxxxxxxxx wrote:
>>>From http://www.cplusplus.com/doc/information/description.html
>
> When choosing a programming language to make a project, many different
> considerations can be taken. First, one must decide what is known as
> the level of the programming language. The level determines how near to
> the hardware the programming language is. In the lower level languages,
> instructions are written thinking directly on interfacing with
> hardware, while in "high level" ones a more abstract or conceptual code
> is written.
>
> Generally, high level code is more portable, that means it can work in
> more different machines with a smaller number of modifications, whereas
> a low level language is limited by the peculiarides of the hardware
> which it was written for. Nevertheless, the advantage of low level code
> is that it is usually faster due to the fact that it is indeed written
> taking advantage of the possibilities of a specific machine.
>
> A higher or lower level of programming is to be chosen for a specific
> project depending on the type of program that is being developed. For
> example, when a hardware driver is developed for an operating system
> obviously a very low level is used for programming. While when big
> applications are developed usually a higher level is chosen, or a
> combination of critic parts written in low level languages and others
> in higher ones.
>
> (So from the above statement its clear that Object Oriented Programming
> is generally used for application type of projects)

No it is not clear, this text only talks about levels of abstraction.

There are reasons for using OOP/OBP. One reason is that the problem when
displayed/presented as interacting objects is easier to understand. Think
about it: how many drivers in fact provide a common interface? This is a
typical example of in-kernel OOP. Other examples are the memory subsystem:
it could be abstracted as a single object that initially owns all
available RAM and then gives it away in an orderly way. Mostly, this is a
case of encapsulation (which is just one facet of OOP) and something which
can also be achieved with good modules written in C. Lastly, there are
dozens of kernel-level object types inside e.g. Linux. Every time you see
a struct and a bunch of associated functions this is in fact an object. If
the struct is only available as declaration, it also has encapsulation. If
it has some function pointers or a pointer to some other struct holding
them it is an implementation of an interface, i.e. derivation and thus
OOP. If it contains a void pointer named 'private' or 'user' or such it is
to extend the data of the struct with data the particular derived
implementation needs.

Please also note that C++ is not synonymous with OOP. C++ supports OOP
(yes, to an extent that disappoints OOP purists) but doesn't mandate it.


> Some minor reasons for using C from
> http://www.linuxdevices.com/eljonline/issue07/4870s1.html
[...]
> C++'s virtues are expensive. Advanced OOP features, such as
> templates and the practice of using classes in the place of primitives,
> to name two examples, cause unacceptable code bloat.

hmmm, templates are not generally an OOP feature. Wrapping primitives can
be just as efficient as using them directly - you just need to inline
relevant accessors. Other than that, an inappropriate design will alway
suck in this or that way and you have a choice to use those features, a
fact the author of above text blissfully ignores.

> Virtual methods and polymorphism complicate runtime linking and
> require many relocations. This slows C++ application launch time
> considerably. C applications are both simple to link and amenable to
> lazy linking, so they load quickly. (For details, see Waldo Bastian's
> paper ``Making C++ Ready for the Desktop",
> http://www.suse.de/~bastian/Export/linking.txt.)

Not only that this doesn't apply to in-kernel programming (as already
pointed out), it has also ceased to be true! It was just a matter of
patching the linker to cope with whole arrays at once, as they happen with
vtables of polymorphic C++ classes, IIRC it was called the 'combreloc'
patch.

cheers

Uli
(who is surprised by the low amount of flames in this thread)

.

Relevant Pages

  • Re: Code Review - is this code shit
    ... "learning" a programming language is not quite the same as other ... I announced my score, I pointed out that it was meaningless, because ...
    (comp.lang.c)
  • Re: book on oop concepts
    ... I came across a book which discusses oop concepts in detail, independent of programming language: ... "An introduction to Object-Oriented Programming", ... I advise you to stay away from OOP theory and sloganizing because I found those kinds of explanations vague and misleading. ... If you're interested, I could mail you a primer for C programmers explaining the basic OOP concepts common to the most popular OOP languages. ...
    (comp.lang.java.programmer)
  • Re: Minsky still posting
    ... pushing Prolog out of the way as the standard logic programming ... I think the lack of appreciation of that amongst most academics ... involved in programming language work was a prime reason why the ...
    (comp.lang.prolog)
  • Re: A taxonomy of types
    ... An object-oriented programming language supports ... OOP language and completely rely on the compiler to make sure things work ...
    (comp.lang.misc)
  • Re: OpenBSD C programming - getting started
    ... You are expected to know about programming language principles, ... You usually let the driver take care of that. ... I'd start with writing programs that don't dig deep into hardware, ...
    (comp.unix.bsd.openbsd.misc)