views:

1208

answers:

17

Is there any way for a C++ programmer with 1,5 years of experience to have no idea that null-terminated strings exist as a concept and are widely used in a variety of applications? Is this a sign that he is potentially a bad hire?

+28  A: 

Is there any way for a C++ programmer with 1,5 years of experience to have no idea that NULL-terminated strings exist as a concept and are widely used in a variety of applications?

No. What have he/she been doing for these 1,5 years?

Is this a sign that he is potentially a bad hire?

Yes. Knowledge of C should be mandatory for a C++ programmer.

dalle
What have they been doing? Anything. Syntax, stdlib, OOP... The best C++ introductory book, "Accelerated C++" doesn't ever get to explaining the implementation of std::string, I believe. It _is_ weird that he never encountered the concept, but it's not a big problem
"should be mandatory" - No! You can learn C++ without knowing anything about C (in fact some people think that's better since you don't learn all of C's bad habits).
paxdiablo
@Pax You mean, to learn the candy object-oriented part of C++ but completely skip the hardcore part concerning memory management, pointers arithmetics, reinterpret_casts?
sharptooth
Game development for example. It almost doesn't require string handling.
n0rd
@Pax: I think you are confusing 2 separate ideas: (1) Avoid using raw C-strings as much as possible in C++ because std::string is much safer and more convenient; (2) Have a working knowledge of common "bad" techniques because you will often have to deal with them when maintaining existing code.
j_random_hacker
Johannes Schaub - litb
@ Pax: not knowing C's bad habits (and the fact that they're bad) means you'll probably make the same mistakes in C++.
Dave Van den Eynde
@sharptooth, those are all part of C++ (real memory mngmn (new/delete) and reint_cast don't even exist in C). Pointers are as much a part of C++ as C. So i mean learn all of that as well. Not necessary to learn null-term strings if you have std::string.
paxdiablo
@jrhacker, I agree with you on the bad practice avoidance.
paxdiablo
@Dave, I would assume you won't make the same mistakes with std::string as with standard C strings (otherwise no point in having them really). My point was dont use malloc/printf/null-term-strings, use the C++ things (new/cout/std::string).
paxdiablo
+15  A: 

What does he use -- std::string only? Does he know about string literals? What is his take on string literals?

There's too little detail to tell you if he's a bad hire, but he sounds like he needs a bit more talking to than most.

dirkgently
What's wrong with just std::string? Maybe he's only ever used string literals to construct std::strings. I use Java's collections every day but I don't care that much how they're implemented under the covers. I don't care if a language used C-null or Pascal-length strings as long as they work.
paxdiablo
Nothing wrong with it at all, Pax. But it *would* be unusual. Or at least a little surprising, no?
dmckee
1.5yrs, I'd be surprised if they've even heard of C++, let alone C. Aren't the Unis pushing Java/Perl/Python/C# nowadays?
paxdiablo
I'm only trying to be fair on the poor chap. Which is why I asked so many questions. I guess you only can find out more.
dirkgently
std::string is null-terminated either.
n0rd
@n0rd:Not required. The standard doesn't mandate that; a vector<char> is equally possible.
dirkgently
If it is not null-terminated, then it will involve some unnecessary operations to make c_str() member function to work properly. That's not very practical.
n0rd
@n0rd: While c_str() is a good reason to implement std::string using null-terminated C strings, it does not imply that it always works that way. Relying on such implementation details is bad practice, since they can change without notice.
j_random_hacker
c_str() returns a null terminated byte string when called. Having a null byte always may raise the question of having to pay for something you don't use. The implementation is free to create and return on accessing c_str().
dirkgently
edited comment: s/NULL/null/g. (I was using all uppercase as reinforcement -- but seems likely there'd be more confusion.)
dirkgently
A: 

NULL-terminated strings don't exist, so I guess he might be a good hire.

Update: null-terminated and terminating '\0' appear in the C++ standard, according to some of the comments. Instead of deleting my answer, I turn it into wiki, to preserve the interesting part of the debate.

Daniel Daranas
The strings are NUL-terminated, of course ;-)
theller
It's kind of a joke. Really they are zero terminated (hence the "z" prefix in the modified hungarian notation) while NULL is a name for a pointer that points to no valid object - it has no actual requirement to have the value 0
1800 INFORMATION
To say NUL-terminated is also incorrect ASCII-centric terminology. To say they are "null-terminated" (lower case null) is correct and the terminology used in both the C and C++ standards.
Chris Young
If I see class C { private: char * someting; } I don't see a "NULL-terminated string", I just see a pointer to a char. What you do with this pointer - you have to document it thoroughly. I can't assume anything from reading the code.
Daniel Daranas
@Daniel: Your last comment is of course correct, but I don't see what it has to do with the question, your post or the preceding discussion.
j_random_hacker
@j_random_hacker: I've seen some people claim that their code has "NULL/NUL/null-terminated strings" (they say it verbally, so you don't know what null they're using) when all that they have are lots of "char * something" members whose ownership, semantics, contract... are unknown to the reader.
Daniel Daranas
@j_random_hacker: (cont.) Actually, I've never seen any "clean" design which doesn't use a decent string class. So, again, I repeat, null-terminated strings don't exist (in the standard language + STL), so if you the code author invent one, it's a _user_ construct and you must document it as such.
Daniel Daranas
Nit-picker. You know he meant NUL.
Michael Kohne
Read my comments. I maintain my answer for any spelling. If I'm wrong and this (what I think to be) user construct actually belongs to the C++ standard, I will delete this answer.
Daniel Daranas
@Daniel: As I said before, you're right to say that "char *p" doesn't imply that p points to a null-terminated string. That doesn't change the fact that many instances of "char *p" *are* used this way (sometimes even documented to that effect!) so programmers need to be familiar with the concept.
j_random_hacker
@j_random_hacker: Alright, but they don't need to be so familiar if they have been maintaining modern code, which mostly uses std::string. char pointer strings are unsafe and very error-prone, and I've fixed lots of bugs related to them - that's why, in modern code, you should hardly find them.
Daniel Daranas
Nonsense. Even if you design a new piece of code perfectly (in your eyes) and therefore use no char*'s, they are still ubiquitous. For example when calling Win32 API functions, many of which take a char* or write to a char buffer.
John Dibling
@Daniel: There are plenty of libraries that do require null-terminated strings -- notably, the Standard C++ Library itself (e.g. the filename argument to ifstream::open()). And I would argue that they *are* a language construct, given that string literals create them.
j_random_hacker
@Chris Young: The phrase "null-terminated" does not appear in the original C++ standard (the one I've got a PDF of; I never did get an official TR1).
David Thornley
Okay, I just found a "null-terminated" in the Standard, despite what the search returned. I apologize for my PDF reader's failing.
David Thornley
+2  A: 

not knowing that they exist - a really bad sign hardly using them - IMO not really a bad sign. Back in the days when I was programming C++ I avoided null terminated strings for everyting except for string literals.

std::strings (or CStrings) were used instead.

bernhardrusch
+15  A: 

Is this a sign that he is potentially a bad hire?

Definitely, C++ programmer must understand what happens behind all cool STL stuff.

Unfortunately there are too many substandard C++ programmers on the market.

BTW: The are not NULL terminated, but rather zero terminated.

Artyom
They are null terminated, the ASCII char #0 is NUL, the null character (see http://www.asciitable.com/).I'm pretty certain most texts refer to them as null-terminated.
DrHazzard
std::string are not null/zero terminated if they were than finding their size would have an O(n) complexity
csiz
csiz: It is possible to implement std::string as null-terminated (internally) and still have time-O(1) size. However, I read this answer as trying to clarify the terminology and not even talking about std::string at all. (And 'null-terminated', or without hyphen, is correct.)
Roger Pate
+3  A: 

NUL-terminated strings (aka ASCIIZ) aren't even a C construct, I think a good programmer should at least know there are different ways to store a string (terminating with 0, prefixing with length...).

Perhaps you won't ever need this, but for me it feels like using your computer without ever opening it and have a look what's in there just to understand it a bit better.

I won't say that someone who doesn't know about it is potentially a bad hire, but note that if you use NUL-terminated strings in your project, he'll have to learn the concept and might stumble about the common mistakes in this field (not increasing the array sizes by 1 to store the additional 0 etc.) which a programmer that knows about NUL-terminated string wouldn't.

schnaader
They are a C construct in the sense that string literals create them, and the standard C runtime library assumes them. The standard does not assume that ASCII is used, but it does assume that a char value of zero terminates a string. In ASCII, that code point is named NUL.
RBerteig
Yes, you're right, the concept is needed if you want to learn C. I just wanted to change the focus from C/C++ to other programming languages - for example you might also get problems if you don't know the concept and use Delphi.
schnaader
I totally agree that the concept is beyond C and even creeps in strange places (e.g. interfacing C and Python since Python strings may have embedded nulls...)
DrHazzard
i don't understand why everyone is saying they are a "c construct". they are a "c++ construct" the same way. so indeed one has to learn them :)
Johannes Schaub - litb
+5  A: 

I'd say it depends on what you want to hire them for, and what their purpose in your organization will be.

Somebody who understands C++ but not C (which is easy to do, nowadays), will fall into this type of category. They can, potentially, be a fine employee. However, I would say this is a warning, so depending on their resume, this would be one mark against them in my book.

However, if they are going to be working on fairly straightforward projects, and not be required to design and develop critical parts of your code base (at least early on), they might be fine.

I would not, however, hire somebody to do design or to work on critical systems who did not understand the basic concepts like this one. Any developer I hire who will be working on C++ projects at a high level needs to understand memory management, basic concepts of C and C++, templates and generic programming, and all of the fundamentals, at least to a reasonable degree, of the language they will be using.

Not understanding the concepts of how string literals work would be a big disadvantage - even if they will be using std::string or the like, I want them to understand how it works underneath, at least to some degree, and also the other options out there. Understanding the concepts helps to understand the rationale behind the newer, nicer technologies, but also to understand the compromises being made when they are used. It also helps to understand the design decisions made there, and apply them to your own projects.

Reed Copsey
+4  A: 

In the work we do at my company, and I guess that is the case for many other places, you must know about NULL-terminated (or zero terminated) strings. Yes, we use C++ and we try to use std::string where we can. But we have code that was developed years ago that uses C-style strings, sprintf and this kind of stuff. Then you have external code and APIs, how can you call even Windows API without knowing about these C concepts?

So will he be a bad hire? Well, what you don't know you can learn... But it is definitely not a good sign.

Dani van der Meer
+10  A: 

IMHO, I'd expect a competent programmer to have the basic curiosity to wonder how things like the STL containers actually work. I wouldn't expect them to necessarily be prepared to implement one, mind you.

But the NUL terminated string is a fundamental data type of both C and C++. Given the chance to avoid the messy details with a container is a luxury. You still have to appreciate what the container is doing for you.

RBerteig
+1  A: 

Consider the coursework in any C/C++ based undergrad coursework. There has to be a data structures course s/he must have taken and this course must have had an assignment wherein they have to implement a string type from scratch. Obviously, nobody expects all functionality of std::string but they must have implemented a string class and when they did that they must have explored this matter, in depth.

No hire.

Nikhil
Most undergrad coursework is Java at this point, where String is practically a primitive type, so no, they likely wouldn't be implementing a string class. Not to say they shouldn't have learned it in some other course, though.
Andrew Coleson
Maybe I am overgeneralizing but that how it was when I was an undergrad. That's how it was when I was a TA during my MS. And that's how it was (quite recently) when I was filling in for an instructor while I was a Phd. student. 8 years across 3 universities. My sampling might be limited.
Nikhil
+1  A: 

It means they have never opened a file forv input or output. The standard library has no means of specifying a file name via a std::string - you have to use a zero-terminated one.

anon
STL includes istream and ostream for input and output via the >> and << operators. Unless I'm very much mistaken, istream and ostream can make use of std::string just fine.
Michael Kohne
Also you could have a string literal in the code, in which case the underlying implementation of the string is of little interest
DrHazzard
@michael please read what I wrote - the open() member function requires a C-string as its first parameter
anon
@drhazzard - code that uses fixed file names is a little unusual - or do you only ever edit a single file with a single fixed name?
anon
+8  A: 

This reminds me of Shlemiel the painter from Joel's post Back to Basics.

compie
+1  A: 

People say and do all sorts of weird things while being interviewed. Have you seen this person do any coding?

1.5 years is not very much time, but experience means squat if the hire can't think properly. So I'd note it as a warning flag and dig deeper. If the interviewing stage is over and you have to make a decision, it sounds to me like your answer should be NO HIRE.

Adam
+1  A: 

I'd say that it depends on what you are looking for. If you're looking for a relatively inexperiences (and therefore presumably cheap) programmer that you can mold to fit your organization, he might be OK. You've just found out that he has no idea how C does things, and that you'll have to explain a whole lot of C concepts to him when they come up.

At this point the important thing is to figure out if he's just uneducated (he's never come across the need before) or if he's he kind of guy who never learns ANYTHING he doesn't immediately need, or if he's an idiot. If #1, then you can consider hiring him, if he knows enough to be useful. If #2 then I'd take a pass, but perhaps you can make use of a 9-5er. If #3, show him the door.

And I wouldn't take not knowing about C stuff TOO seriously, I've met people who've programmed in C for 15 years who didn't know about __FILE__ and __LINE__. And they were good, they just never came across it before I showed it to them. This guy could be the same way – he's only ever seen the STL way of doing things, so he doesn't know anything else.

Michael Kohne
+1  A: 

Well, I heard from a friend in German SAP they they hired someone as a developer and then later discovered he had always thought 1KB = 1000 Bytes. Looks like they discovered it when he made some kind of bug. They were shocked then moved him to do customer support.

Compared to that, your newly hired developer could be a genius. If seriously, he could have just started making his experience when high-level languages occupied the majority of the market and just didn't skim the era of low-level programming (C++ or something).

Does not necessarily mean he is bad. Just belongs to the new pepsi-generation of developers.

User
At the risk of getting hammered - isn't 1KB = 1 kilobyte = 1000 bytes?
Jack BeNimble
A very good question, Jack!
User
They could've just sent him to work in the hard drive industry.
patros
+2  A: 

It sounds like this is a programmer who didn't start out as a programmer. I took C++ classes in college and even read a few books on the language. Every book within the first 3 chapters will explain how a string, which is an array of characters, knows that it ends, by using the "/0" identifier. This is basic knowledge of C++.

This programmer sounds like a business user who wanted to cut costs by learning "programming" in order to create software for the company without getting a properly educated and experienced developer.

Sorry if that sounded harsh. I take my profession very seriously and consider it an art form of sorts.

Tacoman667
+1  A: 

In your hiring decision, you should consider whether or not he will be able to learn the important pieces of information over whether or not he knows them now. A year and a half is hardly any time at all as far as business experience goes. As others have mentioned, dig deeper, try to find the boundaries of his programming knowledge, and try to figure out how hard it will be to push those boundaries outward. This will depend a lot on personal habits and character. If he's a good learner and a good communicator, he's a good hire. If technical learning is beyond him, programming probably isn't the best career for him.

Scottie T