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.

[Gianni Mariani]

Gary Labowitz wrote:

"Gianni Mariani" <gi*******@mariani.ws> wrote in message
news:kd********************@speakeasy.net...

Gary Labowitz wrote:

I'd love to see your "official" answers that are used to determine if

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

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41***********************@news.wanadoo.fr...

Efrat Regev wrote:

I think you missed my point. Possibly you might be interested in this link http://www.ahsd25.k12.il.us/BasicSki...html#KLiteracy

Instead of selecting Tisdale, I selected your reply.
Your message was just one below the intended recipient.

That's all.

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

E. Robert Tisdale wrote:

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]

Mabden wrote:

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.

--
Mike Smith

[Phlip]

E. Robert Tisdale wrote:

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

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Erik de Castro Lopo]

Gary Labowitz wrote:

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 no****@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"The X-files is too optimistic. The truth is not out there."
-- Anthony Ord

[Erik de Castro Lopo]

sushant wrote:

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 no****@mega-nerd.com (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]

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

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]

Gianni Mariani wrote:

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,

#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;
}

[Gianni Mariani]

Manuel Petit wrote:

Gianni Mariani wrote:

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.

But you need to know what C++ does with a virtual method and class
construction. Many C++ programmers (sadly) don't. I'm not sure I agree
that it's OT.

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

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

I agree. It's pretty basic.

BTW - there is another problem.

[Alf P. Steinbach]

* Manuel Petit:

* Gianni Mariani wrote:

b) Explain what is wrong with this code:
[snip]
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

For this design, yes. Ideally, in a better design, the most derived
constructor is where the thread should get started, because thread start
is a once-only action ~100% coupled to object construction. See below.

that is why your base clase
at::Task (correctly) provides a Start() method rather than spawning them
in the constructor.

Providing a function to be called once _after C++ construction_ is,
simply put, blotched design from a type-safety point of view.

In most situations where that is seemingly called for, FAQ 23.4, at
<url:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4>,
provides sound alternatives (might I immodestly mention that that FAQ
item resulted from an initiative by me to get that info into the FAQ,
just to make clear to Gianni that I understand those issues?).

This is, however, not a situation where 23.4 applies.

Instead, this is a situation where the client class code can not
completely specify the full C++ object construction, seemingly requiring
a "post-constructor-execution" language feature.

And one solution is then to provide a template class that typewise must
be used to create a _concrete class_ from any client code task class,
and that ideally does not, typewise, allow further derivation.

Example code, where I've omitted the "don't allow further derivation"
part (can be implemented by adding a virtual base class, overhead):
#include <iostream>
#include <ostream>

class AtTask
{
template< typename Task_ > friend class AtConcrete_;

private:
struct PrivateType {};
void virtual ensureAbstractClass( PrivateType& ) const = 0;

void start()
{
std::cout << "Starting..." << std::endl;
}
};

template< typename Task_ >
class AtConcrete_: public Task_
{
private:
void virtual ensureAbstractClass( AtTask::PrivateType& ) const {};
public:
AtConcrete_() { AtTask::start(); }
};

class A: public AtTask
{
};

int main()
{
AtConcrete_<A> obj;
}

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

[Gianni Mariani]

> #include <iostream>

#include <ostream>

class AtTask
{
template< typename Task_ > friend class AtConcrete_;

private:
struct PrivateType {};
void virtual ensureAbstractClass( PrivateType& ) const = 0;

void start()
{
std::cout << "Starting..." << std::endl;
}
public:
void wait()
{
}
};

template< typename Task_ >
class AtConcrete_: public Task_
{
private:
void virtual ensureAbstractClass( AtTask::PrivateType& ) const {};
public:
AtConcrete_() { AtTask::start(); }
~AtConcrete_() { AtTask::wait(); }

};

class A: public AtTask
{
};

int main()
{
AtConcrete_<A> obj;
}

I like the idea but.

This would make it hard to multiply inherit Task.

class ATask : public Task_
{
virtual void AWork() = 0;
};

class BTask : public Task_
{
virtual void BWork() = 0;
};

class DoubleTask : public ATask, public BTask
{
virtual void AWork() { .... doing A thing }
virtual void BWork() { .... doing B thing }
};

No way AtConcrete_ would work here.

Thread-pool objects have this pre-destructor behaviour as well. I have
not yet published the thread-pool implementation but there is a way to
use this technique of yours since all thread pool "events" in a class
are "registered" in a virtual base class.

BTW - I didn't get much feedback on the idea of adding a language
feature to do this automagically on comp.std.c++. I still would like to
see that happen.

[Alf P. Steinbach]

* Gianni Mariani:

#include <iostream>
#include <ostream>

class AtTask
{
template< typename Task_ > friend class AtConcrete_;

private:
struct PrivateType {};
void virtual ensureAbstractClass( PrivateType& ) const = 0;

void start()
{
std::cout << "Starting..." << std::endl;
}

public:
void wait()
{
}

};

template< typename Task_ >
class AtConcrete_: public Task_
{
private:
void virtual ensureAbstractClass( AtTask::PrivateType& ) const {};
public:
AtConcrete_() { AtTask::start(); }

~AtConcrete_() { AtTask::wait(); }

};

class A: public AtTask
{
};

int main()
{
AtConcrete_<A> obj;
}

I like the idea but.

This would make it hard to multiply inherit Task.

class ATask : public Task_
{
virtual void AWork() = 0;
};

class BTask : public Task_
{
virtual void BWork() = 0;
};

class DoubleTask : public ATask, public BTask
{
virtual void AWork() { .... doing A thing }
virtual void BWork() { .... doing B thing }
};

No way AtConcrete_ would work here.

As I remarked earlier (then wrt. what I am willing to state) blanket
statements have a nasty habit of turning out false.

All you have to do, if you Really Want this functionality, is to
register a task to be started in the AtTask constructor (and of course
de-register that task, if still registered, in the destructor). If on
the other hand you don't want that functionality then the above
Concrete_ template class would give a compile time error for multiple
inheritance of AtTask. So the choice is free: one can design a safe
interface for one or the other, or possibly make support for this or
that a policy, and that's the choice to make.

There might be more and better ways (there is a possible dynamic
allocation and synchronization overhead in registering), but the above
was my first millisecond-response idea. Uh, wait. The client can
possibly pass a type-list as template parameter to AtConcrete_... And
so on. Never say never! :-) I leave the details to you. Btw., yes, I
would be interested in your solution to the bitcounting template.

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

[Gianni Mariani]

Alf P. Steinbach wrote:

* Gianni Mariani:

#include <iostream>
#include <ostream>

class AtTask
{
template< typename Task_ > friend class AtConcrete_;

private:
struct PrivateType {};
void virtual ensureAbstractClass( PrivateType& ) const = 0;

void start()
{
std::cout << "Starting..." << std::endl;
}

public:
void wait()
{
}

};

template< typename Task_ >
class AtConcrete_: public Task_
{
private:
void virtual ensureAbstractClass( AtTask::PrivateType& ) const {};
public:
AtConcrete_() { AtTask::start(); }

~AtConcrete_() { AtTask::wait(); }

};

class A: public AtTask
{
};

int main()
{
AtConcrete_<A> obj;
}

I like the idea but.

This would make it hard to multiply inherit Task.

class ATask : public Task_
{
virtual void AWork() = 0;
};

class BTask : public Task_
{
virtual void BWork() = 0;
};

class DoubleTask : public ATask, public BTask
{
virtual void AWork() { .... doing A thing }
virtual void BWork() { .... doing B thing }
};

No way AtConcrete_ would work here.

As I remarked earlier (then wrt. what I am willing to state) blanket
statements have a nasty habit of turning out false.

All you have to do, if you Really Want this functionality, is to
register a task to be started in the AtTask constructor (and of course
de-register that task, if still registered, in the destructor). If on
the other hand you don't want that functionality then the above
Concrete_ template class would give a compile time error for multiple
inheritance of AtTask. So the choice is free: one can design a safe
interface for one or the other, or possibly make support for this or
that a policy, and that's the choice to make.

There might be more and better ways (there is a possible dynamic
allocation and synchronization overhead in registering), but the above
was my first millisecond-response idea. Uh, wait. The client can
possibly pass a type-list as template parameter to AtConcrete_... And
so on. Never say never! :-) I leave the details to you. Btw., yes, I
would be interested in your solution to the bitcounting template.

I implemented somthing similar to this for thread pool "events". I'm
trying to figure out the trade-offs in making threads (Task) more
complex. You can't save a lazy programmer all the time.

[Manuel Petit]

Gianni Mariani wrote:

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

I agree. It's pretty basic.

BTW - there is another problem.

Yeah, yeah, yeah... destruction, etc... in the same category as the
construction problem. Still off-topic if what you wanted is to test a
candidate C++ knowledge.
manuel,

[Gianni Mariani]

Manuel Petit wrote:

Gianni Mariani wrote:

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

I agree. It's pretty basic.

BTW - there is another problem.

Yeah, yeah, yeah... destruction, etc... in the same category as the
construction problem. Still off-topic if what you wanted is to test a
candidate C++ knowledge.

Then the whole thread is off-topic.... Even if it isn't OT, it's lame
and you and I are wasting our time.

[Keith Thompson]

"Joseph Turian" <tu****@gmail.com> writes:

ERT,

What makes a good C/C++ programmer?

Shouldn't we first discuss what makes someone a good human being,
before tackling more specific and complicated questions?

Yes, absolutely, because the question of what makes someone a good
human being is really what comp.lang.c++ and comp.lang.c are all
about. It's a pity that both newsgroups have such misleading names.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

In article <Bu*******************@newssvr13.news.prodigy.com> ,
"Mario Rosario" <re******@webacre.com> wrote:

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

Laughing,
Mario

You make the assumption that one starts as a rookie and progresses to be
an expert. Some people don't.

Some people have 20 years of experience. Others have 1 year of
experience 20 times.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Rufus V. Smith]

"Mike Wahler" <mk******@mkwahler.net> wrote in message
news:Vi*****************@newsread3.news.pas.earthl ink.net...

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.

Perfect, Mike! I will use that as a guideline when I'm tuning
my resume in my next job search!

It may be that many people hiring won't fully "get it" when
stated that way.

But the ones who "get it" are the ones I'd prefer to work for.

(Incidentally, the folks at my current job are ones who do "get it")

Rufus

This reminds me of the description of an engineer
(paraphrased)

An engineer is a person
who creates what he/she wants
from what he/she has.

or (I can't help myself)

God grant me
1) The pragmatism to acquire the tools that are available
2) The ability to create the tools that are not
3) The wisdom to know the difference

[Chris Croughton]

On Thu, 27 Jan 2005 10:52:39 -0500, Rufus V. Smith
<no****@nospam.com> wrote:

God grant me
1) The pragmatism to acquire the tools that are available
2) The ability to create the tools that are not
3) The wisdom to know the difference

Oh, that one is eminently quotable!

Chris C

[Jerry Coffin]

Mike Wahler wrote:

[ ... ]

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.

While I sympathize with this sentiment, I think it oversimplifies the
real situation a bit. There are lots of problems and lots of tools.
Different tools have differing levels of applicability to those
problems. While it's certainly true that a good programmer will avoid
using a tool that's particularly ill-suited to a given problem, it
isn't necessarily true that he'll always choose fairly/equally among
the available tools.

First of all, spending weeks learning a new tool because it _might_ be
5% better for some small/rare job may make little sense unless he's
reasonably certain he'll be able to apply that tool to a lot of jobs.

Second, he should look not only at the task at hand, but what it may
grow into -- it can often make a great deal of sense to start with a
tool that borders on overkill, rather than one that's highly effective
as it stands right now but won't scale well over time.

Finally, a programmer may have enough greater proficiency with one tool
than another that it's perfectly reasonable for him to describe himself
as a user of that tool, even if he's perfectly open to using others
when they work well.

As an obvious example I'm pretty sure I've described myself as "a C++
programmer". I've certainly written a lot of code in a lot of other
languages, and have no problem with using other tools when they appear
well-suited to the task at hand. Nonetheless, my proficiency with C++
is such that my tendency is to use it unless some other tool appears
_substantially_ better for the task at hand. At least in my case, this
seems to be somewhat justified -- I'd guess that around half the time I
start trying to do something in some other language, I end up doign it
in C++ before I'm done.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Chris Croughton]

On 27 Jan 2005 13:13:49 -0800, Jerry Coffin
<jc*****@taeus.com> wrote:

First of all, spending weeks learning a new tool because it _might_ be
5% better for some small/rare job may make little sense unless he's
reasonably certain he'll be able to apply that tool to a lot of jobs.
And apply it well, not just as a "Swiss Army Knife" (Leatherman?) used
because it's the one which does everything. And in many cases one which
other people can pick up and use/modify/fix (Perl, for instance, it
fairly easy to write but every Perl writer I know is familiar with a
different subset of the language, often making it difficuly for a
maintainer to pick up).
Second, he should look not only at the task at hand, but what it may
grow into -- it can often make a great deal of sense to start with a
tool that borders on overkill, rather than one that's highly effective
as it stands right now but won't scale well over time.
Heh. It was said of me when I was at university that if I wanted to
know the square root of 2 I would start by writing a program that
calculated the roots of nth order complex polynomials. It wasn't quite
true, I probably wouldn't have bothered with complex coefficients (but
would probably have left 'hooks' so that they could be added if
wanted)...
Finally, a programmer may have enough greater proficiency with one tool
than another that it's perfectly reasonable for him to describe himself
as a user of that tool, even if he's perfectly open to using others
when they work well.
Yup. I use awk, sed and grep by preference for shell programming, but I
can also use other languages where it makes sense (and other shells on
other OSs).
As an obvious example I'm pretty sure I've described myself as "a C++
programmer". I've certainly written a lot of code in a lot of other
languages, and have no problem with using other tools when they appear
well-suited to the task at hand. Nonetheless, my proficiency with C++
is such that my tendency is to use it unless some other tool appears
_substantially_ better for the task at hand. At least in my case, this
seems to be somewhat justified -- I'd guess that around half the time I
start trying to do something in some other language, I end up doign it
in C++ before I'm done.

As far as most job agencies I've used are concerned (I was a contractor
for 12+ years, and may be again) they like descriptions like "C
programmer" or for that matter "C/C++ programmer" (or "C++/C" if the C++
skills are greater), they can see at a glance that the person has C and
C++ experience (or C/Fortran, Ada/Pascal/Cobol or other combinations).
They will look at the detailed experience description later, but they
make the initial cut on the description. Yes, they are often
non-technical and will tend to assume that knowledge of C implies
knowledge of C++ (and "What's the difference between C and Fortran?"),
but then they also treat all databases as equivalent, it has nothing to
do with the notation (many non-computer-literate people will also assume
that "you know computers, can you fix my Windoze machine?" without
realising that there is any difference between a PC with WinXP and a VAX
running OpenVMS and that experience with one does not imply familiarity
wth the other).

Chris C