Re: is it ok to know pure C++ and ignore older C style constructs
entirely?
On Dec 17, 9:08 pm, Kaz Kylheku <kkylh...@gmail.com> wrote:
On 2009-12-17, rabbits77 <rabbit...@my-deja.com> wrote:
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.
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).
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.
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.
--
James Kanze