why still use C?

Discussion in 'C Programming' started by cody, Oct 5, 2003.

  1. cody

    cody Guest

    no this is no trollposting and please don't get it wrong but iam very
    curious why people still use C instead of other languages especially C++.

    i heard people say C++ is slower than C but i can't believe that. in pieces
    of the application where speed really matters you can still use "normal"
    functions or even static methods which is basically the same.

    in C there arent the simplest things present like constants, each struct and
    enum have to be prefixed with "struct" and "enum". iam sure there is much
    more.

    i don't get it why people program in C and faking OOP features(function
    pointers in structs..) instead of using C++. are they simply masochists or
    is there a logical reason?

    i feel C has to benefit against C++.

    --
    cody

    [Freeware, Games and Humor]
    www.deutronium.de.vu || www.deutronium.tk
    --
    comp.lang.c.moderated - moderation address:
     
    cody, Oct 5, 2003
    #1
    1. Advertising

  2. In article <>, cody wrote:
    > no this is no trollposting and please don't get it wrong but iam very
    > curious why people still use C instead of other languages especially C++.
    >
    > i heard people say C++ is slower than C but i can't believe that.

    [-]
    It isn't.

    [-]
    > i don't get it why people program in C and faking OOP features(function
    > pointers in structs..) instead of using C++. are they simply masochists or
    > is there a logical reason?

    [-]
    C++ compilers used to pose problems like being more or less standards
    compliant and in all honesty they often still do plus to generate optimal
    machine code the compiler / linker combo needs to work together much more
    closely than it is the case with C.

    Well, and developers used to and use to pose problems, too as just take
    some seasoned C developers and be assured over their dead body they'll
    admit not to be able to output high quality C++ code almost straight
    away and so it must be the language.

    In short C++ isn't slower for sure as both, a C as well as a C++ compiler
    is going to generate machine code. It's just no compiler can do the
    thinking for you (yet) and I haven't met all too many C++ developers
    yet who really do know the language.

    Mind I'm far from saying I'd really do. Far from it, though I'm not
    having problems admiting that while, after being more then 10 years in
    the job, I dare say there's a fair share of developers, often the local
    "star developers", who prefer arguing to listening.

    In general language wars are pointless anyway, though as the end user
    couldn't care less about "your" problems but he or she wants to see
    a working result, so the real question is are you able to deliver or
    are you not ?

    Cheers,
    Juergen

    --
    \ Real name : Juergen Heinzl \ no flames /
    \ EMail Private : \ send money instead /
     
    Juergen Heinzl, Oct 5, 2003
    #2
    1. Advertising

  3. cody

    Sidney Cadot Guest

    Hi cody,

    > no this is no trollposting and please don't get it wrong but iam very
    > curious why people still use C instead of other languages especially C++.


    I can't answer for people in general of course, but as a moderately able
    C programmer with a thorough dislike of C++ I can try to explain what my
    motives are.

    > i heard people say C++ is slower than C but i can't believe that. in pieces
    > of the application where speed really matters you can still use "normal"
    > functions or even static methods which is basically the same.


    A few years ago I did some timing and (counter to my intuition) I found
    that, indeed, it didn't make a difference, as you point out. One
    remarkable thing was that the C++ executables for my (small) benchmarks
    were quite a bit larger, which may be relevant for embedded applications.

    > in C there arent the simplest things present like constants, each struct and
    > enum have to be prefixed with "struct" and "enum". iam sure there is much
    > more.


    These are some areas where I would agree that yes, C++ is (a bit)
    cleaner than C. Another example is declaring variables inside for()
    statements and such, this can truly help readability, and limiting the
    scope of a local variable if possible is a good thing. Note that many of
    these (almost cosmetic) changes have made their way back into C99.

    > i don't get it why people program in C and faking OOP features(function
    > pointers in structs..) instead of using C++. are they simply masochists or
    > is there a logical reason?


    In all honesty I think that many people who prefer C over C++ don't
    quite get what all the fuzz is about in OOP (I know I don't). In
    principle there are sound advantages to grouping together structs and
    their associated method functions from a design perspective. Inheritance
    and polymorphism have an important part to play as well, especially in
    some areas of application (such as GUIs).

    However, this is the first place where you get a tradeoff of execution
    speed, executable size, and runtime memory usage (for virtual method
    tables) versus design-time advantages. In reality of course, especially
    with nowadays' big machines, these disadvantages are not too important
    for most applications. However, (to me at least) it is a bit unnerving
    to be at the mercy of the compiler and its designer, and hope that he
    implemented all this machinery properly and without causing too much
    overhead. This is more a psychological barrier than a real one of
    course, since modern compilers are able to optimize away many
    unneccessary machinery, and some rather clever tricks have been found to
    make virtual method calls very cheap. However, as a programmer I am no
    longer completely in the driver's seat as I am with C. Looking at a C
    porgram, I can have a straightforward and relatively accurate mental
    picture of what the actual machine code produced by the compiler will
    look like. With OOP and C++, that's no longer true, especially with code
    that uses all the available C++ features including exceptions and templates.

    One generic complaint I have with OOP (not limited to C++) is that I can
    no longer look at a code fragment and reconstruct the execution flow in
    my head, because of polymorphism and operator overloading; in C (unless
    you're doing funky stuff with threads or longjumps), the execution flow
    is pretty much known at compile-time, and can be reproduced from the
    code. I happen to like that.

    Of course OOP proponents will counter that this is in fact the entire
    point of OOP: one should no longer be thinking in terms of structural
    execution flow, but rather in terms of objects with a well-defined
    behaviorial 'contract', that can be triggered by invoking methods.

    Now this is where a lot of subjectivity comes in, but I for one simply
    don't think that way. This is probably due to the way I earned my
    computer experience (going up from BASIC to 8-bit machine language to
    Pascal to C). "Thinking in classes", something that is essential for
    good OOP programming, is just not for me (except for some obvious cases
    with a small number of classes - I have done some C++ programming in my
    time of course).

    When the programs get bigger, and the number of classes grows, you come
    to another point: there is a transition in the level of design: instead
    of putting statements in the right order, you have to start managing a
    class model. The Design Patterns school-of-thought comes in here: how do
    I design a set of classes with interaction to get a certain type of
    bahavior? For me, this has two problems. First, there is often more than
    one sensible way of designing a set of classes to address a certain
    problem. I have an instinctive dislike of that kind of situation: I have
    the (admittedly rather naive) feeling that software related problems
    should have a canonical 'best' solution. The second (real) problem is
    that C++ doesn't really support the Design Pattern level of abstraction.
    Instead, it hands the programmer a number of nuts and bolts that enable
    him to approximate the abstract idea encapsulated in a DP. I think there
    are no programming languages available today that properly support the
    Design Pattern methodology, and it's certainly not C++.

    Now of course all this is more a rant against OOP than C++, but IMHO C++
    offers no advantages to C99 other than OOP-support, so it is relevant to
    your question.

    You could argue of course that C++ > (C + OOP). The two most prominent
    features apart from OOP that set aside C and C++ are, I think,
    exceptions and templates.

    As for exceptions, you may know Dijkstra's paper "Goto's considered
    harmful". In this paper he has a number of points that I would subscribe
    to, concerning the ability of the human programmer to read the meaning
    of a piece of code from the source. In essence, he argues that GOTO
    statements destroy this possibility.

    I would argue that exceptions are "goto's on steroids". Since exceptions
    are allowed to cross function-call boundaries, execution flow becomes
    very non-transparant - at least to me! This is a similar objection I
    have with polymorphism as described above.

    A serious problem with exception handling in C++ is it's interaction
    with memory management, which is made even worse by having implicit
    object creation (with implicit constructor calls). Now I know a lot of
    talented programmers, many of which are far more accomplished in C++
    programming than I am, but not a single one of them can quote me the
    do's-and-don'ts of a 'good' C++ program in this respect. It's a minefield.

    Incidentally, having just written a rather big real-life C library with
    error handling, I do appreciate the need for exception handling.
    However, I think it is a mistake to have a language that does include
    exception handling but doesn't do garbage collection for the reason
    stated above. Sure, it's possible to do it properly. But one has to
    remember that programmers are human beings; most programmers I know have
    simply not the level of intimacy with the C++ runtime model to do this
    without making mistakes.

    Templates.... Suffice it to say that one cannot write a portable C++
    program using templates and expect it to work identically on different
    compilers. Portability is nil, and this makes this feature not useful in
    many practical sutuations. One can complain about (or to) compiler
    builders in this regard, but this is just a symptom of overly
    complicated semantics. Even if compiler builders get their act together,
    the semantics would still be too difficult for most programmers.
    Including me.

    To summarize I would say C++ with its feature set is just too
    complicated, as a language design I feel it has failed. One has to keep
    in mind that a programming language is a tool to make programs. If a
    tool has a significant chance of being unintentially misused (with
    possibly disastrous results), it's not a good tool. I will stick with
    something I actually (more or less) understand, which is C.

    By the way, did you ever read the Stroustrup book ('Programming in
    C++')? As the book progresses, his examples evolve from things that look
    sort-of-like-C to STL-based programs that are (to my untrained eye at
    least) simply ugly. My feeling is that he tries to bring the expressive
    power of dynamic interpreted languages to the realm of compiled
    languages. A valliant attempt, and I would applaud him for it. However,
    his writing conveys a breathtaking arrogance or perhaps lack of
    understanding for the fact that most programmers are mere mortals... I'm
    sure as the language's designer he is able to mentally internalize the
    runtime model of C++, but to think that your average programmer could
    readily do the same is just preposterous.

    And a last thing: try writing a library in C++ and linking it with a
    program written in C (like Matlab, IDL, Mathematica...). Now there's a
    practical reason to prefer C over C++ if I ever saw one.

    Thank you for giving me an opportunity to rant a bit about this. Perhaps
    this therapeutical excercise of mine will give you some insight in the
    reasons why some of us still prefer C over C++! :)

    Best regards,

    Sidney Cadot
    The Netherlands
     
    Sidney Cadot, Oct 6, 2003
    #3
  4. Sidney Cadot wrote:

    > Hi cody,
    >
    >> no this is no trollposting and please don't get it wrong but iam very
    >> curious why people still use C instead of other languages especially C++.

    >
    > I can't answer for people in general of course, but as a moderately able
    > C programmer with a thorough dislike of C++ I can try to explain what my
    > motives are.


    <superb answer snipped>

    Very well said. A very thoughtful article indeed.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Oct 6, 2003
    #4
  5. "Sidney Cadot" <> wrote in message
    news:blqeq9$1lc$...
    > Hi cody,
    >
    > > no this is no trollposting and please don't get it wrong but iam very
    > > curious why people still use C instead of other languages especially

    C++.
    >
    > I can't answer for people in general of course, but as a moderately able
    > C programmer with a thorough dislike of C++ I can try to explain what my
    > motives are.
    >
    > > i heard people say C++ is slower than C but i can't believe that. in

    pieces
    > > of the application where speed really matters you can still use "normal"
    > > functions or even static methods which is basically the same.

    >
    > A few years ago I did some timing and (counter to my intuition) I found
    > that, indeed, it didn't make a difference, as you point out. One
    > remarkable thing was that the C++ executables for my (small) benchmarks
    > were quite a bit larger, which may be relevant for embedded applications.


    OOP in general tends to be slower. The process of allocating and
    deallocating memory, including finding a good sized region to allocate,
    takes time. As you say, though, one can do non-OOP in C++, and, with some
    work, OOP in C.

    > > in C there arent the simplest things present like constants, each struct

    and
    > > enum have to be prefixed with "struct" and "enum". iam sure there is

    much
    > > more.


    As if the compiler didn't know... In PL/I structures can be referenced in
    any unambiguous way. I don't know if that leads to more bugs, or makes
    programs more or less readable, though. It does seem strange that you have
    to keep reminding the compiler that something is a struct.

    > These are some areas where I would agree that yes, C++ is (a bit)
    > cleaner than C. Another example is declaring variables inside for()
    > statements and such, this can truly help readability, and limiting the
    > scope of a local variable if possible is a good thing. Note that many of
    > these (almost cosmetic) changes have made their way back into C99.
    >
    > > i don't get it why people program in C and faking OOP features(function
    > > pointers in structs..) instead of using C++. are they simply masochists

    or
    > > is there a logical reason?


    Note, though, that Java is much closer to C than C++ is, despite the
    similarity of names. If you like C, but want an OO language, Java should be
    your choice.

    > In all honesty I think that many people who prefer C over C++ don't
    > quite get what all the fuzz is about in OOP (I know I don't). In
    > principle there are sound advantages to grouping together structs and
    > their associated method functions from a design perspective. Inheritance
    > and polymorphism have an important part to play as well, especially in
    > some areas of application (such as GUIs).


    For some kinds of programming projects, yes.

    (snip)

    >. However, as a programmer I am no
    > longer completely in the driver's seat as I am with C. Looking at a C
    > porgram, I can have a straightforward and relatively accurate mental
    > picture of what the actual machine code produced by the compiler will
    > look like. With OOP and C++, that's no longer true, especially with code
    > that uses all the available C++ features including exceptions and

    templates.

    Well, some people consider C as a glorified assembler. It isn't quite that,
    especially as it has changed over the years, but not so far off.

    > One generic complaint I have with OOP (not limited to C++) is that I can
    > no longer look at a code fragment and reconstruct the execution flow in
    > my head, because of polymorphism and operator overloading; in C (unless
    > you're doing funky stuff with threads or longjumps), the execution flow
    > is pretty much known at compile-time, and can be reproduced from the
    > code. I happen to like that.


    Well, with library functions in general you don't know what is inside the
    function. If you are writing the whole program yourself then the
    abstraction is less useful. If different people are working on different
    parts then abstraction means you need to know less about the specific
    features of those parts. The interface is narrower, which sometimes
    decreases efficiency. (It may take more calls to get something done, or
    more things done than are really needed.)

    > Of course OOP proponents will counter that this is in fact the entire
    > point of OOP: one should no longer be thinking in terms of structural
    > execution flow, but rather in terms of objects with a well-defined
    > behaviorial 'contract', that can be triggered by invoking methods.


    (snip)

    > As for exceptions, you may know Dijkstra's paper "Goto's considered
    > harmful". In this paper he has a number of points that I would subscribe
    > to, concerning the ability of the human programmer to read the meaning
    > of a piece of code from the source. In essence, he argues that GOTO
    > statements destroy this possibility.
    >
    > I would argue that exceptions are "goto's on steroids". Since exceptions
    > are allowed to cross function-call boundaries, execution flow becomes
    > very non-transparant - at least to me! This is a similar objection I
    > have with polymorphism as described above.


    Well, there is that. But the name, exception, gives you some idea of their
    use. They should be used for exceptional things. In compilers sometimes
    there is nothing that can be done. Especially in recursive descent
    compilers it may be that the only thing to do is declare an error and go
    onto the next statement. That requires crossing function call boundaries,
    but it is easy to understand what is happening. The C setjmp/longjmp has a
    similar use, and is similarly non-transparent.

    (snip)

    > To summarize I would say C++ with its feature set is just too
    > complicated, as a language design I feel it has failed. One has to keep
    > in mind that a programming language is a tool to make programs. If a
    > tool has a significant chance of being unintentially misused (with
    > possibly disastrous results), it's not a good tool. I will stick with
    > something I actually (more or less) understand, which is C.


    Well, much of the idea of C is to be simple. I learned PL/I as my first
    structures language, and I still prefer it, in some ways, to C. PL/I is
    complicated, almost by design. (It was designed to include features from
    Algol, Fortran, and COBOL, all in one language.) C string handling is
    simple in design, somewhat efficient, but so easy to do wrong. Again,
    PL/I was designed to be complicated, but such that you didn't need to learn
    parts you didn't need to use. That required no reserved words. (If you
    didn't know about a feature how could you know not to use the words?)
    Writing simple programs is pretty simple. The dynamic memory features of C
    are fine once you are used to them, but pretty strange until then.

    -- glen
     
    Glen Herrmannsfeldt, Oct 6, 2003
    #5
  6. cody

    Guest

    On 6-Oct-2003, "cody" <> wrote:

    > [snip]


    Because C is more portable?
     
    , Oct 6, 2003
    #6
  7. cody

    Mike Wahler Guest

    <> wrote in message
    news:...
    >
    > On 6-Oct-2003, "cody" <> wrote:
    >
    > > [snip]

    >
    > Because C is more portable?


    No more portable than C++.

    -Mike
     
    Mike Wahler, Oct 6, 2003
    #7
  8. cody

    cody Guest

    > Inheritance and polymorphism have an important part to play as well,
    > especially in some areas of application (such as GUIs).
    >
    > However, this is the first place where you get a tradeoff of execution
    > speed, executable size, and runtime memory usage (for virtual method
    > tables) versus design-time advantages. In reality of course, especially
    > with nowadays' big machines, these disadvantages are not too important
    > for most applications. However, (to me at least) it is a bit unnerving
    > to be at the mercy of the compiler and its designer, and hope that he
    > implemented all this machinery properly and without causing too much
    > overhead. This is more a psychological barrier than a real one of


    that is really true!

    > course, since modern compilers are able to optimize away many
    > unneccessary machinery, and some rather clever tricks have been found to
    > make virtual method calls very cheap. However, as a programmer I am no
    > longer completely in the driver's seat as I am with C. Looking at a C
    > porgram, I can have a straightforward and relatively accurate mental
    > picture of what the actual machine code produced by the compiler will
    > look like. With OOP and C++, that's no longer true, especially with code
    > that uses all the available C++ features including exceptions and

    templates.
    >
    > One generic complaint I have with OOP (not limited to C++) is that I can
    > no longer look at a code fragment and reconstruct the execution flow in
    > my head, because of polymorphism and operator overloading;


    yes, operator overloading is one of the most the most sucking thing in c++!

    > As for exceptions, you may know Dijkstra's paper "Goto's considered
    > harmful". In this paper he has a number of points that I would subscribe
    > to, concerning the ability of the human programmer to read the meaning
    > of a piece of code from the source. In essence, he argues that GOTO
    > statements destroy this possibility.
    >
    > I would argue that exceptions are "goto's on steroids". Since exceptions
    > are allowed to cross function-call boundaries, execution flow becomes
    > very non-transparant - at least to me!


    where the exception goes is well defined, it cannot go somewhere, it goes
    simply
    down the callstack which is more readable than gotos, imo.

    but doesn't c support structured exception handling too? i heard something
    like that.

    > It's a minefield.


    absolutely.

    > Templates.... Suffice it to say that one cannot write a portable C++
    > program using templates and expect it to work identically on different
    > compilers. Portability is nil, and this makes this feature not useful in
    > many practical sutuations. One can complain about (or to) compiler
    > builders in this regard, but this is just a symptom of overly
    > complicated semantics.


    that is not true. name me one example where semantics are different on
    different compilers!
    templates are a very very useful and mighty feature in c++. however it is a
    bit difficult to use.

    > To summarize I would say C++ with its feature set is just too
    > complicated, as a language design I feel it has failed. One has to keep
    > in mind that a programming language is a tool to make programs. If a
    > tool has a significant chance of being unintentially misused (with
    > possibly disastrous results), it's not a good tool. I will stick with
    > something I actually (more or less) understand, which is C.


    yes and no. c++ should not be used for everything. gui's should not be made
    with c++.
    for libraries, c++ is good because it is very fast and flexible thanks to
    templates.
    you say the language design has failed, but do you have a better idea how it
    can be solved?
    imo for high performance applications there is no better way than c++. since
    c lacks of templates,
    c++ would be the choice for me.

    > By the way, did you ever read the Stroustrup book ('Programming in
    > C++')? As the book progresses, his examples evolve from things that look
    > sort-of-like-C to STL-based programs that are (to my untrained eye at
    > least) simply ugly. My feeling is that he tries to bring the expressive
    > power of dynamic interpreted languages to the realm of compiled
    > languages. A valliant attempt, and I would applaud him for it. However,
    > his writing conveys a breathtaking arrogance or perhaps lack of
    > understanding for the fact that most programmers are mere mortals... I'm
    > sure as the language's designer he is able to mentally internalize the
    > runtime model of C++, but to think that your average programmer could
    > readily do the same is just preposterous.


    right i cannot imagegine that somebody really and completely understands the
    STL.

    --
    cody

    [Freeware, Games and Humor]
    www.deutronium.de.vu || www.deutronium.tk
     
    cody, Oct 6, 2003
    #8
  9. cody

    Tim Prince Guest

    Mike Wahler wrote:

    >
    > <> wrote in message
    > news:...
    >>
    >> On 6-Oct-2003, "cody" <> wrote:
    >>
    >> > [snip]

    >>
    >> Because C is more portable?

    >
    > No more portable than C++.
    >
    > -Mike

    Are you excluding "C++" programs written for Microsoft compilers, or g++
    prior to 3.x? That would nearly make the point, that C++ portability has
    been possible (but not commonly adhered to) for about a year, compared to
    over 20 for C.
    --
    Tim Prince
     
    Tim Prince, Oct 6, 2003
    #9
  10. cody

    James Kuyper Guest

    Sidney Cadot <> wrote in message news:<blqeq9$1lc$>...
    ....
    > And a last thing: try writing a library in C++ and linking it with a
    > program written in C (like Matlab, IDL, Mathematica...). Now there's a
    > practical reason to prefer C over C++ if I ever saw one.


    It seems to me that only this last issue truly addresses the question.
    In all of your other issues, you're complaining about features of C++
    that you don't have to use if you don't want to.

    I personally use C or C++ for the simple reason that our company's
    contract with NASA requires us to deliver code for either Fortran 77,
    Fortran 90, C90 (more precisely, C94), or Ada.

    I like C because it's a simpler language than C++, and because I've
    got a lot more experience with it. However, I love complicated things,
    and I see all kinds of interesting features in C++ that I'd love to
    have time to play with. However, as long as all of my C++ programming
    is done at home, rather than at work, I'm never going to build up much
    experience with it. I'm hpping that the next project I work on allows
    both C++ and C99 (which also has some neat new features that aren't in
    C++).
     
    James Kuyper, Oct 6, 2003
    #10
  11. On Sun, 5 Oct 2003, cody wrote:

    > no this is no trollposting and please don't get it wrong but iam very
    > curious why people still use C instead of other languages especially C++.
    >
    > i heard people say C++ is slower than C but i can't believe that. in pieces
    > of the application where speed really matters you can still use "normal"
    > functions or even static methods which is basically the same.
    >
    > in C there arent the simplest things present like constants, each struct and
    > enum have to be prefixed with "struct" and "enum". iam sure there is much
    > more.
    >
    > i don't get it why people program in C and faking OOP features(function
    > pointers in structs..) instead of using C++. are they simply masochists or
    > is there a logical reason?
    >
    > i feel C has to benefit against C++.


    There are a few reasons I would use C over C++.

    1) Not all environments have a good C++ compiler.

    There are still some situations where finding a good C++ compiler is just
    not possible. Last time I checked they were still working on an embedded
    C++ standard because the C++ standard does not address the needs of the
    embedded world.

    2) There is a certain amount of overhead with learning and using C++ that
    might not be necessary for specific projects.

    If I am writing a program that I can keep most, if not all, of the project
    in my head then why would I want to use C++? Especially if I have been
    programming C for over 20 years.

    3) C language is closer to assembly language.

    If I am trying to squeak out every last cycle I can out of an application
    or if timing is critical I would write a project in C language, set a
    switch to keep the intermediate assembly source files and then replace the
    C source with assembly source but only for those functions that need to be
    hand tweaked. In situations where I cannot do this, I can often play with
    my C language until I get the same results as programming in assembly
    language.

    Bottom line, I use C with I don't need everything C++ offers. It is sort
    of the same reason they still teach Newtonian physics. Why doesn't
    everyone use Einsteinian physics? Because Newtonian is easier and is good
    enough for today to today physics.

    --
    Send e-mail to: darrell at cs dot toronto dot edu
    Don't send e-mail to
     
    Darrell Grainger, Oct 6, 2003
    #11
  12. cody

    James Kuyper Guest

    Darrell Grainger wrote:
    ....
    > 3) C language is closer to assembly language.


    I don't think that objection holds up. Whatever features of C that
    you're thinking of, are all part of C++ as well. If you need to write
    close to assembly language, you can write C++ code that is also legal
    C90 code with essentially the same meaning. If you follow good C coding
    practices (systematic use of prototypes, etc.), you'll seldom even have
    to hink about the fact that you're writing this code to be compiled by a
    C++ compiler, rather than a C compiler.
     
    James Kuyper, Oct 6, 2003
    #12
  13. cody

    CBFalconer Guest

    Mike Wahler wrote:
    > <> wrote in message
    > >
    > > Because C is more portable?

    >
    > No more portable than C++.


    There are many machines out there that have a C compiler, of some
    sort, available. They do not have any C++ available. PICs, the
    Rabbit, 8051s come to mind. To my mind this makes C more
    portable.

    If you talk solely about portability, but not availability, then
    Pascal is much more portable than C. There are far fewer
    requirements for the underlying machine. But if you talk about
    walking up to some machine while clutching a program source file
    in some ISO standardized language, and getting that program to run
    on that machine, C is most likely to do the job.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Oct 6, 2003
    #13
  14. cody

    Santa Claus Guest

    On Mon, 06 Oct 2003 14:29:46 +0000, Darrell Grainger wrote:

    > Bottom line, I use C with I don't need everything C++ offers. It is sort
    > of the same reason they still teach Newtonian physics. Why doesn't
    > everyone use Einsteinian physics? Because Newtonian is easier and is good
    > enough for today to today physics.


    Allow me, as a former relativist (in the physical sciences sense) to take
    exception on that analogy. While illustrative, it seems to imply that C++
    has some kind of trascendence over C - which, in my view, it has not.

    Both Newtonian physics and Einsteinian physics are superb theories, the
    latter superseding the former, but not obsoleting it for the reasons you
    accurately mentioned.

    However, C++ does not stand vis-a-vis C the same way. C++ is a horribly
    complicated language, based on a philosophy totally different than that
    underlying C, and artificially made it look as close as possible to C. In
    my view, C++ is the most abhorrent contraption ever produced by the CS
    establishment, turning a potentially interesting field (albeit not the
    silver bullet many would have us believe) like object oriented design into
    something unpalatable and repugnant. In my view again, if there is a CS
    hell, I hope that Mr. Stroustrup, the guy whose brainchild C++ is, has an
    honorary place waiting for him in there.
     
    Santa Claus, Oct 6, 2003
    #14
  15. cody

    Eric Sosman Guest

    Santa Claus wrote:
    >
    > However, C++ does not stand vis-a-vis C the same way. C++ is a horribly
    > complicated language, based on a philosophy totally different than that
    > underlying C, and artificially made it look as close as possible to C. In
    > my view, C++ is the most abhorrent contraption ever produced by the CS
    > establishment, turning a potentially interesting field (albeit not the
    > silver bullet many would have us believe) like object oriented design into
    > something unpalatable and repugnant. In my view again, if there is a CS
    > hell, I hope that Mr. Stroustrup, the guy whose brainchild C++ is, has an
    > honorary place waiting for him in there.


    It'll be right next to the place reserved for people who
    sling mud anonymously.

    If your criticism has merit (I know too little of C++ to
    evaluate it), have the courage to put your name to it. If
    the courage is lacking, what are we to make of your confidence
    in your own opinion? And if you have so little confidence in
    it, why bother us with it?

    May the next chimney you slide down have a roaring fire
    at the bottom.

    --
     
    Eric Sosman, Oct 6, 2003
    #15
  16. cody

    Mike Wahler Guest

    "Tim Prince" <> wrote in message
    news:a9egb.224$_%...
    > Mike Wahler wrote:
    >
    > >
    > > <> wrote in message
    > > news:...
    > >>
    > >> On 6-Oct-2003, "cody" <> wrote:
    > >>
    > >> > [snip]
    > >>
    > >> Because C is more portable?

    > >
    > > No more portable than C++.
    > >
    > > -Mike

    > Are you excluding "C++" programs written for Microsoft compilers,


    I'm excluding anything outside the domain of the ISO
    standard C++ language, just as I would exclude anything
    outside standard C when referring to portablility.

    >or g++
    > prior to 3.x?



    I'm not talking about compilers, but (standardized) languages.

    >That would nearly make the point,


    I need refer to no specific imlementations to make the point
    that C and C++ are standardized and portable.

    > that C++ portability has
    > been possible


    The ISO standard C++ language is portable. And yes,
    it's possible that it is what it is.

    >(but not commonly adhered to)


    ISO C and ISO C++ are standardized, portable languages.
    What folks do or not with them does not change this fact.

    > for about a year,


    You don't get out much do you? :) C++ has been standardized
    since 1998.

    >compared to
    > over 20 for C.


    C has not been standardized for 20 years. It was first
    standardized in 1990 (or 1989, depending upon whom you ask).

    -Mike
     
    Mike Wahler, Oct 6, 2003
    #16
  17. cody

    osmium Guest

    cody writes:

    > in C there arent the simplest things present like constants, each struct

    and
    > enum have to be prefixed with "struct" and "enum". iam sure there is much
    > more.


    The only real difference from C++ is in the syntax. I think (perhaps
    wrongly) of the thing you are describing as a mini namespace thing.
    --
    comp.lang.c.moderated - moderation address:
     
    osmium, Oct 6, 2003
    #17
  18. cody

    Jack Klein Guest

    On 05 Oct 2003 21:37:06 GMT, "cody" <> wrote
    in comp.std.c:

    > no this is no trollposting and please don't get it wrong but iam very
    > curious why people still use C instead of other languages especially C++.


    This post is completely off-topic in all three of the newsgroups to
    which you posted it, although the moderator of comp.lang.c.moderated
    apparently disagrees with me.

    It is particularly off-topic in comp.std.c, which discusses the past,
    present, and future of the ISO/IEC International Standard for the C
    programming language. As far as the standard is concerned, there is
    literally no language other than C, although C++ is mentioned a few
    times in non-normative footnotes.

    > i heard people say C++ is slower than C but i can't believe that. in pieces


    What people? What are their qualifications to make such a statement?
    What evidence have they provided to prove the statement?

    And what are your qualifications to refute such a statement? What
    evidence do you have to disprove it?

    > of the application where speed really matters you can still use "normal"
    > functions or even static methods which is basically the same.
    >
    > in C there arent the simplest things present like constants, each struct and
    > enum have to be prefixed with "struct" and "enum". iam sure there is much
    > more.


    Obviously your knowledge of C is minimal. Do you think ignorance of a
    subject qualifies you to expound on it? Or is your wisdom to be
    inferred by your lack of proper capitalization, punctuation, and
    grammar?

    > i don't get it why people program in C and faking OOP features(function
    > pointers in structs..) instead of using C++. are they simply masochists or
    > is there a logical reason?
    >
    > i feel C has to benefit against C++.


    Why should we care about your obviously illogical feelings? C existed
    long before C++ did, and is and was extremely successful. It is the
    most portable programming language in the world. It does not need to
    justify its existence to you or to anyone else, nor does it have to
    compare itself to any other language.

    Discussions of the relative merits of various programming languages
    belong in news:comp.programming if they are cogent. They belong in
    advocacy groups if not. No one is asking you to use C is you don't
    think it is useful to you.

    But comparisons between C and any other language, C++ included, are
    not C language issues and do not belong in any of groups you posted
    to.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c /faq
    --
    comp.lang.c.moderated - moderation address:
     
    Jack Klein, Oct 6, 2003
    #18
  19. cody

    Sandeep Guest

    One word inertia.

    C++ has been around for so long and is a very mature language with
    fantastic tools. The problem is that companies do not invest in
    training developers about object oriented design and programming.

    Sandeep
    --
    http://www.EventHelix.com/EventStudio
    EventStudio 2.0 - Generate Sequence Diagrams and Use Cases in PDF
    --
    comp.lang.c.moderated - moderation address:
     
    Sandeep, Oct 6, 2003
    #19
  20. cody

    Rob Guest

    "cody" <> wrote in message
    news:...
    > no this is no trollposting and please don't get it wrong but iam very
    > curious why people still use C instead of other languages especially C++.
    >
    > i heard people say C++ is slower than C but i can't believe that. in

    pieces
    > of the application where speed really matters you can still use "normal"
    > functions or even static methods which is basically the same.


    I would dispute claims that C++ is slower than C. It is a fair call that
    some early implementations of C++ (particularly while the standard was
    in draft and evolving) were not particularly efficient. But that has
    changed, now that there is a standard and compiler writers have had
    a chance to address shortcomings of earlier implementations.

    There are some aspects of C++ that carry a performance overhead.
    No question. But, doing the same things in C would also carry a
    performance overhead and that needs to be coupled with the fact
    that the programmer must manually craft solutions to address the
    same problem. One obvious example is virtual function dispatch,
    which essentially means that the choice of a function to call is based
    on the type of an object. It carries an overhead in either run time
    or space: each data structure must carry a pointer to the function
    that must be called, or there must be a run-time mechanism that
    examines the type of object and then determins what object to
    run. If such a facility is needed, then it is available in C++ but
    must be explicitly coded in C. The hand coded solutions would
    carry overheads as well.

    >
    > in C there arent the simplest things present like constants, each struct

    and
    > enum have to be prefixed with "struct" and "enum". iam sure there is much
    > more.


    I thought C supported constants, but never mind (willing to stand
    corrected).

    The other points (eg struct and enumerted types needing to carry the
    keywords) are stylistic issues. There are arguments in favour of having to
    use the keywords (eg making it explicit what is actually going on) versus
    not
    (eg not having to know what is going on).

    >
    > i don't get it why people program in C and faking OOP features(function
    > pointers in structs..) instead of using C++. are they simply masochists or
    > is there a logical reason?
    >


    In my experience, this observation is incorrect. There are some older
    codes
    in C that essentially replicated OO features (eg calling a function based on
    type of object) but these are not extremely common, and most of them
    preceded languages like C++ that support OO features.

    The basic fact is that use of OO is a design trade-off. Object oriented
    approaches
    come with a series of trade-offs, in design, coding, and run time
    performance.
    There are other ways of designing systems, that also have trade-offs. Some
    of
    those design approaches are quite amenable to implementation in C. The
    basic
    result is that people who work on problems that aren't well suited to an OO
    solution will often use other design approaches. Those people are often
    quite
    justified in using C, as they don't need to exploit additional features of
    C++.
    --
    comp.lang.c.moderated - moderation address:
     
    Rob, Oct 6, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?SmF6eg==?=
    Replies:
    1
    Views:
    491
    Trevor Benedict R
    Jun 13, 2004
  2. Mr. SweatyFinger

    why why why why why

    Mr. SweatyFinger, Nov 28, 2006, in forum: ASP .Net
    Replies:
    4
    Views:
    907
    Mark Rae
    Dec 21, 2006
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,984
    Smokey Grindel
    Dec 2, 2006
  4. Kza
    Replies:
    4
    Views:
    422
    Andrew Koenig
    Mar 3, 2006
  5. Lawand
    Replies:
    42
    Views:
    7,754
    sorin12345
    May 21, 2011
Loading...

Share This Page