Separating Definition & Implementation Headers and Comments.

Separating Definition & Implementation

Headers and Comments

Goal

• Modular abstractions we can use to build complex systems

Not Modular or Abstract

Function Declaration

• Function Declarationreturn type name(parameter list);

Function Declaration

• Parameter names optional– Strongly encouraged – order matters!

Implementation

• Functions need to be part of class to work with properties

• Naked function is global – not part of any class

Scope Resolution

• :: Scope resolution operator

This::That"That is a part of This"

Scope Resolution

• :: Scope resolution operator

double Circle::getArea()…"getArea is a part of the Circle class"

Modules

• Copy & Paste is not modular or scalable

• Need mechanism to import existing classes/code

The Process

• Build:– Preprocess– Compile– Link

Run:– Load

Separate Compilation

• Each .cpp has to compile on its own• Needs everything declared

Hey, this thing is going to exist…– Does not need actual code

Linking

• Linking combines separate object files into one executable

• Everything better exist– Better only have one copy

Finding headers

• Include with < > looks in compiler defined directories

• Include with " " looks in your project, then regular directories

Guards

• Should not have multiple declarations of same class/function/etc…

• Easy to do by accident with headersInclude A and B, B also includes A

Guards

• Preprocessor guard:– #ifndef : if this symbol not defined, read until

#endif– #define : define a symbol– CIRCLE_H made up

should be unique

.h File

• Class declaration goes in .h file– Clients include .h

.cpp File

• Function implementation must happen once– Dedicated .cpp file• Include .h file and

other headers• NO MAIN!!!

Header Rules

.h file– Header – declaration of data type– Only include other .h files if necessary

.cpp file– Code – implementation of functions– Include necessary headers for declarations– Never include .cpp files in other files

Naming Conventions

• C++ doesn't have one standardized convention• I encourage– Class names : CapitalizeEachWordclass Person, class BankAccount

– File names : .h and .cpp match and match class namePerson.h, Person.cpp

– Variable names : camelCasePerson bob;BankAccount accountOne;

Naming Members

• State (member variables) are (usually) nouns– int hour– string address– int numberOfAuthors

• Behavior (member functions) are (usually) verbs– void printTime()– int getHour()

Shadowing

• Watch out for shadowed names

Shadowing

• Watch out for shadowed names– Goofy parameter names:

– m_ to preceded names of member variables: