Re: Problem with a linked list

Walter Roberson wrote:
> websnarf@xxxxxxxxx wrote:
> >C as a language is clearly in decline, while C++ is not (though a
> >lot of its mindshare got robbed by Java.) And vendors who make C
> >compilers generally make C and C++ combined products. That means
> >in the long run, the vendor will treat their C compiler as a
> >"checkmark" while treating their C++ compiler as the focus of all
> >serious future development.
>
> My understanding (perhaps incorrect) is that most serious
> development for procedural compilers these days is based upon
> having a parser layer that produces intermediate code, with all
> the optimization done at the intermediate code level. The
> bulk of the work is in the optimization phases, so even if the
> parsers get tuned differently, the optimization phases and
> generated code grow at the same rate for all the compilers
> implimented on the common platform.

Yes, but it still takes quite a bit of work to translate from the
langauge level to this intermediate level. And it takes a lot of
testing to make sure its all working correctly. And different
languages will have different emphasis on optimization.

If a language vendor is not getting feedback about C, but is about C++,
and really cannot see C as anything other than "legacy support", then
regardless of how "modularly" they could do it, what would justify them
spending effort, going forward, on the older C compiler outside of
optimizing a few benchmarks?

> There could certainly be differences in the prioritization of
> library implementations, or of prioritization of feature change
> implementation, but the effect is somewhat different than
> implied by your paragraph.

This is what I mean. Any serious compiler vendor cannot view C as
anything other than an opportunity on a few fixed benchmarks, as well
as possible bug fix requests. This is why basically no vendor is
rushing to support the "C99" standard. Of the serious vendors, only
the gcc people (who are not beholden to a market driven considerations)
even made a serious go at full support. If you read the recent
slashdot article on gcc 4.0 you will see that C performance has not
changed at all -- in fact, the majority of the effort has gone towards
better C++ support.

> I am not convinced that "C as a language is clearly in decline".

Ok ... about 10 years ago, there would be no question that C was the
dominant language. The best measures I have seen regarding mindshare
of C today is at about 30% (matched equally by C++ and Java.) The
direction of these trends is obvious. Look at schools today. They
don't teach C as a fundamental language -- they teach either C++ or
Java (or C# if they've been bribed by certain entities in the Pacific
Northwest.)

> It might perhaps have a lower percentage of the market than it once
> did, but the market is expanding.

That's like saying Apple's market is growing, even though their
percentage is going down. (By itself,) Its not a convincing argument
for software vendors to switch to just supporting the Mac.

Most new development is not done in C, unless for some reason, that's
the only thing the programmers know. At my previous place of
employment, we started with a C project, but as we started hiring more
developers, we concluded that there was enough C++ expertise amongst
them that we simply shifted the project into C++. I mean -- knowing C
is basically a subset of knowing C++, and we started in C -- and even
*that* was not enough of an argument to stay in C.

> I think whether I implemented in C or C++ would depend a fair bit
> upon political factors (for stuff I'm paid to do); but when given
> the choice of languages, my determination would depend on
> tradeoffs between efficiency and program structure. There are an
> amazing number of applications that don't *need* classes.

Well, in fact, no applications need classes. That's not the point.
Most modern developers today simply *believe* programming with classes
is better. This causes a shift in mindshare, which causes a shift in
compiler development efforts etc.

> C++ as a development methodology is based upon the premise that
> you will put together a library of objects and that the world will
> rejoice and yeah verity the virtual classes will be fruitful
> all the days of thy life. The reality is somewhat different:
> yup, there are definitely some things that get implimented
> over and over again that can be shared, but there is so much
> application-specific logic that (according to some material I
> was reading) -most- classes get used for at most 2 or 3 projects
> and then get left behind. That's a lot of time spent finding
> beautiful abstractions, that doesn't end up going very far...

Trust me, I'm the last person on earth who would defend C++ as a
language. That isn't the point I was trying to make.

We are in a unique situation where C++ is starting to dominate over C,
certainly compiler development is shifting in that direction (and has
been for some years now), but we have the opportunity to take advantage
of the interesting fact that C++ is an approximation of a superset of
the C language. If you make your code compilable in C or C++, then you
get to leverage the ongoing improvements of C++ compilers while not
shifting your actual language and still remaining portable to C
compilers.

---
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: Learning C++?
    ... | * Have built-in support for common data structures, like lists, tuples, ... | the compiler or the run-time system should deduce it for me. ... library(I love this language, even though I hate it :-)), ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Learning C++?
    ... My ideal programming language would: ... No program that passes the compiler or interpreter should produce ... * Have built-in support for common data structures, like lists, tuples, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Garbage collection
    ... Unfortunately making an accurate GC for C would require compiler ... "The programmers knows what he does" it would be ... support GC or beeing against it. ... So I'd argue there's hardly a language whith more tools ...
    (comp.lang.c)
  • Re: Why the VB6 versus VB.NET contest is baloney
    ... What they should NOT is stop support on VB6. ... About 10 years ago I had to decide what language to ... First and foremost, the problem isn't only one of Microsoft; the problem is selecting _any_ language that is vendor-proprietary, _whoever_ the vendor and whatever the language. ... As long as it is a proprietary product, the possibility exists that the company my change its mind/direction as w/ VB or even cease to exist (being a Fortran guy w/ DEC antecedents, I bought the DEC/CVF Visual Fortran compiler ages ago because it had the DEC VAX extensions and came bundled w/ the MS Visual Studio and the Visual Numerics (IMSL) libraries as a bundled package. ...
    (microsoft.public.vb.general.discussion)
  • Re: static vs. dynamic linking
    ... I think this has to be one of those things where the language changed ... Static and dynamic linking has very little to do ... Some meta-language support is required on some platforms, ... but that is done in the form of compiler directives that are ...
    (comp.lang.fortran)