Searching Array (Help Please)

Did you notice how your compiler complained that the end of Account was reached without a return value? Your Account prints things to cout all by itself, and doesn't return a string; hence that string that you fail to return can't be printed to cout by the main program. Either just call the function from main without the cout, or have Account return a string.

Looking at the code though I see no immediate reason for it to stop reacting...

Originally Posted by tabstop

Did you notice how your compiler complained that the end of Account was reached without a return value? Your Account prints things to cout all by itself, and doesn't return a string; hence that string that you fail to return can't be printed to cout by the main program. Either just call the function from main without the cout, or have Account return a string.

Tabstop: good catch. While I had no desire to fool with a PAUSE command I was intrigued enough to write a work-around just to see wth is going on. You saved me the trouble so thank you. I have enough other code-projects in-progress ATM...

Yup thats it...again good catch Tab.

No, it just says that there is a problem...there isn't anything wrong at compile. That is why I am confused...lol. Everything displays just fine and all, but then it says it is unresponsive.

Originally Posted by jeffcobb

Well I appreciate all of the tips though I really didn't need them as I was keeping my primary goal in mind to demonstrate how the OP could solve both this (searching) and his other problem (sorting) by leveraging the STL. The rest is just window-dressing. I am surprised that I did not get the namespace nazis on me for 'polluting the namespace' by using namespace std.

Oh I missed that. I think that I thought you'd put it in a cpp file which is perfectly fine.
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.

Re: Copy ctor: true enough in this case but in general having a copy ctor is a good thing.

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: Initialization ctor: again, true enough in this case but being in a habit of initializing your variables is s 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.

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.

I must confess that I rarely use std::fill either.

Re: ptr-> vs (*ptr). : you say tomato, I say tomahto. One is not inherently more correct than the other.

No, certainly not, but popular opioion is that one is clearer than the other

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?

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: 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

Have you ever heard the statement "Laziness is the foundation of efficiency"? It's a memorable quote.

(while eating dinner and watching Fringe with the wife).

Oh you do that too. Well we certainly have something in common then!

Actually my grandmother (one of those kind of people whom the Foxfire books were written about) taught me that at a very young age ("I am not lazy, just efficient"). I loved her way of looking at the world. She was probably the most "real" person in my family.

YAGNI: interesting. Never heard that one before. There are definitely two lines of thought as it relates to most of these points: The "be correct at any cost" and the "the only correct way is the low-cost way" perspective. At times I have seen on this forum where a solution to a given problem is picked apart, not because it didn't solve the problem but because it offended someone from a design standpoint. I will be the first to admit that if I am under a time-crunch (like I need to make dinner, do something for my day job, etc) or just want to get through with a solution (like now: its starting to get really HOT here in Las Vegas right now and most of the time I want to spend less time with a heat-generator on my lap), I tend to start taking shorter and shorter cuts if you catch my drift. Not an excuse for less than perfect code but I am a less than perfect person. This is also influenced by the current work-load; in the case of coding this + Fringe + dinner, if you want to know the truth add to it: Working on a system platform of tools with MK27, designing and writing a distributed computing platform to help deal with regulatory issues for work, writing a Python source code formatter that is also CVS-aware for auto-injecting comments (the script is python but the source it manages is everything from C/C++ to Perl to Python to Bash scripts to Ruby to Makefiles to...) plus working on debugging tools for a custom development platform/OS/environment. The point is, the more thinly I have to deal with time-slices on my personal scheduler module, quality can get sacrificed. I still try to maintain quality on stuff directly tied to the solution-part of an answer but the stuff on the edge can take it in the shorts sometimes and for that I apologize. I am human...well don't ask my wife...

Sometimes I have seen where more code is encouraged and sometimes I have seen it discouraged. I am not supporting more code simply for the sake of more code but rather the case where more code can lead to better robustness like in the case of getters/setters. By themselves they add little more than facilitating encapsulation but by adding a little *more* code, you can provide data validation which can mean a lot in any situation where the code is heavily scrutinized and/or regulated. I did not add the validation for any of the lazy-git reasons outlined above but I cannot get behind removing setters for example that *did* do validation just for the sake of having less code. In this case your code winds up becoming more brittle with less code. If code is needlessly complex however, yes less code is better and more easily understood by others reading your code after you leave a team for example.

All of this does bring up something that I alluded to in another discussion here but this is one way that having been around a long time can be a detriment to your ability to do a good job at the design as well as the implementation level. Think back over the past few decades; what was considered the commonly-accepted "right" answer for any given thing was usually invalidated or worse, chastised just a few years later. Take for example Hungarian notation....in the early Windows years, it was considered not only correct but essential. Now however such thinking usually results in the rolling of eyes and snickers when viewed through the lens of 20/20 hindsight. If you stick around long enough you wind up seeing so many of the so-called "best practices" debunked that it can be hard to remember if any given paradigm is still intact or not...I suffer from this often. I know, it is up to me to adapt to the times but still I wind up implementing things in ways that will have others going "WTF was he thinking?" where 10 years ago it would have been accepted if not actively supported as the proper and correct thing to do.

rant off.