DaWei

This isn't possible use of a file, it's definite use of a file. That's why I raised the question. Without external storage or non-volatile memory, one would have to regenerate their contact list every time they powered down the machine.
As I also mentioned, a record number and a unique key aren't precisely the same thing. Sorting by a numerical index would require that the indexes be generated for the data in sort order. The sort order might change from time to time (name? state? phone number?). Using it to distinguish otherwise duplicate records is something else, again.
I can't reconcile this with your actual statement, maybe I'm just thick:
Why? Do you think he needs random access to the file so that he can alter records in place?

As for bringing one or two records in at a time, that's for 20 years ago when memory was scarce. With your desktop machine, you probably don't realize that disk access is orders of magnitude slower than memory access. It's your good OS and its cache that keeps you from seeing just how poor direct, random disk access is as a solution.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Adak

I've done a flat database for a geneology program that used only a file with fixed length fields. Almost nothing in memory. Yes, it was several years ago.

Of course, the performance is not comparable with in-memory speeds, but it is faster than you might think, simply because of the large disk cache's used today.

In that case yes, he would alter records in place, on the disk.

Think of students in a school, employee's at a large corporation. They have ID numbers, and I found them useful in my database (just flat file), programs. When your engineer from India has a name running near 40 characters, your clerk is thrilled to only have to enter a 10 digit employee number to bring up his data. (and nowadays, to just scan the attached bar code or mag memory once he's got his first badge)


Whoa! Never meant that. There would always be a file. The question is how it would be used, only.

Was DavidL inclined toward your linked list post? Looked like an elegant start.

Adak

DaWei

I have no idea what DavidL is inclined to, since he hasn't returned. My point in my posts was not that your ideas weren't good (except for saying 'possibly use a file'). My point is that there are alternatives and one has to choose from among them according to the circumstances and requirements, instead of putting them up as unequivocable decisions. Particularly with a novice.

I am going to seriously doubt that your experiences constitute solid support for your recommendations. I will admit that an employee ID (for example) is a good idea. An employee ID is a field unique to an employee, and not a record number. Your wording is fuzzy, which makes one doubt the amount of thoughtful consideration that you give to your presentation.

Everything I have put up is a target to be shot at. Shoot away. Please explain why your recommendations are automatically the way to go, though; use facts and proper definitions.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Adak

I'm not one to "shoot away" at your idea's - for the most part. You and Narue and Grumpy and Jimbo, etc., may have forgotten more than I ever learned about programming. My opinions are not the "only way to go". They are the way or ways that I see or recommend.

Besides using linked lists, or arrays, or direct file methods, what other options would you recommend for a contact book?

You're certainly welcome to "doubt away". All I can say is what worked well, for me, when commercial database software just took forever to complete the jobs we needed done frequently, and much faster.

Naturally, high performance isn't a factor with a little contact book program.

Adak

DaWei

I think the options that I would recommend are explored above, including the possible tradeoffs.

Forgive me for being upfront. I form my own opinions. I will admit that my opinion has been swayed because you are the guy that refers to nested loops that don't increment in the typical way as "magic odometers." That is intriguing nomenclature, but it is old news.

I would contend that what "worked well for you" might have been judged from a limited perspective which cannot distinguish between a performance that is a couple of orders of magnitude better than another if the program only has to perform for times ranging from a couple hundred milliseconds to a couple of minutes.

It is unlikely that a contact book application is going to have to perform on the cutting edge for an enterprise-wide application. If it did, the time difference would probably be seen to be a day versus a week or a month. Nevertheless, the ability to judge the alternatives is a skill well worth developing. There are two ways that I can suggest that you might discover this: 1) think, 2) submit your solution in a competitive atmosphere that looks at performance and not at cute, coined terms. Incidentally, the Sudoku problem has been definitively solved. That is not to say that Sudoku examples that illustrate design and coding principles have no place. After all, I just put up a tic-tac-toe program, and those were solved long ago.

I don't mean to denigrate you unduly, but I mean to denigrate you a little bit, so that you will go sit on the corral fence and ponder the implications of dealing with the programming world and its machines without too much shooting from the hip.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Adak

The longest work program with a database(s) connection that I've written, took a tad less than 30 minutes to run. It replaced the database program doing the same work, in 19 hours.

On the Suduku program, the "odometers" were in memory of a friend that suddenly died of leukemia. I had coded up an "odometer" for a little game he was working on to spiffy it up a bit, shortly after we became friends.

The "magic" part referred to a technique for quickly solving the parts of a Sudoku puzzle where some trial and error are needed. I named the program "Sudoku Magic", because the "magic touch" function solves difficult puzzles, in almost no time (with the help of the other logic functions which entirely solve easy puzzles).

I don't think "enterprise-wide" solutions would be appropriate, for a novice, either.

You think I "shoot from the hip", and should "think" or ponder things in programming, more.

That's your perspective. You're the one probably with a degree or a lot of CS classes. I'm the one with one semester in a BASIC class, and one semester of C.

Of course you see my descriptions as imprecise, or "from the hip". Just as I see the posts of Grumpy and yourself, as being off target for a real noob's advice, (like DavidL). It's very good, of course, it's just not something he can use, imo.

It's all a matter or our diverse perspectives.

I wouldn't think that my programs are particularly fast or great. If they performed faster, it was because I spent more time and found a better algorithm than the commercial software writers of those days.

Yes, I use things like Quicksort, with maybe a tweak or two, but anybody could do it, and probably make it still faster. I don't know if you remember an old PC utility program called "Ben Baker Utilities", iirc. He had a sorting program in there that was absolutely dynamite! I never coded anything that could beat Baker's sorter, and neither could Sedgewick's or Weiss's versions of Quicksort. Maybe it was hand-tuned assembly code, but I know it was a screamer.

Many of my "performance" idea's come from either a few hardware papers, (mostly all gone from the marketplace, now), a couple of software books, or Robert Hyatt at www.talkchess.com. He's a well-known chess programmer from Cray's to Clusters, to Workstations, to PC's. My chess program is my long-term nemesis.

Right now, I'm working away at a minesweeper program. For me, it's a real challenge. Maybe I'll call it "QuickDraw".

Adak

grumpy

You miss the point. The issue is not qualifications.
And how is telling him to use a file something he can use? How do you know, from the information given, that information is even useful?

One thing you forget is that all of us with experience were once noobs. We weren't born knowing what we know now. We went through a learning curve. We were helped by people who knew more than we did. We tried things out and made mistakes. We were also given bum steers by people who meant well, but didn't know all that much. And we learnt that recovering from a bum steer is significantly more difficult than is recovering from a mistake of our own making -- one reason why we're normally quite prepared to admit our mistakes (we make less of those than we once did, but we still make them and learn from them).

There's an old chinese proverb "Give a man a fish and you feed him for a day. Teach a man to fish, and you feed him for a lifetime". By giving a noob something he can use, you're only giving him the fish and he'll need another one tomorrow --- and, eventually, people will give up and stop giving him fish. What people with experience tend to do is give pointers to noobs so they can learn how to fish --- if they are willing to think about the advice, question it, challenge it, adapt it, etc etc. That is the only way we can encourage beginners to -- eventually -- be more skilled than we are. If everyone was just to give beginners something they can use (i.e. that is within our limits) those beginners might match us, but will never be more skilled than we are.

DaWei

I have to laugh. There's a lot of stuff in this thread and no OP. Oh well.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

peace_of_mind

The OP may be missing, but others aren't

__________________
Amateurs built the ark
Professionals built the Titanic

Pizentios

i am sure he'll post something soon. Probably just isn't used to how fast people around here reply.

__________________
Profanity is the one language that all programmers understand.

Check out my Blog <---updated Nov 30 2007!