CSS501
In-Class Examples
·
11/4: 11.LinkedList exercises: link to source code, in
VS2010, should open in VS2012 and compile/run with no problem.
o
Courteous of
Professor Zander.
o
List.h: Notice:
§
No need to
include NodeData.h, why?
§
Note the
exercises, some of these are implemented (in the implementation files)
o
Notice the
attempt at testings
o
BUG: copy
constructor crashes with empty list input.
§
How to test this?
§
How to trace
this?
§
How to fix this?
o
Notice the ugly
macro in list_exercise_removeNext.cpp
·
10/30: 10.Arrays: All about arrays (link to source
code, in VS2010, should open in VS2012 and compile/run with no problem. No
reference to ImageLib).
o
First, notice the
typedef for ImageClassPtr at the end of ImageClass.h. CONVENIENT! J
o
Second, remember
memory leak tool, two modifications to main.cpp
to use
§
#include the
proper stuff: stdlib.h, crtdgb.h
§
Call the
SetDbFlag() and SetReportMode() functions at the beginning of main
§
We define:
CSS501_Debug_Memory_Leak to block the code
§
Make sure you
include this in HW5.
o
1DArray (in 1DArray.cpp): nothing too
interesting
§
Must define
default constructor to allocate an array!
§
Notice how we can
return the pointer from the function
§
Notice how to
pass an array in a function (just the pointer!)
§
Notice the many
ways to we access array as pointers.
§
Notice pointer
arithmetic!
§
Usually, use
array syntax when you can, least confusing.
o
2DArray (in 2DArray.cpp): 2D array is
"array of array"! J (same as in Java)
§
Notice the new ImageClass*[row];
§
Returning ptr to
ptr from allocate function
§
Passing ptr to
ptr as parameter. Used the typedef symbol, less confusing.
§
Once again, the
many interesting ways of working with array.
o
1DArray of
pointer to objects (in ArrayOfPointers.cpp).
§
Actually,
identical to 2DArray!
§
Just that, the
second dimension, is of size 1! J
o
Don't forget to
run with F5 and checkout the Output Window. How to plug memory leak?
·
10/21: 8.DefaultDestructor: What happens when
default destructors are called (link to source)
o
ImageClassDriver.cpp: line 13
defines a MyOtherClass, that has a private instance of ImageClass.
§
Notice this class
has no explicit destructor
§
We know, when
instances of MyOtherClass are being destroyed, a "default" destructor
will be called.
o
main():
§
Notice, we create
three instances of MyOtherClass
§
Check out the
runtime print out: see that proper ImageClass destructors are called (by the
MyOtherClass destructor)!
o
Lessons learned:
§
When C++ runtime
cleans up an object by calling its default destructor, it will call all of the destructors of all members!
·
10/21: 9.ExplicitDestructor: What happens when
we have explicit destructors defined (link to source)
o
ImageClassDriver.cpp:
Exact same class, MyOtherClass, as defined in example 8.DefualtDestructor,
differences being:
§
Notice the
explicitly defined destructor
§
We know, when
instances of MyOtherClass are being destroyed, this destructor will be called.
§
But, we are not
destroying the mMyImage object explicitly, now, will this cause memory leak?
o
main():
§
Notice, we create
three instances of MyOtherClass
§
Check out the
runtime print out: see that proper ImageClass destructors are called (by the
MyOtherClass destructor)!
o
Lessons learned:
§
When C++ runtime
cleans up an object by calling the explicitly defined destructor, it will call all of the destructors of all members!
§
NOTE: As long as we do not call "new()"
we do not need to call destructors explicitly (by calling
"delete()"). Will see this VERY SOON!!
·
Lecture 6 (10/14): 6. ReturnReferenceToStack:
Returning a reference to a stack variable (link to source).
o
ImageClassDriver.cpp:
line 14:
ImageClass& MyFunction()
{
ImageClass objOnStack("stackObj");
return objOnStack;
}
o
Caller of
MyFunctoin() receives a reference to a variable that was on the stack!!
o
Notice, all the
cerr output (cout was not showing up)
o
Notice, copy
constructor was called, as we expected, but notice the resolution values are
all BAD!!
·
Lecture 6 (10/14): 7.KeepObjOnStack:
Returning a reference to a stack variable (link to source).
§
line 18:
ImageClass FuncReturningACopy()
{
ImageClass
stackVariable("LocalVar");
return stackVariable;
}
§
Call from line:
27
// notice all the constructor and
destructor!
FuncReturningACopy().PrintImageResolution();
cerr
<< "end
of FuncReturningACopy()\n\n";
§
Notice a
temporary object (LocalVarCopy) was created in main to calling PrintImageResolution()!
§
line 13:
void FuncThatTakesAnImage(ImageClass &ref)
{
ref.PrintImageResolution();
}
§
Call from line:
30
FuncThatTakesAnImage(FuncReturningACopy());
cerr
<< "end
of FuncThatTakesAnImage()\n\n";
§
Notice a
temporary object (LocalVarCopy) was created in main to be passed into
FuncThatTakesAnImage()!
o
In both of these
cases, in terms of efficiency, it does not make any difference with: Line 35
// Notice, by explicitly
creating an ImageClass object
// we are achieving the same.
ImageClass myObj =
FuncReturningACopy();
myObj.PrintImageResolution();
FuncThatTakesAnImage(myObj);
o
In C++, to avoid
implicit copying, and/or construction/destruction, we do see much more
explicitly creation of object and invoking method on objects. Rather than,
passing references of objects around as do in Java and C#.
·
Lecture 5 (10/9): 4.
ImageClassCopyConstructorAndAssignmentOp: The assignment operator (link
to source). Continue with previous ImageClass example
o
Assignment
operator: in implementation (ImageClass.cpp),
notice the comparison with "this"
§
A pointer
comparison
§
Does not make
sense (can get wrong results!) to assign to self!
o
ImageClassDriver.cpp:
line 25:
ImageClass cObj = bObj;
§
Logic:
·
cObj is not
constructed, we will construct from bObj, thus, copy constructed is invoked.
·
At this point,
cObj has its own mMyImage memory.
o
ImageClassDriver.cpp:
line 26:
cObj = aObj;
§
Simple assignment
of aObj to cObj.
§
Notice the
original bObj.mMyImage memory is leaked after the assignment!!
o
Given code for
assignment operator is a bad implementation, read HW3 spec for what you are
supposed to do in your version of assignment operator.
·
Lecture 4(10/7):
5.CRTMemoryTool: CRT Memory tool,
here is the source (you will need ImageLib.lib and ImageLib.h to compile/run):
o
Make sure your
CRT output window is open in the IDE (View'Output [ctrl-w o]).
o
Run your program
by Debug'Start Debugging [F5]
o
Notice the output
window
o
Code:
§
Two
modifications: include and calling configuration functions
§
Both surrounded by
CSS501_Debug_MemoryLeack CPP directives so you can easily compile it out.
§
More information http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx
§
Thanks to Rukia
for asking this question and for the pointer.
o
Be careful with:
_CrtDumpMemoryLeaks();
§
This function
tells you memory leak situation at the time that this function is called!!
E.g., if you allocate some memory, call _CrtDumpMemoryLeaks(), and then free
the memory, you will _SEE_ complains of memory leak!! Use this function with
care!!
·
Lecture 4 (10/7): z.ByteAndInt: Example with template, and testing with int and byte.
o
Try running with
ranges of: 0 to 10 (identical results), and then, 250 to 260.
·
Lecture 4 (10/7): 2.ImageClassConstructor: The need of copy constructor part-1 or 2.
Constructors and Destructors: when they are called. Zip to all source
code.
o
ImageClass.h:
§
image object is
not actually used in this example, just as a vehicle to illustrate the point.
§
mName: is a
string for printing, to illustrate which object is being
constructed/destructed.
§
Defines:
Constructor, Destructor(~), and a simple print function
§
My convention:
all instance variables start with a lower case "m" and CapWord,
mCapWord.
§
Constructor: we
did not actually open the image, just allocate an empty image (to illustrate
the point of when constructor/destructors are called)
§
Destructor: print
message of which name we are destroying, and deallocate memory.
§
Notice the
"{}" inside of main(), remember we talk about scopes? All objects
allocated inside { will be destroyed before }.
§
Pay attention to
the creation of the objects:
ImageClass aObj
= ImageClass("aObj");
ImageClass bObj("bObj");
§
How many objects
are we constructing?
§
When we reach
"}" who is being destroyed? Why will the program crash?
·
Lecture 4 (10/7):3.ImageClassCopyConstructor The need of copy constructor part-2 or 2.
Constructors and Destructors: when they are called. Zip to all
source code.
o
ImageClass.h: Notice the
new constructor that takes an instance of the object:
//
this is the copy constructor
ImageClass(const ImageClass&);
§
This is the
"copy" constructor: makes a copy of the object. By default, all C++
defines a copy constructor for all classes defined (performs shallow copy).
o
ImageClass.cpp: Just pay
attention to the definition of the copy constructor (nothing else has changed):
§ We append the name with "Copy" to signifies
we are copying from an existing object
§ In this case, we make a copy of the mMyImage object
(deep copy).
§ No crashing. Run to notice the output! aObj was
destroyed immediately after it was created!
·
Lecture-1 (9/24): 1. InvertImage: Program0.cpp:
Invert an image. Notice:
o
Forward
declaration for compiler syntax checking
o
The
"&" to pass by reference
o
Comments:
§
comments in the
beginning of the file
§
how functions are
commented