Least Common Denominator Feature Set

[Steven T. Hatton]

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

[Victor Bazarov]

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

[Peter van Merkerk]

"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message
news:4J********************@speakeasy.net...

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

[red floyd]

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?

[puppet_sock]

"Steven T. Hatton" <su******@setidava.kushan.aa> wrote in message news:<4J********************@speakeasy.net>...

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

[Steven T. Hatton]

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