-------------------------------------------------------------------------- > i was looking at assignment 4. were the files to be submitted supposed to > be date.h date.cpp and date_main.cpp? (.cpp instead of .c)? They're date.C (note the capital letter) and date_main.C. The compiler will accept either suffix, but please use the .C notation so that all the program files handed in will be consistent. -------------------------------------------------------------------------- > On date_main.C which one do you want us to include, Date.C or > Date.h? A .C source file should never be included (this goes for .c files too). So, you'll need to include date.h in both date.C and date_main.C. Also, note that these files should all begin with lowercase letters. -------------------------------------------------------------------------- > For the class definition should it be "class Date" or should it be "class > date"? The class should be named Date and the source file should be named date.C. -------------------------------------------------------------------------- > I dealt with C++ in my junior year of high school. I vaguely > remember "this." I thought this.month = month; would work fine, > but apparently it doesn't. Given that I can't exactly rule out > my problem systematically since everything seems foreign, I'd > like a little guidance to get me started. You can reference your instance variables by name (day, month, year), but if there's a name conflict, you can use "this". Keep in mind though that in C++, "this" is a pointer. So, you'd have to use "this -> day". Try to take advantage of the textbook for examples on how to use "this", and for other topics you have questions about. -------------------------------------------------------------------------- > In the boolean operator functions, how the heck do I access month, > day, and year through date? When I try, it says they are private, > and that I can't access them. Every other attempt I've made has > been some compiler error. What's wrong? Your problem has to do with the compiler you're using. The compiler on the Unix machines on campus allow you to get away with a bit more, but to do this correctly, you need friend functions. Take a look at your textbook for more info. -------------------------------------------------------------------------- > Also, what the heck does format do? It takes a string, then what? Does it > modify it in some way? In what way am I supposed to modify it? How should > I expect the input to look like? Look in the C and Java versions of the code -- it does the same thing in those. format() in the C++ program takes a string argument, formats the date as "month day, year" (e.g., "December 1, 2001") and returns the formatted date in that string parameter. -------------------------------------------------------------------------- > I seem to be getting a strange error when I compile now. Somehow, I don't > think date.C can be accessed. date_main.C includes date.h, but not date.C, > so how could it know all these functions? What am I missing? You need to compile both on the command line: g++ date.C date_main.C just like in C. -------------------------------------------------------------------------- > In the format function it works ok when I call it with d1 & d2, but when I > call it with d3 it gives me an access violation. I am summing this has > something to do with the pointer. I am using the sprintf from the c code. > how do I need to set it up to work with pointers and non-pointers? Since d3 is a pointer to a Date object, you'll have to deal with it similarly to the way you do in C. To call class functions, you need to use the "->" notation instead of the "." notation. Also, if you pass d3 to a function that's expecting an object, you'll need to dereference d3 with "*". -------------------------------------------------------------------------- > In my date_main.C, I seem to be repeating the same code for > each comparison, ie: > > if (d2 < *d3) > cout << "True" << endl; > else > cout << "False" << endl; > > For every comparison I do, I have this same code. Isn't > there a better way? Yes, there are better ways, and although they're really not necessary for this program, I will list a couple. - You could write a function that took a bool value and returned the corresponding string, but to be object-oriented, it would really need to be included in the bool class. - You could write a macro that did the same as above, but once again, not very OO. - You could declare an array of two strings ("false" and "true") and use the bool return value as an index into it. Not very OO. - You could create a derived class from bool and override the << operator, but that's beyond the scope of this course. There are other ways as well, but I'd just leave the redundant code in the program until you learn about better ways to handle this situation. -------------------------------------------------------------------------- > When I try something like: > d2.operator==(d3->day) > > I get this error: > date_main.C: In function `int main(...)': > date.h:10: `int Date::day' is private > date_main.C:34: within this context > > Could please tell me what I'm doing wrong? You need to use the entire object as the parameter, not just one field. To really perform the equality operation, you need the whole date, not just the day (e.g., 12/1/2001 is not equal to 11/1/2001 even though the day is the same). Since d3 is a pointer to a Date object and the operator wants just a Date object (no pointer), you'll need to think of how to handle that. Also, you shouldn't call the operator in the way you do above -- the whole point of operator overloading is to allow you to use the operator in a normal way, like if (d1 == d2) -------------------------------------------------------------------------- > Is it correct to set up the format func like this? > > void Date::format (char *str) > > If so, exactly how do I go about accessing the string str? The above is OK. Since str is passed a parameter, you should have access to the variable that represents that parameter in the calling function. -------------------------------------------------------------------------- > I am getting a segmentation fault with my format function. I think it's > with the casting in my string concatenation. What should I do instead? > > void Date::format ( char *str ) > { > strcpy( str, monthStr() ); > strcat( str, " " ); > strcat( str, (char*)day ); > strcat( str, (char*)year ); > } Use sprintf (as in the example date.c) program to format the string. -------------------------------------------------------------------------- > I was just wondering how much commenting is necessary > for this project. Do we need to do the style > "standard" with descriptions of every function, or is > it fine to just do the header comments at the top of > each file? Your code should have as much commenting as given in the sample programs. You have the electronic versions of those programs; how hard could it be? -------------------------------------------------------------------------- > I get this error in my program: > > conversion from 'Date *' to non-scalar type 'Date' requested > > which is referring to my main function when I declare my first > two variables: > > Date d1 = new Date(); > Date d2 = new Date(31, 12, 1999); You should only use new when you are dealing with pointer variables (e.g., Date *d3). Since you declare standard objects above, you need to invoke the constructor (according to the syntax we discussed in class) without the new. -------------------------------------------------------------------------- > When I complie my code for the assignment I get the following warnings > for my monthStr function: > > [239](snoopy7) ~/215/asg/asg5/>make > CC -c date.C > "date.C", line 146: Warning: String literal converted to char* in > initialization. > "date.C", line 147: Warning: String literal converted to char* in > initialization. > "date.C", line 148: Warning: String literal converted to char* in > initialization. > etc. > > But the program runs fine and prints the correct output. Do I need to fix > my code so that it doesn't get the compiler warnings, or is it fine the > way it is? Thanks! No, it's fine. --------------------------------------------------------------------------