C++ Input Parsing and Data Validation

Text is not valid data just because it was read

getline can read the text apple:12, apple:2cats or apple:99. Reading a line successfully tells you that text was obtained. It does not tell you that the text follows your format or that its number is suitable. Parsing means turning text that follows a stated structure into values. Validation means checking whether those values satisfy the task's rules. Keep these steps separate so failures are easy to explain.

We use a small record format: a name, one colon, and a quantity. The name has one through twelve lowercase English letters. The quantity has one or two decimal digits and its value must be zero through twenty. There are no spaces, signs, extra fields or empty parts. Leading zeroes within the two-digit limit are accepted, so apple:02 means two. These are written choices, not universal rules for text files.

A narrow format is a good learning tool because every accepted and rejected example can be explained. It is not general CSV, JSON, a spreadsheet import or a language parser. Those formats have their own rules for quoting, escaping, encodings and numbers. Do not call this parser CSV merely because records are on lines. The promise you make in documentation should match the text your program actually understands.

Write the accepted shape before the implementation

Start with ordinary examples. apple:0 and pear:20 are valid. :2 has no name. apple: has no quantity. apple:2:3 has an extra colon. Apple:2 has an uppercase letter, which our rule excludes. apple:21 has the right general shape but a value outside the allowed range. A short list like this is more useful than beginning with conversion code and discovering its accidental behavior later.

Find the first colon and require it to be the only colon. Then check the lengths of the two parts. Loop over the name characters and require each one to belong to the explicit lowercase alphabet. Loop over the quantity characters and require each one to be a decimal digit. We deliberately use explicit character sets rather than claiming to recognize all letters from all languages. No whitespace is trimmed from record lines.

Only after the digit and length checks do we build the quantity. Starting from zero, multiply by ten and add the next digit. With at most two digits, the intermediate number cannot exceed ninety-nine, so this calculation cannot overflow int on a conforming implementation. Finally check zero through twenty. If you later allow longer fields, you must revisit overflow protection rather than copying this bounded calculation into an unlimited parser.

• apple:12 splits into apple and 12.
• The name is nonempty lowercase text and has allowed length.
• Both quantity characters are digits; conversion gives 12.
• 12 is in 0..20, so the record is accepted.

Each early return answers one small question

The parser does not need one giant condition that does everything at once. Each early return rules out one kind of failure before later work depends on it. The separator checks happen before slicing the two fields. Length checks happen before bounded numeric conversion. Digit checks happen before using a character as a number. This order makes the function readable and explains why an invalid input cannot sneak through just because its beginning looked correct.

The local name and quantity are work in progress. Only the final return creates a successful Record value. optional makes the success-or-absence boundary visible, and the caller checks presence before using the record. For an application that needs detailed reasons, you can return a richer error type. A single missing result is enough for this lesson because the surrounding loop adds the record number and stops at the first failure.

Duplicate names are allowed here. The parser checks the shape and quantity of one record, not uniqueness across the whole collection. A business rule such as no repeated item name belongs in a later collection-level validation step. Do not quietly add rules that were never documented. A parser that rejects a valid repeated name can be just as wrong for its contract as one that accepts a malformed quantity.

Report the first bad record without a false success report

When reading several records, keep a one-based record number for the user. If the third required line is missing or invalid, report Invalid record: 3. That points the learner to the failing data without printing a partial total that looks complete. It is a record number after the count header, not the physical file line number including that header. Choose and document one meaning so the report cannot be misread.

Collect accepted records in a temporary vector. Print the success report only after all required records pass. If you later load this into an existing application state, use the candidate-and-commit plan from the exceptions lesson. Validation and state updates should not be interleaved accidentally. A program that prints three accepted records and then fails on the fourth needs to explain that the report is partial; our lab avoids that ambiguity entirely.

Do not fix malformed input by deleting characters until it becomes valid unless that normalization is an explicit requirement. apple:2x must not quietly become apple:2. Leading and trailing spaces on record lines are rejected under our exact rules, even though the separate count reader accepts surrounding whitespace. Different fields can have different contracts. The important point is that these choices are visible, consistent and covered by examples.

Build a tiny record import with honest failure

Read a whole-line count from zero through five, then exactly that many required record lines in the documented name:quantity format. A malformed or out-of-range count prints Invalid input with status one. A missing or invalid required record prints Invalid record followed by its one-based record number, with status two. Stop at that first error. Lines beyond the required count are outside this small exercise's input contract.

On success, print Records followed by the count and Total followed by the sum. Keep duplicate names and zero quantities. At most five quantities of twenty keep the total within one hundred. Test empty data, maximum lengths, leading zeroes, extra colons, spaces, missing lines and an invalid last record after several valid ones. Be able to explain whether each rejected example fails structure, character rules or allowed value. That explanation matters more than a long list of conversions.