is it ok to know pure C++ and ignore older C style constructs entirely?

R

rabbits77

Just a curious thought I had recently...
Would the C++ community(however you care to define
that) find it reasonable that some one would know
only C++ specific conventions? For example, suppose
you were interviewing somebody and they had no
knowledge of C style strings? Or suppose they knew
perfectly well about new/delete but had never used
free/malloc?
Would that strike you as strange or is that
something that is so acceptable that you would not
object to hiring that person as a C++ programmer?
 
V

Victor Bazarov

rabbits77 said:
Just a curious thought I had recently...
Would the C++ community(however you care to define
that) find it reasonable that some one would know
only C++ specific conventions? For example, suppose
you were interviewing somebody and they had no
knowledge of C style strings? Or suppose they knew
perfectly well about new/delete but had never used
free/malloc?
Would that strike you as strange or is that
something that is so acceptable that you would not
object to hiring that person as a C++ programmer?

I would find it a bit strange simply because character arrays and
'malloc' and 'free' are just as part of C++ as they are of C.

Is it possible to survive in the market without ever using a character
array or 'free' and 'malloc'? Yes, quite possible. Just like it is
possible to survive and know nothing of templates.

V
 
K

Kaz Kylheku

Just a curious thought I had recently...
Would the C++ community(however you care to define
that) find it reasonable that some one would know
only C++ specific conventions? For example, suppose
you were interviewing somebody and they had no
knowledge of C style strings?

Someone with no knowledge of ``C'' strings does not know:

- a significant part of the lexical grammar of C++, namely string
literals, which denote null-terminated objects.

- has probably never worked with any platform API that uses C style
strings, such as POSIX and Win32.

I.e. no real-world systems programming experience; nice to meet you,
resume in the trash.
Or suppose they knew
perfectly well about new/delete but had never used
free/malloc?

This is a strange hole in the programmer's background. If you're a C++
programmer, that should mean that you're a systems programmer, and
should know things like this.

Moreover, you should know about platform-specific system calls for
memory allocation mmap and brk on POSIX, VirtualAlloc on Windows
and so on.

Otherwise it looks like you've been coding in some academic vaccuum.

Similar reasoning applies: you've never had to use any third party
library with a C API, featuring lower-level conventions for allocating
memory and managing ownership of passed objects.
 
B

Bo Persson

Kaz said:
Someone with no knowledge of ``C'' strings does not know:

- a significant part of the lexical grammar of C++, namely string
literals, which denote null-terminated objects.

- has probably never worked with any platform API that uses C style
strings, such as POSIX and Win32.

You need SOME knowledge about C strings, but there is not much need
for strxfrm, strcpsn or being able to tell the difference between
strstr, strpbrk, and strrchr (yes they are real C functions!).
I.e. no real-world systems programming experience; nice to meet you,
resume in the trash.

Not so. Not everyone wants C hackers only.


Bo Persson
 
O

osmium

rabbits77 said:
Just a curious thought I had recently...
Would the C++ community(however you care to define
that) find it reasonable that some one would know
only C++ specific conventions? For example, suppose
you were interviewing somebody and they had no
knowledge of C style strings? Or suppose they knew
perfectly well about new/delete but had never used
free/malloc?
Would that strike you as strange or is that
something that is so acceptable that you would not
object to hiring that person as a C++ programmer?

I would assume that the person had "book learnin'" and virtually no
real-world, practical experience. It would not be a plus.
 
J

James Kanze

Just a curious thought I had recently...
Would the C++ community(however you care to define that) find it
reasonable that some one would know only C++ specific conventions? For
example, suppose you were interviewing somebody and they had no
knowledge of C style strings? Or suppose they knew perfectly well
about new/delete but had never used free/malloc? Would that strike
you as strange or is that something that is so acceptable that you
would not object to hiring that person as a C++ programmer?

It depends on what you were hiring them for. I would expect that they
knew at least that string literals didn't have type std::string; if I
am
hiring an advanced programmer for low level work, I would expect some
familiarity with C style arrays, since they do end up being used to
implement higher level constructs, and to avoid dynamic
initialization.
On the other hand, I can't imagine even asking a question which would
determine whether they knew of malloc/free. (The only place I've used
them in close to 20 years of C++ is in implementing my own global
operator new/operator delete.)
 
J

James Kanze

I would find it a bit strange simply because character arrays and
'malloc' and 'free' are just as part of C++ as they are of C.

And valarray is also very much a part of C++. Would you refuse to
hire
me because I'm not familiar with it (other than knowing its name, and
that it exists)?
Is it possible to survive in the market without ever using a character
array or 'free' and 'malloc'? Yes, quite possible. Just like it is
possible to survive and know nothing of templates.

When hiring someone, you vet according to your needs, and what you
expect that person to do. If you don't think there's any chance of
their seeing templates (which means no use of the standard library),
then why not hire someone who knows nothing of templates. All I can
say
is that I use templates extensively, and have in almost all projects
in
the last ten years, so I consider them important. Where as I've used
malloc/free exactly once (in an implementation of global operator
new/operator delete) since I started C++, so it wouldn't bother me if
a
candidate had never heard of them.
 
J

James Kanze

Someone with no knowledge of ``C'' strings does not know:
- a significant part of the lexical grammar of C++, namely string
literals, which denote null-terminated objects.
- has probably never worked with any platform API that uses C style
strings, such as POSIX and Win32.
I.e. no real-world systems programming experience; nice to meet you,
resume in the trash.

I would expect most C++ programmers to be aware that string literals
are
not std::string (and to know what they really are). For the rest:
most
application programmers never see the platform API, so that's not an
issue (but they're likely to have run into other API's which do
require
C style strings).
This is a strange hole in the programmer's background. If you're a C++
programmer, that should mean that you're a systems programmer, and
should know things like this.

Most C++ programmers are NOT systems programmers. (For various
historical reasons, system programmers do need to know C.) Most C++
programmers are applications programmers. And there's absolutely no
reason why an applications programmer should ever have encountered
malloc or free.
Moreover, you should know about platform-specific system calls for
memory allocation mmap and brk on POSIX, VirtualAlloc on Windows and
so on.
Why?

Otherwise it looks like you've been coding in some academic vaccuum.

Or more likely, you've been too busy writing real applications to
worry
about unimportant trivia.
Similar reasoning applies: you've never had to use any third party
library with a C API, featuring lower-level conventions for allocating
memory and managing ownership of passed objects.

Maybe, maybe not. Practically all of the third party libraries I'm
familiar with provide their own "free", and require you to return
memory
through it. I've programmed in C++ now for almost 20 years; I've even
done a lot of low level programming (enough to be quite familiar with
mmap, for example); I've interfaced to a number of different third
party
libraries. And I've used malloc/free exactly once, and that was only
in
a very special case which wouldn't affect most programmers.
 
V

Victor Bazarov

James said:
And valarray is also very much a part of C++. Would you refuse to
hire
me because I'm not familiar with it (other than knowing its name, and
that it exists)?

Probably not, as long as the job doesn't require using them. If the job
does, then it's a matter of how quickly the candidate can get up to speed...

V
 
D

dragan

rabbits77 said:
Just a curious thought I had recently...
Would the C++ community(however you care to define
that) find it reasonable that some one would know
only C++ specific conventions? For example, suppose
you were interviewing somebody and they had no
knowledge of C style strings? Or suppose they knew
perfectly well about new/delete but had never used
free/malloc?
Would that strike you as strange or is that
something that is so acceptable that you would not
object to hiring that person as a C++ programmer?

I prefer someone with no programming experience because teaching someone
without it is easy compared to (un)teaching the other kind. If I had to
choose between someone with just C knowledge and/or experience and someone
with just C++ and someone with C/C++, I'd choose the one with just C
knowledge and/or experience. If I had to choose between just the one with
only C++ and the one with C/C++, I'd choose the one with C/C++.
 
B

Balog Pal

Victor Bazarov said:
Probably not, as long as the job doesn't require using them. If the job
does, then it's a matter of how quickly the candidate can get up to
speed...

In a realistic scenario you don't hire people for a project that is due in a
few days or a week max. (Just as you can't arrange the agreement in that
frame...)

And exact use of library functions are as simple as look up -- and probably
that look up is needed anyway. I don't keep the C library in my head for
sure. And rather fetch thr man page/hit F1 for any function I didn't read
pretty recently.

Many collegues don't do that, just write code on old recollection or deduced
form "examples" lying around. I found a big deal of bugs on review from
that practice, that originated from not reading the details.

is malloc/free any different than say fopen?
 
V

Victor Bazarov

Balog said:
In a realistic scenario you don't hire people for a project that is due
in a few days or a week max. (Just as you can't arrange the agreement in
that frame...)

And exact use of library functions are as simple as look up -- and
probably that look up is needed anyway. I don't keep the C library in
my head for sure. And rather fetch thr man page/hit F1 for any function
I didn't read pretty recently.

The problem with some functions and constructs is not in the wrong
[types of] arguments provided to them, it's usually deeper than that.
There are idioms, best practices, hidden dangers (like performance
implications), side effects (and I don't mean the ones spelled out in
the 'Help' topic)... And knowing those comes from experience. It's
hard to make proper decisions just by reading man pages.
Many collegues don't do that, just write code on old recollection or
deduced form "examples" lying around. I found a big deal of bugs on
review from that practice, that originated from not reading the details.

Could you give an example?
is malloc/free any different than say fopen?

In what sense different? In the sense that people remember what the
interface looks like and what the meanings of those arguments are? Then
in most cases those who use 'fopen' probably use 'malloc' and 'free' on
a regular basis too, and do remember the correct interface. Perhaps I
didn't understand the question.

V
 
B

Balog Pal

Victor Bazarov said:
And exact use of library functions are as simple as look up -- and
probably that look up is needed anyway. I don't keep the C library in my
head for sure. And rather fetch thr man page/hit F1 for any function I
didn't read pretty recently.

The problem with some functions and constructs is not in the wrong [types
of] arguments provided to them, it's usually deeper than that.

Exactly what I'm saying. The arg list is often provided by the environment
as tooltip, so there's not even need to look up. But there may be some
responsibility wrt params or the return value, special considerations,
library bugs, etc.
There are idioms, best practices, hidden dangers (like performance
implications), side effects (and I don't mean the ones spelled out in the
'Help' topic)... And knowing those comes from experience.

Come on, it comes from reading (or being told). It becomes "experience" only
that way. And there is no need to do that reading weeks or years before
the actual need -- as long as it is done.
It's hard to make proper decisions just by reading man pages.

Certainly it is not the only source, my point is that it is even harder to
do it *without* the proper info source, and it is commonplace to just rely
on something superficial.
Could you give an example?

Sure, many, instead let me one of my misses -- where others did the reading;
it was for function strncpy. Which I just assumed to work the same way as
other n-included variant functions.
In what sense different? In the sense that people remember what the
interface looks like and what the meanings of those arguments are?

That a programmer must have it memorized beforehand to details, instead of
having the ability to locate the 'how to deal with memory' or files
sections.
Then in most cases those who use 'fopen' probably use 'malloc' and 'free'
on a regular basis too, and do remember the correct interface.

And I doubt that if you just pick a 'bright' person who never used those
before, but will need in the next job would have disadvantage over one who
is just 'used-to' a few hundred library functions.

Another of my observations, that when I moved to new environments, I
generally discovered a plenty new/better ways to do things or brought latent
problens to light the "experienced" people were not aware of.

Sure, there are situations, where experience to stock knowlege comes handy
or is clearly vital, but in general more abstract things -- like experience
to have certain *approach* has way more benefits.
 
B

Bo Persson

Victor said:
Probably not, as long as the job doesn't require using them. If
the job does, then it's a matter of how quickly the candidate can
get up to speed...

This might be a very important part of an interview.

If using valarray is a requirement, I would probably not take the job.
:)


Bo Persson
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top