Re: is it ok to know pure C++ and ignore older C style constructs
entirely?
Balog Pal wrote:
"Victor Bazarov" <v.Abazarov@comAcast.net>
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...
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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask