Các vấn đề để phỏng vấn một ứng viên lập trình C++

[babythandong]

C++ interview questions: what to ask?

Question for all C++ developers on this forum: what questions would you ask as an interviewer to measure the level of proficiency of a candidate in C++? The opening is for a developer with 3+ years of experience. Our team develops application software that run on both Linux and Windows for relatively large firms.

While I don't expect the candidate to be able to recite "The Annotated C++ Reference Manual" by heart, I want to pose questions that are meaningfully challenging and C++ specific. I'm slightly lost here though because this is the first time I'll be playing an interviewer.
Vick
Tuesday, October 10, 2006


What if you find a good developer who doesn't know C++ yet (but could learn in a very short time)?
Steve Hirsch
Tuesday, October 10, 2006


While I'm not advocating the idea of technical interviews at all (preferring code evaluation from the candidates former projects) - the following topic might be useful:

"What do you think about private virtual functions?"

Micha
Micha
Tuesday, October 10, 2006


A good grasp of C++ text book knowledge != a good programmer.

A good programmer doesn't necessarily know C++
FJ Cruiser
Tuesday, October 10, 2006


I always thought that some of those Lint puzzles (they used to be in the lint ads in Dr Dobbs) were great.
Sunil Tanna
Tuesday, October 10, 2006


I am not any type of "star".
Type my name and collect some question I was struggling with.
DAN LEE
Tuesday, October 10, 2006


You might find some questions here:

http://www.possibility.com/epowiki/W...rviewQuestions
t
Tuesday, October 10, 2006


I always try to get a candidate to explain stack unwinding to me, and what is in danger of being leaked, and what they can do about it. I wouldn't necessarily consider that a super advanced question, but it seems to flunk out enough people it makes a good first question.
Keith Wright
Tuesday, October 10, 2006


Here's what I do for teching out somebody. Ask the question, then leave the room, making sure that the interviewee has a phone to call friends, a web connection, textbooks. Come back in a few to review the answer. Have the person explain how they got the answer.

It's not school. "Cheating" is a good thing, having memorized syntax is worthless when reference materials are easily available. To me, the technical test is the explanation of the answer.
Steve Hirsch
Tuesday, October 10, 2006


<regarding C++ ; when C++ fluency is really what we want to test>
I'm not very fond of too precise and syntax oriented questions.

I'd rather have someone that understands major principles like semantics, LSP, RAII, the most widely used patterns, ... than someone that knows the syntax of custom pre- and post-increment operators, how new/delete operators are overidden, or whatever stuff we never do more than once every 2 years.

I guess I would ask to complete a poorly designed set of classes (of course I'll never say the class are poorly designed) to implement whatever algorithm.

If he immediatelly points out the design flaws and explains what should have been done, I'll be quite happy. Otherwise, any newcomer in C++ world should be able to implement what has been asked without feeling down or disturbed by very complex and jargon-oriented questions he is not able to answer. (C++ has a very precise jargon, and many details are more easily explained when we are fluent in its jargon).

Regarding the design flaws, I'll try to hide things like : - more than two raw ressources in a class, - provide copy-semantics on an entity-semantics oriented class (typically within a hierarchy of polymorphic classes), - use public inheritance for anything but LSP, - ...

=> have something that looks simple, and that permits to test newcomers as well as experimented C++ developpers.
</>

Regarding development, there are many other things to check. As it has been said: a talented developper may have not been initiated to C++ intricacies.

If the person is reconverting from a language to C++, he should at least be able to point out the syntaxic and idiomatic differences between the two languages, and to write down algorithms in a semi-C++/semi-natural dialect.
Luc Hermitte
Tuesday, October 10, 2006


+ 1 for Keith

His type of question is the right kind to ask.

When interviewing, there's no sense in trying to put the person under pressure. Just give them something then let them run with it. Most people will hang themselves. You've got your answer.

The key is that most people like to talk. They suck at listening. That can really work in your favor if you work it right. I've done enough interviews like that and seen it work time after time.
Ryan Smyth
Tuesday, October 10, 2006


What is LSP?
Old Coder
Tuesday, October 10, 2006


Liskov substitution principle, i.e. that you can substitute an object A with another object B which is a subtype of A without breaking any contracts. Rather fundamental to OOP.
-L
Tuesday, October 10, 2006


What books have you read and what did you get out of them?
Christopher Wells
Tuesday, October 10, 2006


Why won't this compile?

int e; for (int i = 0; i < 10; i++){  for (int k = 0; k < 10; k++)  {    if (e == 0)      goto next_i;  }next_i:}

One Pathetic Loser
Tuesday, October 10, 2006


Do they know the STL? At least basic tools like string and vector? Knowledge of the STL is what distinguishes a candidate who really knows C++ from a candidate who thinks they know C++ but really gets totally lost whenever they stray from the C half of the language. Knowledge of the STL implies knowledge of value semantics, RAII, exceptions, templates, and composition (as opposed to aggregation). A candidate that doesn't know STL will turn into an employee who churns out reams of unnecessary code to copy one object to another, destroy an object, insert an object into a collection, expand an array, check error codes and bail, etc.
Alyosha`
Tuesday, October 10, 2006


>> what questions would you ask as an interviewer to measure the level of proficiency of a candidate in C++? <<

Do you want to measure the candidate's proficiency, or do you want to make sure the candidate is at or above a specific level? Because the former is much harder and more time-consuming than the latter.

Why do you need "C++ specific" questions? A good developer is far more than just an encyclopaedia! I would ask just 1 or 2 C++ specific questions, probably around pointers. The rest of my questions would be more generic - see here for some examples:
http://sleeksoft.co.uk/public/techbl...0050920_1.html
Mark Pearce
Tuesday, October 10, 2006


"could learn in a very short time"

Wait a minute. Everyone is saying C# and Java is so great because C++ is way too complicated. Yet you think it's easy enough that someone can learn it in a very short time? Hmmm...
sloop
Tuesday, October 10, 2006


I didn't say that. After developing sw for 20+ years, if I can't learn a new (or relearn an old) language/system in a few days, I'm in the wrong business.
Steve Hirsch
Tuesday, October 10, 2006


You can't learn to write good C++ code in a couple of days, no matter how good you are. I guess you're in the wrong business.
sloop
Tuesday, October 10, 2006


"Liskov substitution principle, i.e. that you can substitute an object A with another object B which is a subtype of A without breaking any contracts. Rather fundamental to OOP."

Isn't that polymorphism?

Anyway, I agree with asking about their knowledge of STL. I have spent the majority of my 7 professional years in C++. I always ask candidates to explain the difference between a vector, list, and map. Make sure they explain the underlying data structures. That will show that they not only know the language but also a little bit about data structures.
A. Nonymous
Tuesday, October 10, 2006


If you want questions that are challenging and C++ specific look at a problem you are currently working on or one that you recently solved which you think took either a clever solution or one that would require a good grasp of the language.

While generally speaking I agree with the above sentiment that a good programmer may not specifically know C++, in my experience if you find somebody that knows C++ well you've found a good programmer. C++ is a complex language and is able to handle a lot of different programming paradigms reasonably well.

I don't think anybody can learn anything more than syntax in a few days. If you already knew C++ and haven't looked at it in a few years and can concentrate on the diffs between where the language is now and where it was then, maybe you can get up to speed in a few days. But if you've never seen C++ before I think you need more than a few days to really get a grasp of it. In a few days, at best, I think all you could really do is write in your language of choice using C++ syntax, assuming your langauge of choice isn't lisp or smalltalk. To get a good grasp of the idioms, best practices and dark corners of a language takes a lot more than a few days in my experience.

If you want to have some fun with this sort of thing, show a hard core VB programmer Duff's Device. Most of the ones I've shown it to just don't get it. The way you nest control structures in Duff's Device just warps the brain too much if your language doesn't allow you that sort of flexibility. Just like co-routines and continuations warp most people's minds (mine included) if they have been exposed to procedural and object oriented languages for most or all of their careers. It takes some time to wrap your mind around these sorts of things if you are not used to them.
Bart Park
Tuesday, October 10, 2006


Duff's device + coroutines - a nice mix:
http://www.chiark.greenend.org.uk/~s...oroutines.html
Mark Pearce
Tuesday, October 10, 2006


> "Liskov substitution principle, i.e. that you can
> substitute an object A with another object B which is a
> subtype of A without breaking any contracts. Rather
> fundamental to OOP."
>
> Isn't that polymorphism?

Polymorphism is much more than just the inclusion polymorphism -- check Cardelli taxinomy on that matter.

Anyway. LSP is indeed strongly tied to the inclusion polymorphism. However someone that understands LSP (even if that someone doesn't know the term) understands a lot about (incl.) polymorphism: he understands what a contract is.

Most of the unwarned designers will think of (inclusion) polymorphism in terms of: "I have a virtual function, I just need to override it, and let's roll". That's plainly wrong! As scolar examples of this bad design, check the "a circle is-not-a rectangle" example (Robert C. Martin (IIRC) has written on this topic, check on objectmentors website), and consider the definition of a sorted_list in terms of a list (any list class where you add as many "virtual"s as you wish).

STL is indeed important in C++ -- SL even more [IMG]images/smilies/wink.png[/IMG]. BTW it is not defined in terms of data structures, but in terms of algorithm complexities (-> O()'s).
Being used to STL does not mean we understand the various semantics, the RAII, etc. It took me some times to grasp what C++ is really about, even after years of STL use. STL and USENET put me on the tracks.


I don't know a lot of people that knows, nor people that will grasp the use of Duff-device in a few minutes just by looking at the code.
I'm not sure I'd want to work with someone who have been initiated to such low detail. I'd be afraid to see NIH, C with classes, and not C++. There are many more important stuff to know in C++ in particular, and in development in general.
Luc Hermitte
Tuesday, October 10, 2006


>> What if you find a good developer who doesn't know C++ yet (but could learn in a very short time)?

>> A good programmer doesn't necessarily know C++

Good thinking. I was going to start a baseball team and limit the search to skilled baseball players but you're right. I should also accept skilled football players, basketball players, etc. because they've shown that they're good at sports and it shouldn't be hard for them to pick up the rules of baseball quickly.

>> It's not school. "Cheating" is a good thing, having memorized syntax is worthless when reference materials are easily available. To me, the technical test is the explanation of the answer.

Hmm, let's see. The time it takes to produce memorized syntax? Maybe a few milliseconds, essentially zero. Time it takes to look up syntax in reference material? At best, a number of seconds if an integrated help system is available that gives you the right answer immediately. More likely minutes or longer weeding through material and Google results looking for the answer. Someone who has memorized more syntax, library details, etc. will be orders of magnitude more productive than someone who has to look it up every time.
SomeBody
Tuesday, October 10, 2006


Alyosha` said:

"A candidate that doesn't know STL will turn into an employee who churns out reams of unnecessary code to ... check error codes and bail, etc."

Unfortunately, I'm one of those programers, but I'm trying to improve. Can you tell how the STL can help with the last point you mentioned: check error codes and bail?
Gilgamesh
Tuesday, October 10, 2006


Ask them how to spell and pronounce Bjarne Stroustrup.

Unless, of course, it's Stroustrup that you're interviewing...
*myName
Tuesday, October 10, 2006


If I have a team of 18 people who've spent 2 years building up a codebase in language X then I'm not going to re-write every 6 months just because a new language pops up. Doesn't matter if X is "C" or "C++" or "C#" or "Haskell" or "Python".

If I have a candidate who's great and knows language X, then an otherwise equally great candidate who's delusional enough to think that "picking up" a language in a few days is the same as mastering the details, then the delusional moron will not get the job. It doesn't matter how much they whine. That just makes them look worse.

Besides, if they want the job they probably have a few days between reading the job ad and being called in for the interview, so if they truely can "pick up" the language in a few days and be an expert, why were they too lazy to actually do so?

Tuesday, October 10, 2006


"Can you tell how the STL can help with the last point you mentioned: check error codes and bail?"

Well, the alternative to using error codes everywhere is to use exceptions. This way errors can propogate several call stack frames easily, you can consolidate your error handling in a few places, and you all but eliminate the "oops, I forgot to check the error / do something intelligent with it". Plus, you can do things that can fail in something like a constructor or assignment operator (like, oh, say, allocate memory) -- which turns out to be extraordinarily useful.

It just so happens that exceptions go hand-in-hand with the STL. First of all, the STL uses exceptions to report errors, so you have to learn them eventually. But more importantly, the STL makes using exceptions a breeze.

See, the hardest part about using exceptions is all the cleanup you have to do if you throw an exception halfway through a function. You don't want to leak resources or memory. So the naive approach is to wrap everything in try-catch blocks and be religious about your error handling again. Ugh. Or, you can use a little technique called RAII -- google it for details, but essentially it means your cleanup code is always in a C++ destructor. This works because C++ guarantees that dtors are always invoked when an object goes out of scope, regardless of the code path (this was what someone above was talking about when they referred to stack unwinding).

What the STL does is provide you a set of containers which follow the RAII pattern. They turn out to be super useful in conjunction with writing exception-safe code.
Alyosha`
Tuesday, October 10, 2006


I would want to see if the candidate understands that C++ is not java.

Base b;Derived d; //Derived is a subclass of Base b=d; //what is the problem? answer: d is sliced Base* b = new Base();Derived* d = new Derived(); b=d; //what is the problem? answer: b is leaked

These aren't hardcore syntax questions or useless trivia. They are easy questions for someone who knows how C++ works at a fundamental level, yet plenty of people will fail them.
Tom C
Tuesday, October 10, 2006


to clarify: slicing is not always a problem and can be used in valid code but you need to be aware of it and sometimes it will be a leak, such as if the subtype has an owning pointer.
Tom C
Tuesday, October 10, 2006


To those who ask "why are you asking C++ questions when you should be asking general programming questions?", I think the answer is that C++ is a totally different beast than garbage collected languages like Java, C#, perl, Ruby or Python. If I were hiring for a position where Ruby was used, I'd accept experience in any language in that list. Not so with C++. There's a ton of niggling little details about C++ that don't translate over to all these other languages. I don't want to argue whether this makes C++ a crappy language or the One True Language; I'm just pointing out the fact that C++ is utterly unlike most other languages in the field. Sure, every language is unique in their own special way, but C++ is unique in ots uniqueness, at least among OOP languages.
Alyosha`
Tuesday, October 10, 2006


“Good thinking. I was going to start a baseball team and limit the search to skilled baseball players but you're right. I should also accept skilled football players, basketball players, etc. because they've shown that they're good at sports and it shouldn't be hard for them to pick up the rules of baseball quickly.”

I’m assuming you’re being sarcastic, but that actually works quite well, unless you’re putting together an MLB team. If you have a 26 person company where the absolute worst developer in your company is one of the top 1000 developers in the world, then that’s a good analogy.
28/w
Tuesday, October 10, 2006


Alyosha,

>> There's a ton of niggling little details about C++ that don't translate over to all these other languages. <<

Who would you prefer to hire? Somebody who's really smart, or somebody who knows all those niggling C++ details?

In an ideal world, you could find a candidate with both sets of attributes, and of course you should hire here. But back in the real world, you've got to make a choice...
Mark Pearce
Tuesday, October 10, 2006


here = her
Mark Pearce
Tuesday, October 10, 2006


> Someone who has memorized more syntax, library
> details, etc. will be orders of magnitude more
> productive than someone who has to look it up
> every time.

Rubbish. Productivity has nothing to do with how fast you write code and everything to do with how well you write code.

I'll take well structured, well designed, well written code over churned out spaghetti code any day.
Jussi Jumppanen
Tuesday, October 10, 2006


> It just so happens that exceptions go hand-in-hand with the STL.

Sounds like another good reason to stay away from STL [IMG]images/smilies/wink.png[/IMG]
Jussi Jumppanen
Tuesday, October 10, 2006


Jussi, you can use the STL just fine without exceptions. I use it a lot, and I don't use exceptions.
sloop
Tuesday, October 10, 2006


In the real world, with otherwise identical people the one who knows the language well will be more productive than the one who doesn't know the language as well. Even if the language is python or lisp, that still holds true.

Given one guy who's a bit smarter but knows 50 languages other than the one your team uses, hiring that guy means taking time to wait for him to learn the language, and unless he's remarkably more intelligent than the other guy, that'll probably be somewhat irritating.

So, assuming you're only interviewing smart people to start with, checking basic things like "do they actually know the language they claimed to know to the level that a real expert would" covers both honesty in the resume, and helps in that experts tend not to be retarded. A C++ expert (and that isn't limited to memorizing language features, but includes knowing when to use or avoid the feature) helps with determining if the guy is smart.

(Which is a point: the natural followup to any language feature question is "when would you do that?" and sometimes the correct answer is "when I'm on drugs".)

Tuesday, October 10, 2006


>> Rubbish. Productivity has nothing to do with how fast you write code and everything to do with how well you write code.

What does speed of coding, fast or slow, have to do with code quality? A developer who takes seconds to type the correct line of code is going to be more productive than a developer who takes minutes or longer. Someone who has fopen's common usage memorized will naturally be much more productive than someone who has to take 30 minutes every time to look up the second parameter and then debug it until they realize they needed the "b". It's really hard to disagree with this. Someone who takes two seconds to type the correct line of code is going to be more productive than someone who takes 30 minutes.
SomeBody
Tuesday, October 10, 2006


I bought the Wrox C# book and learned enough C# in 3 days to pass a pretty tough technical test in a C# .NET shop. I did that because I knew that I could do the job well, I needed to get past the stupid key word filter. I have no regrets.

If you consider that coding is oh, 5 to 10% of the effort of creating sw systems that people actually use, testing potential employees on how much syntax they can spit out as if they were in school will pretty much guarantee you the wrong type of employee. You wind up with people more interested in the tool than your business, and that's never happy.
Steve Hirsch
Tuesday, October 10, 2006


>> It's really hard to disagree with this. Someone who takes two seconds to type the correct line of code is going to be more productive than someone who takes 30 minutes. <<

It's not 30 minutes, it's 5 minutes. And it's only 5 minutes on the first pass - then it's 2 seconds.

In the meantime, the guy who spends 80% of his time and effort on memorising the entire C++ lexicon is always going to lose out on the person who spends 20% doing the same thing, and the other 80% on communication with his peers and customers, learning the business domain, learning other dev tools, and so on.
Mark Pearce
Wednesday, October 11, 2006


If what you're trying to do is assess language proficiency for C++ (rather than assess problem solving skills, communication skills etc.) then I would recommend proficiency tests. There is very little you can determine about language proficiency by asking a few questions in an interview: it's just too hit and miss, especially with a language as baroque as C++.

I use one I am particularly pleased with (email me if you want the name of the supplier).

The results come back placed against all data from the C++ test that the company has run, so you get to see how your candidate scores on a scale of other tested individuals.
Leo Zancani
Wednesday, October 11, 2006


I believe Joel spoke on this topic once.

I think it depends more on your needs than anything else. What shape is the sw in, how old is it, what gotcha's are lurking there, and how important is the sw to your companies well being?

If your sw makes heavy use of inhouse template metaprogramming, you're not going to want to hire a C++ developer who has never done more than worked with Boost, unless you're strictly hiring him be a *user* of your inhouse template metaprogramming.

Saying "I know C++" doesn't really say a whole lot because C++ is such a beast. You don't need to be an expert in C++ to get things done, but some things won't get done in a "good way" without being an expert in C++.


So in the end, the question is, what does the employee need.
Michael Reiland
Wednesday, October 11, 2006


that should read

So in the end, the question is, what does the *employer* need.
Michael Reiland
Wednesday, October 11, 2006


You should absolutely, without question grill your candidates on thorough, detailed knowledge of C++ AND general programming concepts.

I don't understand why one would defer specific knowledge to general skills, or vice versa.

Personally, while I'd love to hire people based on their theoretical or ancillary knowledge, the simple fact is -- I have to produce a working system for customers, under serious time constraints. It has to be correct, it has to work on the specific configurations I need; and if it doesn't, then the project is late and we're sunk.

Anyone else have to deal with this situation? I think it's called business.

And in the business world, it's just not enough to be an underskilled generalist for a position; in most companies I've worked for, once you step on board, it's a moving sidewalk with deadlines and expectations. You shouldn't be fumbling around with the C++ reference syntax when there's real work to be done.

Plus, it's an interview -- you decide your risk tolerance level when hiring. But asking both general and highly specific, syntax questions gives you more information on which to make a decision.

(speaking of which, C++ candidates who don't understand references, bother me highly -- I always ask about that, in a "show me an example of when would you use them," not a "what are they" sense)
indeed
Wednesday, October 11, 2006


I guess the angry voices out there never really programmed in C++. They probably think - hey, C++ is just that plain ol' C with classes and new instead of malloc - cool.
Really C++ is a huge beast with very sharp teeth. Powerful but dangerous and takes time to tame. I don't care if Mr. Genius is able to learn himself C# in 3 days. C++ is not C#
s.
Wednesday, October 11, 2006


>> It's not 30 minutes, it's 5 minutes. And it's only 5 minutes on the first pass - then it's 2 seconds.

No, it's only two seconds the next time if the person actually remembers. The argument here seems to be that no one should ever be expected to remember anything since it can just be looked up.
SomeBody
Wednesday, October 11, 2006


I remember C++ as not too difficult, but it was a while ago. If C++ is that much harder to learn well, then drop it, it's not the right tool for the job.

Hiring a programmer based on the syntax s/he knows is like hiring a mechanic based on whether s/he uses a wrench or a ratchet. If all your developers do is program, then you need to reorganize your department.
Steve Hirsch
Wednesday, October 11, 2006


here is one that most C++ programmers have never used, including myself. I know what they are but never used them..never had to.

what does the keyword mutuable and exclusive mean in C++ and give me an example of how i could use either one.
OpenGL_Programmer
Wednesday, October 11, 2006


"what does the keyword mutuable and exclusive mean in C++ and give me an example of how i could use either one"

mutable means you can modify a variable from a const method. I don't use it very often, but I do use it on critical sections so I can access variables in a critical section from a const method.

exclusive isn't a keyword in standard C++.
sloop
Wednesday, October 11, 2006


oops what i mean was mutable and explicit. for some reason got caught up in thinking of the phrase "mutually exclusive" for some reason. thats when you know its really late and time for bed haha.

has anyone ever used mutable or explicit and what for?
OpenGL_Programmer
Thursday, October 12, 2006


I already mentioned an example of where you might use mutable. explicit is used with constructors to prevent implicit conversions. Take a look at the auto_ptr(T *) constructor for an example.
sloop
Thursday, October 12, 2006


Mutable is used in multithreading programs where the act of aquiring a lock changes the lock structure, declaring the lock mutable lets you keep 'logically const' methods const, e.g. a method that has to lock object state, but does now change it.

Explicit stops all sorts of crazy hidden conversions happening, we used it by default on all single argument constructors.

I think these are good questions to ask, a 'C++ expert' should be able to answer questions like these no probs.
Manny
Thursday, October 12, 2006


I use explicit every time I define a single-argument constructor on types (*) I do not wish to have an implicit convertion from the argument type.
(*) Typically when they have an entity semantics. Sometimes I permit the implict conversion on value semantics based types.

Regarding mutable, sometimes I use it to implement proxies, and quite often on the mutex attributes of my objects.
Luc Hermitte
Thursday, October 12, 2006


OpenGL_Programmer what bothers me, is that not only you don't know why the 'explicit' keyword can be useful, but your C++ colegues don't know it either. It just means that neither you, nor your colegues have read even one decent book on C++. You guys may be wizards of 'C with classes' but this ain't enough to call yourselves C++ programmers. Don't get upset, just read a book. Until you know such "details" call yourselves C++ students. Here is a very short example:

struct Fred {  Fred(int n): v(n) {}  std::vector<int> v;}; int main() {  using namespace std;  Fred f(1);  f.v[0] = 5;  cout << f.v[0] << endl;  f = 7;  cout << f.v[0]; // <---wtf?}

and if you say, that you don't really have to use explicit in the constructor up there, then I say - you don't have to use the loops either, goto is theoretically good enough.
A C++ student
Thursday, October 12, 2006


>> The argument here seems to be that no one should ever be expected to remember anything since it can just be looked up. <<

My argument is that you shouldn't memorise anything until you come to use it, and even then only memorise areas that are tricky or time-consuming to understand.
Mark Pearce
Thursday, October 12, 2006


"has anyone ever used mutable or explicit and what for?"

For explicit, see Luc's answer above. He is exactly correct.

The best way I can describe the use of mutable within a class is with an example. Say you are writing a string class (I know, why would you, but this is an example). You will probably have a length() method that is declared as const. Invariably some ninny is going to iterate whrough it with a loop like this:

const MyString s("This is my string, not a std::string.");for(int i(0); i < s.length(); ++i){  //  Do something with s[i]}

So, why not only compute the length only once and store it in a member variable? (You will also need a way to tell that the length value is invalid, either thorugh a seperate flag or a special value.) The only problem is that because length() is declared as const it cannot modify a member variable. In swoops mutable, its cape flapping in the wind. By declaring the member variable as mutable, the const method length() can modify its value. This little trick will reduce the above loop from O(n^2) to O(n).

(Wow, I'm in a good mood this morning.....)
A. Nonymous
Thursday, October 12, 2006


A C++ student..you are right about one thing and i read your code and i get it. the one thing you are right about is that i dont really see an overwhelming need to use it. i can see where is certain circumstances you might need it.

The point that i would like to make is that at least i knew that those two keywords even exists. go out and find how many C++ programmers have ever even heard of those keywords. many will give you the blank stare. Its because its not used..hardly ever. so to say that i am not a wizard in C++ or something doesnt offend me but i can hardly then i could be disqualified as a C++ programmer because i really dont see much use in using those 2 keywords, especially when there is a lot more to C++(STL for example).
OpenGL_Programmer
Thursday, October 12, 2006


Template metaprogramming is one of the dark corners of the C++ language, but keywords like explicit and mutable are not and have been discussed in classic texts such as Effective C++ (which I expect every good C++ programmer to have read), or columns like GotW, for years. It's not that they are "overwhelmingly" useful, it's that it is very reasonable to expect a programmer with 3+ years of C++ experience to have used them and found them useful at least a couple of times. If you tell me that you don't see that much use for mutable, I will count it against you because it probably means that you don't care much about const-correctness either, which is a bad sign.
...
Thursday, October 12, 2006


OpenGL_programmer:
What bothers me even more is that even given a few examples from various people along with the explanations, you still fail to realise that the 'explicit' word makes your code less bug prone! Unlike you I always use that word in needed constructors, and I rather wonder if I even should allow implicit conversion in a given constructor. Thus I KNOW how my code is going to behave. But you create UB possibility. The sad thing is you're too blind to see that or (hopefully) just too stubborn to admit that.
I am glad we had our conversation, because it's an example how huge C++ is.
Anyway do what you want and have a nice day. EOT
A C++ student
Thursday, October 12, 2006


if you need something to not be implicit you can use static_cast. just what i have always done i guess.

i understand fully why explicit cuts down on bugs and i understand the examples.
OpenGL_Programmer
Thursday, October 12, 2006


"if you need something to not be implicit you can use static_cast. just what i have always done i guess."

The point of explicit is to prevent the compiler from doing implicit conversions in inappropriate places behind your back.
sloop
Thursday, October 12, 2006


i know i know, i am not here to flame or make anyone mad or irritated. perhaps i should re-evaluate how i design some of my class functions but in my 4+ years of C++ development i have never had a bug just because some int was, at compile time, converted into a float or vice versa. if you understand the math algorithms(for example) and understand what is expected and implement that then there is really not much need.

this whole thing started because i merely mentioned the fact that asking about those two keywords would be a good question because many people have never even heard of the keywords, even if they did read the best C++ out there much less know what they do. I was trying to play a little devils advocate but didnt mean to irritate anyone. sorry if i did.
OpenGL_Programmer
Thursday, October 12, 2006

View more random threads:

• Sản Phẩm “Sống” Nhờ Có QC Giỏi
• Chung cư Essensia – Điểm đến cho cuộc sống tiện nghi
• 05 Mẹo nhỏ đơn giản làm sạch ăngten cho tivi Panasonic nhà bạn dịp Tết
• Tiếp theo C/C++ sẽ là gì ?
• Thế nào là một lập trình viên giỏi (Theo bạn)
• Chứng thư số là gì và nó có vai trò như thế nào đối với hóa đơn điện tử?
• Hướng dẫn cách khắc phục tình trạng laptop, máy tính bị treo
• Làm sao để lập trình giỏi???
• Test đầu vào ở cty Data Design
• Khu đô thị Vĩ Cầm – KĐT sinh thái ven sông Công

[diepminhchautoan]

You are still completely missing the point. Several examples were mentioned using explicit on constructors taking raw pointers. Did you miss those or did you just not understand the importance of explicit on those?

Just read up on it and you'll see why it matters. Don't think for a moment that it's something you don't need to know.
sloop
Thursday, October 12, 2006


yes sloop i read those and understand why they are useful and sending in something that the compiler converts without your knowledge or goes against your intent could cause of bugs.

i have just never personally used them or didnt really see a need for them and evidently so far i havent seen any side effects of not using them.
OpenGL_Programmer
Thursday, October 12, 2006


Wow...

This is actually something that bothers me a lot about C++. All of the virtually unspoken rules of how things need to be done to be done right. Things like "all single parameter constructors should be explicit" and things like Andriescu's scope guard, and i'm almost certain I have no idea how to write a copy constructor / assignment operator so that it is perfectly exception safe and thread friendly. I look at it all and say to myself, 'I'd like to be a good C++ programmer, but I'd much rather be getting my work done'.

Does anyone else feel like it takes them forever to get to actually writing the guts of their code?
Keith Wright
Thursday, October 12, 2006


"Does anyone else feel like it takes them forever to get to actually writing the guts of their code?"

No, you're making it a bigger deal than it actually is. And it's not like there's not a lot of these rules in other languages as well. C# has them, Java has them, etc.

I use all of these languages, and I don't feel like C++ is much trickier or requires much more boilerplate code. If anything, there are a lot more tricks in C++ (like RAII, ScopeGuard, templates, etc.) that allows you to write a lot less, and cleaner code. Whenever I go from C++ to C# or Java I feel a little handicapped because I have to do a lot more manual labor than I do in C++. I have to worry about resources, the containers suck, there are no good generic algorithms, and so on.
sloop
Thursday, October 12, 2006


"what questions would you ask as an interviewer to measure the level of proficiency of a candidate in C++?" Vick, I'd be asking what sort of programmer do I want first.

In 1981 a wise old PL1 programmer gave me this advice....a good programmer is a simple programmer....and yes he had a full beard and could drink me under the table.

All the C++ experts I've worked with were measurably poor at turning customer requirements into designs into code into working products but great at the finer points of template classes and passing C++ tests in interviews.
Ginetta Pete
Thursday, October 19, 2006


Trích từ :
http://discuss.joelonsoftware.com/de...el.3.400499.68

[phuongnguyen]

hic,tiếng anh ko,đuối quá

[cuuseo]

Chắc chắn không dành cho mình

[minhtiepvn]

dịch đuối quá. hix