(P) Gigs calendar¶

Header comment and feedback language¶

At the beginning of the main.cpp file, write a comment that includes at least the following information:

• a short description of the program

• author’s name

• student number

• username (Git repository directory name)

• email address

• a short description of the STL data structures used

• justification of implementation choices (mandatory).

For example:

/* Gigs calendar
 *
 * Program description:
 * The program reads data from an input file that lists artists' gigs:
 * performer's name, date, town, and stage.
 *
 * Running the program:
 * The data read from the file is stored in a [suitable data structure]
 * consisting of STL containers and structs. After this, the user can
 * search the data structure using certain commands. The commands take
 * a varying number of parameters, and the program checks both the number
 * and validity of the parameters.
 *
 * Author information: (Fill in your own details!)
 * Name: Teemu Teekkari
 * Student number: 1234567
 * Username: teekkart
 * Email: teemu.teekkari@tuni.fi
 *
 * Justification of implementation choices: (Fill in as appropriate!)
 *   (For example: I chose a data structure X that combines ...
 *   These structures represent the program’s functionality X ...)
 *
 * Additional notes: (Fill in if necessary)
 * - AI tools used (tool, purpose). Be specific!
 * - Possible questions, remarks, etc.
 */

Add the comment (or similar) to the one above at the very beginning of the file main.cpp. Make the description more specific by explaining which STL containers you used.

In this assignment there is only one source code file. If there are multiple source files (as is likely in a later project), the student-specific information must be included in all of them. The program description does not need to be repeated in every file; it is sufficient to include it in the main program file.

Alternatively, you may write the comment in Finnish (see Finnish assignment), but all comments must be written in the same language. Remember to replace the example information with your own personal data.

The point on justification of implementation choices is mandatory. You will miss points, if it is missing.

If working in pairs, remember to include the personal information of both participants.

The feedback language will be chosen in the submission box (at the very end of this page). By default, the feedback language is Finnish, but you can change it, if you want to have the feedback, given by an assistant, in English. We will use the language you have given in the submission box of the final submission.

Data processed by the program¶

The input file given to the program contains lines, each of which has four data fields: performer’s name, date, town, and stage. These fields are separated by semicolons from each other. The structure of an input file accepted by the program can, for example, be as follows:

Olavi Uusivirta;2026-05-08;Jyvaskyla;Tanssisalo Lutakko
Anssi Kela;2026-05-09;Turku;M/S Viking Grace
Dingo;2026-05-09;Helsinki;M/S Finlandia
Dingo;2026-05-15;Kuhmo;Hotelli Kainuu
Anssi Kela;2026-05-15;Vantaa;Tikkurilantori
Uniklubi;2026-05-16;Tuusula;Krapin Paja
Dingo;2026-05-22;Turku;M/S Viking Grace
Pete Parkkonen;2026-06-26;Tampere;Tavara-asema
Pete Parkkonen;2026-08-08;Helsinki;Allas Live
Anssi Kela;2026-08-27;Helsinki;Huvila-teltta
Samu Haber;2026-09-18;Helsinki;Kulttuuritalo
Eva Dahlgren;2026-09-24;Turku;Logomo
Eva Dahlgren;2026-09-25;Helsinki;Kulttuuritalo
Anssi Kela;2026-11-18;Turku;Logomo
Orion;2026-12-05;Tampere;Tavara-asema
Hector;2026-12-05;Helsinki;Veikkaus Arena

Here, gigs have been listed one after the other in chronological order, but the above lines could have been listed in any order.

The names of both artists and stages can consist of several words. If this is the case, queries require quote marks, as will be shown in later examples. On the other hand, in implementing the program you need not care about this, since the given split function can handle quotes in an appropriate way.

The given dates must be acceptable ones. This must be checked but it can be done easily by calling the given function is_valid_date.

Error messages related to file management¶

When the program starts up, it reads the name of the input file from the user as follows:

Give a name for input file: data.txt

If the program cannot open the input file, it will print the text:

Error: File could not be read.

After that, the program terminates with no other prints with the return value EXIT_FAILURE.

If the input file can be opened but the file does not correspond to the specification above, the program prints the error message:

Error: Invalid format in file.

and terminates with the return value EXIT_FAILURE. This can be the case, if, for example, a line of the input file contains something else than four text pieces separated by a semicolon. Empty text pieces are not accepted either.

However, if the date in the file is impossible, the program prints the error message:

Error: Invalid date.

You must check double bookings from the input file. If based on input file, an artist has several gigs at the same time (possibly in different stages), the program prints the error message:

Error: Already exists.

The same error message will be printed, if a stage has several gigs at the same time (possibly given by different artists). In these cases also, the program terminates with the return value EXIT_FAILURE.

There are more error messages related to the commands. They will be explained in the context of the command in question.

Commands and error messages in general¶

The program parses the lines of the input file and stores the information about artists and their gigs in an adequate internal data structure.

After reading the input file, the program starts the actual execution. Each time the user is expected to give input, the program prints the prompt:

gigs>

to which, the user can give commands listed in next sections.

Each command has 0-4 parameters. If too few parameters are given for a command, the program gives the error message:

Error: Invalid input.

If there are too many parameters, the extra ones are ignored. No error message is given, the extra ones are just useless.

Parameters are typically artists and/or stages. If a command is used to print something about them, the program ensures that the artist/stage in question can be found in the data structure. If this is not the case, the program gives an error message explained with the commands in question a bit later.

On the other hand, if a command concerns adding a new gig, the program ensures that the addition can be done (no double bookings), and gives an error message if needed.

If the user gives another command, not listed below, the program prints the error message:

gigs> xyz
Error: Invalid input.
gigs>

After completing the execution of a command given by the user, the program prints the prompt again, until the user gives the command QUIT.

Both lower-case and upper-case letters are allowed in the commands. (Here you can use toupper function provided for char type. Before comparing user input e.g. to the word QUIT, change all the letters in the user-given command into upper-case ones.)

Commands to be implemented (with error messages)¶

All the commands listed in this section must be implemented and they must work to get any points from the project.

• QUIT - The program terminates with the return value EXIT_SUCCESS without printing anything.

• ARTISTS - The command prints all artists one after the other in alphabetical order. For example:

  gigs> ARTISTS
  All artists in alphabetical order:
  Anssi Kela
  Dingo
  Eva Dahlgren
  Hector
  Olavi Uusivirta
  Orion
  Pete Parkkonen
  Samu Haber
  Uniklubi
  gigs>
  

  Here alphabetical order means the order according to ASCII codes. It is almost like alphabetical order but all upper-case letters precede all lower-case letters. For example, if we had above written Anssi Kela as anssi kela, it would have been written as the last one in the list.

• ARTIST <artist> - The command prints the gigs of the given artist in chronological order one after the other. For example:

  gigs> ARTIST Dingo
  Artist Dingo has the following gigs in the order they are listed:
   - 2026-05-09 : Helsinki, M/S Finlandia
   - 2026-05-15 : Kuhmo, Hotelli Kainuu
   - 2026-05-22 : Turku, M/S Viking Grace
  gigs>
  

  The command must have at least one parameter. If this is not the case, the program gives the error message:

  gigs> ARTIST
  Error: Invalid input.
  gigs>
  

  If the given artist is unknown, the program prints the error message:

  gigs> ARTIST xyz
  Error: Not found.
  gigs>
  

  The name of an artist can consist of several words. In such cases, the name must be enclosed with quotes, since otherwise the name cannot be considered as a single parameter. For example:

  gigs> ARTIST "Anssi Kela"
  Artist Anssi Kela has the following gigs in the order they are listed:
   - 2026-05-09 : Turku, M/S Viking Grace
   - 2026-05-15 : Vantaa, Tikkurilantori
   - 2026-08-27 : Helsinki, Huvila-teltta
   - 2026-11-18 : Turku, Logomo
  gigs>
  

  Even if the artist’s name consists only of a single word, the user is allowed to use quotes. For example the commands ARTIST Dingo and ARTIST "Dingo" have the same effect.

• STAGES - The command prints the gig places one after the other in alphabetical order, a town first, and then a stage, separated by a comma. (Again the order is based on ASCII codes as with the command ARTISTS.) For example:

  gigs> STAGES
  All gig places in alphabetical order:
  Helsinki, Allas Live
  Helsinki, Huvila-teltta
  Helsinki, Kulttuuritalo
  Helsinki, M/S Finlandia
  Helsinki, Veikkaus Arena
  Jyvaskyla, Tanssisalo Lutakko
  Kuhmo, Hotelli Kainuu
  Tampere, Tavara-asema
  Turku, Logomo
  Turku, M/S Viking Grace
  Tuusula, Krapin Paja
  Vantaa, Tikkurilantori
  gigs>
  

  A town can have several stages. In such cases, print in alphabetical order (based on ASCII codes), first based on the town, and then based on the stage.

• STAGE <stage> - The command prints in alphabetical order (based on ASCII codes) those artists that have gigs on the given stage. Each artist will be printed in the line of its own. For example:

  gigs> STAGE Kulttuuritalo
  Stage Kulttuuritalo has gigs of the following artists:
   - Eva Dahlgren
   - Samu Haber
  gigs>
  

  The command requires at least one parameter. If this is not the case, the given error message is the same as with the command ARTIST in the corresponding situation.

  If the given stage is unknown, the program prints the same error message as with the command ARTIST in the corresponding situation.

  The name of a stage can consist of several words. In such case, quote marks are used in the same way as in command ARTIST. Quote marks are allowed also in names with a single word.

• ADD_GIG <artist> <date> <town> <stage> - The command adds in the data structure the given gig (with its date and place) for the given artist and prints the text Gig added. For example:

  gigs> ARTIST Uniklubi
  Artist Uniklubi has the following gigs in the order they are listed:
   - 2026-05-16 : Tuusula, Krapin Paja
  gigs> ADD_GIG Uniklubi 2026-06-06 Huittinen Lautarokki
  Gig added.
  gigs> ARTIST Uniklubi
  Artist Uniklubi has the following gigs in the order they are listed:
   - 2026-05-16 : Tuusula, Krapin Paja
   - 2026-06-06 : Huittinen, Lautarokki
  gigs>
  

  If the given artist is unknown, the command prints also the text Artist added.. For example:

  gigs> add_gig "Jannika B" 2026-06-06 Kouvola "Kouvolan Wiinijuhlat"
  Artist added.
  Gig added.
  gigs>
  

  Adding a gig can be seen with the commands ARTIST and STAGE. If an artist is a new one, it can also be seen with the command ARTISTS. If a stage is a new one, it can also be seen with the command STAGES.

  The command requires at least four parameters. If this is not the case, the given error message is the same as with the command ARTIST in the corresponding situation.

  You must check the validity of the date, which can be done easily by calling the function is_valid_date given in the code template. If the user gives an impossible date, the program prints the error message:

  gigs> ADD_GIG Uniklubi 2027-02-29 Huittinen Lautarokki
  Error: Invalid date.
  gigs>
  

  The date given above is impossible, since 2027 is not a leap year. Other impossible dates are, for example, those which have too great number for a day or month, or those which have other characters than numbers or hyphen. Gigs can be reserved until the year 2030, and thus, years greater than this are not accepted.

  An artist cannot have several gigs at the same date, and there cannot be several gigs at the same time at the same stage. Both of these cases produce the same error message. Assuming that the gig at 2026-06-06 at Lautarokki was already added for Uniklubi, the program gives the following error messages:

  gigs> ADD_GIG Uniklubi 2026-06-06 x y
  Error: Already exists.
  gigs> ADD_GIG xy 2026-06-06 Huittinen Lautarokki
  Artist added.
  Error: Already exists.
  gigs>
  

  (In the latter ADD_GIG command of the example above, the given artist xy is unknown, and thus, the command prints the text "Artist added.", but alternatively, you leave this print away, since now the gig could not been added.)

  Note that the ADD_GIG command has very much the same action as has been done in reading the input file and storing its content into a data structure. Could it be possible to use here code you have written earlier?

• CANCEL <artist> <date> - The command cancels all those gigs that are allocated for the given artist after the given date. In addition, the command prints the text Artist's gigs from the given date on cancelled. For example:

  gigs> artist "Anssi Kela"
  Artist Anssi Kela has the following gigs in the order they are listed:
   - 2026-05-09 : Turku, M/S Viking Grace
   - 2026-05-15 : Vantaa, Tikkurilantori
   - 2026-08-27 : Helsinki, Huvila-teltta
   - 2026-11-18 : Turku, Logomo
  gigs> cancel "Anssi Kela" 2026-08-27
  Artist's gigs from the given date on cancelled.
  gigs> artist "Anssi Kela"
  Artist Anssi Kela has the following gigs in the order they are listed:
   - 2026-05-09 : Turku, M/S Viking Grace
   - 2026-05-15 : Vantaa, Tikkurilantori
  gigs>
  

  The artist need not have a gig on the given date, but the gigs after the given date will be cancelled.

  If the artist has no gigs after the given date, i.e. there is nothing to cancel, the program informs about it. For example, if Anssi Kela’s gigs were already cancelled after 2026-08-27, and we try to cancel them again, the program prints the error message:

  gigs> CANCEL "Anssi Kela" 2026-08-27
  Error: No gigs after the given date.
  gigs>
  

  The command requires at least two parameters. If this is not the case, the given error message is the same as with the command ARTIST in the corresponding situation.

  If the given artist is unknown, the program prints the error message:

  gigs> CANCEL xyz 2026-06-06
  Error: Not found.
  gigs>
  

  If the given date is impossible, the program gives the same error message as shown with the command ADD_GIG. If both the parameters are erroneous (unknown artist and impossible date), the program informs only about the first error.

The addition and cancel commands described above do not require modifying the file. It is enough to just change the data structure.

Tips¶

• For splitting the file input and the user input, you can use the function split given in the code template. It can handle quote marks in an appropriate way.

• Recall that an iterator becomes invalid if the container changes, i.e. elements are added or removed.

• Recall that as a default, the program will be compiled into a build directory, and again as a default, an input file is searched from there. So, for testing purposes, you can move the input data file to the build directory.

• The version of the compiler used in automated tests is c++17. Therefore newer features, e.g. transform function in algorithm library, does not work.

• Before implementing the program, think carefully how to structure the program to be able fulfill all the requirements.

  • You can either select a data stucture that inherently follows the desired order, or you can sort the elements in the data structure based on a certain criteria when needed.

• Consider how to divide the program into parts. If you wish, you can use classes, but you will not lose points for not using them. It is more important that you can divide the code into functions that are not too long.

• Note that when reading the input file you store artist and gig data. Consider how to use the same code in implementing the command ADD_GIG. This is important in order to avoid repetitive code.

Implementing the program in parts¶

There are basically three parts in the implementation of the program:

• choice of the data structure and reading the file into the data structure

• user interface

• search algorithms.

Consider carefully in which order you want to implement them so that it is possible for you to create and test them one by one before moving on to the next step. The minimum requirement for using the version control is these three parts having been executed as separate commits, but it would, of course, be best if you had more commits. It is possible to divide each of the above parts into several commits.

Special requirements¶

If you want your assignment to pass the evaluation, you must meet these requirements:

• You can only read the input file once during the program execution.

  • This means that you must read the data from the input file to STL data structures. After that all searches, additions, and removals must be done in the chosen data structures (not in the input file).

• You must use STL library, not e.g. Boost.

Evaluation¶

To end up to assistents’ evaluation, your work must first pass automatic tests. Automatic tests do not accept a program producing warnings while compiling. If the automated tests give 0 points for your work, also your final points will be 0, and your work will not be evaluated by an assistant.

The assistant evaluates the latest Plussa submission that has passed the automated testing (= 1 p) and fulfilled the special requirements of the assignment before the deadline, according to the following criteria:

• The overall principle of the solution: 0-20 points:

  • The learning goals of the exercise have been achieved.

  • The program code has been split into logical, suitably long segments using functions, classes, and/or methods.

  • The data structure does not include repetitive data nor unnecessary parts. The chosen data structures have been used in a reasonable way.

  • The program code does not include unnecessary repetitions nor other unnecessary parts.

  • The program code does not include unnecessary limitations or assumptions or other forced solutions.

  • The implementations of the program’s structures are easy to understand.

  • Global variables have not been used in the program code (global constants are OK).

  • The program does not terminate with the exit function.

• Programming style: 0-20 points:

  • Note the section About programming style on this round.

  • Variables and functions are named clearly and appropriately. These items have named by using only one language, not e.g. Finnish and English mixed.

  • Named constants have been used instead of magic numbers.

  • The program code is neatly formatted.

  • The length of program code lines do not exceed 80 characters.

  • At the beginning of each file, there is a comment explaining the purpose of the file, the creator(s) of the project and other necessary information.

  • At the beginning of each function/method (in the header file if such exists), there is a comment describing its working, return value and parameters.

  • There are comments in the code where necessary.

  • Comments are related to the current version of the program, not to an older one.

  • All comments have written in the same language (fi/en), but comments can be written in a language different from that used in naming variables and such.

  • All the variables have been initialized.

  • The compiler does not give warnings while compiling.

• Using the version control: 0-10 points:

  • There are enough commits.

  • The content of commit messages is clear and relevant.