Function Overloading and Automatic Type Conversion in C++, Slides of C programming

Function overloading in C++, which allows the use of the same function name with different parameter lists. It also covers automatic type conversion and its impact on function call resolution. examples and best practices for using function overloading and automatic type conversion.

Typology: Slides

2021/2022

Uploaded on 09/27/2022

aasif
aasif 🇺🇸

4.9

(7)

218 documents

1 / 22

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Chapter 4
-Function Overloading
-Function Testing
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16

Partial preview of the text

Download Function Overloading and Automatic Type Conversion in C++ and more Slides C programming in PDF only on Docsity!

Chapter

-Function Overloading

-Function Testing

Overloading

Same function name

Different parameter lists

Two separate function definitions

Function ‘signature’

Function name & parameter list ƒ Must be ‘unique’ for each function definition

Allows same task performed on different data

Overloaded Average() Cont’d

Which function gets called?

Depends on function call itself:

avg = average(5.2, 6.7); ƒ Calls ‘two-parameter average()’ ƒ avg = average(6.5, 8.5, 4.2); ƒ Calls ‘three-parameter average()’

Compiler resolves invocation based on signature of function call

‘Matches’ call with appropriate function ƒ Each considered separate function

Overloading Pitfall

Only overload ‘same-task’ functions

A mpg() function should always perform same task, in all overloads ƒ Otherwise, unpredictable results

C++ function call resolution:

st : looks for exact signature ƒ

nd : looks for ‘compatible’ signature

Overloading Resolution Example

Given following functions:

  1. void f(int n, double m);
    1. void f(double n, int m);
      1. void f(int n, int m); ƒ These calls: f(98, 99);

Æ

Calls # f(5.3, 4);

Æ

Calls # f(4.3, 5.2);

Æ

Calls ???

Avoid such confusing overloading

Automatic Type Conversion andOverloading

Numeric formal parameters typically made ‘double’ type

Allows for ‘any’ numeric type

Any ‘subordinate’ data automatically promoted ƒ int Æ double ƒ float Æ double ƒ char Æ double *More on this later!

Avoids overloading for different numeric types

Default Arguments

Allows omitting some arguments

Specified in function declaration/prototype

void showVolume( int length, int width = 1, int height = 1); ƒ Last 2 arguments are defaulted ƒ Possible calls: ƒ showVolume(2, 4, 6); //All arguments supplied ƒ showVolume(3, 5); //height defaulted to 1 ƒ showVolume(7); //width & height defaulted to 1

Default Arguments Example

Display 4.8,page 160

The assert Macro

Assertion: a true or false statement

Used to document and check correctness

Preconditions & Postconditions ƒ Typical assert use: confirm their validity ƒ Syntax: assert(<assert_condition>); ƒ No return value ƒ Evaluates assert_condition ƒ Terminates if false, continues if true

Predefined in library

Macros used similarly as functions

An assert Macro Example

Given Function Declaration: void computeCoin(

int coinValue, int& number, int& amountLeft); //Precondition: 0 < coinValue < 100 0 <= amountLeft < //Postcondition: number set to max. number of coins

Check precondition:

ƒ assert ((0 < currentCoin) && (currentCoin < 100) && (0 <= currentAmountLeft) && (currentAmountLeft < 100)); ƒ If precondition not satisfied Æ condition is false Æ program execution terminates!

assert On/Off

Preprocessor provides means

#define NDEBUG #include

Add ‘#define’ line before #include line

Turns OFF all assertions throughout program

Remove ‘#define’ line (or comment out)

Turns assertions back on

Stubs and Drivers

Separate compilation units

Each function designed, coded, tested separately ƒ Ensures validity of each unit ƒ Divide & Conquer ƒ Transforms one big task Æ smaller, manageable tasks

But how to test independently?

Driver programs

Stubs

Develop incrementally

Write ‘big-picture’ functions first

Low-level functions last ƒ ‘Stub-out’ functions until implementation ƒ Example: double unitPrice(int diameter, double price) { return (9.99); // not valid, but noticeably // a ‘temporary’ value } ƒ Calls to function will still ‘work’

Fundamental Testing Rule

To write ‘correct’ programs

Minimize errors, ‘bugs’

Ensure validity of data

Test every function in a program where every other function has already been fully tested and debugged ƒ Avoids ‘error-cascading’ & conflicting results