ecec 201 – advanced programming for engineers

1. ecec 201 – advanced programming for engineers andrew r. cohen – drexel ece lecture 1

2. today • hello! • business • syllabus • academic policies / etc. • calendar • problem set 1 intro • lecture 1 • pre-lab 2

3. problem set 1

4. slides in white are textbook slides yellow highlights are my comments Chapter 1 Introducing C

5. Origins of C • C is a by-product of UNIX, developed at Bell Laboratories by Ken Thompson, Dennis Ritchie, and others. • Thompson designed a small language named B. • B was based on BCPL, a systems programming language developed in the mid-1960s.

6. Origins of C • By 1971, Ritchie began to develop an extended version of B. • He called his language NB (“New B”) at first. • As the language began to diverge more from B, he changed its name to C. • The language was stable enough by 1973 that UNIX could be rewritten in C.

7. Standardization of C • K&R C • Described in Kernighan and Ritchie, The C Programming Language (1978) • De facto standard • C89/C90 • ANSI standard X3.159-1989 (completed in 1988; formally approved in December 1989) • International standard ISO/IEC 9899:1990 • C99 • International standard ISO/IEC 9899:1999 • Incorporates changes from Amendment 1 (1995)

8. C-Based Languages • C++ includes all the features of C, but adds classes and other features to support object-oriented programming. • Java is based on C++ and therefore inherits many C features. • C# is a more recent language derived from C++ and Java. • Perl has adopted many of the features of C. More recent languages like Rust have attempted to address the shortcomings of C/C++, while preserving many of its advantages that plague alternatives like Java and C#

9. Properties of C • Low-level • Small • Permissive

10. Strengths of C • Efficiency • Portability • Power • Flexibility • Standard library • Integration with UNIX FAST light weight

11. Weaknesses of C • Programs can be error-prone. • Programs can be difficult to understand. • Programs can be difficult to modify. security maintainability anyone can make their own code work can someone else make your code work?

12. Effective Use of C • Learn how to avoid pitfalls. • Use software tools (lint, debuggers) to make programs more reliable. • Take advantage of existing code libraries. • Adopt a sensible set of coding conventions. • Avoid “tricks” and overly complex code. • Stick to the standard. use caution with existing libraries! make sure you know the price before you buy… …and everything has a price

13. languages • key difference – interpreted vs. compiled • development time vs. run time • be careful in making assumptions about performance • can MATLAB be faster than C? • can Javascript be faster than assembler?

14. it’s not about the language • Church’s thesis: https://www.jstor.org/stable/2269326 • Wikipedia has good background on this

15. performance • ALWAYS MEASURE BEFORE YOU OPTIMIZE • before you optimize, you should measure • measure first, optimize later • how do you measure performance? • Old school: Zen of Code Optimization: The Ultimate Guide to Writing Software That Pushes PCs to the Limit, Michael Abrash, 1994 • New school: distributed application performance measurement is an open question

16. what’s next? • our focus here is on the basics of programming • this is a first step • it’s not about the language, it’s about the theory • data structures • algorithms • theory of computation • and the hardest part in the process is the …

17. the hardest part • the human factor • security • usability • reliability • value • …

18. pre-lab 2 – due at beginning of lab week 2 • read chapters 1-2 of textbook • read pp. 71-92 from the file linuxfun.pdf from the course website • do programming projects 1,2,7 from chapter 2 (pp 34-35) • note that this is your pre-lab for week 2 lab and that your week 1 lab will also be due at the beginning of your week 2 lab session