Oh I missed that. I think that I thought you'd put it in a cpp file which is perfectly fine.
Originally Posted by jeffcobb
Even those of us that mostly just come here to help can always expect to learn a thing or two. I know I do every now and then. I don't want to seem like I'm picking on you, your C++ knowledge is very reasonable and I don't ever want to discourage others from posting code. Critiquing others' code is somewhat similar to a demonstration by a vacuum cleaner salesman. There's always someone else who can show something even better.
I suppose now that I've started this, I may as well elaborate.
Having less code is a good thing. Other problems with implementing a copy-constructor when it isn't necessary include someone adding another member and forgetting to update it. Of all the principles out there YAGNI is one of the most important in my books.
Re: Copy ctor: true enough in this case but in general having a copy ctor is a good thing.
That's just it, they are initialised in the code I posted - default initialised. Your code does that same thing but in a less direct way. The end result is the same apart from being perhaps a smidgen slower, and it takes more code. More code means more opportunities for bugs. I can think of no context in which the version you wrote is better other than if you are paid by the line. :p
Re: Initialization ctor: again, true enough in this case but being in a habit of initializing your variables is s a good thing.
I must confess that I rarely use std::fill either.
Re: memset vs std::fill: agreed although either will work just as well.
Re: const and the nameList: At this point I was just trying to get through the test code as quickly as possible.
No, certainly not, but popular opioion is that one is clearer than the other
Re: ptr-> vs (*ptr). : you say tomato, I say tomahto. One is not inherently more correct than the other.
A large number of getters and setters typically means that the code that deals with those variables is not accompanying the variables. OOP afterall is all about the co-habitating of functions and data. By using getters and setters, the data is in one place, and the functions/algorithms that deal with it are most likely in an unrelated place.
Re: us of string streams: That did occur to me, it really did. The reason I did not use it over the more old-school sprintf() stuff is that I was trying to keep the OP in mind. Basically if he/she didn't know that std::map could be used in this manner, I didn't want to confuse him by adding more std:: stuff, hopefully so he could focus on the solution that I presented here. In other cases, stringstreams are indeed my friend :)
Re: getters and setters: This is the first time I have ever heard that they are bad for encapsulation when indeed that is what they facilitate. Care to back that statement up?
Have you ever heard the statement "Laziness is the foundation of efficiency"? It's a memorable quote. :)
Re: getters and using const: agreed and in production code I do. Again for me this was an exercise to see how quickly I could generate a solution for his/her problem
Oh you do that too. Well we certainly have something in common then!
(while eating dinner and watching Fringe with the wife).