How Strings Are Represented (Conceptual View)

In the previous page, we defined a string as an ordered sequence of characters—a clean, mathematical abstraction. But abstractions don't compute. Every string you've ever worked with exists somewhere physically: in RAM chips, on disk platters, or traversing network cables as electrical signals.

This page bridges the gap between logical model and physical reality. We'll develop intuition for how strings are stored without diving into data structure terminology. Think of this as understanding how the numbered boxes from our mental model translate into actual locations in a computer's memory.

This understanding is crucial. Many string behaviors that seem mysterious—why concatenation can be slow, why indexing is fast, why strings have size limits—become obvious once you understand the physical layer.

Computer memory can be understood as a vast, linear sequence of storage locations—think of it as billions of tiny boxes arranged in a single row, each with a unique number called an address.

Memory:
┌────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
│  ...   │  1000  │  1001  │  1002  │  1003  │  1004  │  1005  │  1006  │  ...   │
└────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘
           ↑                                                        ↑
         (address)                                              (address)

Each box (memory location) has two critical properties:

1. A unique address: An integer that identifies this location. Like a street address, it tells you exactly where to find this particular box.

2. Storage capacity: Each box can hold a fixed amount of data—typically one byte (8 bits). This box size is determined by the hardware.

Key insight: Memory is linear and addressable.

This means:

• Every location has a numeric address you can compute
• You can jump directly to any address (this is called random access)
• Locations next to each other have consecutive addresses

This linear, addressable structure is why the 'row of boxes' mental model is so powerful—it directly mirrors how computers actually work at the hardware level.

When a string is stored in memory, its characters are placed in consecutive memory locations—one after another, with no gaps.

Let's trace how the string "HELLO" would be stored:

Logical View (what we think about):
Position:   0      1      2      3      4
          ┌──────┬──────┬──────┬──────┬──────┐
          │  H   │  E   │  L   │  L   │  O   │
          └──────┴──────┴──────┴──────┴──────┘

Physical View (what actually happens in memory):
Address:   1000   1001   1002   1003   1004
          ┌──────┬──────┬──────┬──────┬──────┐
          │  H   │  E   │  L   │  L   │  O   │
          └──────┴──────┴──────┴──────┴──────┘
              ↑
          Start address (base address)

Notice the beautiful correspondence:

• Position 0 (logical) → Address 1000 (physical)
• Position 1 (logical) → Address 1001 (physical)
• Position k (logical) → Address 1000 + k (physical)

This is no coincidence—it's by design. The consecutive storage means we can compute any character's location with simple arithmetic.

Why contiguous? Why not scatter characters around memory?

Contiguous storage has profound advantages:

1. Instant access by position: Calculate address = base + k. Jump directly there. Done.

2. Efficient traversal: To visit all characters, just walk through consecutive addresses. Hardware is optimized for this pattern—it's called spatial locality.

3. Simpler implementation: One number (the base address) plus one number (the length) fully describes where the string lives.

4. Cache efficiency: Modern CPUs load chunks of memory at once. Contiguous data means loading one chunk gets multiple useful characters.

The cost? If you need to insert a character in the middle, you might need to move everything after it to make room. But for most string operations, contiguous storage wins.

Memory stores numbers, not pictures of letters. So how does the character 'H' get stored in a memory box?

The answer is character encoding: a standardized mapping between characters and numbers.

The most foundational encoding is ASCII (American Standard Code for Information Interchange), which assigns a number 0-127 to each character:

When you store "HELLO", the computer actually stores the sequence of numbers: 72, 69, 76, 76, 79.

What actually happens in memory:

"HELLO" stored starting at address 1000:

Address:  1000   1001   1002   1003   1004
          ┌──────┬──────┬──────┬──────┬──────┐
Logical:  │  H   │  E   │  L   │  L   │  O   │
          ├──────┼──────┼──────┼──────┼──────┤
Actual:   │  72  │  69  │  76  │  76  │  79  │
          └──────┴──────┴──────┴──────┴──────┘

The characters 'H', 'E', 'L', 'L', 'O' are a convenient fiction for humans. What the memory actually contains are numbers that, by convention, represent those characters.

This encoding is completely transparent to you as a programmer—the language handles conversion automatically. But understanding it explains several phenomena:

• Why strings that look different might have the same bytes (different encodings)
• Why comparing characters works (you're really comparing numbers)
• Why case conversion is simple ('a' = 'A' + 32 in ASCII)

When you store "HELLO" in memory, how does the computer know the string is 5 characters long and not 50? How does it know when to stop reading?

This is the boundary problem: in a vast sea of memory locations, how do we mark where one string ends and the next begins?

Historically, two approaches emerged:

Approach 1: Sentinel Termination (Null Terminator)

Place a special marker (typically the number 0, called the null character or \0) after the last character:

"HELLO" with null terminator:
Address:  1000   1001   1002   1003   1004   1005
          ┌──────┬──────┬──────┬──────┬──────┬──────┐
          │  H   │  E   │  L   │  L   │  O   │  \0  │
          │ (72) │ (69) │ (76) │ (76) │ (79) │ (0)  │
          └──────┴──────┴──────┴──────┴──────┴──────┘
                                               ↑
                                         Null terminator
                                         (string ends here)

To find the length, scan forward until you hit 0. This approach is used by C and C++.

Approach 2: Explicit Length Storage

Store the length as a number alongside (typically before) the character data:

"HELLO" with explicit length:
Address:  996-999     1000   1001   1002   1003   1004
          ┌─────────┬──────┬──────┬──────┬──────┬──────┐
          │  5      │  H   │  E   │  L   │  L   │  O   │
          │ (length)│ (72) │ (69) │ (76) │ (76) │ (79) │
          └─────────┴──────┴──────┴──────┴──────┴──────┘
               ↑
         Length stored
         before characters

Now finding the length is instant—just read that stored number. This approach is used by most modern languages (Java, Python, JavaScript, etc.).

When we work with a string in code, we don't actually carry around all its characters—that would be impractical. Instead, we work with a reference to the string: essentially the memory address where the string begins.

This starting address is called the base address or start pointer.

String variable str contains address 1000:

    str
    ┌─────────┐
    │  1000   │  ← This is what the variable holds: an address
    └─────────┘
         │
         ▼
Memory: ┌──────┬──────┬──────┬──────┬──────┐
        │  H   │  E   │  L   │  L   │  O   │
        └──────┴──────┴──────┴──────┴──────┘
        1000   1001   1002   1003   1004

The variable str doesn't contain the letters 'H', 'E', 'L', 'L', 'O'. It contains the number 1000—a pointer to where those letters are stored.

Why addresses instead of actual characters?

1. Efficiency: Copying an address (one number) is much faster than copying every character.

2. Sharing: Multiple variables can reference the same string data without duplicating it.

3. Flexible sizing: Variables have fixed size (enough to hold an address), even for strings of wildly different lengths.

4. Indirection enables operations: To get character at position k, compute address + k. Without the address, you couldn't locate the string.

The equation that powers string access:

address_of_character_at_position_k = base_address + (k × character_size)

For ASCII strings where each character is 1 byte:

address("HELLO"[2]) = 1000 + (2 × 1) = 1002

Look at address 1002, find 'L'. Done. This is why indexing is constant time (O(1))—no matter how long the string, one multiplication and one addition give you the exact location.

While the core idea—characters stored consecutively in memory—is universal, the exact layout varies across languages and systems. Understanding these variations explains why string behavior differs across environments.

C-style strings:

┌───┬───┬───┬───┬───┬───┐
│ H │ E │ L │ L │ O │\0 │
└───┴───┴───┴───┴───┴───┘
  Characters + null terminator
  Length: computed by scanning

Pascal-style strings:

┌───────┬───┬───┬───┬───┬───┐
│   5   │ H │ E │ L │ L │ O │
└───────┴───┴───┴───┴───┴───┘
  Length prefix + characters
  (length in first byte, limited to 255)

Modern language strings (Java, Python, etc.):

┌───────────────────────────────┐
│  String Object Header         │  (metadata: type info, etc.)
├───────────────────────────────┤
│  Length: 5                    │  (explicit length field)
├───────────────────────────────┤
│  Hash: <cached hash code>     │  (optimization for comparisons)
├───────────────────────────────┤
│  Data: H E L L O              │  (actual characters)
└───────────────────────────────┘

Now that we understand physical storage, we can predict the cost of operations. This is the payoff of understanding the physical layer—no need to memorize; you can derive it.

Accessing a character at position k:

Compute base + k × character_size. Jump directly there. Read one value.

Cost: O(1) — constant time, regardless of string length.

Finding the length:

• If length is stored: Read the stored number. O(1)
• If null-terminated: Scan forward counting until you hit null. O(n)

Concatenating two strings:

You can't just 'attach' one string to another—memory is fixed in place. You must:

1. Allocate new memory large enough for both strings
2. Copy all characters from the first string
3. Copy all characters from the second string

Cost: O(n + m) where n and m are the lengths of the two strings.

Strings don't just exist—they must be created (allocated in memory) and eventually destroyed (memory freed for reuse). This lifecycle explains many runtime behaviors.

Creation (Allocation):

When you create a string, the runtime must:

1. Calculate how many bytes are needed (characters + overhead)
2. Find a contiguous block of memory that large
3. Copy the character data into that block
4. Return the base address

For a string literal like "hello", this often happens at compile time—the string is embedded directly in the program's binary. But dynamically created strings (concatenation results, user input) are allocated at runtime.

Destruction (Deallocation):

When a string is no longer needed, its memory should be returned to the pool for reuse. How this happens depends on the language:

• Manual memory management (C): The programmer explicitly frees memory. Forget to free → memory leak. Free too early → use-after-free bug.

• Garbage collection (Java, Python, Go): The runtime automatically detects unreachable strings and reclaims their memory. Safer, but with some performance overhead.

Our discussion assumed each character occupies the same amount of space (one byte). This is true for ASCII, but modern strings often use variable-width encoding like UTF-8.

In UTF-8:

• ASCII characters (U+0000 to U+007F): 1 byte
• Extended Latin, Greek, Cyrillic (U+0080 to U+07FF): 2 bytes
• Common CJK characters, most symbols (U+0800 to U+FFFF): 3 bytes
• Rare characters, emoji (U+10000 to U+10FFFF): 4 bytes

Implications for our mental model:

With fixed-width characters:

Logical position 3 → Physical offset 3 × 1 = 3 bytes

With variable-width characters:

Logical position 3 → ??? (depends on how wide preceding characters are)

The simple address = base + k formula breaks down. To find the k-th character, you must scan from the start, counting characters (not bytes) until you reach k.

We've journeyed from the abstract sequence of our logical model to the concrete reality of bytes in memory. Let's consolidate the key insights:

Next up:

We've covered the logical view (ordered sequence) and physical view (contiguous memory). The final piece of the representation puzzle is understanding length, indexing, and mutability—the practical concepts that determine how you work with strings in code.