Least Common Denominator Feature Set

Discussion in 'C++' started by Steven T. Hatton, Jun 8, 2004.

  1. I often encounter statements in documentation or comments in source code
    that says things along the lines of "not all compilers support X, so we did
    not use it." X might be namespaces, dynamic_cast, templates, RTTI, etc. Is
    this a common situation for a lot of C++ development? Are there some major
    platforms that lack good C++ compiler support?

    Sometimes I have the sense the guideline or decision was made years ago, and
    never revised to address progress in compiler support. Is that a likely
    scenerio?

    --
    STH
    Hatton's Law: "There is only One inviolable Law"
    KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
    Mozilla: http://www.mozilla.org
     
    Steven T. Hatton, Jun 8, 2004
    #1
    1. Advertising

  2. Steven T. Hatton wrote:
    > I often encounter statements in documentation or comments in source code
    > that says things along the lines of "not all compilers support X, so we did
    > not use it." X might be namespaces, dynamic_cast, templates, RTTI, etc. Is
    > this a common situation for a lot of C++ development? Are there some major
    > platforms that lack good C++ compiler support?


    I can't attest to commonality, but in several places that have employed
    me over the years I've encountered that often that's true. And it may
    not necessarily be the platforms, but rather clients who use older C++
    compilers. Of course, when we had time we'd put #ifdef all over the code
    and let the "advanced" users enjoy the fuller compliance of their newer
    compilers. One thing you're *not* supposed to do is to force your clients
    to upgrade (whether the OS or the compiler). When they get to it, they
    will do it. Unfortunately, even when they do, we usually don't have time
    to go and weed out all older implementations. So, the backward-compatible
    code lives on.

    > Sometimes I have the sense the guideline or decision was made years ago, and
    > never revised to address progress in compiler support. Is that a likely
    > scenerio?


    Usually, the decision is quite generic. You either support retarder OSes
    and compilers or you don't. At any given time, there will always be some
    compilers and/or OSes that are advanced and some that are retarded. So,
    if you decide to support the retarded ones, you're never going to get out
    of that loop. Whether it's a good idea or bad is very individual because
    it's your business, it's your clients, it's your money to spend on support
    of those older environments.

    V
     
    Victor Bazarov, Jun 8, 2004
    #2
    1. Advertising

  3. "Steven T. Hatton" <> wrote in message
    news:...
    > I often encounter statements in documentation or comments in source code
    > that says things along the lines of "not all compilers support X, so we

    did
    > not use it." X might be namespaces, dynamic_cast, templates, RTTI, etc.

    Is
    > this a common situation for a lot of C++ development?


    If you try to support multiple platforms this is a common problem. Every
    compiler supports its own subset (and superset) of the C++ standard. And
    even if both compilers support feature X of standard C++, it is still
    possible that they produce different results (e.g. namespace resolution).
    This can be because one or both compilers are not fully standard compliant
    or that the standard is ambigious on the subject (and of course there is
    undefined behaviour which should avoided anyway). One way to deal with this
    is to avoid those features altogether (which can be impractical), another
    way is to #ifdef your problem away (this can get real ugly real quickly).

    > Are there some major
    > platforms that lack good C++ compiler support?


    Things are improving, fortunately.

    > Sometimes I have the sense the guideline or decision was made years ago,

    and
    > never revised to address progress in compiler support. Is that a likely
    > scenerio?


    Yes, I have seen coding standards that demanded that the names of public
    functions should be no longer than 6 characters because there was once a
    linker (10 years before) that could not handle name longer than 6
    characters. For some features it took a long time before (the majority of)
    compilers supported them correctly. Often the rule to avoid those
    'problematic' features stays in coding standards and in peoples heads long
    after the reason for that rule ceased to exist. This is one of the reasons
    why it is important know the motivation behind guidelines/rules.

    Another consideration is that in many places don't use the latest version
    of a compiler. I know of plenty of places where they still use GCC 2.9.5,
    and often for good reasons. Besides standard compliancy there are other
    concerns when deciding whether or not to upgrade a compiler. Especially in
    production environments changing compilers should not be taken to lightly
    (if it ain't broke, don't fix it).

    --
    Peter van Merkerk
    peter.van.merkerk(at)dse.nl
     
    Peter van Merkerk, Jun 8, 2004
    #3
  4. Steven T. Hatton

    red floyd Guest

    Peter van Merkerk wrote:

    > (if it ain't broke, don't fix it).


    That may also apply to the code, not just the compiler. They may have
    gone to a newer, more standards-compliant compiler, but the code is
    written, documented, debugged, and tested. It may be suboptimal, given
    some newer features of the language, but why bother changing it if it's
    known to work properly?
     
    red floyd, Jun 8, 2004
    #4
  5. Steven T. Hatton

    Guest

    "Steven T. Hatton" <> wrote in message news:<>...
    > I often encounter statements in documentation or comments in source code
    > that says things along the lines of "not all compilers support X, so we did
    > not use it." X might be namespaces, dynamic_cast, templates, RTTI, etc. Is
    > this a common situation for a lot of C++ development? Are there some major
    > platforms that lack good C++ compiler support?
    >
    > Sometimes I have the sense the guideline or decision was made years ago, and
    > never revised to address progress in compiler support. Is that a likely
    > scenerio?


    Your suspicion, that there is an old decision involved, is probably
    based in good solid fact. Many shops will have old compilers, or
    they will have old code that only compiles on old compilers, etc.
    Managers often see the effort to update old code as a waste. In
    *some* cases, they may be right. If somebody wants to rewrite code
    for the single purpose of updating it to a new coding standard,
    the chances are good it's not worth it.

    I have a set of rules.
    - If the users (clients, etc.) are not complaining, and
    - The software satisfies the specs, and
    - Nothing in particular is messing up downstream, then:
    don't change that code without a good reason. It's a lot of
    effort to rewrite code, and you may introduce new bugs doing it.

    So there may well be some ancient dinosaur of a compiler involved.

    For another angle on it, someplace in one of the "big name" books
    I read a story about the ubercoder. The new hire was very sorry to
    have missed him, because the ubercoder had made it a point of pride
    to use every single feature of the coding language in every single
    project he worked on. Ubercoder knew every jot and line of the
    standard, and had crawled over every nut-and-knob of the compiler,
    and could make things happen that nobody else even suspected.
    The new hire would have really enjoyed meeting ubercoder, excpet
    he had been fired the week before the new hire started.
    Socks
     
    , Jun 8, 2004
    #5
  6. red floyd wrote:

    > Peter van Merkerk wrote:
    >
    >> (if it ain't broke, don't fix it).

    >
    > That may also apply to the code, not just the compiler. They may have
    > gone to a newer, more standards-compliant compiler, but the code is
    > written, documented, debugged, and tested. It may be suboptimal, given
    > some newer features of the language, but why bother changing it if it's
    > known to work properly?


    That sounds almost like a contagious disease. If I have a product that a
    major customer uses as a development took kit, and the customer has legacy
    requirements that preclude the use of certain features I may be forced to
    implement my product without using the newer features of the language. If
    I have other customers who use my product as a key part of their
    development... And the more you add using the workaround to compensate for
    the once missing language feature the deeper it gets.

    I know of a situation where this kind of vicious cycle prevails. It can be
    frustrating to me. I always want to be using the very latest innovations.
    It's hard to stay motivated when you know there are better ways of
    accomplishing what your working one, but you can't use them.
    --
    STH
    Hatton's Law: "There is only One inviolable Law"
    KDevelop: http://www.kdevelop.org SuSE: http://www.suse.com
    Mozilla: http://www.mozilla.org
     
    Steven T. Hatton, Jun 9, 2004
    #6
    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. Replies:
    4
    Views:
    340
    Andrew Thompson
    Jan 8, 2005
  2. David Mathog
    Replies:
    22
    Views:
    667
    James Antill
    Oct 23, 2006
  3. Denny
    Replies:
    1
    Views:
    809
  4. AAaron123
    Replies:
    0
    Views:
    631
    AAaron123
    Oct 3, 2008
  5. Steven D'Aprano
    Replies:
    5
    Views:
    96
    Tim Delaney
    Aug 24, 2013
Loading...

Share This Page