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.nasa.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.nasa.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**********@nntp1.jpl.nasa.gov>,
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_lifetime.h" // Austria C++ smart pointer interface

struct M;

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

struct M
: at::PtrTarget_Basic
{
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_lifetime.h" // Austria C++ smart pointer interface

struct M;

struct N
: at::PtrTarget_Basic
{
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_ptr.

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.

[Erik de Castro Lopo]

"E. Robert Tisdale" wrote:

What makes a good C/C++ programmer?
There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.
Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?

Well it wouldn't be the first time you have been wrong.

Anybody who employs a person with poor or non-existant knowledge
of the programming language they will be using has to teach them
that language before they can start anything else.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo no****@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"There are only two things wrong with C++: The initial concept and
the implementation." -- Bertrand Meyer

[E. Robert Tisdale]

Gianni Mariani wrote:

[snip]

What do you think of these questions?
[snip]
b) Explain what is wrong with this code:

austria-0.8/job> cat main.cc
#include <iostream>
#include "at_lifetime.h" // Austria C++ smart pointer interface

struct M; // foraward declaration

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

struct M: at::PtrTarget_Basic {
at::Ptr<N*> n;
void Do(void) { std::clog << "M::Do(void)" << std::endl; }
};

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

int main(int argc, char* argv[]) {
F()->Do();
return 0;
}
After removing superfluous semicolons after namespace definitions,

austria-0.8/job> g++ -Wall -Wno-long-long -ansi -pedantic \
-I../src/austria/code -L../src/austria/code/work.gx86 \
-o main main.cc -laustria
austria-0.8/job> ./main
M::Do(void)

it compiles and runs without complaint.
You need to explain an "Austria C++ smart pointer".
An astute candidate would *not* assume that it has the usual meaning.
But, if it has the usual meaning
and the candidate is familiar with smart pointers,
then you should expect the candidate to spot the error immediately.

I would say this *is* a good question
because the programmer cannot depend upon the compiler or testing
to reveal the bug. Of course,
we would expect that this bug would manifest itself eventually.

Evidently, smart pointers are important to you
and you should make sure that your programmers understand them.
But smart pointers are *not* a difficult concept to grasp
so any deficiency in understanding them is easily corrected
and I don't think that this question would do very much
to help you decide which candidate is the better C++ programmer.

[E. Robert Tisdale]

Alan Krueger wrote:

E. Robert Tisdale 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.

Besides a lot of very expert professional programmers,
we also have a lot of scientists and engineers
who know just enough about Fortran, C or C++ to be really dangerous.
They write their own codes because it's easier and cheaper
than training a professional programmer in the application domain
and having the professionals write these codes.
I don't know how you end up
tracking down errors introduced by "developers".
It seems to me that they should be tracking down their own errors.
Why do you feel compelled to contribute to their code development.

I don't mind helping and advising other programmers.
But I wish they would come to me sooner rather than later.

[David White]

"Erik de Castro Lopo" <no****@mega-nerd.com> wrote in message
news:41***************@mega-nerd.com...

"E. Robert Tisdale" wrote:

What makes a good C/C++ programmer?

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

Yes, a CV that gives the applicant's C/C++ experience always looks
suspicious. It's as though the applicant believes that they are
interchangeable languages or that C experience can be passed off as C++.
They should always be treated separately.

Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?

Well it wouldn't be the first time you have been wrong.

Anybody who employs a person with poor or non-existant knowledge
of the programming language they will be using has to teach them
that language before they can start anything else.

Yes, but talented people don't need long to learn it. IMO, someone who's
memorized every nuance of C++ but can't solve the kinds of problems they'll
need to solve isn't going to be as productive after a few weeks as someone
who knows no C++ but is obviously a talented programmer.

DW

[Todd Shillam]

You can be a very knowledgeable programmer; however, without imagination I
don't think any programmer can truly be successful.

A good programmer can leverage their knowledge with their creative ability
(imagination if you prefer). Thus, a good programmer has the ability to
foresee how their knowledge can manifest into various actions in a given
environment to resolve problems or make productive change.

Just my two cents,

Todd

"David White" <[e-mail]> wrote in message
news:L_*****************@nasal.pacific.net.au...

"Erik de Castro Lopo" <no****@mega-nerd.com> wrote in message
news:41***************@mega-nerd.com...

"E. Robert Tisdale" wrote:

>
> What makes a good C/C++ programmer?

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

Yes, a CV that gives the applicant's C/C++ experience always looks
suspicious. It's as though the applicant believes that they are
interchangeable languages or that C experience can be passed off as C++.
They should always be treated separately.

> Would you be surprised if I told you that
> it has almost nothing to do with your knowledge of C or C++?

Well it wouldn't be the first time you have been wrong.

Anybody who employs a person with poor or non-existant knowledge
of the programming language they will be using has to teach them
that language before they can start anything else.

Yes, but talented people don't need long to learn it. IMO, someone who's
memorized every nuance of C++ but can't solve the kinds of problems
they'll
need to solve isn't going to be as productive after a few weeks as someone
who knows no C++ but is obviously a talented programmer.

DW

[E. Robert Tisdale]

Erik de Castro Lopo wrote:

Anybody who employs a person with poor or non-existant knowledge
of the programming language they will be using
[must] teach them that language
before they can start anything else.

So employers should select a candidate who is a "quick study?

[David Hilsee]

"Erik de Castro Lopo" <no****@mega-nerd.com> wrote in message
news:41***************@mega-nerd.com...

"E. Robert Tisdale" wrote:

What makes a good C/C++ programmer?

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

The "/" is typically read as "or." Tisdale was simply commenting on both C
and C++ simultaneously, and that was obvious when you consider the rest of
his post. The "no such language" attack is getting a bit old, so it's best
to reserve it for when it is truly deserved.

--
David Hilsee

[Joseph Turian]

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?

Joseph

[Gianni Mariani]

Alf P. Steinbach wrote:

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

There is alot more to it than that.

The actual answer to the question is not as important as the process in
which the candidate goes through.

BTW - these are pre-interview questions.

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

I thought it was only std::endl that was not defined in ostream.

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

Not quite - you only got 50% of the answer. You got the gimme answer.

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

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

struct M;

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

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

No. It's wether they can research it.

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

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.

Describe why you think that is a problem.

BTW - there are still other issues.

The point is, it's a starting point for a dialogue.

[Gianni Mariani]

E. Robert Tisdale wrote:

Gianni Mariani wrote: ....

After removing superfluous semicolons after namespace definitions,

austria-0.8/job> g++ -Wall -Wno-long-long -ansi -pedantic \
-I../src/austria/code -L../src/austria/code/work.gx86 \
-o main main.cc -laustria
austria-0.8/job> ./main
M::Do(void)

it compiles and runs without complaint.
You need to explain an "Austria C++ smart pointer".
An astute candidate would *not* assume that it has the usual meaning.
But, if it has the usual meaning
and the candidate is familiar with smart pointers,
then you should expect the candidate to spot the error immediately.
Yep. This is a design issue. This should be somthing that someone with
experience should pick up.

I would say this *is* a good question
because the programmer cannot depend upon the compiler or testing
to reveal the bug. Of course,
we would expect that this bug would manifest itself eventually.

Evidently, smart pointers are important to you
and you should make sure that your programmers understand them.
But smart pointers are *not* a difficult concept to grasp
so any deficiency in understanding them is easily corrected
and I don't think that this question would do very much
to help you decide which candidate is the better C++ programmer.

You're right. Smart pointers are somthing that could be picked up
quickly. The point is that the questions were pre-interview, the "take
as long as you like to answer them" type and so if someone decided to,
they could find out with about 5 minutes of google and reading (if not
less).

[Gianni Mariani]

Erik de Castro Lopo wrote:

"E. Robert Tisdale" wrote:

What makes a good C/C++ programmer?

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

Actually, there is. Alot of my code 4-5 years ago was C but with a
little C++.

There are many "ways" you can use C++, one of them is the "C/C++" which
is the guy who is good at C trying to be a C++ programmer.

[Gianni Mariani]

Joseph Turian wrote:

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?

Anyone that writes good C++ must be a good human ?

[Alan Krueger]

E. Robert Tisdale wrote:

Alan Krueger wrote:

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.

[...] I don't know how you end up
tracking down errors introduced by "developers".
It seems to me that they should be tracking down their own errors.

If we could magically detect who introduced a bug before finding the
cause, I'm sure we'd assign it to that person up front. However, in
reality, you need to actually determine what's causing a software fault
before you can know how it got introduced, and who might have introduced it.

As an example of the "knows enough to be dangerous" label, consider
someone who has learned about C++ references, but not yet know that you
shouldn't receive a temporary automatic into a non-const reference.

[E. Robert Tisdale]

Joseph Turian wrote:

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?

I don't know what makes someone a good human being.

All that I know is that
only the kindness and grace of the people who love them
can redeem them.

[Alf P. Steinbach]

* Gianni Mariani:

* Alf P. Steinbach wrote:

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

There is alot more to it than that.

Such as?

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

template<>
struct BitsSetInAux_< 0 >
{
static T const value = 0;
};

public:
static T const value = BitsSetInAux_<value_>::value;
};

I fail to see the "lot more to it than that".
[snip]

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

I thought it was only std::endl that was not defined in ostream.

Presumably you mean "not defined in <iostream>", since what you write
doesn't make sense.

Assuming that: no, your perception was incorrect regarding the normative
text of the standard (the non-normative examples are defective).

<iostream> only gives 'extern' declarations for 'std::cout' etc.

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

Not quite - you only got 50% of the answer. You got the gimme answer.

What is the other 50%, and what is a "gimme" answer.

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

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

struct M;

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

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

No. It's wether they can research it.

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

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.

Describe why you think that is a problem.

Why I think _what_ is a problem?

If you mean, why is it impossible to say what could be wrong without
knowing the functionality of the things used, well, that could be the
exception to the rule that there are no stupid questions.

If you mean, why is it a problem to expose public data members and not
use constructors, I think you should ask that question in
[comp.programming], because it's a newbie design-level / general OOP
question not specifically related to C++. Or, consult the nearest good
introductory textbook. ;-)

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

[CBFalconer]

David White wrote:

"Erik de Castro Lopo" <no****@mega-nerd.com> wrote in message

"E. Robert Tisdale" wrote:

What makes a good C/C++ programmer?

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

Yes, a CV that gives the applicant's C/C++ experience always looks
suspicious. It's as though the applicant believes that they are
interchangeable languages or that C experience can be passed off as
C++. They should always be treated separately.

Would you be surprised if I told you that
it has almost nothing to do with your knowledge of C or C++?

Well it wouldn't be the first time you have been wrong.

Anybody who employs a person with poor or non-existant knowledge
of the programming language they will be using has to teach them
that language before they can start anything else.

Yes, but talented people don't need long to learn it. IMO, someone
who's memorized every nuance of C++ but can't solve the kinds of
problems they'll need to solve isn't going to be as productive
after a few weeks as someone who knows no C++ but is obviously a
talented programmer.

I see the c.l.c primary troll has managed to spark something by
crossposting to c.l.c++. The residents of c.l.c are generally
aware of Trollsdale and won't bite, but the c.l.c++ readers have
been trolled. Be aware that he 'edits' quotes. Sometimes he even
sounds knowledgeable. F'ups set.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Gianni Mariani]

Alf P. Steinbach wrote:

* Gianni Mariani: ....
I fail to see the "lot more to it than that".
Nice try. First, you understood that it was a meta-programming question
- many programmers would not. Second, the three most recent versions of
compilers I have don't like the code - which tells me either you didn't
try it or the three compilers I used are broken. If it's a case of not
trying your code, then, I am more interested in candidates that are more
rigorous. That's just the beginning, wait ... there's more.

MSVC 2k3 says:

bit_count_alf.cpp
bit_count_alf.cpp(10) : error C2065: 'value' : undeclared identifier
bit_count_alf.cpp(10) : see reference to class template
instantiation 'BitsSetIn_<T,value_>::BitsSetInAux_<n_>' being compiled
with
[
T=int,
value_=-2,
n_=-1
]
bit_count_alf.cpp(20) : see reference to class template
instantiation 'BitsSetIn_<T,value_>::BitsSetInAux_<n_>' being compiled
with
[
T=int,
value_=-2,
n_=-2
]
bit_count_alf.cpp(27) : see reference to class template
instantiation 'BitsSetIn_<T,value_>' being compiled
with
[
T=int,
value_=-2
]
bit_count_alf.cpp(10) : error C2056: illegal expression

http://www.comeaucomputing.com/tryitout/
says:

Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1
Copyright 1988-2003 Comeau Computing. All rights reserved.
MODE:strict errors C++

"ComeauTest.c", line 13: error: explicit specialization is not allowed
in the
current scope
template<>
^

"ComeauTest.c", line 10: error: constant value is not known
(n_ % 2) + BitsSetInAux_<n_ >> 1>::value;
^
detected during:
instantiation of class "BitsSetIn_<T,
value_>::BitsSetInAux_<n_>
[with T=int, value_=-2, n_=-1]" at line 10
instantiation of class "BitsSetIn_<T,
value_>::BitsSetInAux_<n_>
[with T=int, value_=-2, n_=-2]" at line 20
instantiation of class
"BitsSetIn_<T, value_> [with T=int, value_=-2]"
at line
27

2 errors detected in the compilation of "ComeauTest.c".

and GCC says

bit_count_alf.cpp:13: error: invalid explicit specialization before ‘>’
token
bit_count_alf.cpp:13: error: explicit specialization in non-namespace
scope ‘class BitsSetIn_<T, value_>’
bit_count_alf.cpp:13: error: enclosing class templates are not
explicitly specialized
bit_count_alf.cpp:14: error: template parameters not used in partial
specialization:
bit_count_alf.cpp:14: error: ‘T’
bit_count_alf.cpp:14: error: ‘value_’
bit_count_alf.cpp: In instantiation of ‘BitsSetIn_<int,
-0x000000002>::BitsSetInAux_<-0x000000001>’:
bit_count_alf.cpp:10: instantiated from ‘BitsSetIn_<int,
-0x000000002>::BitsSetInAux_<-0x000000002>’
bit_count_alf.cpp:20: instantiated from ‘BitsSetIn_<int, -0x000000002>’
bit_count_alf.cpp:27: instantiated from here
bit_count_alf.cpp:10: error: incomplete type ‘BitsSetIn_<int,
-0x000000002>::BitsSetInAux_<-0x000000001>’ used in nested name specifier



[snip]

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>.
I thought it was only std::endl that was not defined in ostream.

Presumably you mean "not defined in <iostream>", since what you write
doesn't make sense.

Assuming that: no, your perception was incorrect regarding the normative
text of the standard (the non-normative examples are defective).

<iostream> only gives 'extern' declarations for 'std::cout' etc.

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

Not quite - you only got 50% of the answer. You got the gimme answer.

What is the other 50%, and what is a "gimme" answer.

What happens after B's construction ?

A "gimme putt" in golf is an easy "tap in" putt.

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

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

struct M;

struct N
: at::PtrTarget_Basic
{
at::Ptr<M *> m;
};
Is the purpose of the question to ascertain whether the interviewee
knows the "Austria C++ smart pointer interface"?
No. It's wether they can research it.

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

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.

Describe why you think that is a problem.

Why I think _what_ is a problem?

There is somthing much more fundamentally wrong here. The generated
constructor (in this case) is perfectly fine. As to why we don't place
accessor functions around members. I think that's more of a religion
question and if you have somthing more than that to say, I'd like to
know, I don't mind being wrong...

If you mean, why is it impossible to say what could be wrong without
knowing the functionality of the things used, well, that could be the
exception to the rule that there are no stupid questions.
I know this is not a case where you're interested in the job, but I
suspect that a few minutes of research would yield your unknowns.

If you mean, why is it a problem to expose public data members and not
use constructors, I think you should ask that question in
[comp.programming], because it's a newbie design-level / general OOP
question not specifically related to C++. Or, consult the nearest good
introductory textbook. ;-)

Do you think that answer would get you the job ?

There is a constructor (2 in fact) that the compiler created for you.
Why do somthing that the compiler does better ?

The whole point is, the questions are just the opening point for
discussion. For example, I can tell you're not very interested in the job !

[Christian Bau]

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.

[sushant]

this piece of information is fabulous....................:-)

[Mabden]

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

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.

You're wrong!

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

.... I assume.

--
Mabden

[Gernot Frisch]

> You're wrong!

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

... I assume.

I know of people that start as roookie and progress to troll...

[Mabden]

> Gernot Frisch" <[e-mail]> wrote in message
news:35*************@individual.net..."Christian Bau"

ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

In article <Bu*******************@newssvr13.news.prodigy.com> ,
"Mario Rosario" <re******@webacre.com> wrote:
>
> Are you a rookie or an expert C++ programmer?
>

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

You're wrong!

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

... I assume.

I know of people that start as roookie and progress to troll...

<looks in mirror>
Nah! I'm an expert!
Your hypothesis is obviously limited.

...But everyone STILL assumes "that one starts as a rookie and progresses
to be an expert"!

It's an Axe'em. If they don't belief it you can axe 'em.

--
Mabden

p.s. If you axe 'em and they don't reply - they ain't got no comate!

[Efrat Regev]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:ct**********@nntp1.jpl.nasa.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.

What makes a good E. Robert Tisdale?

Would you be surprised if I told you that
it has to do with nothing concerned with your knowledge of C or C++?
There isn't much difference in productivity, for example,
between a newborn E. Robert Tisdale with a few weeks of experience
and an old E. Robert Tisdale with years of experience.

You don't really need to understand anything
or use anything
(except phrases like "useful programs in your application domain").
What really helps is understanding nothing
and experience solving nothing.

So what should employers look for when hiring E. Robert Tisdale?
Well, probably for their next job.
The best thing to do is to ask them
to please leave

[Gary Labowitz]

"David White" <[e-mail]> wrote in message
news:L_*****************@nasal.pacific.net.au...

"Erik de Castro Lopo" <no****@mega-nerd.com> wrote in message
news:41***************@mega-nerd.com...

"E. Robert Tisdale" wrote:

What makes a good C/C++ programmer?

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

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++. 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.
--
Gary

[jacob navia]

Efrat Regev wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:ct**********@nntp1.jpl.nasa.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.

What kind of measurements have you undertook to justify such an absurdity?

You mean if I give a complex C program to sombedoy that
has just written an "hello world" program he will as
productive as an experienced programmer?

This is plain nonsense, not justified by anything else
but the sayings of Mr Tisdale.

[Alf P. Steinbach]

* Gianni Mariani:

Alf P. Steinbach wrote:

* Gianni Mariani: ...

I fail to see the "lot more to it than that".

Nice try. First, you understood that it was a meta-programming question
- many programmers would not. Second, the three most recent versions of
compilers I have don't like the code - which tells me either you didn't
try it or the three compilers I used are broken.

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

If it's a case of not
trying your code, then, I am more interested in candidates that are more
rigorous.
I do not accept the label 'candidate', nor that the insinuation that I'm
not rigorous.

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?

Get a grip.

That's just the beginning, wait ... there's more.

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

[umpteen lines of compiler error message]

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

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

Not quite - you only got 50% of the answer. You got the gimme answer.

What is the other 50%, and what is a "gimme" answer.

What happens after B's construction ?

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.

>c) Explain what is happening and wrong with the following code and how
>you would resolve this.
>
>#include "at_lifetime.h" // Austria C++ smart pointer interface
>
>struct M;
>
>struct N
> : at::PtrTarget_Basic
>{
> at::Ptr<M *> m;
>};
Is the purpose of the question to ascertain whether the interviewee
knows the "Austria C++ smart pointer interface"?

No. It's wether they can research it.
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_ptr.

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.

Describe why you think that is a problem.

Why I think _what_ is a problem?

There is somthing much more fundamentally wrong here. The generated
constructor (in this case) is perfectly fine. As to why we don't place
accessor functions around members. I think that's more of a religion
question and if you have somthing more than that to say, I'd like to
know, I don't mind being wrong...

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

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

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

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

[Gary Labowitz]

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

Not quite - you only got 50% of the answer. You got the gimme answer.

<<snip>>

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

No. It's wether they can research it.

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

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

[Efrat Regev]

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

Efrat Regev wrote:

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:ct**********@nntp1.jpl.nasa.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.

What kind of measurements have you undertook to justify such an absurdity?

You mean if I give a complex C program to sombedoy that
has just written an "hello world" program he will as
productive as an experienced programmer?

This is plain nonsense, not justified by anything else
but the sayings of Mr Tisdale.

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

[jacob navia]

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.

[Gianni Mariani]

dropping comp.lang.c ...

Alf P. Steinbach wrote:

* Gianni Mariani:

Alf P. Steinbach wrote:

* Gianni Mariani:
...

I fail to see the "lot more to it than that".

Nice try. First, you understood that it was a meta-programming question
- many programmers would not. Second, the three most recent versions of
compilers I have don't like the code - which tells me either you didn't
try it or the three compilers I used are broken.

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.

If it's a case of not
trying your code, then, I am more interested in candidates that are more
rigorous.

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 just the beginning, wait ... there's more.

MSVC 2k3 says:

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

....

What happens after B's construction ?

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.

Why I think _what_ is a problem?
There is somthing much more fundamentally wrong here. The generated
constructor (in this case) is perfectly fine. As to why we don't place
accessor functions around members. I think that's more of a religion
question and if you have somthing more than that to say, I'd like to
know, I don't mind being wrong...

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]

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

[Erik de Castro Lopo]

Gianni Mariani wrote:

Erik de Castro Lopo wrote:

"E. Robert Tisdale" wrote:

What makes a good C/C++ programmer?

There is no such thing. There are good C programmers, good C++
programmers and programmers who are good at both.

There is no such language as C/C++.

Actually, there is. Alot of my code 4-5 years ago was C but with a
little C++.

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

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo no****@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Java is, in many ways, C++--." -- Michael Feldman

[Gary Labowitz]

"Thomas Matthews" <Th*************************@sbcglobal.net> wrote in
message news:41**************@sbcglobal.net...

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.

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

[Alf P. Steinbach]

* Gianni Mariani:

dropping comp.lang.c ...

Alf P. Steinbach wrote:

* Gianni Mariani:

Alf P. Steinbach wrote:

* Gianni Mariani:

...

I fail to see the "lot more to it than that".

Nice try. First, you understood that it was a meta-programming question
- many programmers would not. Second, the three most recent versions of
compilers I have don't like the code - which tells me either you didn't
try it or the three compilers I used are broken.

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

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.

If it's a case of not
trying your code, then, I am more interested in candidates that are more
rigorous.

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 ?

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

What happens after B's construction ?

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.

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 somthing much more fundamentally wrong here. The generated
constructor (in this case) is perfectly fine. As to why we don't place
accessor functions around members. I think that's more of a religion
question and if you have somthing more than that to say, I'd like to
know, I don't mind being wrong...

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.

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

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

Gary Labowitz wrote:

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

Not quite - you only got 50% of the answer. You got the gimme answer.

<<snip>>

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

No. It's wether they can research it.

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]

Alf P. Steinbach wrote:

* 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";
}

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.

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.

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.

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

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.

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.

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 ?

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.

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

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


....

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.

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.

....

There is no state to set up the object.

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]

Erik de Castro Lopo wrote:

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

Just barely ! :-)

[Gary Labowitz]

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

:-).

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

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

[Andrew Koenig]

"Guillaume" <"grsNOSPAM at NOTTHATmail dot com"> wrote in message
news:41***********************@news.club-internet.fr...

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