Parallel arrays and inventory operations

Parallel arrays store different fields of a record in separate arrays at matching indexes. An inventory can store product names in one array and quantities in another. The index connects the fields, so every operation must preserve that connection.

Review CS1: active counts and CS1: searching and element movement. CS1: records shows a later representation that groups related fields into one object. This lab makes the same relationship explicit using shared indexes.

Treat each matching index as one record #

If names[i] identifies a product, quantities[i] is that product's quantity. Both arrays use the same active count. In an array with n elements, the valid indexes are zero through n minus one.^[1]

Imagine two active records: index zero holds Apples with quantity three, and index one holds Bread with quantity five. The meaning of each quantity depends on its matching name. Swapping the names alone would relabel three as Bread and five as Apples, corrupting the inventory without necessarily violating any array bound.

Capacity counts distinct product records, not the total number of items. With capacity two, those two records fill the inventory even though their quantities total eight. You may still add another apple to the existing Apples record without creating a third record.

State this as a rule for every operation: active names and quantities stay aligned, and used counts complete records. A half-written record is not an accepted inventory entry.

Search before deciding how to add #

For an addition, first search the active names for the requested product. The search returns either a valid index or not-found. Check that result before using it as an array index.

If Apples is already at index zero and two more arrive, update its quantity from three to five. Used stays two because the number of distinct entries did not change. The full-capacity condition does not block this existing-record update.

If Tea is absent and a spare slot exists, put the name and its accepted quantity at the next free index, then increase used once. If Tea is absent and no spare slot exists, leave the structure unchanged and report the capacity condition. Do not update only the name array or increase used before both fields have been stored.

Validate quantities according to the intended inventory rules before storing or adding them. A requested positive addition should not be confused with a subtraction, and an integer quantity update must fit its storage type. Rejected input should leave the existing record and shared count unchanged.

Remove items or remove a record #

First find the product. An absent product cannot be used as a valid index. If present, require a positive requested removal amount no greater than the stored quantity before performing the subtraction. Under this policy, zero and negative removal requests are rejected; otherwise subtracting a negative request would wrongly increase stock.

Removing one item from a quantity of three leaves quantity two and retains the entry. Used is unchanged. Requesting more items than exist needs an explicit error or policy; it must not accidentally create a negative stock quantity under a nonnegative-stock model.

When a permitted removal reduces the quantity to zero, delete the complete record. Suppose the active records are Apples, Bread, Tea and Bread reaches zero. Move Tea's name from index two to index one and move Tea's quantity along with it. Then reduce used from three to two. The former last slots still exist physically, but are no longer active records.

The name and quantity moves are one logical operation. Moving only one field breaks the shared-index rule. Shifting begins at the removed position and proceeds left through subsequent active records, preserving their relative order.

Sort records, not independent columns #

Sorting alphabetically by name is another operation that moves both fields together. When two names exchange positions, their corresponding quantities must exchange positions too.

For example, Bread with quantity five followed by Apples with quantity three should become Apples with three followed by Bread with five. Sorting the names while leaving the quantities as five, three would create the wrong inventory. Sorting each array independently is no improvement: it orders individual columns without retaining the original associations.

Use a dry-run table with an index column and both fields. After every exchange, read each row as a record and ask whether it still names the same product-quantity pair. This reveals a relationship error that a bounds check alone cannot find.

Give each menu choice one defined effect #

A menu-driven program repeats until an explicit exit choice. An invalid choice should not perform an unrelated operation or consume a record. Empty-inventory display, searches, and removals need suitable behavior before any subscript is used.

Keep the operation's result separate from the decision to continue the menu. For example, a failed removal should report why it failed, leave state unchanged, and return to the menu according to the program's policy. Ending the whole program is a different action.

As more fields are added, parallel arrays create more coordinated moves to remember. A structure can make one record explicit in the type system, but the logical rules still matter: search results, quantities, capacity, and permitted state changes must remain valid.

Practice and test plan #

Test an empty inventory, a missing product, a duplicate addition, partial removal, exact removal to zero, excessive removal, and an invalid menu choice. At full capacity, compare adding an existing product with adding an absent product: only the absent product needs a new slot.

When removing the first of three records, both later records shift left and used becomes two. When removing the final record, no later record needs shifting, but used still decreases. For every sorting test, check the complete name-quantity pair rather than checking names alone.