What's your C++ skill level?
oskarmellow
be interesting (at least for me) to hear some thoughts on how you
would self-assess your C++ skill level.
So, the big question... on a scale of 1 to 10, how would you rate
your C++ skill level.
1 being - "what's C++?"
10 being - "I wrote a C++ compiler fully supporting C++0x last night
after dinner (on my iPhone)"
As for my response:
I think I first hit this question in an interview N number of years
back, at which point I told the interviewer "I'd say like an 8 or 9
(in my head i was saying 6)".
Ever since then, I find myself always trying to determine my skill
level.
And in the process of doing so, my self-assessed rating keeps getting
lower and lower.
It's rather depressing, but I've asked my colleagues this question as
well and it seems that we've all come to the conclusion that you know
you're true skill level when you realize you know nothing about C++.
Currently, I rate myself a 3, which means i'm two levels shy of
nirvana. (or conversely, 7 levels away from writing my own C++
compiler that likes me)
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Phlip
> So, the big question... on a scale of 1 to 10, how would you rate
> your C++ skill level.
> 1 being - "what's C++?"
> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
> after dinner (on my iPhone)"
9 - wrote a book with leading-edge techniques in it
8 - published a used library with leading-edge techniques
(or wrote a generic tutorial with standard techniques in it)
7 - have invented leading-edge techniques & blogged about them
6 - have architected entire successful C++ applications
5 - have unit-tested, maintained, and debugged C++ apps
4 - know how to factually avoid undefined behavior
3 - obey a sane subset so narrow most of my behavior is defined!
2 - know how to debug C++ until it works
1 - am allowed to look at C++ written by other teammates
0 - I post "delete NULL" questions to the newsgroups!
I am at 6 with tutorial attempts at 7.
> As for my response:
> I think I first hit this question in an interview N number of years
> back, at which point I told the interviewer "I'd say like an 8 or 9
> (in my head i was saying 6)".
That's one of the interview questions that sucks but has to be asked. One major
problem with C++ is its undefined behavior envelop is so wide, the crew needs to
know if you are above 2. Lots of C++ development, run wrong, consists of weeks
of agonizing hunting for each bug.
The interviewer can't fault you for interviewing skills. In US culture, at
least, you are expected to brag and not be modest about anything. However, you
now know the question is an invitation for you to walk my list from the top down.
"Well, 10 is I could write a compiler, and 9 is I could write a book, so I
am..." etc.
> Ever since then, I find myself always trying to determine my skill
> level.
> And in the process of doing so, my self-assessed rating keeps getting
> lower and lower.
Props - that shows you are learning more C++!
--
Phlip
Dragan Milenkovic
> I know this group is about technical C++ items, but I thought it might
> be interesting (at least for me) to hear some thoughts on how you
> would self-assess your C++ skill level.
>
> So, the big question... on a scale of 1 to 10, how would you rate
> your C++ skill level.
> 1 being - "what's C++?"
It depends on the type of C...
> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
> after dinner (on my iPhone)"
Damn it! "Dinner"... I knew I forgot something...
> As for my response:
> I think I first hit this question in an interview N number of years
> back, at which point I told the interviewer "I'd say like an 8 or 9
> (in my head i was saying 6)".
>
> Ever since then, I find myself always trying to determine my skill
> level.
> And in the process of doing so, my self-assessed rating keeps getting
> lower and lower.
>
> It's rather depressing, but I've asked my colleagues this question as
> well and it seems that we've all come to the conclusion that you know
> you're true skill level when you realize you know nothing about C++.
... ongoing mission: to explore strange new C++ features; to
seek out new issues and defects...
Isn't it more important how good you are with object oriented design
and maybe meta programming than knowing C++ well enough to write
a compiler? Understanding scalability issues with a server software
you develop has nothing to do with C++, but is crucial for the task.
I'll never even try to learn the nit-pick details of C++, unless
I really engage in a compiler writing project. Features of C++
are tools for developing good and clean designs (although honestly,
the mentioned server was written in Java and is far from
being clean :-).
--
Dragan
Stuart Golodetz
The interview question sounds as if it's designed to determine your
attitude, not your skill level. (If they want to find out the latter,
they set you a coding test, they don't trust your word on it.) It's an
interesting question from the interviewer's perspective because it
potentially reveals a lot about you.
As to how I'd answer the question, I think in an interview I'd grin and
call them on it - there's no numeric answer to that question that will
help your cause. The advantage of answering that way is that you get to
see something about them from how they react instead - interviews are a
two-way process, after all, and you want that glimpse of how they think.
Regards,
Stu
Pavel
brainbench.com (they give C++ tests for free from time to time if you do
not want to pay, about once a year for a month or so). They will let you
know "where you stay" among all those who took the test before.. I would
say, with all those nice dark corners of the language, only your level
relative to others matter, in some objective metrics, and the absolute
knowledge is nonsense. What I mean is that if an interviewer can
embarrass you in a closed-book exam on C++ and you can do same to her
when tables change, who knows C++ better and what would be your and her
"score"?
And, as you mentioned C++0x: when it comes out with all its nice little
features (like that badly needed ;-) support of functional programming
paradigm -- as if yet another meaning for brackets were really all we
needed) the "1-10 score" will become .. well .. a pure abstraction (do
not mix with a pure virtual function).
-Pavel
Jerry Coffin
@m11g2000yqh.googlegroups.com>, oskar...@gmail.com says...
>
> I know this group is about technical C++ items, but I thought it might
> be interesting (at least for me) to hear some thoughts on how you
> would self-assess your C++ skill level.
>
> So, the big question... on a scale of 1 to 10, how would you rate
> your C++ skill level.
> 1 being - "what's C++?"
> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
> after dinner (on my iPhone)"
What's the point of having a rating of 10, if nobody on earth can
possibly hope to come close to receiving it?
That aside, I can see two entirely kinds of things to rate. One is a
persons ability to apply the C++ language to solving problems. The
other is knowing a great deal about the technical details of the
language itself.
While there is _some_ correlation between the two, it's often fairly
loose. A person certainly needs to know the language reasonably well
to apply it to solving problems, but "reasonably well" is a flexible
measure, to put it mildly. To an even greater degree than many other
languages, C++ has a lot of details that matter very little for most
real practitioners.
In the other direction, excessive knowledge of technical details can
lead to writing code that depends on them -- to the point that few
can understand the code, and fewer still can maintain it, sometimes
including the original author. Worse, in some cases the code may
depend on features that many compilers don't implement (at least
correctly). Unless a _great_ deal is gained in return, this can have
a cost that's (much) greater than any possible benefit.
--
Later,
Jerry.
Louis Lavery
Yes. Clever code is easy. But easy code is clever.
Louis.
--
Thomas Matthews
I would rate myself at 7 or 8. I've written compilers. At one time
I did know the dark secrets of C++.
Since then, I've realized that knowing the language is not enough and
not to bother knowing all the secrets. Scott Meyers and Andrei A.
can show you neat little tricks, but if you can't implement some
common design patterns, what good is it?
Also, if you use the dark secrets, other cheaper labor cannot
maintain your software. I would rather spend more of my effort
resolving issues at requirements and design level than at the
coding stage. On interviews, the statement "V-tables are an
implementation detail and not part of the language." doesn't cut the
mustard. They still want to know platform specific issues.
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library
Balog Pal
"Pavel" <dot_com_yahoo@paultolk_reverse.yourself>
> Just take some reasonably decent online assessment, like one from
> brainbench.com (they give C++ tests for free from time to time if you do
> not want to pay, about once a year for a month or so). They will let you
> know "where you stay" among all those who took the test before.. I would
> say, with all those nice dark corners of the language, only your level
> relative to others matter, in some objective metrics, and the absolute
> knowledge is nonsense. What I mean is that if an interviewer can
> embarrass you in a closed-book exam on C++ and you can do same to her
> when tables change, who knows C++ better and what would be your and her
> "score"?
IMO the most important think is to know thy limits. Problems come from
confidence that is built on sand.
Corner cases are okay if you recognise them as such.
Interesting, that the tests I've seen are just broken in this most important
regard. If I made a selection test, it would always include answers like 'I
don't know', 'must RTFM', 'who cares, you mustn't do anything like this
anyway'.
And would use negative scores on wrong answer picked -- weighted with
wrongness.
In the practice the idontknow cases are benign -- you look up the stuff or
ask someone. While going the wrong path exposes the system to bugs.
Peter_APIIT
> oskarmellow wrote:
> > So, the big question... on a scale of 1 to 10, how would you rate
> > your C++ skill level.
> > 1 being - "what's C++?"
> > 10 being - "I wrote a C++ compiler fully supporting C++0x last night
> > after dinner (on my iPhone)"
>
> 9 - wrote a book with leading-edge techniques in it
> 8 - published a used library with leading-edge techniques
> (or wrote a generic tutorial with standard techniques in it)
> 7 - have invented leading-edge techniques & blogged about them
> 6 - have architected entire successful C++ applications
> 5 - have unit-tested, maintained, and debugged C++ apps
> 4 - know how to factually avoid undefined behavior
> 3 - obey a sane subset so narrow most of my behavior is defined!
> 2 - know how to debug C++ until it works
> 1 - am allowed to look at C++ written by other teammates
> 0 - I post "delete NULL" questions to the newsgroups!
My rating is 3 after 3 years C++ programming.
I feel bad because still cannot improved my programming skill. Need
advice.
--
Balog Pal
> That aside, I can see two entirely kinds of things to rate. One is a
> persons ability to apply the C++ language to solving problems. The
> other is knowing a great deal about the technical details of the
> language itself.
>
> While there is _some_ correlation between the two, it's often fairly
> loose. A person certainly needs to know the language reasonably well
> to apply it to solving problems, but "reasonably well" is a flexible
> measure, to put it mildly. To an even greater degree than many other
> languages, C++ has a lot of details that matter very little for most
> real practitioners.
Yea. Though there is a list of gotchas one must know in order to not get
hurt.
> In the other direction, excessive knowledge of technical details can
> lead to writing code that depends on them -- to the point that few
> can understand the code, and fewer still can maintain it, sometimes
> including the original author. Worse, in some cases the code may
> depend on features that many compilers don't implement (at least
> correctly). Unless a _great_ deal is gained in return, this can have
> a cost that's (much) greater than any possible benefit.
IMO the true knowledge of details comes with knowledge of the real world
implementations, and the very problem you describe here. While IME the
'showing off' type programming is tied to people with really limited
knowledge and understanding, just picking up some crumbs.
--
CornedBee
> That aside, I can see two entirely kinds of things to rate. One is a
> persons ability to apply the C++ language to solving problems. The
> other is knowing a great deal about the technical details of the
> language itself.
Very true. But there is another scale, namely the design experience. I
like to consider myself a 10 on the technical scale (and I do
participate in C++ compiler development), and very high on the
practical application scale too, but my actual experience is
considerably more limited - I'd rate myself a 5 or 6 there. I have
developed a medium-scale C++ application and have participated in the
development of large-scale C++ applications. But this third scale is
not strictly about C++.
Sebastian
--
Walter Bright
> So, the big question... on a scale of 1 to 10, how would you rate
> your C++ skill level.
> 1 being - "what's C++?"
> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
> after dinner (on my iPhone)"
Well, I did write a C++ compiler from opening the source file to closing
the object file and everything in between (as far as I know, I'm still
the only person to have done that).
But for me it's like the chief mechanic for a drag racer. I know how to
build them, but I defer to others who know how to drive 'em.
(And I heard at least one Top Fuel chief mechanic say he was not crazy
enough to ever try driving one of those machines! <g>)
Writing a C++ compiler doesn't automatically confer or imply top C++
coding skills. So what is my C++ driving skill? I'd give it a 5.
----
Walter Bright
Digital Mars
http://www.digitalmars.com
Free C, C++, D programming language compilers
George Neuner
>oskarmellow wrote:
>
>> So, the big question... on a scale of 1 to 10, how would you rate
>> your C++ skill level.
>> 1 being - "what's C++?"
>> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
>> after dinner (on my iPhone)"
>
>9 - wrote a book with leading-edge techniques in it
>8 - published a used library with leading-edge techniques
> (or wrote a generic tutorial with standard techniques in it)
>7 - have invented leading-edge techniques & blogged about them
>6 - have architected entire successful C++ applications
>5 - have unit-tested, maintained, and debugged C++ apps
>4 - know how to factually avoid undefined behavior
>3 - obey a sane subset so narrow most of my behavior is defined!
>2 - know how to debug C++ until it works
>1 - am allowed to look at C++ written by other teammates
>0 - I post "delete NULL" questions to the newsgroups!
7b - have invented leading-edge techniques but NOT blogged about them
--
Rune Allnor
> oskarmellow wrote:
> > So, the big question... on a scale of 1 to 10, how would you rate
> > your C++ skill level.
> > 1 being - "what's C++?"
> > 10 being - "I wrote a C++ compiler fully supporting C++0x last night
> > after dinner (on my iPhone)"
>
> 9 - wrote a book with leading-edge techniques in it
> 8 - published a used library with leading-edge techniques
> (or wrote a generic tutorial with standard techniques in it)
> 7 - have invented leading-edge techniques & blogged about them
> 6 - have architected entire successful C++ applications
> 5 - have unit-tested, maintained, and debugged C++ apps
> 4 - know how to factually avoid undefined behavior
> 3 - obey a sane subset so narrow most of my behavior is defined!
> 2 - know how to debug C++ until it works
> 1 - am allowed to look at C++ written by other teammates
> 0 - I post "delete NULL" questions to the newsgroups!
Somewhere between 3 and 5. Even if I have dabbled with C++
for a decade and a half, I am still learning trivial
stuff, like how (not) to implement operator*() and friends.
At the other extreme, I'm planning and implementing
what is intended to become an industrial-scale data
processing tool for use in my day-job.
The tools that are out there today seem to be hard
to maintain and expand. One vendor sent a maintenance
engineer to my location, who apparently had never seen
the tools in actual use for the several years he had
worked for the vendor. It was kind of a revelation
for him to see what the tools were used for, and how,
compared to his ideas of the same. Of course, this guy
switched jobs a few months afterwards, so the vendor
never had any benefits from his new-found insights.
The same vendor is rumored to not want to include
user's requests in theur tools, because 'modifying
the source code introduces bugs in cod ethat works.'
So even rudimentary knowledge about how to do things
in C++ is very helpful, since it allows me to see
where improvements can be made. And help me get an
impression of which players out there are serious
and which are not.
Rune
--
Martin Eisenberg
> Clever code is easy. But easy code is clever.
That makes for a nice sig, is it attributable to you?
Martin
--
Quidquid latine scriptum est, altum videtur.
Dragan Milenkovic
> oskarmellow wrote:
>
>> So, the big question... on a scale of 1 to 10, how would you rate
>> your C++ skill level.
>> 1 being - "what's C++?"
>> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
>> after dinner (on my iPhone)"
>
> 9 - wrote a book with leading-edge techniques in it
> 8 - published a used library with leading-edge techniques
> (or wrote a generic tutorial with standard techniques in it)
> 7 - have invented leading-edge techniques & blogged about them
> 6 - have architected entire successful C++ applications
This I did... a server application, reliable, modular ...
> 5 - have unit-tested, maintained, and debugged C++ apps
No unit-testing whatsoever...
> 4 - know how to factually avoid undefined behavior
I would say many UBs would strike me if I used float.
But I avoid float altogether. Other kinds I can handle well.
> 3 - obey a sane subset so narrow most of my behavior is defined!
> 2 - know how to debug C++ until it works
> 1 - am allowed to look at C++ written by other teammates
> 0 - I post "delete NULL" questions to the newsgroups!
How do I grade? 3? :-D
--
Dragan
Louis Lavery
> Louis Lavery wrote:
>
>> Clever code is easy. But easy code is clever.
>
> That makes for a nice sig, is it attributable to you?
Thanks. I'm glad you like it. I came up with it one
morning while lead in bed. I'm sure it can be improved
upon.
Louis.
--
George Neuner
>oskarmellow wrote:
>
>> So, the big question... on a scale of 1 to 10, how would you rate
>> your C++ skill level.
>> 1 being - "what's C++?"
>> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
>> after dinner (on my iPhone)"
>
>9 - wrote a book with leading-edge techniques in it
>8 - published a used library with leading-edge techniques
> (or wrote a generic tutorial with standard techniques in it)
>7 - have invented leading-edge techniques & blogged about them
>6 - have architected entire successful C++ applications
>5 - have unit-tested, maintained, and debugged C++ apps
>4 - know how to factually avoid undefined behavior
>3 - obey a sane subset so narrow most of my behavior is defined!
>2 - know how to debug C++ until it works
>1 - am allowed to look at C++ written by other teammates
>0 - I post "delete NULL" questions to the newsgroups!
This list places a lot of emphasis on publishing ... leaving out those
of us who do proprietary work.
>"Well, 10 is I could write a compiler, and 9 is I could write a book, so I
>am..." etc.
Then I guess I'm at 9 or 10 - I haven't written a C++ compiler but I
could if I had enough time. I have written 2 native compilers: a
Lisp-like FPL on x86 and a Pascal inspired OO array-processing DSL
targeting a parallel FPGA boosted DSP based system (which I also
helped design).
George
--
John G Harris
wrote:
>oskarmellow wrote:
>
>> So, the big question... on a scale of 1 to 10, how would you rate
>> your C++ skill level.
>> 1 being - "what's C++?"
>> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
>> after dinner (on my iPhone)"
>
>9 - wrote a book with leading-edge techniques in it
>8 - published a used library with leading-edge techniques
> (or wrote a generic tutorial with standard techniques in it)
>7 - have invented leading-edge techniques & blogged about them
>6 - have architected entire successful C++ applications
>5 - have unit-tested, maintained, and debugged C++ apps
>4 - know how to factually avoid undefined behavior
>3 - obey a sane subset so narrow most of my behavior is defined!
>2 - know how to debug C++ until it works
>1 - am allowed to look at C++ written by other teammates
>0 - I post "delete NULL" questions to the newsgroups!
-1 - Wrote a book full of C++ urban myths (to put it politely)
John
--
John Harris
Mathias Gaunard
> >"Well, 10 is I could write a compiler, and 9 is I could write a book, so I
> >am..." etc.
>
> Then I guess I'm at 9 or 10 - I haven't written a C++ compiler but I
> could if I had enough time. I have written 2 native compilers: a
> Lisp-like FPL on x86 and a Pascal inspired OO array-processing DSL
> targeting a parallel FPGA boosted DSP based system (which I also
> helped design).
I believe mostly everyone has already done a compiler for a simplistic
language in his life (it's even part of good undergraduate studies
these days, albeit they usually target simple RISC architectures and
don't bother much with optimization).
Doing a C++ compiler is hard because C++ is big and complicated. Just
doing a good parser (which the required embedded semantic analysis)
would probably take years.
Yes, given time and dedication, you could do anything; but if you
haven't done it, you haven't acquired the experience of doing it.
I don't think writing a book should be 9 though. Writing a book is not
strictly dependent on skill on the subject, and even people such as
Scott Meyers, Herb Sutter or Andrei Alexandrescu are not necessarily
the biggest C++ gurus.
Mathias Gaunard
> > 4 - know how to factually avoid undefined behavior
>
> I would say many UBs would strike me if I used float.
> But I avoid float altogether. Other kinds I can handle well.
Wouldn't that be unspecified behaviour, rather?
--
Pavel
> "Pavel" <dot_com_yahoo@paultolk_reverse.yourself>
>
>> Just take some reasonably decent online assessment, like one from
>> brainbench.com (they give C++ tests for free from time to time if you do
>> not want to pay, about once a year for a month or so). They will let you
>> know "where you stay" among all those who took the test before.. I would
>> say, with all those nice dark corners of the language, only your level
>> relative to others matter, in some objective metrics, and the absolute
>> knowledge is nonsense. What I mean is that if an interviewer can
>> embarrass you in a closed-book exam on C++ and you can do same to her
>> when tables change, who knows C++ better and what would be your and her
>> "score"?
>
> IMO the most important think is to know thy limits. Problems come from
> confidence that is built on sand.
and below, aren't you?
>
> Corner cases are okay if you recognise them as such.
>
> Interesting, that the tests I've seen are just broken in this most important
> regard. If I made a selection test, it would always include answers like 'I
> don't know', 'must RTFM', 'who cares, you mustn't do anything like this
> anyway'.
>
> And would use negative scores on wrong answer picked -- weighted with
> wrongness.
>
> In the practice the idontknow cases are benign -- you look up the stuff or
> ask someone. While going the wrong path exposes the system to bugs.
Totally agree. I guess in Brainbench a tested can even guess without a
penalty which is completely unprofessional. If you miss a question (do
not answer it in 60 seconds) you lose points but if you just guess you
have a chance to guess right.
It's interesting that even in more professional tests they penalize for
guessing but this penalty is usually like -1/4 for answering a multiple
choice of 4. Even with this penalty, it is actually beneficial to guess
if you have any clue at all (say, you can exclude one of the wrong
choices with certainty but have no idea how to select among other 3
answers).
I think in engineering, medical ans similar tests, they need to give 1
for a correct answer, 0 for not answering and -1 (or even less) for a
wrong answer -- this would naturally encourage professionalism.
On the other hand, in testing pilots, military commanders, salesmen and
other professionals who have to make decisions in real-time, some
guessing encouragement could make sense.
This said, I felt the OP's question was valid -- and my answer is that
even a poorly designed but objective test would help to rate yourself
relative to others as long as it does not assume wrong answers
(Brainbench tests are decent in this regard).
-Pavel
Dragan Milenkovic
> On 17 juil, 17:01, Dragan Milenkovic <dra...@plusplus.rs> wrote:
>
>>> 4 - know how to factually avoid undefined behavior
>> I would say many UBs would strike me if I used float.
>> But I avoid float altogether. Other kinds I can handle well.
>
> Wouldn't that be unspecified behaviour, rather?
So... you're reduced my grade to a 2? Thanks a lot! :-D
In my defense, I have a assumed that it was referring to
both undefined and unspecified behavior. For example,
the order of evaluation of function arguments is
unspecified and you have to be aware to avoid it.
But never mind my defense, I'll write a 2 to my file...
--
Dragan
James Kuyper
....
> I believe mostly everyone has already done a compiler for a simplistic
> language in his life (it's even part of good undergraduate studies
> these days, albeit they usually target simple RISC architectures and
> don't bother much with optimization).
I studied to be a computational physics - my formal education was long
on physics, and covered only the basics of computer programming and some
numerical techniques. My career has ended up taking quite a different
path - I'm a computer programmer/analyst specializing in scientific
applications. I've taken only a small number of formal classes in
computer programming, and most of them were solely for the purpose of
getting a piece of paper to document that I knew something I had already
taught myself outside of class. Therefore, I've never done most of the
standard CompSci stuff like writing a compiler. It sounds interesting,
but I can't imagine where I'd find the time to do it.
Dragan Milenkovic
> I don't think writing a book should be 9 though. Writing a book is not
> strictly dependent on skill on the subject, and even people such as
> Scott Meyers, Herb Sutter or Andrei Alexandrescu are not necessarily
> the biggest C++ gurus.
It's fine you did it to me in the previous post... But leave
others alone, please! :-)
Seriously though, are you a friend to those people? What does
"people such as" mean? Would having your own flag in G++
be a better criterion than writing a book?
--
Dragan
Dave Harris
> 9 - wrote a book with leading-edge techniques in it
> 8 - published a used library with leading-edge techniques
> (or wrote a generic tutorial with standard techniques in it)
> 7 - have invented leading-edge techniques & blogged about them
I don't think the difference between those has much to do with C++
expertise. Non-experts can write books.
> 6 - have architected entire successful C++ applications
> 5 - have unit-tested, maintained, and debugged C++ apps
These seem to be more about being an expert programmer than an expert in
C++. We can use C++ successfully while only knowing a small sub-set of
it.
> 4 - know how to factually avoid undefined behavior
> 3 - obey a sane subset so narrow most of my behavior is defined!
A lot of emphasis on undefined behaviour. There's more to C++ than that.
My own hierarchy would be more oriented around language features and
techniques.
2-3 At the bottom end are people who mostly stick within the
C/C++ subset, perhaps using new/delete and std::vector<>.
4-5 Next are the ones who know when to use references in their
own code, and who can implement classes with virtual functions.
They know the std collection classes quite well.
6-7 Next comes some facility writing their own templates. They
can use std::algorithms, but may choose not to. They can use
local classes and predicates and pointers to member functions.
They may be considered experts by their colleagues. They may
have some awareness of the dark corners of C++, in which case
they are probably aware of how much they don't know.
8-9 Next comes the people who understand books like "Modern C++
Design", and are comfortable with notions like typelists.
They know what "SFINAE" means and why it matters, and why
perfect forwarding has been problematic. They probably follow
the evolution of the C++ standard.
10 Finally we have the ones who can contribute to the state of
the art (whether through books or otherwise). Who can make
worthwhile criticisms or suggestions for proposals such as
r-value references or lambdas or concepts.
On that scale I'd probably put myself around 8. Most people who come to
interview at my employers are below 4. If you ask them, "what is a
reference and when would you use one?" they are floored.
Idealy the chief architect for a project would at least be at 6-7, that
is, would know when to design using templates rather than virtual
functions. The rank and file can be below that. You don't need to be an
expert to be a useful C++ programmer.
> oskarmellow wrote:
> > Ever since then, I find myself always trying to determine my skill
> > level. And in the process of doing so, my self-assessed rating
> > keeps getting lower and lower.
That's what I had in mind at 6-7. You get to know enough that colleagues
start coming to you with obscure compiler errors, and you can help them,
so you think you are the local expert. And then you get exposed to the
wider world, such as some of the debates in this newsgroup, and you
realise how much you don't know.
-- Dave Harris, Nottingham, UK.
--
George Neuner
wrote:
>On 17 juil, 23:27, George Neuner <gneun...@comcast.net> wrote:
>
>> >"Well, 10 is I could write a compiler, and 9 is I could write a book, so I
>> >am..." etc.
>>
>> Then I guess I'm at 9 or 10 - I haven't written a C++ compiler but I
>> could if I had enough time. I have written 2 native compilers: a
>> Lisp-like FPL on x86 and a Pascal inspired OO array-processing DSL
>> targeting a parallel FPGA boosted DSP based system (which I also
>> helped design).
>
>I believe mostly everyone has already done a compiler for a simplistic
>language in his life (it's even part of good undergraduate studies
>these days, albeit they usually target simple RISC architectures and
>don't bother much with optimization).
You're right - a whole lot pf people have written simple compilers. I
have written a dozen or so myself. However these particular ones I
mentioned are not simple ... they are not C++ complex, but definitely
not simple.
The FPL is my own design, inspired by the old sexpr Dylan and by
OCaml. OO all the way down (like Dylan). It has (still evolving)
type inference and latent typing standard. The inferencer currently
needs type declarations for recursive structures, but declarations are
allowed for any data. The compiler tries to optimize code wherever
all the types can be nailed down ... e.g., if the compiler can
conclude that a particular variable is integer rather than numeric it
may be able to emit better code, elide runtime type checks, etc. This
is an ongoing project as I have time to work on it.
The DSP/FPGA compiler is proprietary, commercial and I don't own the
rights to it so I can only give a general description here.
The compiler targets custom hardware having one or more interconnected
FPGAs with a high speed DSP for I/O, control sequencing and for
primary floating point support. You can do floating point on the
arrays but it takes a lot of cell space and isn't practical on small
arrays. The hardware was designed modularly so as to be able to
accommodate different FPGA families. It was designed around a DSP
rather than a CPU to make sure very fast floating point was always
available.
The compiler and runtime were designed with performance of the FPGAs
as the primary objective (at this time the DSP code is only fair, but
improving - the runtime bundles a commercial DSP library for optimized
support functions). The compiler does not generate FPGA
configurations itself, but rather uses a library of existing
configurations along with meta information about which functions are
contained in which configurations and information about the functions
such as their parameters, interconnect requirements and operational
requirements such as needing inputs and outputs in different memory
banks, etc. Users of the compiler can add new library FPGA
configurations, all that is needed for the compiler to use them is the
proper meta information about the functions they contain.
The programming language was designed to hide as much of the
complexity of using the FPGAs as possible. For example, the FPGAs can
access several disjoint memories - DRAM configuration caches, SRAM
scratchpad and parameter memories, several banks of DRAM data memory.
The compiler understands these memories and allocates objects
appropriately. There are also constraints for allocation: all the
inputs to and outputs from a FPGA function need to come from different
banks in the data memory. The compiler allocates data objects to
minimize any copy movement that may be necessary (like register
spill/fill). The programming language is modular and the compiler
does compilation unit optimization of data object placement. A
program can involve multiple code modules, although currently "extern"
data objects have to be copied across module boundaries because the
compiler has no way of knowing statically in which memory bank they
are allocated.
Invoking a FPGA function involves filling in a parameter block,
loading in the configuration containing the function (if necessary)
and finally pointing the FPGA to the parameter block and starting it.
The hardware supports demand loading of configurations, but
reconfiguring is time consuming and the FPGA is idle until it
completes (actually newer FPGAs support partial reconfiguration while
running but the compiler doesn't yet support that). To minimize
wasted time, the compiler looks within the user's procedure for
mutually independent FPGA operations that use the same configuration
and reorders execution where possible to minimize the number of
reconfigurations required. The compiler allocates, deallocates and
fills in the FPGA parameter blocks automatically. The hardware
supports chained execution of multiple FPGA functions (with demand
reconfiguration as necessary) so the compiler tries to construct the
longest function chains with the fewest reconfigurations. DSP code
executes in parallel with the FPGAs and synchronization barriers are
inserted where needed to preserve sequential execution where program
objects need to change owners.
Where multiple FPGAs are used in the same user procedure, the compiler
tries to schedule sequences of dependent operation to switch FPGAs
whenever a reconfiguration is necessary so that the reconfiguration
happens in parallel with useful work.
The programming language has a number of constructs that expand into
quite complicated chains of operations, the whole point being to
assist the casual user in producing fast FPGA applications without
having to know too many low level details about the hardware. Experts,
of course, have a way to bypass the compiler's automagic handling of
program objects and FPGA functions and basically do whatever they
want.
I've only touched on a few highlights, but in no way is this thing a
toy.
Anyway, enough off-topic chat.
We now return to the regularly scheduled comp.lang.c++.moderated.
>Doing a C++ compiler is hard because C++ is big and complicated. Just
>doing a good parser (which the required embedded semantic analysis)
>would probably take years.
C++ is not alone in being complicated.
>Yes, given time and dedication, you could do anything; but if you
>haven't done it, you haven't acquired the experience of doing it.
>
>I don't think writing a book should be 9 though. Writing a book is not
>strictly dependent on skill on the subject, and even people such as
>Scott Meyers, Herb Sutter or Andrei Alexandrescu are not necessarily
>the biggest C++ gurus.
Yup ... anyone can write a book.
George
Alf P. Steinbach
> phli...@gmail.com (Phlip) wrote (abridged):
>> 9 - wrote a book with leading-edge techniques in it
>> 8 - published a used library with leading-edge techniques
>> (or wrote a generic tutorial with standard techniques in it)
>> 7 - have invented leading-edge techniques & blogged about them
>
> I don't think the difference between those has much to do with C++
> expertise. Non-experts can write books.
True, non-experts can write books, but they can't write /good/ books. Now, I
have only a very few C++ books, namely Andrei's "Modern C++ Design" and various
editions of Bjarne's "The C++ Programming Language" (1st and 2nd edition in
paperback, and 3rd edition in illegal downloaded PDF -- sorry Bjarne, but I did
buy it, but then it was stolen/not returned, and I don't buy it twice! <g>). And
having written various compendiums and a C++ tutorial (the only one referenced
from our FAQ), and having tried for years to write a C++ book for novices, I can
attest that writing a good C++ book is really, really hard, extremely hard.
One hurdle is of course just the C++ understanding. That isn't a problem for me
-- but there is a vast difference between, on the hand, describing current
knowledge and, on the other hand, inventing new techniques and combining old
techniques in novel, useful ways, as Andrei did. I could never have written
Andrei's MCCPD book; it's a masterpiece. And when I helped review Andrei's old
Mojo article, it was more like Andrei helping me than the other way, which is a
sign of an Expert: you may feel that you're talking as equals, but later you
discover that you learned a lot and some beliefs were adjusted. :-) Still,
although Andrei is indisputably a C++ expert and a Very Smart Guy, I have later
answered one or two of his questions here, so "expert" does not mean "know all":
I submit that a true expert is one who's not afraid to ask about stuff.
Another hurdle is the pedagogical, and I find that much much worse than the
technical, which is trivial in comparision. For ideally everything used should
already have been explained. Some forward references and unexplained cookbook
"for now, just do this..." are unavoidable in any programming introduction. But
with C++ it all hangs together in so many ways that it's a real nightmare. When
you get down to it and try to describe things exactly -- which is what I've
been trying to -- you discover that even the tiniest little piece of the
language connects with and depends on much everything else. And so our Holy
Standard is also that way. It's a spaghetti mess of cross-references. ;-)
I like this scale. Probably because I don't do badly on this scale. <g>
Another reason is that I consider you a person with good insight: before my
latest disk crash my "C++ documentation" folder contained, among other things,
one Usenet article by you.
Good insight may be more important than pure C++ expertise...
Cheers,
- Alf
Mathias Gaunard
> Mathias Gaunard wrote:
> > I don't think writing a book should be 9 though. Writing a book is not
> > strictly dependent on skill on the subject, and even people such as
> > Scott Meyers, Herb Sutter or Andrei Alexandrescu are not necessarily
> > the biggest C++ gurus.
> Seriously though, are you a friend to those people? What does
> "people such as" mean? Would having your own flag in G++
> be a better criterion than writing a book?
First, I said writing a book, even if that book is popular, is not a
guarantee of skill, which is fairly obvious: a lot of popular (and by
popular I mean they sell a lot) C++ books are quite bad.
Then, I made an extreme example: even being the author of one of the
most acclaimed C++ books is not guarantee for "ultimate" skill. As it
happens, they're all very good, but being the author of the most
acclaimed C++ book isn't what I'd consider the absolute grade (or the
next thing near to it) on the scale.
Well, Herb Sutter has been chairman (or something like that) of the C+
+ standards committee, and I suppose that would be the highest grade
you can make on such an artificial scale, but anyway, I hope you get
my point.
--
Balog Pal
"Dragan Milenkovic" <dra...@plusplus.rs>
> Mathias Gaunard wrote:
>> I don't think writing a book should be 9 though. Writing a book is not
>> strictly dependent on skill on the subject, and even people such as
>> Scott Meyers, Herb Sutter or Andrei Alexandrescu are not necessarily
>> the biggest C++ gurus.
>
> It's fine you did it to me in the previous post... But leave
> others alone, please! :-)
>
> Seriously though, are you a friend to those people? What does
> "people such as" mean? Would having your own flag in G++
> be a better criterion than writing a book?
AFAIK term 'guru' means like 'teaching master'. The listed beople, ang
anyione 'such as' are definitely C++ gurus, and top ones too.
Possibly Mathias used (or meant) sometginh other in 'guru', maybe someone
who wrote much code or made systems directly -- it is quite possible those
people did not concentrat so much effort in that field, but then so what?
The important thing is they
- know much to start with
- know areas they don't grok and seek answers, especially if it is needed to
some publication/book/course
- keep looking for new areas to cover
I agree that book writing is much different than just application of
skill/knowledge to solve problems. For a good result you need special
ability to shape the thoughts into short and clear phrases, spiced with
style to keep the readers attention. and it is enough if you know the
stuff under discussion -- what is out of scope /can/ be completely unknown.
Unlike for practice, where such narrowing does not work. But in practice
good writing on narrow subject is built on wide knowledge.
--
Martin T.
> phli...@gmail.com (Phlip) wrote (abridged):
>> 9 - wrote a book with leading-edge techniques in it
>> 8 - published a used library with leading-edge techniques
>> (or wrote a generic tutorial with standard techniques in it)
>> 7 - have invented leading-edge techniques & blogged about them
>
> A lot of emphasis on undefined behaviour. There's more to C++ than that.
>
>
> My own hierarchy would be more oriented around language features and
> techniques.
>
> 2-3 At the bottom end are people who mostly stick within the
> C/C++ subset, perhaps using new/delete and std::vector<>.
>
> 4-5 Next are the ones who know when to use references in their
> own code, and who can implement classes with virtual functions.
> They know the std collection classes quite well.
>
> 6-7 Next comes some facility writing their own templates. They
> can use std::algorithms, but may choose not to. They can use
> local classes and predicates and pointers to member functions.
> They may be considered experts by their colleagues. They may
> have some awareness of the dark corners of C++, in which case
> they are probably aware of how much they don't know.
>
> 8-9 Next comes the people who understand books like "Modern C++
>
> On that scale I'd probably put myself around 8. Most people who come to
> interview at my employers are below 4. If you ask them, "what is a
> reference and when would you use one?" they are floored.
>
That's also my experience.
Most people here are still below 4 after a few years of programming --
still, they do a decent job -- and I was way below 4 when I came out of
uni. (I hope I'm at 6 atm :-) )
> (...)
>> oskarmellow wrote:
>>> Ever since then, I find myself always trying to determine my skill
>>> level. And in the process of doing so, my self-assessed rating
>>> keeps getting lower and lower.
>
> That's what I had in mind at 6-7. You get to know enough that colleagues
> start coming to you with obscure compiler errors, and you can help them,
> so you think you are the local expert. And then you get exposed to the
> wider world, such as some of the debates in this newsgroup, and you
> realise how much you don't know.
>
An experience I also had from time to time :)
br,
Martin
Francis Glassborow
C++ Standard is is probably as near as you can get to the top. While
writing a book did not make any of those three one of the top C++ gurus,
the praise from other top C++ gurus means that it would be surprising if
they were not among that elite class.
Actually writing a book is hard work and getting it published is harder
still.
--
Note that robinton.demon.co.uk addresses are no longer valid.
Dragan Milenkovic
> On 19 juil, 21:48, Dragan Milenkovic <dra...@plusplus.rs> wrote:
>> Mathias Gaunard wrote:
>>> I don't think writing a book should be 9 though. Writing a book is not
>>> strictly dependent on skill on the subject, and even people such as
>>> Scott Meyers, Herb Sutter or Andrei Alexandrescu are not necessarily
>>> the biggest C++ gurus.
>
>> Seriously though, are you a friend to those people? What does
>> "people such as" mean? Would having your own flag in G++
>> be a better criterion than writing a book?
>
> First, I said writing a book, even if that book is popular, is not a
> guarantee of skill, which is fairly obvious: a lot of popular (and by
> popular I mean they sell a lot) C++ books are quite bad.
Exactly! It is obvious... Which is why I found it was a bad context
for referring to those people.
> Then, I made an extreme example: even being the author of one of the
> most acclaimed C++ books is not guarantee for "ultimate" skill. As it
> happens, they're all very good, but being the author of the most
> acclaimed C++ book isn't what I'd consider the absolute grade (or the
> next thing near to it) on the scale.
>
> Well, Herb Sutter has been chairman (or something like that) of the C+
> + standards committee, and I suppose that would be the highest grade
> you can make on such an artificial scale, but anyway, I hope you get
> my point.
I understood perfectly what you were saying. There was no error in
the logical part. However, I wouldn't hire you for a marketing campaign,
though. :-D IMHO, you should have rephrased it. What would one think
about the mentioned individuals if one was knew nothing about them?
Maybe it's just my poor understanding of the language, but I would
think: "they wrote books, but that doesn't make them experts... hm...
they seem to be some slackers... did they write learn C++ in 24 days?"
--
Dragan
DeMarcus
> On Jul 16, 3:45 pm, Phlip <phlip2...@gmail.com> wrote:
>> oskarmellow wrote:
>>> So, the big question... on a scale of 1 to 10, how would you rate
>>> your C++ skill level.
>>> 1 being - "what's C++?"
>>> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
>>> after dinner (on my iPhone)"
>> 9 - wrote a book with leading-edge techniques in it
>> 8 - published a used library with leading-edge techniques
>> (or wrote a generic tutorial with standard techniques in it)
>> 7 - have invented leading-edge techniques & blogged about them
>> 6 - have architected entire successful C++ applications
>> 5 - have unit-tested, maintained, and debugged C++ apps
>> 4 - know how to factually avoid undefined behavior
>> 3 - obey a sane subset so narrow most of my behavior is defined!
>> 2 - know how to debug C++ until it works
>> 1 - am allowed to look at C++ written by other teammates
>> 0 - I post "delete NULL" questions to the newsgroups!
>
>
> My rating is 3 after 3 years C++ programming.
> I feel bad because still cannot improved my programming skill. Need
> advice.
>
My advice is
1. To buy following books (no I don't get any profit)
The C++ Programming Language by Bjarne Stroustrup
Effective C++ by Scott Meyers
C++ Coding Standards by Sutter & Alexandrescu
(and continue check out interesting books in your
local bookstore)
2. Have a fun private project to fine tune. I hear
Google allow their employees play around one day
a week with own projects. Is it true? Sounds like
heaven.
3. Brute force. Don't stop until you're pleased with
your home brew application.
Tech07
"Jerry Coffin" <jerryv...@yahoo.com> wrote in message
news:MPG.24c808935...@news.sunsite.dk...
> In article <3e0827b0-822e-482a-aaad-d37aaa1a6ff4
> @m11g2000yqh.googlegroups.com>, oskar...@gmail.com says...
>>
>> I know this group is about technical C++ items, but I thought it might
>> be interesting (at least for me) to hear some thoughts on how you
>> would self-assess your C++ skill level.
>>
>> So, the big question... on a scale of 1 to 10, how would you rate
>> your C++ skill level.
>> 1 being - "what's C++?"
>> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
>> after dinner (on my iPhone)"
>
> possibly hope to come close to receiving it?
>
> That aside, I can see two entirely kinds of things to rate. One is a
> persons ability to apply the C++ language to solving problems. The
> other is knowing a great deal about the technical details of the
> language itself.
>
> loose. A person certainly needs to know the language reasonably well
> to apply it to solving problems, but "reasonably well" is a flexible
> measure, to put it mildly. To an even greater degree than many other
> languages, C++ has a lot of details that matter very little for most
> real practitioners.
>
> lead to writing code that depends on them -- to the point that few
> can understand the code, and fewer still can maintain it, sometimes
> including the original author.
I've recently been examining cfront code (2.0 is even worse than 1.0). It
seems like an example of what you describe directly above. Try to figure out
how to implement virtual functions from that spaghetti, e.g. !
>Worse, in some cases the code may
> depend on features that many compilers don't implement (at least
> correctly). Unless a _great_ deal is gained in return, this can have
> a cost that's (much) greater than any possible benefit.
--
Bo Persson
> "Jerry Coffin" <jerryv...@yahoo.com> wrote in message
> news:MPG.24c808935...@news.sunsite.dk...
>> In article <3e0827b0-822e-482a-aaad-d37aaa1a6ff4
>> @m11g2000yqh.googlegroups.com>, oskar...@gmail.com says...
>>>
>>> I know this group is about technical C++ items, but I thought it
>>> might be interesting (at least for me) to hear some thoughts on
>>> how you would self-assess your C++ skill level.
>>>
>>> So, the big question... on a scale of 1 to 10, how would you rate
>>> your C++ skill level.
>>> 1 being - "what's C++?"
>>> 10 being - "I wrote a C++ compiler fully supporting C++0x last
>>> night after dinner (on my iPhone)"
>>
>> What's the point of having a rating of 10, if nobody on earth can
>> possibly hope to come close to receiving it?
>>
>> That aside, I can see two entirely kinds of things to rate. One is
>> a persons ability to apply the C++ language to solving problems.
>> The other is knowing a great deal about the technical details of
>> the language itself.
>>
There is a really humorous side to this, in that some of the more well
known compiler gurus actually use C to implement their C++ compilers.
Perhaps they are really C experts?
Bo Persson
Brian Wood
> Tech07 wrote:
> > "Jerry Coffin" <jerryvcof...@yahoo.com> wrote in message
> >news:MPG.24c808935...@news.sunsite.dk...
> >> In article <3e0827b0-822e-482a-aaad-d37aaa1a6ff4
>
> >>> I know this group is about technical C++ items, but I thought it
> >>> might be interesting (at least for me) to hear some thoughts on
> >>> how you would self-assess your C++ skill level.
>
> >>> So, the big question... on a scale of 1 to 10, how would you rate
> >>> your C++ skill level.
> >>> 1 being - "what's C++?"
> >>> 10 being - "I wrote a C++ compiler fully supporting C++0x last
> >>> night after dinner (on my iPhone)"
>
> >> What's the point of having a rating of 10, if nobody on earth can
> >> possibly hope to come close to receiving it?
>
> >> That aside, I can see two entirely kinds of things to rate. One is
> >> a persons ability to apply the C++ language to solving problems.
> >> The other is knowing a great deal about the technical details of
> >> the language itself.
>
> There is a really humorous side to this, in that some of the more well
> known compiler gurus actually use C to implement their C++ compilers.
> Perhaps they are really C experts?
>
That's a good point. They don't seem to believe in the work
they've done enough to use it themselves. On the other hand,
I did hear of one developer who has recently given up on using
C and started using C++ instead to write a C++ compiler.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
Francis Glassborow
> Tech07 wrote:
>> "Jerry Coffin" <jerryv...@yahoo.com> wrote in message
>> news:MPG.24c808935...@news.sunsite.dk...
>>> In article <3e0827b0-822e-482a-aaad-d37aaa1a6ff4
>>> @m11g2000yqh.googlegroups.com>, oskar...@gmail.com says...
>>>> I know this group is about technical C++ items, but I thought it
>>>> might be interesting (at least for me) to hear some thoughts on
>>>> how you would self-assess your C++ skill level.
>>>>
>>>> So, the big question... on a scale of 1 to 10, how would you rate
>>>> your C++ skill level.
>>>> 1 being - "what's C++?"
>>>> 10 being - "I wrote a C++ compiler fully supporting C++0x last
>>>> night after dinner (on my iPhone)"
>>> What's the point of having a rating of 10, if nobody on earth can
>>> possibly hope to come close to receiving it?
>>>
>>> That aside, I can see two entirely kinds of things to rate. One is
>>> a persons ability to apply the C++ language to solving problems.
>>> The other is knowing a great deal about the technical details of
>>> the language itself.
>>>
>
> There is a really humorous side to this, in that some of the more well
> known compiler gurus actually use C to implement their C++ compilers.
> Perhaps they are really C experts?
Why is that humorous? First class programmers use the right tool for the
job, they have no time for language wars. Whilst I know several expert
level C programmers who know very little about C++, I cannot recall any
expert level C++ programmer who is not a competent C programmer as well.
Bo Persson
You didn't see that Tech07 believes that one qualifying ability for
guru-ness is to apply the C++ language to solving problems. Still some
that actually would qualify for a 10 score, "I wrote a C++ compiler",
probably do most of their work in C.
> First class programmers use the right tool
> for the job, they have no time for language wars.
Of course.
> Whilst I know
> several expert level C programmers who know very little about C++,
> I cannot recall any expert level C++ programmer who is not a
> competent C programmer as well.
This would lower my level a bit, if it was on the scale. I used to
write some C before C++ was available, but wouldn't call myself
competent anymore. :-)
Bo Persson
Brian Wood
> >>news:MPG.24c808935...@news.sunsite.dk...
> >>> In article <3e0827b0-822e-482a-aaad-d37aaa1a6ff4
> >>>> I know this group is about technical C++ items, but I thought it
> >>>> might be interesting (at least for me) to hear some thoughts on
> >>>> how you would self-assess your C++ skill level.
>
> >>>> So, the big question... on a scale of 1 to 10, how would you rate
> >>>> your C++ skill level.
> >>>> 1 being - "what's C++?"
> >>>> 10 being - "I wrote a C++ compiler fully supporting C++0x last
> >>>> night after dinner (on my iPhone)"
> >>> What's the point of having a rating of 10, if nobody on earth can
> >>> possibly hope to come close to receiving it?
>
> >>> That aside, I can see two entirely kinds of things to rate. One is
> >>> a persons ability to apply the C++ language to solving problems.
> >>> The other is knowing a great deal about the technical details of
> >>> the language itself.
>
> > There is a really humorous side to this, in that some of the more well
> > known compiler gurus actually use C to implement their C++ compilers.
> > Perhaps they are really C experts?
>
> Why is that humorous? First class programmers use the right tool for the
> job, they have no time for language wars. Whilst I know several expert
> level C programmers who know very little about C++, I cannot recall any
> expert level C++ programmer who is not a competent C programmer as well.
>
Are you saying C is the right tool for writing a C++ compiler?
In my opinion C++ is the better tool for writing a C++ compiler.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
Walter Bright
> There is a really humorous side to this, in that some of the more well
> known compiler gurus actually use C to implement their C++ compilers.
> Perhaps they are really C experts?
The Digital Mars C++ compiler was originally in C, but that was for
bootstrapping reasons, as it was the first native C++ compiler on DOS.
It's now in C++.
----
Walter Bright
Digital Mars
http://www.digitalmars.com
Free C, C++, D programming language compilers
Jerry Coffin
[ ... ]
> There is a really humorous side to this, in that some of the more
> well known compiler gurus actually use C to implement their C++
> compilers. Perhaps they are really C experts?
Perhaps. Some of this, however, is almost certainly for a rather
simpler reason. A fair number of C++ compilers have "grown" from
existing C compilers. Switching from C to C++ trades a short-term
loss for a long-term gain -- but that short-term loss is hard to
take, so it gets delayed, often (probably) permanently.
At least at one time, a fair number of compiler vendors had developed
tools for writing compilers, and applied the same tools to nearly
every language around. At one time one a fairly respected C++
compiler (maybe Metaware -- I don't remember for sure) was actually
written in PL/I (just like essentially all the other compilers from
the same vendor).
--
Later,
Jerry.
Walter Bright
> Walter Bright <newsh...@digitalmars.com> writes:
>> The Digital Mars C++ compiler was originally in C, but that was for
>> bootstrapping reasons, as it was the first native C++ compiler on DOS.
>> It's now in C++.
>
>
> - The C source code was changed just so much that it
> now can be compiled with a C++ compiler.
>
> Or:
>
> - It was rewritten in �idiomatic C++� using C++ I/O,
> C++ containers and algorithms, possibly boost,
> template metaprogramming, �export� and all that stuff
> whereever it is recommended by recommended C++ text
> books.
One thing about C++ (and D!) is you can write in a quite vast array of
very different programming styles. The Digital Mars compiler source code
isn't written in any paragon of C++ programming virtue, it shows its
ancestry of being once C, but it is in C++ and does use C++ features.
The newer layers in it tend to be more C++ than the older dinosaur brain
parts.
(The Digital Mars C++ source code is now available, so anyone can look
at it and decide for themselves. Don't blame me if it makes you blind
and bald :-) )
> The difference between these two possibilities should be
> larger than the difference between C and the first
> possibility (which is covered by
>
> http://david.tribble.com/text/cdiffs.htm
>
> ). In 2007, Linus Torvalds wrote:
>
> �[T]he only way to do good, efficient, and system-level
> and portable C++ ends up to limit yourself to all the
> things that are basically available in C.�
Remember that DMC++ started in 1985 or so, at the start of the great OOP
boom, predating much of what is considered modern idiomatic C++ style.
All production quality C++ compilers started at least 15 years ago, long
before Andrei's "Modern C++ Design", long before Boost, long before even
the STL. DMC++'s code base starts in 1982, it's the oldest production
C++ compiler I know of.
The D programming language front end code base is much newer, and makes
more extensive use of C++. It's not in D for bootstrapping reasons.
As for C++ I/O, meaning iostreams, I disliked it from the beginning.
Other than type safety, it's got nothing to recommend it:
1. Overloading << and >> is astonishingly unreadable. Throw templates
on top of it, and it's just a trainwreck.
2. It's slow.
3. Bloated code is generated.
4. It's not thread safe.
5. It's not exception safe.
Of course, it was developed before templates, exceptions, and any
support for threads, so the design is understandable, but that's not a
recommendation.
DMC++'s internal I/O is custom for performance reasons (and even used to
be in assembler).
Consider also that, as far as I know, I'm the only person to have
written a C++ compiler from preprocessor to object file output. Anyone
else writing one will be taking the pragmatic approach of using some
existing optimizer/back end, and so will have to deal with whatever
language that is written in (probably C).
Walter Bright
> Actually writing a book is hard work and getting it published is harder
> still.
And producing a programming book that has a shelf life of longer than a
few weeks is far harder still. Sutter, Meyers, and Alexandrescu have all
accomplished that.
--
Walter Bright
> Then I guess I'm at 9 or 10 - I haven't written a C++ compiler but I
> could if I had enough time.
If you've got a spare 10 years. Heck, EDG spent 3 man-years on just one
feature: exported templates.
There's a good reason why there are far fewer C++ compiler code bases
than C ones.
Then there's the optimizer and code generator and runtime ...
Walter Bright
> Are you saying C is the right tool for writing a C++ compiler?
> In my opinion C++ is the better tool for writing a C++ compiler.
There are many external reasons that can force the choice of a C++
compiler implementation language, but let's set that aside for the moment.
I've written compilers in Pascal, C, C++, and the D programming
language. I've looked at compilers written in Basic and Java. I'd rank
them as, from easiest implementation language to hardest:
D
C++
C
Java
Pascal
Basic
The latter two are such nightmares to get a compiler done, I'd rather
use assembler.
DeMarcus
> I know this group is about technical C++ items, but I thought it might
> be interesting (at least for me) to hear some thoughts on how you
> would self-assess your C++ skill level.
>
> So, the big question... on a scale of 1 to 10, how would you rate
> your C++ skill level.
> 1 being - "what's C++?"
> 10 being - "I wrote a C++ compiler fully supporting C++0x last night
> after dinner (on my iPhone)"
>
We must not forget other qualities than just construction. People able
to read code, analyze, understand and give comments/modify are quite
high ranked in my opinion. So everyone giving input on hard problems in
this newsgroup are pretty skilled in my opinion.
A one dimension scale can sometimes miss the true skill.
> As for my response:
> I think I first hit this question in an interview N number of years
> back, at which point I told the interviewer "I'd say like an 8 or 9
> (in my head i was saying 6)".
>
If I would get that question I would rather answer that I at least try
to help out in comp.lang.c++.moderated.
> Ever since then, I find myself always trying to determine my skill
> level.
> And in the process of doing so, my self-assessed rating keeps getting
> lower and lower.
>
This is an interesting and quite common behavior. The more you know the
more you realize how little you know, and most people usually become
more humble in their attitude to their skills.
Most pure professionals I've met are very humble and optimistic.
{ mod factoid (the mod humbly asks forgiveness for intruding, especially since
this is not a C++ but a psychology factoid): for the general effect see e.g.
<url: http://en.wikipedia.org/wiki/Dunning-Kruger_effect>; also, Charles Darwin
said, "ignorance more frequently begets confidence than does knowledge". -mod }