DOC PREVIEW
Princeton COS 333 - Evolution of Programming Languages

This preview shows page 1-2-3-4 out of 13 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Evolution of Programming Languages• 40's machine level– raw binary• 50's assembly language– names for instructions and addresses– very specific to each machine• 60's high-level languages: Fortran, Cobol, Algol, Basic• 70's system programming languages: C, PL/1, Algol 68, Pascal• 80's object-oriented languages: C++, Ada, Smalltalk, Objective C, …strongly typed (to varying degrees)better control of large programs (at least in theory)better internal checks, organization, safety• 90's scripting, Web, component-based, …: Perl, Java, Visual Basic, …glue• 00's Web server and client: Python, PHP, Ruby, Javascript, ...focus on interfaces, components; frameworks Program structure issues• how to cope with ever bigger programs?• objects– user-defined data types• components– related objects• frameworks– automatic generation of routine code• interfaces– boundaries between code that provides a service and code that uses it• information hiding– what parts of an implementation are visible• resource management– creation and initialization of entities– maintaining state– ownership: sharing and copying– memory management– cleanup• error handling; exceptionsComplicated data types in C• representation is visible, can't be protected– opaque types are sort of an exception• creation and copying must be done very carefully– and you don't get any help with them• no initialization– you have to remember to do it• no help with deletion– you have to recover the allocated memory when no longer in use• weak argument checking between declaration and call– easy to get inconsistencies• the real problem: no abstraction mechanisms– complicated data structures can be built,but access to the representation can't be controlled– you can't change your mind once the first implementation has been done• abstraction and information hiding are nice for small programs,absolutely necessary for big programs C++• designed & implemented by Bjarne Stroustrup– began ~ 1980; ISO standard in 1998; still evolving (C++0x in 2011?)• a better C– almost completely upwards compatible with C– more checking of interfaces (e.g., function prototypes, added to ANSI C)– other features for easier programming• data abstraction– methods reveal only WHAT is done– classes hide HOW something is done in a program, can be changed as program evolves• object-oriented programming–inheritance-- define new types that inherit properties from previous types–polymorphismor dynamic binding -- function to be called is determined by data type of specific object at run time• templates or "generic" programming– compile-time parameterized types– define families of related types, where the type is a parameter• a "multi-paradigm" language– lots of ways to write codeC++ classes• data abstraction and protection mechanism derived from Simula67 (Kristen Nygaard, Norway)class Thing {public:methods -- functions for operations that can be done on this kind of objectprivate:variables and functions that implement the operations};• defines a data type 'Thing'– can declare variables and arrays of this type, create pointers to them, pass them to functions, return them, etc.• object: an instance of a class variable• method: a function defined within the class • private variables & functions not accessible from outside the class• it is not possible to determine HOW the operations are implemented, only WHAT they do.C++ synopsis• data abstraction with classes– a class defines a type that can be used todeclare variables of that type, control access to representation• operator and function name overloading– all C operators (including =, +=..., ( ), [ ], ->, argument passing and function return but not . and ?:) can be overloaded to apply to user-defined types• control of creation and destruction of objects – initialization of class objects, recovery of resources on destruction• inheritance: derived classes built on base classes– virtual functions override base functions– multiple inheritance: inherit from more than one class• exception handling• namespaces for separate libraries• templates (generic types)– Standard Template Library: generic algorithms on generic containers– template metaprogramming: execution of C++ code during compilation• compatible (almost) with C except for new keywordsTopics• basics• memory management, new/delete• operator overloading• references– controlled behind-the-scenes pointers• constructors, destructors, assignment– control of creation, copying and deletion of objects• inheritance– class hierarchies– dynamic types (polymorphism)• templates– compile-time parameterized types• Standard Template Library– container classes, generic algorithms, iterators, function objects• performanceStack class in C++// stk1.c: simple-minded stack classclass stack {private: // default visibilityint stk[100];int *sp;public:int push(int);int pop();stack(); // constructor decl};int stack::push(int n) {return *sp++ = n;}int stack::pop() {return *--sp;}stack::stack() { // constructor implementationsp = stk;} stack s1, s2; // calls constructorss1.push(1); // method callss2.push(s1.pop());Inline definitions• member function body can be written inside the class definition• this normally causes it to be implemented inline– no function call overhead// stk2.c: inline member functionsclass stack {int stk[100];int *sp;public:int push(int n) { return *sp++ = n; }int pop() { return *--sp; }stack() { sp = stk; }};Memory allocation: new and delete• new is a type-safe alternative to malloc– delete is the matching alternative to free• new T allocates an object of type T, returns pointer to itstack *sp = new stack;• new T[n] allocates array of T's, returns pointer to firstint *stk = new int[100];– by default, throws exception if no memory• delete p frees the single item pointed to by pdelete sp;• delete [] p frees the array beginning at pdelete [] stk;• new uses T's constructor for objects of type T– need a default constructor for array allocation• delete uses T's destructor ~T()• use new/delete instead of malloc/free– malloc/free provide raw memory but no semantics– this is inadequate for objects with state– never mix new/delete and malloc/freeDynamic stack with new, delete// stk3.c: new, destructors, deleteclass stack {private:int


View Full Document

Princeton COS 333 - Evolution of Programming Languages

Download Evolution of Programming Languages
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Evolution of Programming Languages and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Evolution of Programming Languages 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?