Lecture 17 storage classes scope and program modules
Download
1 / 38

Lecture - 17 - PowerPoint PPT Presentation


  • 368 Views
  • Uploaded on

Lecture 17: Storage Classes, Scope and Program Modules Homework: Read Chapter 7, Appendix G of Barclay Lecture 17: Outline Storage Classes, Scope, and program modules: Abstract Data Types. Storage classes: auto, static, extern, register. Global variables, scope, visibility.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Lecture - 17' - omer


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Lecture 17 storage classes scope and program modules l.jpg

Lecture 17: Storage Classes, Scope and Program Modules

Homework: Read Chapter 7, Appendix G of Barclay


Lecture 17 outline l.jpg
Lecture 17: Outline

  • Storage Classes, Scope, and program modules:

    • Abstract Data Types.

    • Storage classes:

      • auto, static, extern, register.

    • Global variables, scope, visibility.

    • Compiling and linking program modules.


Abstractions l.jpg
Abstractions

  • Abstractions are used for a variety of reasons:

    • Overcomes complexity.

    • Divides large programs into smaller manageable pieces.

    • Each piece can represent a function in the problem.

    • Ignores details.


Abstractions contd l.jpg
Abstractions (contd.)

  • Abstract Data Types:

    • Represent abstract concepts.

    • Include

      • Set of variables.

      • Set of operations on those variables.

      • External visible interface.

      • Hidden implementation.


Abstractions contd5 l.jpg
Abstractions (contd.)

  • Implementation using

    • Storage classes.

    • Scope.

      • Region of a program over which a declaration is active.

    • Object linkage.

    • Program units/modules.

    • Separate compilation and linking.


Storage classes l.jpg
Storage Classes

  • Types:

    • auto.

    • static.

    • extern.

    • register.


Storage classes contd l.jpg
Storage Classes (contd.)

  • auto:

    • Simple variables in a function block.

    • Scope is limited to the function/block in which the variable is declared.

    • Visible ONLY inside a function or block and exists only while the function/block is active.


Storage classes contd8 l.jpg
Storage Classes (contd.)

  • E.g:

    void main ()

    {

    int x;

    } // visibility of x is only inside this block

    void print ()

    {

    printf ("something");

    x = 10; // WRONG as x is not visible

    }


Storage classes contd9 l.jpg
Storage Classes (contd.)

  • static:

    • Local variables:

      • Visible ONLY in function where declared

      • Private to containing function (similar to auto).

      • Retains values between function calls.

    • E.g:

      int foo ()

      {

      static int x; x++;

      return x;

      }


Notes on static contd l.jpg
Notes on static (contd.)

  • E.g:

    Using the foo function that we just wrote:

    # include <stdio.h>

    int main ()

    {

    printf ("%d\n", foo ());

    printf ("%d\n", foo ());

    }


Notes on static contd11 l.jpg
Notes on static (contd.)

  • Running the program:

    [axgopala@nitrogen tmp]$ ./a.out

    1

    2

    NOTE: value of x is now 2 !!!


Notes on static contd12 l.jpg
Notes on static (contd.)

  • static:

    • Global variables:

      • Visible ONLY to functions inside the program unit where declared.

      • Private to declaring module.

      • Potentially visible to ALL functions within theprogram unit.


Notes on static contd13 l.jpg
Notes on static (contd.)

  • E.g:

    # include <stdio.h>

    int x = 0; // declaring a global variable x before main

    int main ()

    {

    x = 2;

    add ();

    printf ("%d\n", x);

    }

    void add ()

    { x++; } // x accessible out here also


Notes on static contd14 l.jpg
Notes on static (contd.)

  • Running the program:

    [axgopala@nitrogen tmp]$ ./a.out

    3

    NOTE: value of x is 3, as it was increased by 1 inside the function add ().


Storage classes contd15 l.jpg
Storage Classes (contd.)

  • extern:

    • Defined in some other program unit/module.

    • Declared as locally accessible.

    • Made available to calling modules through linking.

    • Variables declared with extern cannot be initialized locally in functions.


Notes on extern l.jpg
Notes on extern

  • E.g: file ext.c

    # include <stdio.h>

    int main ()

    {

    extern int y;

    printf ("%d\n", y);

    }


Notes on extern contd l.jpg
Notes on extern (contd.)

  • E.g: file y.c

    # include <stdio.h>

    int y = 5;

    Running the program:

    [axgopala@nitrogen tmp]$ ./a.out

    5

    NOTE: value of y = 5 !!!


Notes on extern contd18 l.jpg
Notes on extern (contd.)

  • Cannot do this in main:

    # include <stdio.h>

    int main ()

    {

    extern int y;

    y = 10; // cant do this as y is an extern

    printf ("%d\n", y);

    }


Storage classes contd19 l.jpg
Storage Classes (contd.)

  • register:

    • Creates/stores variables in CPU registers.

    • Implementation dependent, sometimes does not work 

    • Only automatic variables and function arguments are permitted, not functions.

    • If an unacceptable type or more variables than available registers, they are just ignored.


Notes on register l.jpg
Notes on register

  • register:

    • Use of address operator (&) is ignored (as it is meaningless).

    • Register variables can produce faster code since their values are not retrieved from memory (RAM).

    • Frequently, optimizing compilers will generate register variables automatically.


Scope and visibility l.jpg
Scope and Visibility

  • What is main () ???

    • It is:

      • A function like all other functions.

      • Required for a C executable program.

    • It is not:

      • The program.

      • A module/program unit.


Scope and visibility contd l.jpg
Scope and Visibility (contd.)

  • The object containing main () is a module/program unit.

    • Variables declared outside of its functions are external to the functions.

    • Variables declared inside functions are visible ONLY inside function.

    • Scope of external declaration:

      • From the point of declaration to the end of the module in which declared.


Scope and visibility contd23 l.jpg
Scope and Visibility (contd.)

  • Compound statements:

    • Statements between ‘{‘ and ‘}’.

      • Variables can be declared within these statements.

      • Bodies of ifs, loops …..

      • Declaration inside these statements are invisible outside !!!

      • Example follows.


Scope and visibility contd24 l.jpg
Scope and Visibility (contd.)

  • E.g:

    # include <stdio.h>

    int main ()

    {

    int x = 10;

    {

    int y = 20; y is only visible in this block b/w { and }

    }

    use y; // error

    }


Scope and visibility contd25 l.jpg
Scope and Visibility (contd.)

  • Global vs. Local variables:

    • Global variables are potentially available to more than one function.

    • Scope and visibility are controlled by:

      • Placement/location in code.

      • Declaration of same name variables in overriding location affects visibility.


Scope and visibility contd26 l.jpg
Scope and Visibility (contd.)

  • Global vs. Local variables:

    • Local variables are available only in containing function/block.

    • Not visible outside of the function, but can return value of local variable.

      • E.g:

      • int foo () {int x = 0; return x;}


Some examples ex 1 l.jpg
Some examples (ex. 1)

# include <something.h>

int a;

static int b; /* b is private to this module, attempts to reference b using extern in other modules produces linker error */

int main ()

{

... use a, b …

}

some_function ()

{

int a; // different a, not the first one, this overrides the first one

use … a, b …

}


Some examples ex 2 l.jpg
Some Examples (ex. 2)

# include <something.h>

int main ()

{

... use a, b ... /* ERROR, as a,b must be declared here since main () is out of scope of following declaration */

}

int a,b; // visibility of a and b starts here

some_function ()

{

static float c = 1; // local and retains value between calls

... use a,b,c ... // can use a and b as they are visible here.

}


Compiling and linking modules l.jpg
Compiling and Linking Modules

  • Using the cc/gcc command:

    • Use of the cc command has so far been limited to:

      • Compiling C files to get an executable.

      • cc filename.c produces a.out

      • filename.c is automatically preprocessed, compiled and linked to become a.out

      • What do we do when a program spans several files ??


Compiling and linking modules30 l.jpg
Compiling and Linking Modules

  • Compiling separate modules

    • When program spreads over many modules.

      • cc –c file.c only object file named file.o

      • cc file.o  a.out

      • To link files, we need them to be object files.

      • What about multiple files ??


Compiling and linking modules31 l.jpg
Compiling and Linking Modules

  • Compiling separate modules

    • Combining separate modules

      • cc file1.c file2.c compiles and links file1.c and file2.c to produce a.out

      • cc –c file1.c file2.c  compiles to respective object files file1.o and file2.o

      • To produce executable link these two together:

        • cc file1.o file2.o links and produces a.out


Compiling and linking modules32 l.jpg
Compiling and Linking Modules

  • We can directly compile two files, so why is getting an object file useful ???

    • We can catch compile time errors without having to link the files.

      • Linking files is an expensive process (compiler has to do a lot of work).

    • Sometimes library files are only object files.

      • This is to make sure that you don’t see the code, but you only know how to use it.


Compiling and linking modules33 l.jpg
Compiling and Linking Modules

  • Only preprocessing:

    • Using either the –E or the –P flag

    • -E flag sends the output to stdout, so redirect it to save it in a file:

      • cc –E file1.c > temp

      • temp is a text file here


Compiling and linking modules34 l.jpg
Compiling and Linking Modules

  • Only preprocessing:

    • -P writes output to filename.i

      • cc –P file1.c file1.i

      • file1.i is the preprocessed file.

      • file1.i is a text file.


Compiling and linking modules35 l.jpg
Compiling and Linking Modules

  • Smart compilation:

    • Mixing options allowed:

    • cc –o out file1.o file2.c

      • file1 is NOT compiled.

      • file2 IS compiled.

      • file1.o and file2.o are linked

      • Output file is named out.


Compiling and linking modules36 l.jpg
Compiling and Linking Modules

  • Building executes all steps from scratch.

  • Make only does what is needed.

    • Using the make utility.

    • Available on UNIX platforms.

    • Reads a Makefile to perform required action

      • Makefile is a script file that contains a list of commands to execute.

    • make looks at the time stamps and compiles only those files who have changed since the last time make was executed.


Compiling and linking modules37 l.jpg
Compiling and Linking Modules

  • More cc flags:

    • -g: to add debug symbols to use while debugging.

    • -H: print name of each header file used.

    • -Wall: print all warning messages.

    • Etc. etc. see man pages for more.


Next lecture l.jpg
Next Lecture

  • Preprocessing in C

    • C preprocessor.

    • Macros

      • Defining, redefining, undefining macros.

      • Macros with arguments.

    • ifdef and ifndef directives.

    • Miscellaneous directives.


ad