II.6 Program Development and Execution

⬆️ P-I.II. Programming Fundamentals · Question Bank · Chapter II (2016–2026)

🧠

Remember: Build the program; run it; diagnose the stage that failed.

Start here — what you should be able to do

• Separate development activities from translation stages.
• Explain compiler, linker, loader and IDE roles.
• Classify compile, link, runtime and logic failures.

Reading order: foundation checks → full notes and examples → exam traps → self-test without notes → past-paper answers. All sections below remain part of the topic; code examples are kept in full.

Foundation checks

Error diagnosis map

Undefined behaviour is not guaranteed to crash. Array bounds and valid arithmetic remain the programmer's responsibility. Workflow: define → design → code → build → test/debug → deploy/maintain; repeat as needed.

1. Program Development Life Cycle

1. Edit — write/modify source code in an editor or IDE
2. Compile/Interpret — translate source code toward machine-executable form
3. Link — combine object code with libraries into a complete executable
4. Load — the OS loader brings the executable into memory
5. Execute — the CPU runs the loaded program
6. Debug — locate and fix errors found during testing/execution
7. Maintain — update the program over time as requirements change or bugs surface post-release

2. Compiler

• Translates the entire source code into machine code before execution, producing a standalone executable
• Errors are reported only after the whole program is analyzed/translated (all syntax errors listed together)
• Produces a faster-running final program since translation happens once, ahead of time
• Examples: C, C++, Rust
• Typical compiler phases: lexical analysis (tokenizing) → syntax analysis (parsing, building a parse tree) → semantic analysis (type checking) → intermediate code generation → optimization → code generation (target machine code)

3. Interpreter

• Interpretation: a runtime executes source or an intermediate representation; literal line-by-line execution is only a simplified model.
• No standalone executable is produced — the source is needed every time the program runs, together with the interpreter
• Errors surface only when execution reaches the faulty line — earlier correct lines may already have run
• Examples: Python, classic BASIC, shell scripts

4. Compiler vs Interpreter

5. Linker and Loader

• Linker: combines the compiled object code of a program with the object code of libraries/other modules, and resolves references to functions/variables defined elsewhere, producing one complete executable
• Loader: at run time, copies the executable from disk into main memory, allocates memory for it, sets up the stack/heap, and transfers control to the program's entry point to begin execution

6. 💻 Code Examples: C & C++

The full Edit → Compile → Link → Load → Execute cycle, shown as actual commands (both gcc/g++ compile and link in a single step by default):

C:

// hello.c
#include <stdio.h>
int main(void) {
    printf("Hello, World!\n");
    return 0;
}

gcc hello.c -o hello    # Compile + Link -> produces the executable "hello"
./hello                 # Load (by the OS loader) + Execute

C++:

// hello.cpp
#include <iostream>
using namespace std;
int main() {
    cout << "Hello, World!" << endl;
    return 0;
}

g++ hello.cpp -o hello   # Compile + Link -> produces the executable "hello"
./hello                  # Load + Execute

• gcc/g++ are true compilers: they translate the whole file before producing hello, matching the Compiler row of the table (all errors reported together, faster final program, standalone executable)

---

7. MCQ Traps

• Interpretation: a runtime executes source or an intermediate representation; literal line-by-line execution is only a simplified model.
• A compiler produces a reusable executable file; an interpreter needs the source code present every time the program is run
• Linking happens after compilation (combines object files/libraries); loading happens right before execution (brings the executable into memory)
• Hybrid languages like Java/C# are compiled to bytecode first, then that bytecode is interpreted/JIT-compiled by a virtual machine — not purely one or the other

8. ✅ Self-Test Questions (with Answers)

Q1. List, in order, the seven stages of the Program Development Life Cycle.

Answer — key points

• The Program Development Life Cycle describes the path from typing source code to keeping a released program alive.
• The seven stages, in order, are:

1. Edit — write or modify the source code in an editor or IDE, saving it as a .c/.cpp file
2. Compile / Interpret — translate the source toward machine-executable form; syntax and semantic errors are reported here
3. Link — combine the object code with library and other module object code, resolving external references into one executable
4. Load — the OS loader copies the executable from disk into main memory and allocates its stack and heap
5. Execute — the CPU runs the loaded program and results appear
6. Debug — locate and remove the errors revealed during testing and execution
7. Maintain — update the program after release as requirements change or latent bugs surface

# The first five stages as real commands
nano hello.cpp            # 1. EDIT
g++ -c hello.cpp          # 2. COMPILE -> hello.o
g++ hello.o -o hello      # 3. LINK    -> executable "hello"
./hello                   # 4. LOAD + 5. EXECUTE
# (g++ hello.cpp -o hello performs steps 2 and 3 in one command)

• Stages 2 and 3 are usually invisible because gcc/g++ compile and link in a single command by default
• Debug → Edit forms a loop: every fix sends you back to stage 1 and through the cycle again
• Maintenance consumes the largest share of a program's total lifetime cost — a favourite short question

MCQ trap: linking happens after compilation; loading happens immediately before execution — reversing the two is the standard wrong option. Note also that preprocessing (#include, #define) precedes compilation proper, and that an interpreted language skips the link and load stages entirely.

Q2. Compare a compiler and an interpreter on translation unit, output, and error reporting.

Answer — key points

• Both are language translators, but they differ fundamentally in when and how much they translate.
• A compiler processes the entire program at once before any of it runs, producing a standalone executable
• an interpreter translates and immediately executes one statement at a time during the run, producing nothing permanent.
• This single difference drives every other contrast between them.

cout << "Line 1 runs\n";
int x = 5 0;              // SYNTAX ERROR
cout << "Line 3\n";
// COMPILER (C++): nothing executes at all -- no .exe is produced,
//                 and every error in the file is reported together.
// INTERPRETER  : "Line 1 runs" WOULD already be printed before the
//                 faulty line was reached and execution halted.

• MCQ trap: the classic wrong option is that an interpreter "produces an executable" — it does not.
• Remember also the hybrid case: Java and C# compile to bytecode first and then interpret/JIT it on a virtual machine, so they are neither purely compiled nor purely interpreted.

Q3. What are the six phases of compilation, in order?

Answer — key points

• A compiler translates source to target code through six phases, the first three forming the analysis (front-end) and the last three the synthesis (back-end).
• The symbol table and the error handler run alongside all six.

1. Lexical Analysis (Scanning) — reads the source character by character, discards whitespace and comments, and groups the rest into tokens; reports invalid symbols
2. Syntax Analysis (Parsing) — checks the token stream against the language grammar (BNF) and builds a parse/syntax tree; reports syntax errors such as a missing semicolon
3. Semantic Analysis — checks meaning: type compatibility, undeclared variables, wrong number of arguments; annotates the tree and inserts type conversions
4. Intermediate Code Generation — produces a machine-independent representation such as three-address code, easing portability to different CPUs
5. Code Optimization — improves the intermediate code for speed or size without altering its meaning (constant folding, dead-code elimination, loop-invariant motion)
6. Code Generation — emits the target machine/assembly code, allocating registers and memory

int x = a + b * 2;
// 1. Tokens     : int | x | = | a | + | b | * | 2 | ;
// 2. Parse tree : assignment( x , plus( a , times( b , 2 ) ) )
// 3. Semantics  : are a and b declared? are they numeric? -> ok
// 4. 3-addr code: t1 = b * 2 ;  t2 = a + t1 ;  x = t2
// 5. Optimized  : (if b and 2 were constants, folded at compile time)
// 6. Target     : MOV R1, b / MUL R1, #2 / ADD R1, a / MOV x, R1

• MCQ trap: the order is fixed — lexical before syntax before semantic; a missing ; is caught in phase 2, while int x = "hello"; survives to phase 3.
• Note that preprocessing (#include, #define) happens before phase 1, and linking happens after phase 6 — neither is one of the six compilation phases, a distinction examiners rely on.

Q4. Differentiate the role of a linker from that of a loader.

Answer

• Linker input: object files and library information.
• Linker job: combine modules, resolve symbols and perform relocation; produce an executable or library.
• Loader job: create the process image and arrange the program's runtime dependencies.
• Dynamic linking: some bindings happen at load time or runtime.
• Final step: transfer control to startup code, which eventually calls the program entry routine.
• Contrast: linking prepares the binary; loading prepares execution.

g++ -c main.cpp        # compile only  -> main.o   (object file)
g++ -c helper.cpp      # compile only  -> helper.o
g++ main.o helper.o -o app     # LINKER: resolves calls, produces "app"
./app                          # LOADER: brings "app" into memory, then executes

// main.cpp calls a function DEFINED IN ANOTHER FILE
int add(int, int);            // declaration only -- an external reference
int main() { cout << add(2, 3); }   // prints 5 once the linker finds add()
// If helper.o is omitted: "undefined reference to add(int, int)" -- a LINKER error

• MCQ trap: an "undefined reference" is a linker error, not a compiler error — the file compiled perfectly; only the definition was missing at link time.
• Note too that static linking copies library code into the executable (larger file, self-contained), while dynamic linking uses shared libraries such as .dll/.so files; symbol resolution can occur at load time or later.

9. 📜 Past-Paper Questions & MCQs (CSS 2016–2026)

2018 · Paper-I · Q2(d) · 3 marks

Recall cue: Give four distinct practices with their purpose: naming, formatting, documentation and modularity.

Q. List any four best practices for coding standards.

Answer — key points

• Use meaningful, consistent names for variables, functions and classes.
• Format code consistently with proper indentation and spacing.
• Write clear comments and documentation, explaining why and not only what.
• Avoid magic numbers (use named constants) and break work into small, reusable functions.
• Also: handle errors, use version control, and review code.

2021 · Paper-I · Q3(c) · 5 marks

Recall cue: Define an IDE; connect features to development tasks; list only tools you have used when asked.

Q. What are IDEs? How do they help in software development? List the IDEs you have used.

Answer — key points

• An IDE (Integrated Development Environment) is one program that combines a code editor, compiler or interpreter, debugger and build tools.
• How it helps: syntax highlighting, auto-completion, instant error checking, one-click build and run, debugging with breakpoints, project management and version-control integration. All this saves time and reduces mistakes.
• Common IDEs: Visual Studio, Visual Studio Code, Code::Blocks, Dev-C++, Eclipse, NetBeans, IntelliJ IDEA, PyCharm, Android Studio. (In the exam, list the ones you have actually used.)

2021 · Paper-I · Q4(c) · 6 marks

Recall cue: Compare detection stage and examples; distinguish compile, link, runtime and logical errors.

Q. What do you mean by runtime and compile-time errors?

Answer — key points

• Logical errors are different again: the program runs but gives wrong results.

MCQs

2024 P-I · Q13. When compiled, which of the following classes of statement often yields no executable code?

• (A) Assignment statement
• (B) Structural statements ✅
• (C) Input and output statements
• (D) None of these
• Answer: (B) Structural statements.
• Why: declarations and other structural statements only tell the compiler about the program's structure (types, names, blocks), so they usually produce no machine instructions. Assignments and input/output statements are translated into executable instructions.

2024 P-I · Q15. A compiler can check errors.

• (A) Syntax ✅
• (B) Content
• (C) Logical
• (D) None of these
• Answer: (A) Syntax.
• Why: a compiler can detect violations of the language grammar (a missing semicolon or bracket) and type errors, but it cannot know what the programmer meant, so logical errors (wrong result) are not found at compile time.

Technical accuracy notes

• Translation models: ahead-of-time compilation, interpretation and JIT compilation can be combined. Avoid treating these as fixed properties of a language.

Recall check and coverage

• Explain the three learning outcomes at the top without looking.
• Reproduce one example or trace and test a boundary case.
• Answer each self-test, then compare with the key.
• Attempt each recorded past-paper task on this page.

Recorded written references: 2018 · Paper-I · Q2(d) · 3 marks; 2021 · Paper-I · Q3(c) · 5 marks; 2021 · Paper-I · Q4(c) · 6 marks

Evidence limit: this page preserves the question records found in your Notion notes. Disputed labels and questions not checked against original PDFs remain flagged in the Question Bank; this is not a claim of exhaustive original-paper verification.