What makes a good C/C++ programmer?

[E. Robert Tisdale]

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.

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.

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.

[Mario Rosario]

Are you a rookie or an expert C++ programmer?

Laughing,
Mario

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:ct******** **@nntp1.jpl.na sa.gov...

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.

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.

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.

[shez]

E. Robert Tisdale wrote:

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.

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.

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.

Thanks for the tip.

-shez-

[David White]

"E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
news:ct******** **@nntp1.jpl.na sa.gov...

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.

Yes, at our place we don't place a lot of emphasis on C++ knowledge when
interviewing for a C++ programming position. We are more interested in an
aptitude for programming in general and an ability to solve problems. Such a
person is unlikely to have difficulty picking up C++.

DW

[Richard Tobin]

In article <ct**********@n ntp1.jpl.nasa.g ov>,
E. Robert Tisdale <E.************ **@jpl.nasa.gov > wrote:

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

[...]

Another rejection letter?

-- Richard

[E. Robert Tisdale]

Richard Tobin wrote:

E. Robert Tisdale wrote:

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

[...]

Another rejection letter?

I used to have a file folder labeled "DROP DEAD".
It got to be quite large before I went to work.
I kept them for some time before discarding them.
Now, I keep my [pay stubs] in that file folder.
Persistence pays. It is a much larger file now.

I have been programming for a long time
and I've been programming in C++
almost as long as Bjarne Stroustrup.
I never applied for a job as a programmer
and I never intended to learn as much as I know
about C++ or any other computer programming language.

[Gianni Mariani]

E. Robert Tisdale wrote:

What makes a good C/C++ programmer?
Knowledge of the language, algorithms, class design, math, logic and
experience.

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.
I doubt that.

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.

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.

That's not always possible.

What do you think of these questions ?

a) Write a template class that counts the number of set bits in a
constant and provides a constant for any integer type.

template <typename T, T val>
struct NumBitsSet
{
static const unsigned m_value = *****; //what goes where the ***** is?
};

b) Explain what is wrong with this code:

#include "at_thread. h" // Austria C++ thread interface
#include <iostream>

class A
: public at::Task
{
public:

A()
{
Start();
}
};

class B
: public A
{
virtual void Work()
{
std::cout << "Hello World\n";
}
};

int main()
{
B b;
}

c) Explain what is happening and wrong with the following code and how
you would resolve this.

#include "at_lifetim e.h" // Austria C++ smart pointer interface

struct M;

struct N
: at::PtrTarget_B asic
{
at::Ptr<M *> m;
};

struct M
: at::PtrTarget_B asic
{
void Do() {};
at::Ptr<N *> n;
};

at::Ptr<M *> F()
{
at::Ptr<M *> m=new M;
m->n = new N;
m->n->m = m;
return m;
}

int main()
{
F()->Do();
}

[Martin Ambuhl]

Mario Rosario wrote:

Are you a rookie or an expert C++ programmer?

ERT is comp.lang.c's most persistent troll. If he has as little
knowledge of C++ as he has of C, then he is quite experienced at writing
bad code.

[Alf P. Steinbach]

* Gianni Mariani:

What do you think of these questions ?

a) Write a template class that counts the number of set bits in a
constant and provides a constant for any integer type.

template <typename T, T val>
struct NumBitsSet
{
static const unsigned m_value = *****; //what goes where the ***** is?
};
Such templates are not very portable. A compiler may have a very strict
limit on recursive template instantion. Also, it's IME very seldom
a good idea to mix bit-level and high-level abstractions tools.

b) Explain what is wrong with this code:
From a technical point of view, that it does not #include the
header <ostream>, because operator<< is not defined by <iostream>.

#include "at_thread. h" // Austria C++ thread interface
#include <iostream>

class A
: public at::Task
{
public:

A()
{
Start();
}
};

class B
: public A
{
virtual void Work()
{
std::cout << "Hello World\n";
}
};
Presumably the interviewer wants the interviewee to answer "Gosh oh my,
that won't call B::Work", which would be introducing a number of
unwarranted assumptions. If that's the sought answer, then only by
demonstrating lack of clear thinking can the interviewee manage to give
an _impression_ of expertise. Ouch.
c) Explain what is happening and wrong with the following code and how
you would resolve this.

#include "at_lifetim e.h" // Austria C++ smart pointer interface

struct M;

struct N
: at::PtrTarget_B asic
{
at::Ptr<M *> m;
};

Is the purpose of the question to ascertain whether the interviewee
knows the "Austria C++ smart pointer interface"?

Without knowing that it's impossible to say what could be wrong.

If OTOH e.g. std::auto_ptr was used that way there would be a clear
problem, and a number of clear solutions such as boost::shared_p tr.

The main thing undeniably wrong with the above code is a design level
issue: that class N lacks a constructor and offers a public data member.

Fix that.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alan Krueger]

E. Robert Tisdale <E.************ **@jpl.nasa.gov > wrote:

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.
You can cross a minefield much more quickly if you don't know it's a
minefield.

I've had to track down enough errors introduced by developers who knew
just enough C/C++ (particularly the latter) to be dangerous that I don't
buy this.
What really helps is understanding the problem domain
and experience solving problems in that domain with computers.

This is like claiming the same for creating legal contracts. If you
don't know the details of proper legalese, you may not be writing what
you intend, even if you have domain knowledge.