The worst thing about C++

Discussion in 'C++' started by Steven T. Hatton, May 10, 2005.

  1. #
    --
    "If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true." - Bertrand
    Russell
     
    Steven T. Hatton, May 10, 2005
    #1
    1. Advertising

  2. Steven T. Hatton wrote:

    > #

    <rant>
    And a close second and closely related flaw is .h, .H .hh, .HH .h++, .H++,
    <osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and who knows
    what else. It makes managing a code base extremely difficult(manually, or
    with automated tools), and adds nothing useful to the language.
    </rant>
    --
    "If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true." - Bertrand
    Russell
     
    Steven T. Hatton, May 12, 2005
    #2
    1. Advertising

  3. Steven T. Hatton

    Alvin Guest

    Steven T. Hatton wrote:

    > Steven T. Hatton wrote:
    >
    >> #

    > <rant>
    > And a close second and closely related flaw is .h, .H .hh, .HH .h++, .H++,
    > <osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and who knows
    > what else. It makes managing a code base extremely difficult(manually, or
    > with automated tools), and adds nothing useful to the language.
    > </rant>


    That's the beauty of the 'rename' command. :)

    --
    Alvin
     
    Alvin, May 12, 2005
    #3
  4. Steven T. Hatton

    Phlip Guest

    Steven T. Hatton wrote:

    > #


    ?

    Is this an effort to recite the "don't lean on the preprocessor" admonitions
    from all the C++ tutorials that don't suck?

    Finding the real worst thing about C++ would require many lifetimes of
    careful, painstaking research. I'm certain the inventor of the language
    didn't realize the copy construction rules and the exception propagation
    rules would collude to make assignment operators depend on an
    exception-proof swap() method. But don't quote me on that.

    --
    Phlip
    http://www.c2.com/cgi/wiki?ZeekLand
     
    Phlip, May 12, 2005
    #4
  5. In message <>, Steven T. Hatton
    <> writes
    >Steven T. Hatton wrote:
    >
    >> #

    ><rant>
    >And a close second and closely related flaw is .h, .H .hh, .HH .h++, .H++,
    ><osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and who knows
    >what else. It makes managing a code base extremely difficult(manually, or
    >with automated tools), and adds nothing useful to the language.
    ></rant>


    None of which is a flaw of, or indeed anything to do with, the standard
    C++ language we're supposed to discuss here.

    --
    Richard Herring
     
    Richard Herring, May 13, 2005
    #5
  6. Alvin wrote:

    > Steven T. Hatton wrote:
    >
    >> Steven T. Hatton wrote:
    >>
    >>> #

    >> <rant>
    >> And a close second and closely related flaw is .h, .H .hh, .HH .h++,
    >> .H++, <osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and who
    >> knows
    >> what else. It makes managing a code base extremely difficult(manually,
    >> or with automated tools), and adds nothing useful to the language.
    >> </rant>

    >
    > That's the beauty of the 'rename' command. :)
    >


    IIRC RENAME is a DOS command. Suppose I have hundreds of files that
    #include files using various extension for the file names.

    #!/bin/bash

    function backupCPlusPlus()
    {
    local BACKUP=$STH/"backup-c++"/$PWD-$(date +%F-%H-%M-%S)/
    test -d $BACKUP || mkdir -p $BACKUP;
    cp -r * $BACKUP;
    }

    function kdev2emacs()
    {
    for f in *.h; do
    test -f $f && cat $f | sed -e /"#include "/s/"\.h\([\"\>]\)"/.hh\\1/
    > ${f%%.h}.hh;

    mv $f old;
    done

    for f in *.cpp; do
    test -f $f && cat $f | sed -e /"#include "/s/"\.h\([\"\>]\)"/.hh\\1/
    > ${f%%.cpp}.cc;

    mv $f old;
    done
    }


    Works great if everything in the emacs code base uses .hh. But that won't
    happen if I build against boost and OSG. Boost uses .hpp and OSG uses no
    extension. Further more, I don't want boost and OSG #includs modified. I
    guess I could go through my code base and find all the filenames I use, and
    check each #include against that list, before I make a modification.

    But that's only one problem. There is also a problem of telling the tool
    (e.g., Emacs speedbar) which files contain C++ source code. OSG include
    files contain an Emacs mode specification line which works for determining
    the type of the file being loaded, but is not used by tools such as
    speedbar to determine the type of files in the current directory. Sure,
    someone can write code to check each file in the current directory for a
    mode specification line, but that means that every tool that is going to
    use extensionless headers with mode specification lines has to do that.

    It's much easier just to specify that .el means Emacs Lisp, .java means Java
    source, .c means 'C' source, etc.
    --
    "If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true." - Bertrand
    Russell
     
    Steven T. Hatton, May 13, 2005
    #6
  7. Richard Herring wrote:

    > In message <>, Steven T. Hatton
    > <> writes
    >>Steven T. Hatton wrote:
    >>
    >>> #

    >><rant>
    >>And a close second and closely related flaw is .h, .H .hh, .HH .h++, .H++,
    >><osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and who knows
    >>what else. It makes managing a code base extremely difficult(manually, or
    >>with automated tools), and adds nothing useful to the language.
    >></rant>

    >
    > None of which is a flaw of, or indeed anything to do with, the standard
    > C++ language we're supposed to discuss here.
    >


    It has to do with the usability of the C++ programming language.

    --
    "If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true." - Bertrand
    Russell
     
    Steven T. Hatton, May 13, 2005
    #7
  8. Steven T. Hatton wrote:

    > It has to do with the usability of the C++ programming language.



    Meaning? (I think I am going to see how "C# handles this" yet another time. C++ handles
    the .NET dlls the same under .NET. Dlls are not the same as source code files).



    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, May 13, 2005
    #8
  9. In message <>, Steven T. Hatton
    <> writes
    >Richard Herring wrote:
    >
    >> In message <>, Steven T. Hatton
    >> <> writes
    >>>Steven T. Hatton wrote:
    >>>
    >>>> #
    >>><rant>
    >>>And a close second and closely related flaw is .h, .H .hh, .HH .h++, .H++,
    >>><osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and who knows
    >>>what else. It makes managing a code base extremely difficult(manually, or
    >>>with automated tools), and adds nothing useful to the language.
    >>></rant>

    >>
    >> None of which is a flaw of, or indeed anything to do with, the standard
    >> C++ language we're supposed to discuss here.
    >>

    >
    >It has to do with the usability of the C++ programming language.


    No, it has to do with how C++ IDEs and other development tools integrate
    into the environment provided by your chosen OS. That has nothing to do
    with the language itself.

    --
    Richard Herring
     
    Richard Herring, May 16, 2005
    #9
  10. Richard Herring wrote:

    > In message <>, Steven T. Hatton
    > <> writes
    >>Richard Herring wrote:
    >>
    >>> In message <>, Steven T. Hatton
    >>> <> writes
    >>>>Steven T. Hatton wrote:
    >>>>
    >>>>> #
    >>>><rant>
    >>>>And a close second and closely related flaw is .h, .H .hh, .HH .h++,
    >>>>.H++, <osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and
    >>>>who knows
    >>>>what else. It makes managing a code base extremely difficult(manually,
    >>>>or with automated tools), and adds nothing useful to the language.
    >>>></rant>
    >>>
    >>> None of which is a flaw of, or indeed anything to do with, the standard
    >>> C++ language we're supposed to discuss here.
    >>>

    >>
    >>It has to do with the usability of the C++ programming language.

    >
    > No, it has to do with how C++ IDEs and other development tools integrate
    > into the environment provided by your chosen OS. That has nothing to do
    > with the language itself.
    >


    This is not the case. The problems I am describing are not platform
    specific. I can emulate a DOS shell under Linux, and I can run a posix
    compliant shell under NT(AKA XP). Almost all tools I use are platform
    independent. A person who does not have a reason to deal with the issues
    related to using different tools at different times to work on the same
    code base will probably not appreciate the nature of my concerns. If a
    person has never studied the problem of parsing C++ source code to extract
    useful information to provide to the programmer at edit time, he will
    probably not appreciate the difficulties introduced by the use of the
    preprocessor. If I were to restrict myself to using only one set of tools
    in a clearly defined environment such as NT user space where I could, more
    or less, predict all the variables, much of the problems I am describing
    would be non-issues. That is not the spirit in which C++ was created, and
    it is not good for the longterm health of the computing field.

    Nonetheless, some of this goes beyond using multiple tools. It is utterly
    absurd to have a langue support features that cause a compiler to detect
    errors in code located in "header files" the programmer did not write, and
    which contain no errors, because there is a minor syntax error in code the
    programmer did write. But this happens with C++.

    I understand the advantage the preprocessor provides to C++ programmers. It
    allows for the crossing of the boundary between the language and the
    observer of the language. This is a form of selfreferential recursion that
    we might call selfawareness, or introspection. Stringification demonstrates
    this very well. If I want my program to contain both the product of
    compiling a function definition, and the human readable information
    contained in the function definition, I have to have a way to access that
    human readable information at runtime. Stringizing such information with a
    Macro is a way to generate both the source and a characters representation
    of the source to be included in the program at runtime.

    With some languages such as Mathematica, Lisp, Java, ECMAScript, C#(?), that
    is simply part of the way the language works. With the interpreted
    languages, it is rather straight forward. The source code *is* the
    executable. With compiled languages, it takes more intentional thought to
    support such a feature.

    I understand that C++ would incur costs in both space and time if such
    introspection were required of all executable code. Introducing support
    for it into the core language might add excessive complexity to an already
    dauntingly complex specification.

    All that being said, I believe much use of the preprocessor to generate
    cookiecutter code is a way for the programmer to avoid correctly solving
    the underlying programming problem. Virtually every use of the
    preprocessor that I have seen that could not be replaced with a native C++
    construct has to do with storing information about the source code to be
    available at runtime.
    --
    "If our hypothesis is about anything and not about some one or more
    particular things, then our deductions constitute mathematics. Thus
    mathematics may be defined as the subject in which we never know what we
    are talking about, nor whether what we are saying is true." - Bertrand
    Russell
     
    Steven T. Hatton, May 17, 2005
    #10
  11. In message <>, Steven T. Hatton
    <> writes
    >Richard Herring wrote:
    >
    >> In message <>, Steven T. Hatton
    >> <> writes
    >>>Richard Herring wrote:
    >>>
    >>>> In message <>, Steven T. Hatton
    >>>> <> writes
    >>>>>Steven T. Hatton wrote:
    >>>>>
    >>>>>> #
    >>>>><rant>
    >>>>>And a close second and closely related flaw is .h, .H .hh, .HH .h++,
    >>>>>.H++, <osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and
    >>>>>who knows
    >>>>>what else. It makes managing a code base extremely difficult(manually,
    >>>>>or with automated tools), and adds nothing useful to the language.
    >>>>></rant>
    >>>>
    >>>> None of which is a flaw of, or indeed anything to do with, the standard
    >>>> C++ language we're supposed to discuss here.
    >>>
    >>>It has to do with the usability of the C++ programming language.

    >>
    >> No, it has to do with how C++ IDEs and other development tools integrate
    >> into the environment provided by your chosen OS. That has nothing to do
    >> with the language itself.
    >>

    >
    >This is not the case. The problems I am describing are not platform
    >specific.


    Then your <rant> </rant> was obscurely worded. I interpreted it as a
    complaint about (the lack of) file naming conventions, or possibly the
    separation of interface and implementation into separate files, but you
    seem to be talking about something entirely different.

    --
    Richard Herring
     
    Richard Herring, May 17, 2005
    #11
    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. Zeng
    Replies:
    5
    Views:
    411
    John Saunders
    Aug 20, 2003
  2. aron t

    best and the worst features

    aron t, Aug 2, 2005, in forum: ASP .Net
    Replies:
    6
    Views:
    476
    Diane Wilson
    Aug 3, 2005
  3. Steven T. Hatton
    Replies:
    23
    Views:
    7,792
    Phlip
    Mar 12, 2006
  4. JohnQ
    Replies:
    2
    Views:
    325
    Ian Collins
    Aug 26, 2007
  5. Zam
    Replies:
    1
    Views:
    259
    Mark Schupp
    Mar 14, 2005
Loading...

Share This Page