Pointer to functions

Quote:

---

Originally Posted by dcjr84

I might, it depends on the situation. But at least the post-increment operator or pre-increment operator have a meaning behind their use. It is not pointless to use either one of them. you could not just omit one of them entirely from a situation and still get them same result. Using void to indicate no parameters in C++ is a huge waste of time and code space, which leads me to my next point...

---

But pre- and post- increment operators are different in that there is a real run-time difference. There are many people who use post-increment operators all the time in for loops:

Code:

---

for (int i=0; i<max_value; i++)

---

but then use the same syntax for iterators:

Code:

---

for (my_containter::iterator it=aContainer.begin(); it!=aContainer.end(); it++)

---

but this has hidden run-time penalties. See this FAQ for more information.

Studies have shown that fixing run-time problems after development are 10 to 1000 times more expensive than problems caught at development time (I'd put 'void' in the latter case since there is no run-time difference.) Thus any problem related to pre- and post- increment operators can be immensely more expensive than 'void'.

Now, I'm all about following Knuth's law, but this is an optimization that can be easily avoided by following the right style. My recomendation: Only use post-increment operators where the code is cleaner by using them.

That being said, I wouldn't refuse to hire someone because the code they developed in the past used too many post-increments. I might mention the problems during an interview and see if they would be willing to change the way they code. Regardless, I would show them the project's coding style document before they started developing and make sure to note the pre- vs. post- increment section and then expect them to follow the style guide thereafter.

Quote:

---

Originally Posted by dcjr84

I will even take this one step further. Let's say somehow a programmer did get hired into my company that did this without me knowing. After a while, I would notice he used such notation. I would keep track, over the weekly/bi-weekly pay period, of how many times he used the word void in a no argument function signature. Then, I would figure out on average how long it takes him to type void each time. I would multiply the two together to find out how much total time he has wasted typing void in such situations, multiply it by his hourly rate, and deduct it from his paycheck.

---

That sounds very exteme to me. This should be easily taken care of by showing the programmer a document outlining the code style guidelines for the project. Mistakes will happen, but you correct him (or her). But if after time, they cannot follow directions, then that represents a deeper problem -- and that problem I would be unwilling to work with long-term.

Quote:

---

Originally Posted by dcjr84

I am sure others feel the same way, but about other aspects of the language. Like people using void main() instead of int main(), etc, etc. It's just the way I feel about it.

---

I don't think there should ever be a single style-related restriction to hiring someone. If the developer is talented -- they should be able to adapt to new guidelines. Follow up on that. If, in the interview, they explain that they won't follow any other guidelines than their own, then yes, don't hire them. But people can and do adapt.

- Kevin

Quote:

---

Originally Posted by exterminator

I would not hire a programmer if when I asked him about pointer to functions and pointers to member functions and he started discussing abomination of void and programming incompetencies related to it.. ;) :D

---

:lol: :thumb: :D :lol: True, true!!!

Quote:

---

Originally Posted by exterminator

I would not hire a programmer if when I asked him about pointer to functions and pointers to member functions and he started discussing abomination of void and programming incompetencies related to it.. ;) :D

---

Haha, yeah, this is a good point.

Honestly though, I was only goofin' around.

I mean, I don't like it when people use the void syntax, and I would never use it, but that's about the extent of my feelings towards it.

I was just really bored today; thought I might have a little discussion about something off the wall :D

Yeah, I know.. but this has gone so off-topic.. :D

In my opinion, that usage of void is not as condemned as to reject a candidate.. or lessen his paycheck... why?

1. Good guys are hard to find and I cannot reject based on 1 limitation only.
2. That thing can be corrected.
3. If I recruited him and he is working in my team (assuming I am the manager) - I will not try to cause him distress by cutting the paycheck.. why? He may leave - I will have an attrition factor in my own performance appraisal. I will get negatively affected.

I will try the best I can to let him know not to do it.. if he does.. fine.. or else I will sneak in and change the code :D ;)

To summarize : I don't think it is that much of a serious issue.

Quote:

---

Originally Posted by Mitsukai

pre-judging or w/e its called in english.

like im now pre-judging that because you say that you dont care about that evry person is diffrent and likes it in his own way.

bad stylish wise? how can style be bad? i understand some basic styling like tabbing scopes/namespaces/classes for easy reading but some other person might not like this and do it his way

---

Pre-judging, if you like. I think of it as "forming an opinion". I also get a bit suspicious of someone who uses "superclass" when talking about C++, or someone who can tell me about constructors, but is vague on destructors. These lead me to think "Java programmer trying out C++". Using "(void)" makes me think "C programmer trying out C++". I'm not saying it's a sure-fire indicator - it's just one small point that contributes toward an overall impression of a candidate's suitability.

I've never been in a position of hiring people but what you are doing is probably no worse than what I would be tempted to do - give them a programming exercise and immediately eliminate any that used style I do not like including K&R bracing and any excessive use of Hungarian notation.

Quote:

---

Originally Posted by NMTop40

I've never been in a position of hiring people but what you are doing is probably no worse than what I would be tempted to do - give them a programming exercise and immediately eliminate any that used style I do not like including K&R bracing and any excessive use of Hungarian notation.

---

Awe c'mon.. I won't get hired by you then.. :D

I tend to use both but it is our coding guideline because of which I need to NOT do it. The bracing is what I choose because it saves a new line.. You get to see more code in the text area. ;)

Hungarian notation, I started using because I was a VB programmer to start with my professional career. It helped a lot because then we could use Cntrl + Enter and the names starting with a character would get shown in the editor.

Rejecting a candidate on style is the worst thing that I guess can happen to a interviewee. They shouldn't be. I mean there is always scope for change. You guys are just being a little harsh (and off-topic :D ;)).

Quote:

---

Originally Posted by dcjr84

I will even take this one step further. Let's say somehow a programmer did get hired into my company that did this without me knowing. After a while, I would notice he used such notation. I would keep track, over the weekly/bi-weekly pay period, of how many times he used the word void in a no argument function signature. Then, I would figure out on average how long it takes him to type void each time. I would multiply the two together to find out how much total time he has wasted typing void in such situations, multiply it by his hourly rate, and deduct it from his paycheck.

---

Interesting.

Now, a few questions. If you see somebody using two declarations when one is sufficient, like that:

Code:

---

MyClass var1;
MyClass var2;

---

Instead of the shorter:

Code:

---

MyClass var1,var2;

---

Would you deduct this lost of time from his paycheck?

And, if he has many functions or methods having the same prototype to declare.
Would you accept:

Code:

---

double f1(int,double);
double f2(int, double);
double f3(int, double);
double f4(int, double);

---

Or would you prefer:

Code:

---

typedef double Func(int, double);
Func f1,f2,f3,f4;

---

And, for a set of functions returning a value of the same type, would you accept the verbose:

Code:

---

ErrorType f1(int, double);
ErrorType f2(int);
ErrorType f3(const MyClass&);

---

While, it's faster to write:

Code:

---

ErrorType f1(int, double), f2(int), f3(const MyClass&);

---

Would you require "using namespace std;" at the top of each translation unit which uses std:: more than a few times?

Quote:

---

Originally Posted by NMTop40

I've never been in a position of hiring people but what you are doing is probably no worse than what I would be tempted to do - give them a programming exercise and immediately eliminate any that used style I do not like including K&R bracing and any excessive use of Hungarian notation.

---

It's not very fair to refuse the K&R bracing style, because the bracing style is something defined by guidelines of a programming team... And a few bracing styles are used, so you can't know which one will be used when going to an interview.
The problem is that there may exist at least two different people:

• The ones who hate K&R style and won't hire you if you use it.
• The ones who love K&R style and won't hire you if you don't use it.

So, it's a lottery.
You can't know which style will be considered as an abomination... And, since I'm style-agnostic, I feel that this reject would be a bit stupid.

It's a bit like asking someone his favorite color and don't hire them if they answer "green" while the exact answer was "blue".

The old "saving a line" argument doesn't really hold up anymore in modern editors which can display as many lines as you need to see. If you don't put any comments in your code you also can see more code, so perhaps one shouldn't include any of those either.

Hungarian notation doesn't annoy me quite so much and I do use prefixes myself in certain situations but not usually to define a variable type other than sometimes using p for a pointer. I will also sometimes use an n prefix to denote "number of" but that is really part of the variable name - it is an abbreviation rather than a type description. (Similarly the p prefix means "pointer to").

Bringing style from a different language into C++ is exactly what we have been talking about in this topic.

Candidates get rejected for all sorts of stupid reasons other than ability. The main reason a candidate is immediately rejected from most jobs is for not having played with the right toys. Design nowadays is about quoting the fancy names for patterns. Ability to use your brain doesn't enter the equation anymore.

Quote:

---

Originally Posted by SuperKoko

It's a bit like asking someone his favorite color and don't hire them if they answer "green" while the exact answer was "blue".

---

Exactly!! :thumb:

I mean.. I have seen recruiters struggle so much.. and there are so many other things that need to be considered befor taking a decision on "hire" and "no-hire". Style to me is like the least important and to me : it does not matter. I will recruit someone who can learn. Who when the need comes can write a VBA marco as well program in C++. People capable of working on more than one technology are boost for any team. And if that is the case, it is very tough to maintain one style.

There are so many better things to know about a candidate to reject him. Style does not qualify. Moreover, a lot depends on the level of experience of the interviewee.

Quote:

---

Originally Posted by NMTop40

The old "saving a line" argument doesn't really hold up anymore in modern editors which can display as many lines as you need to see. If you don't put any comments in your code you also can see more code, so perhaps one shouldn't include any of those either.

---

Don't take it otherwise, I don't usually write code that is longer than 20 or so lines in a function. In that case, I am okay. Comments are a different thing.

Quote:

---

Originally Posted by NMTop40

Candidates get rejected for all sorts of stupid reasons other than ability. The main reason a candidate is immediately rejected from most jobs is for not having played with the right toys. Design nowadays is about quoting the fancy names for patterns. Ability to use your brain doesn't enter the equation anymore.

---

Yes, that is a truth that I accept and I hate that this situation exists. That has made people more bookish than ever. It is of course good to know about patterns but it is more important that to know of a candidates problem solving skills. I would not hesitate for a moment in recruiting a candidate who does not know what a smart pointer is but if I asked about self-cleanup - he tells me an example which shows RAII. That is a sure hire! (alteast for me)

I value ideas more.. I have seen many people talk about variety of stuff but not knowing the basics - they bring ill-fate to an organization and sometimes are non-manageable and become sooner a liability.

But of course, all that depends on the experience level the recruit is for. It is not expected that a guy is having 5+ or years of experience but does not know what a Factory is or how a Visitor can be implemented.

Since you are talking about the design level, I guess you are targetting a higher level of experience than what my arguments target.

Quote:

---

Originally Posted by SuperKoko

It's not very fair to refuse the K&R bracing style, because the bracing style is something defined by guidelines of a programming team... And a few bracing styles are used, so you can't know which one will be used when going to an interview.
The problem is that there may exist at least two different people:

• The ones who hate K&R style and won't hire you if you use it.
• The ones who love K&R style and won't hire you if you don't use it.

So, it's a lottery.
You can't know which style will be considered as an abomination... And, since I'm style-agnostic, I feel that this reject would be a bit stupid.

It's a bit like asking someone his favorite color and don't hire them if they answer "green" while the exact answer was "blue".

---

Ok, I guess if I were hiring I could simply mention that the programming style is block and obviously if they objected to programming that way, they would choose not to join. If I were interviewed and was told that I would have to program K&R I would probably refuse to join.

My ideal really would be to start my own software company.

what is K&R?

Quote:

---

Originally Posted by exterminator

Exactly!! :thumb:

But of course, all that depends on the experience level the recruit is for. It is not expected that a guy is having 5+ or years of experience but does not know what a Factory is or how a Visitor can be implemented.

Since you are talking about the design level, I guess you are targetting a higher level of experience than what my arguments target.

---

But that is assuming that they know that the pattern they have been using for years is called Visitor. I'd rather you'd give them a problem where the solution is the visitor pattern and see if they use that technique in the design for the solution rather than hit them with names.

Also, interviewers often ask far too much detail. It is reasonable that a C++ programmer might have heard of boost, and would probably know one or two of the classes, so you might ask them what is boost and if they know any of their classes or libraries, but don't expect them to know all the detail!

I think one of the brainbench tests asked whether you should inherit "public virtual" or "virtual public". I'm not sure it even makes a difference, although i'm pretty sure I have used public virtual. It's rather a stupid question because in reality you'd try one and if it were wrong, it would fail to compile so you'd try it the other way.

i think th reason they ask so much detail. is not to test if they have much "knowledge" about certain things, but they watch the reaction of that person. this way they know how he works and is able to work socially in the project with other project members.