Re: GCC

From: Dave Carrigan (dave_at_rudedog.org)
Date: 02/20/04

  • Next message: David T-G: "Re: CLI" 
    Date: Thu, 19 Feb 2004 20:18:38 -0800
To: debian-user@lists.debian.org

    On Thu, Feb 19, 2004 at 09:42:26PM -0500, Mike M wrote:
    > On Thu, Feb 19, 2004 at 05:16:53PM -0600, Alan Shutko wrote:
    > > Mike M <linux-support@earthlink.net> writes:
    > >
    > > > C++ seems to be steaming away in this direction. I've got my doubts
    > > > that the .h is going away in C however.
    > >
    > > As far as I know, nobody has proposed that the C header files change
    > > in this way.
    >
    > I was unaware too until someone in this thread posted that stdlib.h is out
    > and cstdlib is in.
    > >
    > > > It seems that this is going to cause more portability problems than
    > > > it solves. Code written for advanced compilers will be incompatible
    > > > with older compilers.
    > >
    > > This has been a problem of C++ for at least a decade. But at least
    > > it looks like it's finally getting better now that the standard is
    > > standardized and compilers catch up.
    >
    > A decade of C++ becomes deprecated? How can this be? I
    > argue that it cannot from a practical point of view. The body of
    > existing work is too large to allow drastic change.

    I think you missed the point. The header names changed explicitly to
    *support* backward compatibility. The Standard says that the standard
    library belongs in the std:: namespace. This decision was made for a lot
    of good reasons. However, most vendors were already shipping iostream.h,
    that did not put iostream into the std namespace.

    So, the standard writers had two choices: force vendors to change their
    iostream.h so that it puts everything into the std namespace -- and
    break millions of lines of legacy code, or ask vendors to provide a
    different header for std::iostream. The standards committee chose to use
    a different header, expressly to *preserve* backward compatibility with
    existing code.

    > On the one hand we have a standards committee and eager-to-please
    > compiler maintainers creating features and requiring us to change
    > existing code to adapt to the new features.

    Languages change, and compilers change along with them. How many ifdefs
    do you see today in C code in order to support K&R vs. ANSI? Not too
    many, because programmers and programs catch up to standards. All you
    need to do is trace the history of much of the GNU code to see how their
    function definitions evolved from pure K&R to a macro hack that did K&R
    or ANSI depending on the compiler to today, where most GNU code uses
    ANSI only.

    That doesn't mean that legacy K&R code won't compile with a modern C
    compiler. It means that programmers no longer feel that they need to
    refrain from using ANSI constructs because they're worried that some
    compilers won't support it.

    Or do you still live in fear of encountering a K&R compiler, so you continue
    to declare your functions like:

     int foo(a,b)
     int a;
     char b;
     {
     }

    > I am not opposed to new features in C++ as long as they are not mandatory.
    > If the new features are mandatory, then rename the language to C+++ so
    > there'll be no confusion.

    Languages change. C went from K&R to ANSI to C89 to C99. C++ is evolving
    in the same way.

    > Back to the case in point - header files. Why the change? To support
    > the namespace feature? A project as well-known as Mozilla says to not
    > use namespace because it's not portable.

    The mozilla project started 6 years ago, possibly even before the
    standard was even ratified and certainly at a time when many mainstream
    C++ compilers did not support namespaces well. Things have
    changed. Today, there's no way that the mozilla folks would be against
    namespaces; all mainstream C++ compilers support them very well. Today,
    they would be telling you to avoid things like partial template
    specialization, because it's not well-supported yet. And 5 years from
    now, they will probably be telling you to avoid the export keyword
    because it's not well supported (yet!).

    > I've worked in telecom for many years and from that I know that when a
    > system becomes very large, you can no longer change the standards on
    > which it is based. The costs are too great. The new must adapt to the
    > old.

    Nobody is saying you have to change. What they're saying is that if you
    #include <iostream.h>, you're NOT getting std::iostream, and you can't
    complain if whatever iostream you do happen to get doesn't conform to
    the C++ standard. If you want std::iostream, then you need to #include
    <iostream>.

    Under GCC, you're probably going to get behavior nearly identical to
    std::iostream even if you #include <iostream.h>. But you might be in
    for a nasty shock if you try to compile your code with Visual C++ or
    Comeau C++ or some other C++, because their iostream.h (if it even
    exists) may or may not behave like your iostream.h.

    Conversely, their <iostream> *will* behave like yours, or else one of
    the vendors has a bug with their implementation. Bugs like this are
    still a common and sad fact, but the situation would be much worse if
    none of your vendors followed a standard at all. 

    -- 
Dave Carrigan
Seattle, WA, USA
dave@rudedog.org | http://www.rudedog.org/ | ICQ:161669680
UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-C++-DNS-PalmOS-PostgreSQL-MySQL



    -- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: David T-G: "Re: CLI"

    Relevant Pages

    • Re: __atoi64 not working correctly
      ... are missing from header files. ... programmers have to work to is the C89/90 standard, ... of the C compilers available are C99 compliant ... I want to determine the 'best' floating point type for my ...
      (comp.lang.c)
    • Re: Fixed sized datatypes.
      ... standard header. ... now, quite a few compilers supply this header already, and it works ... standard conforming except for the 64 bit integer types. ...
      (comp.lang.cpp)
    • Re: learning C++
      ... which isn't discussed here (except to note that it's not standard). ... header becomes, The 'string' header becomes, ... namespace std, so you'd write 'std::printf' intead of plain 'printf'. ... A stream object (it's type is 'std::ostream'. ...
      (alt.comp.lang.learn.c-cpp)
    • Re: Standard header and using
      ... >> standard header. ... if the standard header iostream defines the names cout then why ... > A namespace is just another higher level of scope. ... > file without having to automatically have every part of that header file ...
      (alt.comp.lang.learn.c-cpp)
    • Re: Visual C++.Net: Cannot find stdlib.h?
      ... Here is what the standard says about the C subset header files: ... Every C header, each of which has a name of the form name.h, behaves as ... corresponding cname header is also placed within the namespace scope ... of the namespace std and is followed by an explicit using-declaration ...
      (microsoft.public.dotnet.languages.vc)