Re: New release of the Dynace OO extension to C

Discussion in 'C++' started by fft1976, Jul 15, 2009.

  1. fft1976

    fft1976 Guest

    On Jul 13, 1:10 pm, Blake McBride <> wrote:

    (...)

    But OOP can be done in C. Generic programming on the other hand ...

    Good luck using macros for that! It's "possible", but my many
    inquiries into whether there is a macros-based STL analog in the C
    world turned up nothing.
     
    fft1976, Jul 15, 2009
    #1
    1. Advertising

  2. fft1976 wrote:
    > But OOP can be done in C.


    I think that's debatable.

    You can simulate object-oriented programming in C to an extent, but
    since the language has basically no support, it will inevitably be
    rather "hacky" and complicated.

    The gtk+ library for C is a good example of a C library which
    extensively uses OO techniques. However, the resulting code is
    necessarily uglier and less efficient than the equivalent C++ code would
    be. (For example, when using gtk+, every single pointer cast from one
    type to another, even when it's from a derived object type to a base
    object type, is done dynamically at runtime, with runtime checks.)

    > Generic programming on the other hand ...
    >
    > Good luck using macros for that! It's "possible", but my many
    > inquiries into whether there is a macros-based STL analog in the C
    > world turned up nothing.


    There are many things doable with templates which are impossible to do
    in C with precompiler macros. A very trivial example:

    //--------------------------------------------------------------
    template<typename T>
    void foo(T value)
    {
    std::cout << "The value is: " << T << std::endl;
    }
    //--------------------------------------------------------------

    A slightly more complicated example:

    //--------------------------------------------------------------
    template<typename T>
    void foo()
    {
    std::cout << "The specified type is"
    << (std::numeric_limits<T>::is_integer ? "" : " not")
    << " an integral type.\nThe maximum value which can "
    << "be represented by it is: "
    << std::numeric_limit<T>::max() << std::endl;
    }
    //--------------------------------------------------------------
     
    Juha Nieminen, Jul 15, 2009
    #2
    1. Advertising

  3. "fft1976" <> wrote in message
    news:...
    On Jul 13, 1:10 pm, Blake McBride <> wrote:

    > (...)


    > But OOP can be done in C. Generic programming on the other hand ...


    Well, you can definitely create highly minimalist generic interfaces fairly
    easily in C:

    http://clc.pastebin.com/f52a443b1




    > Good luck using macros for that! It's "possible", but my many
    > inquiries into whether there is a macros-based STL analog in the C
    > world turned up nothing.


    Well, you can also do something crazy like:

    http://h30097.www3.hp.com/cplus/6026pro_genr.html

    http://www.softwarepreservation.org...urce/incl-master/const-headers/generic.h/view


    funny:
    ______________________________________________________________________
    #define CONCAT_RAW(mp_token1, mp_token2) \
    mp_token1 ## mp_token2

    #define CONCAT(mp_token1, mp_token2) \
    CONCAT_RAW(mp_token1, mp_token2)


    #define DECLARE_STACK(mp_name, mp_type) \
    void CONCAT(mp_name, _stack_push) ( \
    mp_type* const self, \
    mp_type const node \
    );\
    mp_type \
    CONCAT(mp_name, _stack_pop) ( \
    mp_type* const self \
    );


    #define DEFINE_STACK(mp_name, mp_type, mp_pname) \
    void CONCAT(mp_name, _stack_push) ( \
    mp_type* const self, \
    mp_type const node \
    ) { \
    node->mp_pname = *self; \
    *self = node; \
    } \
    mp_type \
    CONCAT(mp_name, _stack_pop) ( \
    mp_type* const self \
    ) { \
    mp_type node = *self; \
    if (node) *self = node->mp_pname; \
    return NULL; \
    }




    #include <stdlib.h>


    DECLARE_STACK(foo, struct foo*)


    struct foo {
    struct foo* next;
    };


    DEFINE_STACK(foo, struct foo*, next)


    static struct foo* g_stack = NULL;


    int main(void) {
    foo_stack_push(&g_stack, malloc(sizeof(*g_stack)));
    foo_stack_push(&g_stack, malloc(sizeof(*g_stack)));
    foo_stack_push(&g_stack, malloc(sizeof(*g_stack)));
    foo_stack_push(&g_stack, malloc(sizeof(*g_stack)));
    free(foo_stack_pop(&g_stack));
    free(foo_stack_pop(&g_stack));
    free(foo_stack_pop(&g_stack));
    free(foo_stack_pop(&g_stack));
    return 0;
    }
    ______________________________________________________________________



    Generic type-safe intrusive stack? lol.
     
    Chris M. Thomasson, Jul 15, 2009
    #3
  4. fft1976

    BartC Guest

    "Juha Nieminen" <> wrote in message
    news:0gm7m.90$w%...
    > fft1976 wrote:
    >> But OOP can be done in C.

    >
    > I think that's debatable.
    >
    > You can simulate object-oriented programming in C to an extent, but
    > since the language has basically no support, it will inevitably be
    > rather "hacky" and complicated.
    >
    > The gtk+ library for C is a good example of a C library which
    > extensively uses OO techniques. However, the resulting code is
    > necessarily uglier and less efficient than the equivalent C++ code would
    > be. (For example, when using gtk+, every single pointer cast from one
    > type to another, even when it's from a derived object type to a base
    > object type, is done dynamically at runtime, with runtime checks.)
    >
    >> Generic programming on the other hand ...
    >>
    >> Good luck using macros for that! It's "possible", but my many
    >> inquiries into whether there is a macros-based STL analog in the C
    >> world turned up nothing.

    >
    > There are many things doable with templates which are impossible to do
    > in C with precompiler macros. A very trivial example:
    >
    > //--------------------------------------------------------------
    > template<typename T>
    > void foo(T value)
    > {
    > std::cout << "The value is: " << T << std::endl;
    > }


    You mean << value << here?

    --
    bart
     
    BartC, Jul 15, 2009
    #4
  5. fft1976

    ld Guest

    On 15 juil, 17:06, Juha Nieminen <> wrote:
    > fft1976 wrote:
    > > But OOP can be done in C.

    >
    >   I think that's debatable.
    >
    >   You can simulate object-oriented programming in C to an extent, but
    > since the language has basically no support, it will inevitably be
    > rather "hacky" and complicated.


    Wrong.

    >   The gtk+ library for C is a good example of a C library which
    > extensively uses OO techniques.


    This is the worst example I know. Heavy, slow, odd.

    > However, the resulting code is
    > necessarily uglier and less efficient than the equivalent C++ code would
    > be. (For example, when using gtk+, every single pointer cast from one
    > type to another, even when it's from a derived object type to a base
    > object type, is done dynamically at runtime, with runtime checks.)


    This is related to gtk+, not OOP in C.

    > > Generic programming on the other hand ...

    >
    > > Good luck using macros for that! It's "possible", but my many
    > > inquiries into whether there is a macros-based STL analog in the C
    > > world turned up nothing.

    >
    >   There are many things doable with templates which are impossible to do
    > in C with precompiler macros.


    Do you _really_ know what is doable with C macros?

    > A very trivial example:
    >
    > //--------------------------------------------------------------
    > template<typename T>
    > void foo(T value)
    > {
    >     std::cout << "The value is: " << T << std::endl;}
    >
    > //--------------------------------------------------------------
    >
    >   A slightly more complicated example:
    >
    > //--------------------------------------------------------------
    > template<typename T>
    > void foo()
    > {
    >     std::cout << "The specified type is"
    >               << (std::numeric_limits<T>::is_integer ? "" : " not")
    >               << " an integral type.\nThe maximum value which can "
    >               << "be represented by it is: "
    >               << std::numeric_limit<T>::max() << std::endl;}
    >
    > //--------------------------------------------------------------


    Polymorphism can replace template here and hence be done in C. A C++
    MTP example would be better to show something not possible in C at
    compile time. But this not OOP.

    a+, ld.
     
    ld, Jul 15, 2009
    #5
  6. "Juha Nieminen" <> wrote in message
    news:0gm7m.90$w%...
    > fft1976 wrote:
    >> But OOP can be done in C.

    >
    > I think that's debatable.
    >
    > You can simulate object-oriented programming in C to an extent, but
    > since the language has basically no support, it will inevitably be
    > rather "hacky" and complicated.
    >


    it depends on how one does it...

    "some" options get hacky and complicated...
    very often though, things just get terribly verbose...

    usually the "hacky and complicated" results from people trying in a
    misguided attempt for "maximum performance" and thus implementing their
    whole damn object system in terms of nested structs and casting, ...

    the other alternative is to force an opaque API, which can largely avoid
    much of the horror, but does not have the same air of "maximum performance"
    about it (typically because accessing a field typically involves a function
    call, a switch, and maybe a few pointer-ops...).

    the switch can be eliminated if one is willing to sacrifice features, or
    require a separate API function for each type of field.


    > The gtk+ library for C is a good example of a C library which
    > extensively uses OO techniques. However, the resulting code is
    > necessarily uglier and less efficient than the equivalent C++ code would
    > be. (For example, when using gtk+, every single pointer cast from one
    > type to another, even when it's from a derived object type to a base
    > object type, is done dynamically at runtime, with runtime checks.)
    >


    the GTK+ library is a good example of almost pure horror...

    then again, in GPL land there are much worse offenders in the land of "pure
    horror"...


    as for the common horror and hackiness seen when people attempt things like
    this:
    often, this is the result of people trying to move directly from an OOPL to
    C, and just trying to (directly) force their existing practices onto C,
    rather than adapting to a more "C-appropriate" approach to problems...

    for example, if we take OO in the more abstract sense (AKA, in the more
    'philosophical' sense promoted by 'H.S. Lahman' and friends over in
    comp.object), then the problem need not turn into an ugly mess (since, hell,
    there is no real reason that OOP should look anything like the approaches we
    usually see in OOPL's...).


    for example, see the Linux kernel, which would seem to be applying some
    amount of 'OOP' as well, but has generally refrained from the obtuse
    hackiness of GTK and friends, mostly because problems are abstracted and
    modularized, and not because of large amounts of hacky "struct-ninjitsu"...


    granted, in general the code-quality in most of open-source land is not
    exactly to the highest standards...


    >> Generic programming on the other hand ...
    >>
    >> Good luck using macros for that! It's "possible", but my many
    >> inquiries into whether there is a macros-based STL analog in the C
    >> world turned up nothing.

    >
    > There are many things doable with templates which are impossible to do
    > in C with precompiler macros.


    the bigger issue (in your examples) is not the lack of templates, but the
    lack of iostream...

    but, on the same token, I can note that there are many things one can do is
    LISP macros which are impossible to do with C++ templates... (due to, for
    example, LISP macros being turing complete and having full access to the
    language...).

    as well, although the C-preprocessor is limited, it does not rule out the
    possibility of custom preprocessors (but, then one can debate that by the
    time such a tool includes certain features, such as a full parser, it is no
    longer a preprocessor, rather it is a compiler...).
     
    BGB / cr88192, Jul 15, 2009
    #6
  7. BartC wrote:
    >> template<typename T>
    >> void foo(T value)
    >> {
    >> std::cout << "The value is: " << T << std::endl;
    >> }

    >
    > You mean << value << here?


    Yes. Braino.
     
    Juha Nieminen, Jul 15, 2009
    #7
  8. ld wrote:
    >> You can simulate object-oriented programming in C to an extent, but
    >> since the language has basically no support, it will inevitably be
    >> rather "hacky" and complicated.

    >
    > Wrong.


    I have yet to see a clean solution.

    > Do you _really_ know what is doable with C macros?


    I'm pretty sure you cannot resolve the proper format string to use
    with printf() to print something you got as a macro parameter
    (especially if that something is eg. a struct instantiation). I'm also
    pretty sure you cannot eg. resolve whether a parameter is of an integral
    or a non-integral type.

    > But this not OOP.


    So?
     
    Juha Nieminen, Jul 15, 2009
    #8
  9. BGB / cr88192 wrote:
    > but, on the same token, I can note that there are many things one can do is
    > LISP macros which are impossible to do with C++ templates... (due to, for
    > example, LISP macros being turing complete and having full access to the
    > language...).


    Btw, AFAIK it has been proven that the C++ template metalanguage is
    turing-complete as well... :)

    You can do surprising things with template metaprogramming (all at
    compile time), such as linked lists (with many operations familiar from
    lisp, such as getting the first element and the list tail, etc), binary
    trees, resolving whether a given integer is prime or not... I once even
    wrote an ascii mandelbrot set generator using template metaprogramming,
    which the compiler calculated at compile-time (the resulting program
    just printed the resulting string and nothing more).
     
    Juha Nieminen, Jul 15, 2009
    #9
  10. fft1976

    Ben Pfaff Guest

    Juha Nieminen <> writes:

    > You can do surprising things with template metaprogramming (all at
    > compile time), such as linked lists (with many operations familiar from
    > lisp, such as getting the first element and the list tail, etc), binary
    > trees, resolving whether a given integer is prime or not...


    I think you've put your finger on the problem with template
    metaprogramming: people tend to do surprising things with it.
    Programming should not be surprising.
    --
    Ben Pfaff
    http://benpfaff.org
     
    Ben Pfaff, Jul 15, 2009
    #10
  11. fft1976

    ld Guest

    On 15 juil, 21:04, Juha Nieminen <> wrote:
    > ld wrote:
    > >>   You can simulate object-oriented programming in C to an extent, but
    > >> since the language has basically no support, it will inevitably be
    > >> rather "hacky" and complicated.

    >
    > > Wrong.

    >
    >   I have yet to see a clean solution.


    Did you read the paper I mentioned?

    http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos_draft-dls09.pdf.gz

    > > Do you _really_ know what is doable with C macros?

    >
    >   I'm pretty sure you cannot resolve the proper format string to use
    > with printf() to print something you got as a macro parameter
    > (especially if that something is eg. a struct instantiation). I'm also
    > pretty sure you cannot eg. resolve whether a parameter is of an integral
    > or a non-integral type.
    >
    > > But this not OOP.

    >
    >   So?


    this thread is about OOP in/for C in the way of Dynace, not about C++
    non-OOP features like generic (generative) programming. I have never
    said that C macros can do the same as C++ template. My statement is
    that they can do enough to implement clean _OOP_ in C.

    a+, ld.
     
    ld, Jul 15, 2009
    #11
  12. Ben Pfaff wrote:
    > Juha Nieminen <> writes:
    >
    >> You can do surprising things with template metaprogramming (all at
    >> compile time), such as linked lists (with many operations familiar from
    >> lisp, such as getting the first element and the list tail, etc), binary
    >> trees, resolving whether a given integer is prime or not...

    >
    > I think you've put your finger on the problem with template
    > metaprogramming: people tend to do surprising things with it.
    > Programming should not be surprising.


    I think you are playing with words.
     
    Juha Nieminen, Jul 15, 2009
    #12
  13. fft1976

    Squeamizh Guest

    On Jul 15, 12:25 pm, ld <> wrote:
    > On 15 juil, 21:04, Juha Nieminen <> wrote:
    >
    > > ld wrote:
    > > >>   You can simulate object-oriented programming in C to an extent, but
    > > >> since the language has basically no support, it will inevitably be
    > > >> rather "hacky" and complicated.

    >
    > > > Wrong.

    >
    > >   I have yet to see a clean solution.

    >
    > Did you read the paper I mentioned?
    >
    > http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos_draft-dls09.pdf.gz
    >
    > > > Do you _really_ know what is doable with C macros?

    >
    > >   I'm pretty sure you cannot resolve the proper format string to use
    > > with printf() to print something you got as a macro parameter
    > > (especially if that something is eg. a struct instantiation). I'm also
    > > pretty sure you cannot eg. resolve whether a parameter is of an integral
    > > or a non-integral type.

    >
    > > > But this not OOP.

    >
    > >   So?

    >
    > this thread is about OOP in/for C in the way of Dynace, not about C++
    > non-OOP features like generic (generative) programming. I have never
    > said that C macros can do the same as C++ template. My statement is
    > that they can do enough to implement clean _OOP_ in C.


    That was not your original statement, and you waste everyone's time by
    being dishonest.

    Here is the original context:
    JUHA: There are many things doable with templates which are impossible
    to do in C with precompiler macros.
    YOU: Do you _really_ know what is doable with C macros?
     
    Squeamizh, Jul 15, 2009
    #13
  14. fft1976

    ld Guest

    On 15 juil, 22:04, Squeamizh <> wrote:
    > On Jul 15, 12:25 pm, ld <> wrote:
    >
    >
    >
    >
    >
    > > On 15 juil, 21:04, Juha Nieminen <> wrote:

    >
    > > > ld wrote:
    > > > >>   You can simulate object-oriented programming in C to an extent, but
    > > > >> since the language has basically no support, it will inevitably be
    > > > >> rather "hacky" and complicated.

    >
    > > > > Wrong.

    >
    > > >   I have yet to see a clean solution.

    >
    > > Did you read the paper I mentioned?

    >
    > >http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos_draft-dls09.pdf.gz

    >
    > > > > Do you _really_ know what is doable with C macros?

    >
    > > >   I'm pretty sure you cannot resolve the proper format string to use
    > > > with printf() to print something you got as a macro parameter
    > > > (especially if that something is eg. a struct instantiation). I'm also
    > > > pretty sure you cannot eg. resolve whether a parameter is of an integral
    > > > or a non-integral type.

    >
    > > > > But this not OOP.

    >
    > > >   So?

    >
    > > this thread is about OOP in/for C in the way of Dynace, not about C++
    > > non-OOP features like generic (generative) programming. I have never
    > > said that C macros can do the same as C++ template. My statement is
    > > that they can do enough to implement clean _OOP_ in C.

    >
    > That was not your original statement, and you waste everyone's time by
    > being dishonest.
    > Here is the original context:


    Why do you remove 70% of the context? I have myself suggested in this
    thread to give more advanced MTP examples to show something not
    possible in C and doable with C++ template. Many examples exist like
    gcd, factorial or fft compile time computation or (advanced)
    dimensional analysis. So my statement is relative to what template
    brings to OOP comparing to C macros, not to the all possibilities of C+
    + template. Both have pros and cons and despite that C++ template is
    Turing complete, it cannot replace the preprocessor. And AFAIK, the
    printf example aforementioned relies on variadic templates which is
    not (yet) part of C++.

    > JUHA: There are many things doable with templates which are impossible
    > to do in C with precompiler macros.


    The opposite is also true. Does it bring something? I don't think so.
    So I took this statement as part of the discussion.

    > YOU: Do you _really_ know what is doable with C macros?


    Yes, so what? Most of C/C++ programmer sees the preprocessor as a
    primitive tool for string substitution. My remark was just there to
    ensure that JUHA does not and see if I need to reevaluate its
    position.

    If you want to contribute, be positive and less arrogant. No need for
    noise here.

    a+, ld.
     
    ld, Jul 15, 2009
    #14
  15. "Juha Nieminen" <> wrote in message
    news:CQp7m.155$w%...
    > BGB / cr88192 wrote:
    >> but, on the same token, I can note that there are many things one can do
    >> is
    >> LISP macros which are impossible to do with C++ templates... (due to, for
    >> example, LISP macros being turing complete and having full access to the
    >> language...).

    >
    > Btw, AFAIK it has been proven that the C++ template metalanguage is
    > turing-complete as well... :)
    >
    > You can do surprising things with template metaprogramming (all at
    > compile time), such as linked lists (with many operations familiar from
    > lisp, such as getting the first element and the list tail, etc), binary
    > trees, resolving whether a given integer is prime or not... I once even
    > wrote an ascii mandelbrot set generator using template metaprogramming,
    > which the compiler calculated at compile-time (the resulting program
    > just printed the resulting string and nothing more).


    odd...

    well, then again, I have not done a whole lot with templates...
     
    BGB / cr88192, Jul 15, 2009
    #15
  16. William Pursell wrote:
    > It has to do with simplicity.
    > C is simpler than C++. Often, that is the overriding
    > factor in selecting C over C++ for a project.


    May I express my opinion that C's "simplicity" is often a hindrance
    rather than an aid in programming and, rather ironically, C's
    "simplicity" actually makes the programs written with it more complex
    than a (well-written) equivalent C++ program would be (even though C++
    is a more complex language).

    While simpler languages are generally preferred over more complex
    languages, IMO C has the wrong type of "simplicity". Rather than making
    programming easier, it makes it harder. The "simplicity" of C doesn't
    help you express things in shorter and simpler ways, like is the case
    with other, truely simple languages.

    IMO the complexity of the language definition and its standard is
    *not* a valid measure of how well that language can be used for large
    projects (or, for that matters, projects of any size). In many cases the
    complexity of C++ actually makes it easier to write simple and
    straightforward programs.
     
    Juha Nieminen, Jul 16, 2009
    #16
  17. "Juha Nieminen" <> wrote in message
    news:NNK7m.111$...
    > William Pursell wrote:
    >> It has to do with simplicity.
    >> C is simpler than C++. Often, that is the overriding
    >> factor in selecting C over C++ for a project.

    >
    > May I express my opinion that C's "simplicity" is often a hindrance
    > rather than an aid in programming and, rather ironically, C's
    > "simplicity" actually makes the programs written with it more complex
    > than a (well-written) equivalent C++ program would be (even though C++
    > is a more complex language).
    >


    this is the wrong sense of "simplicity".

    for many tasks, it is more important what goes on in the compiler and
    linker, than what the user has to type...

    C is "simpler" primarily in that, since it has a whole lot less "magic"
    going on, compilers are easier to write, the compiler output is easier to
    work with, ...

    more so, C's simplicity allows projects to more easily write specialized
    source-processing tools, where although a C parser is a hassle, a C++ parser
    is far worse...



    > While simpler languages are generally preferred over more complex
    > languages, IMO C has the wrong type of "simplicity". Rather than making
    > programming easier, it makes it harder. The "simplicity" of C doesn't
    > help you express things in shorter and simpler ways, like is the case
    > with other, truely simple languages.
    >


    and, in many cases, why should we care?...

    the simplicity that C does offer, may well be an overriding factor in a
    project, especially if this project involves programmatic handling of source
    code, machine code, or both...


    > IMO the complexity of the language definition and its standard is
    > *not* a valid measure of how well that language can be used for large
    > projects (or, for that matters, projects of any size). In many cases the
    > complexity of C++ actually makes it easier to write simple and
    > straightforward programs.


    but, at what cost?...

    we can easily see above the sorts of costs C++ has for tooling and
    processing...

    this is while ignoring many other issues:
    integration with VMs and scripting languages;
    integration between code developed and compiled independently (such as
    system libraries);
    ....

    as noted, most VMs do not integrate well with C++, but they do much better
    with C...

    similarly, the use of many of C++'s features create horrible binary-level
    dependency issues, making C++ not really a good choice for, for example, the
    public interface for a DLL...

    "trivial" internal changes to a class or its implementation, ... could break
    binary compatibility with code compiled against a different version of the
    DLL, thus leading to far worse versioning issues than would otherwise be the
    case... however the types of API-design practices usually used in DLLs
    (which prohibit use of even many C features) can largely mitigate these
    issues (allowing multiple versions of a DLL exporting the same interface, or
    "equivalent" DLLs to be developed and maintained by different people).

    take, for example, 'opengl32.dll', which, as a dll, has a number of versions
    by a number of companies, yet GL is relatively free of DLL versioning
    issues...

    ....


    in many projects, these sorts of matters may well be far more important than
    how nice the code looks or how many nifty features the runtime may
    include...

    granted, C++ may well be a good choice for frontend apps, but may not be as
    ideal in many cases for systems-programming and library-backend tasks...

    ....


    so, these being the main factors, C++ is my 3rd ranked language, after C and
    ASM...

    I may use C++ when I can be sure doing so will not have adverse
    consequences...

    (I have written a few of my libraries in C++, but it is a decided minority,
    and in general I don't let it anywhere near the public API...).

    or such...
     
    BGB / cr88192, Jul 16, 2009
    #17
  18. BGB / cr88192 wrote:
    > C is "simpler" primarily in that, since it has a whole lot less "magic"
    > going on, compilers are easier to write, the compiler output is easier to
    > work with, ...


    You are talking about pretty low-level programming, like C was just a
    thin wrapper around assembly.

    Most people don't need nor want to write program at such low level,
    especially with bigger projects. This is both when programming for hobby
    and professionally. It may mostly be relevant only when programming
    things like device drives and OS kernels (and certain types of programs
    for embedded devices), but little else.

    C does have its uses, but it's a rather niche market, really.

    Efficiency in itself is not a good reason to choose C over C++, as
    it's perfectly possible to achieve the same level of efficiency in the
    latter, all while using a higher level of abstraction.

    >> While simpler languages are generally preferred over more complex
    >> languages, IMO C has the wrong type of "simplicity". Rather than making
    >> programming easier, it makes it harder. The "simplicity" of C doesn't
    >> help you express things in shorter and simpler ways, like is the case
    >> with other, truely simple languages.
    >>

    >
    > and, in many cases, why should we care?...


    Because in most cases you want simple, clear, easy-to-understand and
    efficient programs which have a minimal amount of coding conventions and
    metaparadigms which exist solely because of the limitations of the
    programming language. (Coding conventions in general are ok, of course,
    but if a convention exist solely to get around a limitation of the
    language and nothing else, then it's only a hindrance and makes it
    harder to learn how the program works and how it should be developed
    further.)

    Granted, C++ might not be the *best* language out there in order to
    achieve this goal, but IMO it at least offers much better tools to get
    closer to that goal than C does.

    > the simplicity that C does offer, may well be an overriding factor in a
    > project, especially if this project involves programmatic handling of source
    > code, machine code, or both...


    You'll have to admit that those types of projects are quite rare. If
    you personally are involved in lots of such projects, then of course you
    should choose the best tools for that purpose. However, you shouldn't
    assume that all projects are like that nor that C would be the best tool
    for those.

    > in many projects, these sorts of matters may well be far more important than
    > how nice the code looks or how many nifty features the runtime may
    > include...


    I have never been involved in such projects (even though I have been
    writing C++ professionally for a decade). C is just not the tool for me.
     
    Juha Nieminen, Jul 17, 2009
    #18
  19. "Juha Nieminen" <> wrote in message
    news:hKZ7m.52$...
    > BGB / cr88192 wrote:
    >> C is "simpler" primarily in that, since it has a whole lot less "magic"
    >> going on, compilers are easier to write, the compiler output is easier to
    >> work with, ...

    >
    > You are talking about pretty low-level programming, like C was just a
    > thin wrapper around assembly.
    >
    > Most people don't need nor want to write program at such low level,
    > especially with bigger projects. This is both when programming for hobby
    > and professionally. It may mostly be relevant only when programming
    > things like device drives and OS kernels (and certain types of programs
    > for embedded devices), but little else.
    >


    or when trying to work through deep-seated problems that exist within
    computing...

    one has to go down fairly far before they can effectively build up,
    otherwise, one ends up with the tall monolithic towers of crap many VMs and
    HLLs are known for...


    > C does have its uses, but it's a rather niche market, really.
    >
    > Efficiency in itself is not a good reason to choose C over C++, as
    > it's perfectly possible to achieve the same level of efficiency in the
    > latter, all while using a higher level of abstraction.
    >


    who ever says I am talking about performance?...


    going down to the level of C and ASM allows one to very effectively tap the
    well of "turingness" and "von-neumanness" which exists at the lower levels,
    but which has to a large degree faded by the time one gets to C and C++.

    many VMs (and apps) then attempt to build a new layer of "turingness" over
    the already faded backdrop, rather than going right to the source:
    the CPU...

    and then building on the same foundations as the rest of the technologies we
    have come to take for granted...


    >>> While simpler languages are generally preferred over more complex
    >>> languages, IMO C has the wrong type of "simplicity". Rather than making
    >>> programming easier, it makes it harder. The "simplicity" of C doesn't
    >>> help you express things in shorter and simpler ways, like is the case
    >>> with other, truely simple languages.
    >>>

    >>
    >> and, in many cases, why should we care?...

    >
    > Because in most cases you want simple, clear, easy-to-understand and
    > efficient programs which have a minimal amount of coding conventions and
    > metaparadigms which exist solely because of the limitations of the
    > programming language. (Coding conventions in general are ok, of course,
    > but if a convention exist solely to get around a limitation of the
    > language and nothing else, then it's only a hindrance and makes it
    > harder to learn how the program works and how it should be developed
    > further.)
    >


    why should we avoid having and following conventions?...

    anyways, I typically restrict my conventions far more than what is allowed
    by the language...

    good rules make good code...

    (much like, as they say, "good fences make good neighbors"...).


    > Granted, C++ might not be the *best* language out there in order to
    > achieve this goal, but IMO it at least offers much better tools to get
    > closer to that goal than C does.
    >


    why is there this goal?...


    AFAICT, the main advantage of programming languages is to reduce the amount
    of typing and to provide some semblance of error checking. however, these
    are not mandatory, and if a better way can be found, this may well be worth
    trying...


    >> the simplicity that C does offer, may well be an overriding factor in a
    >> project, especially if this project involves programmatic handling of
    >> source
    >> code, machine code, or both...

    >
    > You'll have to admit that those types of projects are quite rare. If
    > you personally are involved in lots of such projects, then of course you
    > should choose the best tools for that purpose. However, you shouldn't
    > assume that all projects are like that nor that C would be the best tool
    > for those.
    >


    yes, "those" people can just go and use Java...


    >> in many projects, these sorts of matters may well be far more important
    >> than
    >> how nice the code looks or how many nifty features the runtime may
    >> include...

    >
    > I have never been involved in such projects (even though I have been
    > writing C++ professionally for a decade). C is just not the tool for me.



    I do a whole lot of things like compilation and custom code generation at
    runtime...

    there are many things which can be done very well at low levels of
    abstraction, but which can only be crudely and inefficiently faked at higher
    levels.


    consider you were told you could no longer directly write in a language for
    native code, but could only target a poorly written interpreter, itself
    written in native code?...

    capabilities are poor, and performance is poor, whereas operating at a level
    at or below that of C, one can operate at the "full power" available to a
    language like C, and integrate on C "at equal terms", meanwhile still
    gaining new capabilities...


    for example, the JVM and .NET try to compete with C and C++ and native
    code...

    do they do this by using pure interpreters written in C or C++?...
    no, both frameworks derive much of their power from directly targetting the
    HW (AKA: Just-In-Time compilation, or JIT).

    however, IMO, neither has gone far enough, as neither has really "primed the
    well to the watertable of power...".

    or such...
     
    BGB / cr88192, Jul 18, 2009
    #19
  20. fft1976

    Miles Bader Guest

    William Pursell <> writes:

    > I disagree. He has absolutely identified one of the core issues.
    > Else-thread, you express wonderment that many C-programmers are
    > "prejudiced against C++", and here you ignore one of the fundamental
    > answers to the reason that many people prefer C to C++. It has
    > nothing to do with "prejudice". It has to do with simplicity. C is
    > simpler than C++.


    That's certainly true, but it may not be as relevant as you suggest.

    The _library implementors_ surely need to be well acquainted with C++,
    and writing good C++ template libraries can be complicated -- but for
    the _average programmer_ writing an app, C++ can be very simple indeed,
    maybe even _simpler_ to use than C because the library authors' hard
    work gives them more robust abstractions that allow better error
    checking and more concise code.

    Moreover, C++ has the nice property that you can use practically any
    subset you want, down to the point where it becomes simply C.

    -Miles

    --
    Youth, n. The Period of Possibility, when Archimedes finds a fulcrum,
    Cassandra has a following and seven cities compete for the honor of endowing a
    living Homer.
     
    Miles Bader, Jul 19, 2009
    #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. Blake McBride
    Replies:
    0
    Views:
    324
    Blake McBride
    Jan 9, 2008
  2. Blake McBride
    Replies:
    0
    Views:
    418
    Blake McBride
    Jan 9, 2008
  3. Juha Nieminen
    Replies:
    58
    Views:
    1,361
    Juha Nieminen
    Aug 9, 2009
  4. Juha Nieminen

    Re: New release of the Dynace OO extension to C

    Juha Nieminen, Jul 13, 2009, in forum: C Programming
    Replies:
    68
    Views:
    1,464
    Juha Nieminen
    Aug 9, 2009
  5. fft1976
    Replies:
    202
    Views:
    3,125
    David Thompson
    Aug 10, 2009
Loading...

Share This Page