Help in my program using Classes

[Mark44]

I really thought I made the names a lot better. Like caseA() stands for what the user type in 'a' to choose adding a name. It is in a switch-case part of the code. I call the header file fileVector exactly what it is doing, working on both file and vector. In my mind, this is as clear as it can.

In both cases above, your choices describe how something is implemented rather than what the symbol is supposed to represent. "caseA" used four letters to represent the keyword, but only one letter to convey that idea that you're going to add something. What should be emphasized is the adding part, not the keyword used in some switch statement.

I feel very frustrated with it when I read about friends, now Memberwise Assignment and Copy Contruction. It's like the language want to be straight...then when it comes to something inconvenient, then create a back door to bypass it! Specially like the friend thing. I thought it's a good practice to have control of the traffic flow having private and all.

It is good practice to control access via the access specifiers. I don't have any good reasons why you should spend any time on learning about friend functions or classes.
Memberwise assignment and copy construction are important if you have a class whose members are pointers to memory somewhere. If you want to have a copy of something that is its own object, rather than just copy the values of the pointers, these are useful topics.

I peaked into the overload section, sounds like it want to use the operator differently with definitions. I don't know the detail, but that is so so discouraging to me. It's is like playing tricks to make the code looks simpler and save a line of two.

If you want to make it so that a class you create can be inserted into a stream or extracted from a stream, the same way that integers, floats, and the basic types can, it's useful to overload the << and >> operators.
If being able to join two objects together makes sense in your application, the you might consider overloading the + operator (this is done for the std::string template class).

I was very excited studying chapter 13 on classes, but 14 looks to be all the tricks. I am questioning whether programming is for me or not. I hope I can finish to chapter 16 in the complete book( that has 20 lessons) on library and templates, but it's just getting harder to concentrate with all these in my mind. I feel very frustrated at this point.

Class design is a subject all its own, and there are many books written on it out there. A search for "c++ design patterns" would probably turn up a lot of hits. We've been trying to get across to you some of the things that make a good design, and some that don't. It's not something you can learn in a month.

 

[pbuk]

Regarding indentation, instead of

void fileVector::createFile()
  { DirFile.open("Directory.dat", std::ios::out | std::ios::binary | std::ios::app);
    DirFile.close();
  }

write

void fileVector::createFile() {
  DirFile.open("Directory.dat", std::ios::out | std::ios::binary | std::ios::app);
  DirFile.close();
}

This takes up less space on the page than your version and is clearer and easier to work with (it is called the 'one true brace' style and is the preferred style of many programmers in many languages).

Look at these two statements:

if (choice != tolower('q')) return;
if (tolower(choice) != 'q')) return;

Which one is similar to something written in the book?

 

[Vanadium 50]

I don't think better bracing would be high on my priority list. I think some of your earlier points, while all good, are more important than others.

It is not clean to hard code the same filename in 6 different places.

Absolutely agree. I disagree with yungman's "It's not wrong". It is wrong and works only by accident. Explictly naming a file in 6 different places tells the compiler you want to work with 6 different files.

It is not clean to use cryptic method names like caseA.

Couldn't agree more. Method (and variable) names should be clear to you, Future You, and anybody else who works on the code, including people you ask for help.

It is not clean to lay your code out randomly:

1. sometimes placing a { in the same column as the previous statement, sometimes with 1, 2 or 4 additional spaces of indentation
2. sometimes placing the next statement on the next line, sometimes on the same line as the { after 0, 1, 2 or 3 spaces
3. etc. etc.

I agree. Some of these cause more trouble than others. Placing a cin.ignore on the same line after a read probably contributed to not identifying it as the culprit for a downstream cin. And while there are several reasonable styles for brackets and indentations, it is far better to pick with one and stick with it (even if it is "wrong") than flipping back and forth.

It is not clean to write a comment "Assume file is OPEN already" and 2 lines later open the file.

Who could argue with that?

• It is not clean to mix PascalCase and camelCase randomly for variable names.
• It is not clean to mix snake_case and camelCase randomly for method names (are you trying to achieve a record with sort_firstName?)
• It is not clean to use PascalCase for variable names and camelCase for class names (it IS clean to do this the other way round).

These are fairly low priority for me. I would much rather have understandable method and variable names with case style all over the place than incomprehensible variable names that strictly follows a given style.

It is not clean to write tolower('q').

That is true. I do not believe that it is in the book this way, and if it is, it is an error that the student should recognize as such.

The general string handling could use some work. If the program asks "Are you sure?" and the user types "ynnnnnnNNN", do you really want the program to interpret that as a yes?

It is not clean to try to open the same file twice, do you think the computer tries harder to find it the second time?

I laughed when I read this.

 

[Vanadium 50]

"caseA" used four letters to represent the keyword, but only one letter to convey that idea that you're going to add something. What should be emphasized is the adding part, not the keyword used in some switch statement.

I thought about this for a while, because I couldn't figure out what was bugging me. (on top of what has been said previously) On top of all the previously mentioned issues, a variable name like CaseA breaks encapsulation, at least psychologically. It doesn't describe what it is, or what it does. It doesn't even describe how it's used, which would be bad enough. It describes when it is called.

That's not part of the object. It's not even a stable part of the calling routine: the name refers to the way it is called today, but not necessary the (only) way it will be called in the future.

There is an art to variable and method naming, that's for sure. It's not reasonable to expect to get everything right the first time. But the wise beginning programmer will listen to people with more experience.

Similarly DirV describes the implementation of the set of Directory objects, thus mixing interface and implemenation. Imagine a future discussion "It's called DirV because it used to be a vector of Directory entries?" "So it's a vector?", "No. It used to be a vector. Then we changed it to a list". "Oh, so it's a list of Directory objects?" "No, we changed it again to a binary tree. And it's not a set of Directory objects, it's a set of Directory entries."

 

[pbuk]

Similarly DirV describes the implementation of the set of Directory objects, thus mixing interface and implemenation. Imagine a future discussion "It's called DirV because it used to be a vector of Directory entries?" "So it's a vector?", "No. It used to be a vector. Then we changed it to a list". "Oh, so it's a list of Directory objects?" "No, we changed it again to a binary tree. And it's not a set of Directory objects, it's a set of Directory entries."

Your turn to make me laugh

 

[Mark44]

Similarly DirV describes the implementation of the set of Directory objects, thus mixing interface and implemenation.

This was also my thought when I first saw the program we're discussing here. The name of a variable should describe what it represents, not how it is implemented. Aside from this, the name itself is confusing. Does it represent a vector of Directory objects? More likely the intent is a single directory that contains a vector of directory entries. In any case, the name should not include, suggest, or hint at anything to do with the vector template class for reasons already given.

I should also add that in the real world, there is such a thing as code review, in which other members of the developer's team (including the dev manager) review the code, and make suggestions for improvement.