What makes a good C/C++ programmer?

[Gianni Mariani]

dropping comp.lang.c ...

* Gianni Mariani:



Worked fine with Visual C++ 7.1, at highest warning level. 2 Anyway, as I
stated, _don't do that_. Templates were not made for arithmetic, much
less bitcounting.

Which version of MSVC are you using ?

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86

Are you saying it should not work ? Please explain. Templates *are*
made for arithmetic, it says so in the standard. Also, if your code did
work, try finding the number of set bits in int(-2).

Generally, C++ compilers today are much better at conforming to
standards than they were a year ago. There is a conforming solution to
this problem that is accepted by all the `recent' compilers.

I do not accept the label 'candidate', nor that the insinuation that I'm
not rigorous.

That's nice. This is a hypothetical situation that you decided to
engage in an attempt to answer your question. Re-read the response in
that light and you'll see there is no insinuation or understanding of
candidacy.

I don't, however, do a long research project to get something portable
for a usenet posting where I'm warning you that it's not likely to be
portable -- what the &/()=? would be the point of that?

Are you saying there is no portable answer ?

Get a grip.

You should try it some-time.

That's _not_ MSVC 2003 (aka 7.1); not very rigorous of you...

What's not MSVC 2003 ? The outside of the box it came in says "Visual
Studio Professional Version 2003".

[umpteen lines of compiler error message]

That's one reason why it's not a good idea, yes.

This NG is about the C++ standard. If you think there is no "standard"
answer then I'd like to know about why you think so. Otherwise you're
just pontificating and I'm not one for tolerating "religion".

....


That's impossible to know in detail without knowing at::Task, but
in general terms, at::Task::~Task is executed, and 'main' returns.

Do you mean that what's "wrong" is somehow buried in at::Task::~Task,
which isn't defined in the question?

That's an interview I'd walk out of very very quickly.

That would be a good thing for you to do.

If you care to know, which I suspect more than likely you don't, the
problem here has more to do with what happends before ~Task is called.

The generated constructor is not OK: it doesn't take arguments to set
up the state of the object.

There is no state to set up the object.

Exposing public data members is something only the worst programmers do.

How do you know this is exposed ? This may be deep inside an
implementation. Oh - wait a minute, is this pontification again - yep,
I said it before, Religion !

If you're interested in getting better than the very worst, don't show
that code in interviews -- or include the wrongness in your "answer".

As I said, this is a pre-interview questionaire. How do you know my
answers are wrong since you don't have them yet ?

 

[Thomas Matthews]

What makes a good C/C++ programmer?

Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?
There isn't much difference in productivity, for example,
between a C/C++ programmers with a few weeks of experience
and a C/C++ programmer with years of experience.

Actually, this is a misconception. A person with a lot of
knowledge and experience with the language can be far more
productive than one who has less.

Look at a big company. What part of the project are intern's
programming? Junior programmers? Senior programmers?
Who are the designers?

You don't really need to understand the subtle details
or use the obscure features of either language
to write useful programs in your application domain.
Expert C and C++ programmers
are only marginally more effective than rookies.
What really helps is understanding the problem domain
and experience solving problems in that domain with computers.

I've produced more efficient (in both time and space) code
than programer's that are my juniors. Knowing the subtleties
of the languages helps me write more robust code. Know what
not to put into the project is as important as knowing what
to put in.

I've often had to correct mistakes of other programmers because
they didn't have a deep understanding of the language. I've
saved companies much development costs by knowing about
portability issues (which I've learned from these newsgroups).

So what should employers look for when hiring C/C++ programmers?
Well, it probably doesn't help to ask them questions
about syntax errors that compiler diagnostics would catch.
Nor would it help to query them about subtle details
or obscure features. The best thing to do is to ask them
for examples of programs that they have written
or to write a simple program for your application domain.

An employer wants somebody who can fullfill their requirements.
They would appreciate somebody who can go beyond the company's
expectations.

Companies do not hire people who only know the languages.
Companies want programmers who can apply the language to the
companies needs. For example, somebody who has experience
programming database applications will have a very low
chance of getting a job programming an embedded processor
on a medical or avionic device. At this time in the U.S.,
companies are asking for all of their requirements be
fulfilled. If you only have 95% of the requirements, they
will wait. Very few companies can afford the extra time
to train a new employee in areas other than company
policy or environment.

--
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

 

[Gary Labowitz]

Actually, this is a misconception. A person with a lot of
knowledge and experience with the language can be far more
productive than one who has less.

Look at a big company. What part of the project are intern's
programming? Junior programmers? Senior programmers?
Who are the designers?

Experience usually means something, but it is possible it doesn't. We had an
academic (taught at Rutgers) who was very good. Always learning and very
precise. He met a project manager with 10 years experience who just kept
making the same mistakes over and over. He said of the manager, "He has one
year of experience, ten times." I'm afraid that's a very common case. Unless
a person is constantly learning, he is liable to just do the same
sloppy/inexact/poor/wrong design and code over and over. This is why
licenses expire and have to be recertified.

 

[Alf P. Steinbach]

* Gianni Mariani:

dropping comp.lang.c ...


Which version of MSVC are you using ?

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86

Yep, that exact one.

Are you saying it should not work ? Please explain.

I wrote <q>The following "works"</q>, with quotes, meaning it was an
example of what I wrote earlier, that that kind of stuff is generally
not portable.

The code I gave compiles fine with MSVC 7.1 (exact same build as yours),
and yields correct answers.

But AFAIK it's not standard-conforming, due to the explicit
specialization _within_ a class.

Templates *are*
made for arithmetic, it says so in the standard. Also, if your code did
work, try finding the number of set bits in int(-2).

If you try the code shown earlier you'll find that it simply doesn't
compile when used with a negative number.

Generally, C++ compilers today are much better at conforming to
standards than they were a year ago. There is a conforming solution to
this problem that is accepted by all the `recent' compilers.

Really? I think that's interesting and hope you can present it here.
Just to see I tried templatizing on a type that represents the number,
but didn't get the specialization (at namespace scope) to work...

Please post that code.

That's nice. This is a hypothetical situation that you decided to
engage in an attempt to answer your question. Re-read the response in
that light and you'll see there is no insinuation or understanding of
candidacy.


Are you saying there is no portable answer ?

No: such blanket statements have a nasty tendendency to turn out false.

But in practice advanced template tricks are seldom portable (not to
mention maintainability), whether or not they're standard-conforming.

IOW., best avoided, unless there is a Really Good Reason.

[umpteen lines of compiler error message]

That's one reason why it's not a good idea, yes.

This NG is about the C++ standard. If you think there is no "standard"
answer then I'd like to know about why you think so. Otherwise you're
just pontificating and I'm not one for tolerating "religion".

If you put forward the template-based solution you're thinking of, then
we can compare the complexity and practical portability, with respect to
e.g. a macro-based solution (or function, if compile-time isn't needed).

That would be a good thing for you to do.

If you care to know, which I suspect more than likely you don't, the
problem here has more to do with what happends before ~Task is called.

Nothing _can_ happen after B's construction in standard C++, except
destruction of the object and return from 'main', because there's no
code specified after the declaration of the B object.

If the class inherited from starts a thread that, say, invokes UB, well
that's something outside the scope of the given information.

You might then as well ask for what's wrong with 'foo();', when 'foo' is
some function that I leave undefined until you've answered.

There is no state to set up the object.

No state implies no data members, which is not the case.

 

[Gianni Mariani]

This is a tricky point. In that case, the fair way of asking the question is
"How would you research the following problem:" followed by the problem.

There is no possible way that an accomplished C++ developer has not done
research in various unfamiliar APIs. Underlying problems b) and c) are
fundamental computer science issues. Nothing peculiar to the API. In
the normal course of work, being able to research unfamiliar API's
independantly is a critical part of "problem solving". It's not so much
about knowing everything rather than being able to find what you need
to know quickly. Someone that does not attempt to perform the research
given the questions, is not a very interesting cadidate.

To ask a question (A) to determine an answer (B) which is "derived" from the
process is not only unfair, but can't be validated. Suppose the interviewee
answers the question. Did he research it? Did he research it "properly."
What is it you really want to know?

I want to know wether the candidate can a) problem-solve, b)
read/understand c++, c) that they have an underlying knowledge of
computer science principles and how they apply to b), d) they're
enthusiastic and motivated about programming and C++ and e) they present
a cordial and positive demeanour.

We will let it slide that these kinds of problem situations are exactly what
comes up all the time in the normal course of work (which I doubt, but it
could be) or a person not selected for interview who finds later that your
workers typically work on programs without such problems has a cause to
complain --- and could do so legally. These look like headaches waiting to
happen.

I seem to come up to these issues all the time. The problem in c) is
fundamental with the style of life-time management involved. Violate
these rules (related to the problem) and you create nasty buggy code.
There is no easy way to get around it other than being a diligent and
motivated developer. The alternatives have significant issues as well.
b) combines issues with C++ object lifetime and thread race conditions
which are again fundamental issues if you deal with multi-threading.

I'd love to see your "official" answers that are used to determine if the
interviewee gave a right or reasonable answer to them, which you could show
the court to prove that you actually had an "answer" that a reasonable man
would understand. I'm sure I would flunk this test, so I would like to see
the answers in order to learn something more about C/C++ programming (I
think these are just C++, however).

I'd first like to know in more detail what you think the answers are and
take a few minutes to do some research as if you were on the job
reviewing my (bad) code. Otherwise, the first issue is (as a
hypothetical cadidate), you resist problem solving.

BTW - Alf did post an answer (which I can't verify works because all
compilers I tried rejected that code). He's very close though and I
would probably consider that someone who gave that answer can
read/understand C++ but I suspect lost points on "cordial and positive" .

 

[Gianni Mariani]

* Gianni Mariani:

Yep, that exact one.

Add this to the code you posted...

#include <iostream>
#include <ostream>

int main()
{
std::cout << BitsSetIn_< int, -2 >:: value << "\n";
}

I wrote <q>The following "works"</q>, with quotes, meaning it was an
example of what I wrote earlier, that that kind of stuff is generally
not portable.

The code I gave compiles fine with MSVC 7.1 (exact same build as yours),
and yields correct answers.

crashes and burns for me... OK OK - it works for positive numbers on
MSVC. But how would you fix it so that it worked for negative numbers
as well?

But AFAIK it's not standard-conforming, due to the explicit
specialization _within_ a class.

This has nothing to do with template arithmetic though.

If you try the code shown earlier you'll find that it simply doesn't
compile when used with a negative number.

That's got nothing to do with template arithmetic, there is a logic
issue that would manifest itself in non-template code.

Really? I think that's interesting and hope you can present it here.
Just to see I tried templatizing on a type that represents the number,
but didn't get the specialization (at namespace scope) to work...

Please post that code.

I'd rather just send it to you personally if you promise to keep it to
youself until someone else comes up with a better or equal answer.

No: such blanket statements have a nasty tendendency to turn out false.

But in practice advanced template tricks are seldom portable (not to
mention maintainability), whether or not they're standard-conforming.

IOW., best avoided, unless there is a Really Good Reason.

Yes. But unless some of us try to push the edge, compilers won't get
better. Some of these "tricks" can be very useful. In this particular
case, I would suspect that using the conforming solution is quite
acceptable.

If you put forward the template-based solution you're thinking of, then
we can compare the complexity and practical portability, with respect to
e.g. a macro-based solution (or function, if compile-time isn't needed).

OK - if you agree to keep it private until someone else independantly
comes up with an equal or better answer.

....


Nothing _can_ happen after B's construction in standard C++, except
destruction of the object and return from 'main', because there's no
code specified after the declaration of the B object.
Good.


If the class inherited from starts a thread that, say, invokes UB, well
that's something outside the scope of the given information.

Why do you think so ? If you were to try the code, it would likely be
obvious.

You might then as well ask for what's wrong with 'foo();', when 'foo' is
some function that I leave undefined until you've answered.

The code is completly defined, unlike your foo() method.

....

No state implies no data members, which is not the case.

Ah - religion again. I must be a pretty crappy developer then

Dogmas like this one are likely more a waste of time if followed
blindly. If I recall, the reason for these "must have constructor" or
"must have accessor methods" rules are to enhance encapsulation. This
is not allways important (IMHO). Especially when the code is
"implementation" and is not part of an interface.

 

[Gianni Mariani]

Did that code compile with an ISO Standard C compiler? If not then it
was probably C++ but definitely not C.

Just barely !

 

[Guillaume]

Would you be surprised if I told you that

it has almost nothing to do with your knowledge of C or C++?
There isn't much difference in productivity, for example,
between a C/C++ programmers with a few weeks of experience
and a C/C++ programmer with years of experience.

This is kind of crap, here.

A programming language is just a tool: no doubt about that.

But like any tool, it requires training and experience to use
it efficiently, or to use it at all and get usable results.

If you have never seen the difference, it's actually kind of sad.
But you don't even say if you mean a "seasoned programmer" that
is new to C, or simply a new programmer. Big difference here too.

Last but not least, your way of writing "C/C++" shows that you
just love trolling. This is exactly the best way of irritating
people on a C newsgroup. "C/C++" doesn't mean anything, and if
you're irritated with silly job interview questions, that one
would be the icing on the cake.

You're right in claiming (if that ever was what you meant) that
engineering is a state of mind, methods, and not bound to some
particular tools. That being said, I would never call someone
that is new to C a "good C programmer". I might call them a
"good engineer". Just because I've learnt music in a music school
doesn't mean that I can take a trumpet and be good at it in a few
weeks.

 

[Gary Labowitz]

Gary Labowitz wrote:

I'd first like to know in more detail what you think the answers are and
take a few minutes to do some research as if you were on the job
reviewing my (bad) code. Otherwise, the first issue is (as a
hypothetical cadidate), you resist problem solving.

BTW - Alf did post an answer (which I can't verify works because all
compilers I tried rejected that code). He's very close though and I
would probably consider that someone who gave that answer can
read/understand C++ but I suspect lost points on "cordial and positive"

.

Well, this do beat all!! You asked a couple of questions. You say they can
be used to evaluate a candidate to see if they know C++. Now you say it's to
find out if they know C++, can research things they do not know, are cordial
and positive, and who knows what else. First, I think you are using an
interview quiz to do too much. Second, I don't know what you want and don't
understand the questions. I'm here to learn. I would think that your answers
would show me what the C++ issues were and what was wrong about the
questions posed and what is corrent in the answers. Then I could learn. I
hope I'm asking for this in a cordial and positive way.

Fortunately, I only teach basic C++ to get people started in programming. I
still feel I should know as much as possible, so I'm open to learning all
kinds of things that I won't have to teach. My quizes test my students on
specific topics. I don't think it makes sense to say I'm checking if they
know "A" but am really seeing if they know "B." This may work for the CIA,
or something, but I'm only testing for specific knowledge. I realize that
when hiring (and I've done it) you would like to know if the candidate can
do "everything" but reality says that they should be able to do the work you
are hiring them for, more or less. If more, good. If less, you need to do
some training. It's difficult to decide if a person who is trying to get a
job is all they say they are. Thus the questions. But if you want to test
their demeanor, you are better served with a psychological test that has
been verified as determinative.

Anyway, I was hoping you had some answer that would show me what would be
correct answers to your questions. Forget it.

 

[Andrew Koenig]

"C/C++" doesn't mean anything, and if you're irritated with silly job
interview questions, that one
would be the icing on the cake.

"C/C++" seems to be used often to refer to C programs compiled on C++
compilers, with the small changes needed to make the programs compile.

 

[Gianni Mariani]

....

Anyway, I was hoping you had some answer that would show me what would be
correct answers to your questions. Forget it.

The first answer is - how well do you problem solve.

Apparently you like to argue more than research.

Forgotten...

 

[Efrat Regev]

My sincere apologies - I got carried away.

Incidentally, I thought your lcc-win32 was great - please let me thank you
for it at this point. (Your name sounded familiar...)

 

[Thomas J. Gritzan]

The following "works":

template< typename T, T value_ >
class BitsSetIn_
{
private:
template< T n_ >
struct BitsSetInAux_
{
static T const value =
(n_ % 2) + BitsSetInAux_<n_ >> 1>::value;

[...]

This code won't work with negative numbers since "operator >>" fills the
number with bits equal to the MSB.

This code is similar, but works with negative numbers and compiles on MSVC
2003. I tested it on gcc but it did not compile.

I tried to avoid nested templates by partial template specialisation, but
MSVC didn't get it that way...

template <typename T, T val, T comp = 1>
class NumBitsSet
{
template <T comp>
struct BitsSet
{
static const unsigned m_value = (val & comp?1:0) + BitsSet<comp <<
1>::m_value;
};

template <>
struct BitsSet<0>
{
static const unsigned m_value = 0;
};

public:
static const unsigned m_value = BitsSet<1>::m_value;
};

Thomas

 

[Julie]

What makes a good C/C++ programmer?

Not sinning?

So what should employers look for when hiring C/C++ programmers?

Who hires C/C++ programmers?

They should be looking to hire programmers that are proficient in first, the
subject matter in which they will be focusing, second, proficient with the
framework(s) and 3rd party libraries that they will be using, and third,
proficient in the language(s) that are primarily used.

 

[Mike Smith]

Everyone assumes that one starts as a rookie and progresses to be an
expert.

... I assume.

Are you sure that *everyone* progresses to be an expert? I certainly
wouldn't be so sure.

 

[Phlip]

What makes a good C/C++ programmer?

Fingertip mastery of lots of other language.

(And a healthy "sane subset" of the C languages, to avoid all the common
mistakes.)

 

[Erik de Castro Lopo]

This is correct, but look at the ads. The HR department writer of ads often
doesn't know what the difference is and may reject a resume that only says
C++.

Mine says :

Langugaes : C, C++, Python, Java, O'caml

Fice distinct lanugages.

HR weeds out applicants and those that are technically correct may
never reach the stage of being called in for an interview.
The only good way of getting interviews is to know someone in the company
and getting an interview through networking, without going through HR.
My resume says "C/C++" and I have to say I know very little C. I think I
could pick it up if needed, but I never worked in it.

Then maybe your resume *should* say C++ and not "C/C++" and not "C, C++".

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo (e-mail address removed) (Yes it's valid)
+-----------------------------------------------------------+
"The X-files is too optimistic. The truth is not out there."
-- Anthony Ord

 

[Erik de Castro Lopo]

this piece of information is fabulous....................

If you think that was valuable, I'll sell you the world famous Sydney
Opera House for $1000.

Tisdale, is well known as a troll in comp.lang.c. His posts are usually
wrong and always useless.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo (e-mail address removed) (Yes it's valid)
+-----------------------------------------------------------+
"Having a firewall that allows NFS to the Internet is like having a
seat belt that lets your head touch the dashboard." -- Marcus Ranum

 

[Mike Wahler]

What makes a good C/C++ programmer?

A good programmer is one who does not describe himself
as "[insert name of language or tool here] programmer",
but one who knows how to solve problems effectively, using
available tools. One who knows how to learn to use those
tools which are new to him. One who knows to look for
existing solutions (or components of them) before attempting
to recreate them yet again.

Would you be surprised if I told you that

I've long ago stopped being surprised at what you
write in the language newsgroups.

-Mike

 

[Manuel Petit]

b) Explain what is wrong with this code:

There are a couple of things wrong with that code, first is off topic
since you were testing the candidate knowledge of C++ not his
understanding of threading and your pet library. Second auto-starting
the thread in A's constructor prevents further derivation as the thread
will start running with a not fully constructed object. Thread start up
must be always done after construction, that is why your base clase
at::Task (correctly) provides a Start() method rather than spawning them
in the constructor.

But as I said, for testing C++ knowledge is off topic. And as threading
question, pretty basic.

manuel,