You might be able to get a C++ program working, but you haven't mastered
C++ if you haven't mastered C. For one thing, writing C++ in the real
world also means working with C: C libraries, C system interfaces, etc.
Maybe we're talking different things, here. I know lots of people who
have mastered C - they rarely if ever need to consult the spec, they
know the entire language including corners and nasty surprises. How many
people know C++ that well? Heck, I wrote a C++ compiler and I still have
to go and check the spec, and I still get surprised. I get emails from
well known C++ experts sending me snippets of code wondering if they are
valid C++ code or not. I don't get those for C. Some people, like Scott
Meyers, have made a career out of helping people understand C++. Where
are the equivalent C gurus if C is as difficult?
It's reasonable to master C code in a year or two. Give it 5 years at
least for C++.
Well, I could claim that about what you've said, but won't.
I know people who have claimed to learn C and other to learn
C++ "in a day". Of course, no such thing occurred.
Furthermore, IMO, nobody ever learns all of both languages.
Both you and I are in the C and C++ compiler business and
I bet both of us don't know all of C or C++. I will even
say that I bet you do not know all of D even though it is
your baby (for instance, I'll bet people send you code that
you either go Ugh to or Wow to because you never thought of
it before, etc). But I don't think that's what we're talking about.
I also personally believe that programming take a lifetime.
I certainly learn more about it each year. But I also think
that's different mastering than being discussed, although it
is in line for it.
Those things said:
In my experience it takes the average C beginner about 6 months
to *start* to be able to move with a swagger. And that it
takes about 9 months for C++. Also, as that is the average,
it might take some C programmers a year, and some C++ programmers
5 months, and so on. Also, it does not have to continue at
that same pace.
It also depends upon whether they are a complete newbie to
programming or not. For instance, somebody who already knows
Ada would not have some of the same concerns as somebody
who already knows COBOL, or against somebody who knows nothing
at all.
Intuition tells us what I've claimed makes no sense. But it's
not much different from some of the original claims about C++:
for instance, that because it was bigger than C, that it HAD
to be slower. That's not a generalism because the sum of the
parts is not always the same as the sum of the whole. I think
that we have a similar situation here.
Many claim that C++ is not a superset of C, and so many find
your claim that that is the case to be an extraordinary claim.
Personally if I had to choose I would say it is, but I also
acknowledge that there is some wiggle room here (actually more
than that, there is common ancestry but there is also different
approaches even on some of the so-called common parts).
And either way, the overlap becomes critital.
IOWs, a C++ programmer does not always learn "the C part of C++"
in isolation. Often it occurs in unison.
And no, that does not necessarily make them a C programmer too
in the end. Ironically though (again, intuition tells us otherwise,
often wrongly), many C++ programmers find that it makes them
better C programmers (not necessarily on the same issues).
Whatever it is about the culture and mindset I think is significant
here. For instance, I believe that many C++ programmers end
up understanding pointers better. I also believe that many
C++ educational approaches (for instance books) do a better job
at explaining concepts and techniques than their "equivalent"
C approaches which focus more on language. This also ripples
into other areas because although one can do many of the
techniques in C, there are not direct constructs through which
to do them with that are naturally supported by C. This lends
to a reverse learning kind of situation which the knowledge
becomes leaked in the C++ programmers case to the C++ side.
Also, despite C being around longer, and on more platforms,
it still has a limited and too low level standard library.
I find both C and C++s libraries daunting but at the same time
always expect that more can be added (which normally goes
against my default design constraints). This can pretty much
puts lots upside down when C++'s more high level library can
come into play.
On a personal level, I knew many languages before I knew C.
And I've always said I've had to learn C 3 times.
Against many other larger languages, I think I had the hardest
time with C. And I think some of the same issues fall out when
C++ is considered even though it is clearly larger and more
complicated. And certainly many of C++ problems are shared
not only by C but literally with C.
BTW, I also think there is biased picked up with people learn
programming languages. For instance many C programmer's style
might be influeced by K&R, and contrary issues might be influenced
by Stroustrup, and so on. I don't think that's just a neutral
issue or even just language cultural issue.
Re master C programmers, most of the master C programmers
I know do consult the spec. And I think saying they know all
corners, the entire language, and all nasty surpriseds would
be extraordinary. I think I know C well, but probably would
not make that claim about myself so maybe we are talking about
different things somehow. I agree many people know many of
the issues though, but probably not enough.
Despite being in the C++ compiler and other related businesses
I too find myself checking the C++ standard often, and as well
often being surprised. But despite being in the C compiler and
other related businesses, I also find that I need to check the
C standard too, and that often I'm surprised with it too.
So, in conclusion, it's reasonable to master both in about
the same time. There's too many issues on the table to say
otherwise anyway. I know in my own case that I knew an awful
lot about C in a year, and had written 100s of KLOC and large
apps in C and other languages at that point, but I think I would
be kidding myself to say I was a master C programmer at that point,
even though I probably thought I was.
