” 写作CSCI 2122编程、c/c++程序设计调试Lab 10: Adventuring in the Land of TreborCSCI 2122 – Fall 20201 IntroductionThis final lab is designed for you to create a program which can utilize some past data structures to help the heroesof the land of Trebor become famed and experienced adventurers.In this lab you are expected to perform the basics of cloning your Lab 10 repository from the GitLab course group.A link to the course group can be found here and your repository can be found in the Lab10 subgroup. See theLab Technical Document for more information on using git. You will notice that your repository has a file in theLab10 directory named delete this file. Due to the limitations of GitLab, we are not able to push completelyempty directories. Before you push your work to your repository (which should be in the Lab10 directory anyway),make sure to first Use the git rm command to remove the extra file. If you do not, your pipeline could fail.Be sure to read this entire document before starting!12 ForewordIn this lab you will be writing several program contracts, although those contracts are much less structured thanin previous labs. You are free to write your code however youd like, although you are still required to adhere tothe checklist found in the Submission section of this document. We recommend you look that over before you startcoding so you know Which requirements do exist.While we do not have Specific function requirements in the form of function contracts, we do expect you to adhere togood code design:1. Include as many comments as necessary to make your code easy to understand.2. Create reasonably modular code and make functions for things you do repeatedly (initializations, common datamanipulations, etc.).3. Split your code into multiple C source/header files and use a Makefile to compile them all together. Dont putall of your code into one giant file. This is inefficient and messy and you are likely to lose points if you do so.4. Remember that debugging tools can help you create better code by pointing out memory leaks or invalidreads/writes. Use them often to produce better code.At the end of this lab you will be tasked with creating your own GitLab pipeline scripts. You may find it easier tomake these as you are coding so you can stay on top of each thing you plan on testing. Feel free to look at the pastGitLab pipeline scripts included in the previous labs (the .gitlab-ci.yml file and the scripts in the CI directories). Wewill briefly go through the anatomy of a pipeline job script in the Pipeline Scripts section.23 The Land of TreborIn the Land of Trebor you will find many kinds of adventurers, from the aquamancers of the Southern Seas to theknights of the Halls of Splendor. There are many perils through the lands, and its your job to help as many adventurersreach level 200 as possible.In this lab, you will be given 300 heroes and 200 adventuring locations. Heroes can start at any location you choose,but then are tasked with moving from area to area, trying to overcome the challenges within. Once an area iscompleted, the hero will gain a level and their attributes will increase. If a hero is unable to complete a given area,they perish, but their journeys end is recorded in the record books.3.1 HeroesA hero is a skilled adventurer trying to overcome the mystical challenges of the world. All heroes contain the followingvital statistics:Name: Every hero needs a name. This will be used to differentiate heroes from each other because simplynumbering them seems rude.Class: Every hero is given a class, which defines what their job is. Most jobs are assigned randomly, but a fewrare jobs are Assigned based on statistics.Strength Attribute: Some heroes are strong. They will do well in locations that need Power.Agility Attribute: Some heroes are fast. They will do well in locations that require Subtlety.Intelligence Attribute: Some heroes are smart. They will do well in locations which need Strategy.Charisma Attribute: Some heroes are smooth talkers. They will do well in locations which need Charm.Level: A heros level determines how their attributes improve. A hero always starts at level 0. Get to level 200and theyll go down in the history books!While you are free to code your program however youd like, we recommend creating a C struct for holding the variousHero information. You should minimally have a field for each of the statistics mentioned above, although if youthink there should be more fields added (for your convenience), feel free to do so. In this lab we will not restrict howyou write your code, although you should make sure your submission matches the checklist in the Submission section.This lab includes a file named heroes.lot which contains starting statistics for 300 heroes. Each hero entry is storedin plain text in the heroes.lot file and contains three lines. There will be 300 such heroes stored one after another inthe text file.The first line in a heros entry is a string representing their name. The second line in a heros entry is a stringrepresenting their class name. The third line in a heros entry is a comma-separated list of numbers, which representthat heros Strength, Agility, Intelligence, and Charisma, in that order. These hero attributes start in the range [5, 25]and should increase Over time based on their primary attribute (see Gaining Levels below). The heroes in the .lotfile are given in no particular order.For example:In this entry we find the hero named Rosalina the Vigilant. Her class is Diviner, which is a type of wizard thatspecializes in divination magic, often letting them predict the future or see/hear distant places. She has 22 Strength,25 Agility, 6 Intelligence, and 22 Charisma. Shes very good at most things, but apparently not very studious. Seemsbackwards for a wizard, but who am I to judge? She might become a great hero someday!Its a good idea to read in the heroes.lot file and store all of that hero information somewhere so you can use it whileyour program is Running. How you do this is completely up to you.3.2 LocationsA location is a Dungeon or questing location where a hero can solve a problem and earn some experience. In orderfor a hero to be legendary, they must reach level 200. Each time a hero completes a location, they gain one level. Ifthey fail to complete a location, they die a heroic death. How tragic!A location has the following vital statistics:Name: The name of the location. This is used to differentiate locations later.Level: The difficulty level the location was generated with. While this is generally a good indication of difficulty,there is some variance between location level and that locations difficulty ratings.Power Rating: The locations Power rating opposes a heros Strength.Subtlety Rating: The locations Power rating opposes a heros Agility.Strategy Rating: The locations Power rating opposes a heros Intelligence.Charm Rating: The locations Power rating opposes a heros Charisma.While you are free to code your program however you like, similar to the heroes, we recommend creating a C structto hold Location information. You may find this especially useful when working with threads with the hero/locationrestrictions. See the Challenging a Location section below.3This lab includes a file named locations.lot which contains the statistics for each location you will be using in yoursimulations, stored in plain text. Each location will be stored as two lines and there are 200 such locations stored inthe text file.The first line in a locations entry is a string representing the locations name. The second line of a locations entryis a comma-separated list of numbers which represent that locations Level, Power, Subtlety, Strategy, and Charmratings, in that order. These attributes could be any integer values, but the current locations.lot files ratings do notexceed 75. The locations in the .lot file are given in no particular order.For example:In this entry we find a location named The Dread Catacombs. This location has a Level of 1, a Power Rating of13, a Subtlety Rating of 21, a Strategy Rating of 12, and a Charm Rating of 17. This is a somewhat average earlylocation, where most heroes should be able to challenge this location successfully.Similar to the heroes file, its a good idea to read in the locations.lot file and store your locations in a place wherethey are easily retrievable later.3.3 Challenging a LocationNow that youve read in and stored your heroes and locations, its time to consider what happens when a hero entersa location and attempts to defeat any monsters and solve any puzzles inside. We wont make you work that out onan individual Basis, so instead we will abstract the challenge that a location presents by breaking it down into a fewcomparisons.Whenever a hero attempts to challenge an area, you will compare the heros attributes to the difficulty ratings of thelocation. Consider the following example with Rosalina and the Dread Catacombs:Rosalina the Vigilant The Dread CatacombsStrength 22 13 PowerAgility 25 21 SubtletyIntelligence 6 12 StrategyCharisma: 22 17 CharmWhen Rosalina challenges the Dread Catacombs, you perform the following comparisons between the hero and thelocation: Strength vs. Power, Agility vs. Subtlety, Intelligence vs. Strategy, Charisma vs. Charm. For each comparison,if the heros attribute is greater than or equal to the corresponding location rating, then the hero wins thattest. In the above table, the bolded values are the winners of the comparisons. If the hero wins any tests in thechallenge, they have successfully completed the challenge. They gain one level and then move to the next location ontheir path. In Rosalinas case, she has a successful test of Strength, Agility, and Charisma, so she gains a level andmoves to the next location.If the hero does not manage to successfully win any tests, they perish at this location. You should store which locationthe hero died in (for use later), then add the heros name to a list of all characters who have died at this location.When a hero is challenging a location, no other hero is allowed to challenge that location at the same time. If a heroattempts to Challenge a location which is already being challenged, they must wait until that location is free beforethey can start their challenge. You may want to consider ways to keep other heroes from entering locations theyshouldnt, from the point of view of threads.3.4 Gaining LevelsWhen a hero levels up, their level statistic should increase by 1. At that point their attributes should be increased.When a hero enters the world, they have some statistics based on the heroes.lot file. Whatever their highest attributeis when they enter play is considered their primary attribute. In the case of a tie, choose their primaryattribute in the order of Strength, Agility, Intelligence, and then Charisma. For example, if a character has 22 Agilityand Charisma, then Agility is their primary attribute.A heros primary attribute will improve faster than their other attributes when they gain a level. Make sure you takenote of each Characters primary attribute as necessary.When a character gains a level, their primary attribute should increase by 0.35 and all of their other attributes shouldincrease by 0.25.3.5 Running the SimulationIn order to do any adventuring in the Land of Trebor, you will need to follow the steps found here. Note that thesesteps are recommended as an overarching design philosophy, but are not necessarily the only way to do it. If youhave a different strategy for solving the problems as they have been laid out, feel free to attempt those instead.This lab expects you to use a thread pool to send your adventurers out into the world to go questing. This meansonly a certain number of heroes will be adventuring at any given time. When an adventurer has completed every4location (and thus achieved level 200) or they have died, they are removed from the thread pool and the next herosadventure begins. When all of the heroes adventures have concluded, we will then print some information about thesimulation to the screen. That said, the following sections will outline a reasonable order to achieve success with thislab.3.5.1 Define your StructsYou should Define any structs necessary to hold data. For us, this would include an Args struct for holding anynecessary thread input data, a Hero struct for holding Hero information, and a Location struct for holding Locationinformation. The various structs could potentially hold more than the fields explicitly outlined in the previous sections,such as lists of names in the Location struct for dead heroes. Its always a good idea to have a design in mind beforeyou start coding.3.5.2 Decide on Preliminary Source and Header FilesCreate C source files and header files for categories of data. For example, it might be useful to have heroes.c,locations.c, and simulation.c (along with their associated headers) to hold structs and functions for the heroes,locations, and your main thread pool/simulation logic.3.5.3 Decide on an Initial Design FlowIf you need to, draw on some paper how you imagine the interaction of various pieces of code will occur, then createa list of functions which will be capable of following those interactions. For example, if you have to read in variouspieces of data from a file, consider when that will happen in the overall flow of your code. How will you handlelocation ordering? Under which conditions will you decide when to create a new thread for the pool, and when willthat generally happen? Writing some pseudo-code in comments to outline the steps and procedures of your programbefore you write it can make your life significantly easier in the long run.3.5.4 Create a Working MakefileThis is not something to be left to the end. This is what you should do at the start, once you finalize which librariesand files you Will need to compile in order to reach the final executable file. Remember to make object (.o) filesfor each of your source files, and use the -g compiler option whenever you can in order to help with the debuggingprocess. Its also extremely useful to define a clean target in your Makefile so you can remove any generated .o orexecutable files for the next time you run make, which will then compile everything completely from scratch.3.5.5 Get One Hero Working without ThreadsStart by reading in a single hero and a single location and write a function for having a hero challenge a location.Get that working perfectly. Once thats done, read in multiple locations and test your hero against all of them.3.5.6 Repeat with Multiple HeroesOnce you have one hero working on many locations, try running different heroes against the same locations and see ifthe results are as you expect them to be. Getting multiple heroes working on a subset of locations is a good startingpoint for threads.3.5.7 Attempt to Run Threads for Your HeroesNext you can try creating a thread for each hero and see if they are still able to execute properly. Dont run morethan one thread at a time until youre able to get the single threads working.3.5.8 Set Up Your Thread PoolOnce you Have the hero threads working, you can start to build your thread pool. Start with a small thread pool.You may find it useful to accept a single command line argument (which will appear in argv in your main functiondefinition) to define the number of threads in your thread pool. That way you can execute your program with./programName N to tell your program to create a pool with N threads.3.5.9 Ensure Your Threads Arent RacingOne of the problems with threads is that they can enter a race condition, where two threads will operate on the samedata and cause that datas state to become unstable. We detailed how to avoid race conditions and protect criticalsections in Lab 9. You may need to treat Locations as critical sections.3.5.10 Collect and Print Required InformationOnce your thread pool executes successfully and all of the threads have been completed, you can collect and printany relevant statistics to the screen, as defined by the contract youre currently working on.4 Pipeline ScriptsCreating a pipeline script to run on GitLab is similar to writing a bash script, with a few small bookkeeping changes,which will be Outlined below. When you push to GitLab and there is a pipeline script available, GitLab will automaticallyattempt to execute that pipeline script to completion by executing a series of jobs. The jobs are executed basedon the order defined by the pipeline system and (typically) the current stage of the pipeline depends on the previous.This means you can logically break your various jobs out into the individual stages and ensure that everything runsin the appropriate order. While this is be no means a comprehensive explanation of pipeline script files, it should be5more than enough to get you started with your own pipeline executions.We will start With the pipeline script from Lab 8. Every pipeline script is stored in the root of your repository andmust be named .gitlab-ci.yml in order for GitLab to properly detect it. The script for Lab 8 can be seen here:1 # Robert Smith — Check Lab 8 Code Outputs23 stages :4 – setup5 – build6 – test78 check – file – structure :9 stage : setup10 tags :11 – ugrad12 script :13 – test -d Lab814 – test -d Lab8 / birthday15 – test -d Lab8 / heap16 – test -f Lab8 / birthday / birthday_debug17 – test -f Lab8 / heap / heap . c18 – test -f Lab8 / heap / heap . h19 – test -f Lab8 / heap / Makefile2021 run – birthday :22 stage : test23 tags :24 – ugrad25 script :26 – cp CI / objects / birthday /* Lab8 / birthday /27 – cd Lab8 / birthday /28 – Test -f happy_birthday_geralt29 – test -f example_story_out30 – gdb – batch -x birthday_debug31 – ../../ CI / compare – memory – outputs . sh3233 run – heap :34 stage : test35 tags :36 – ugrad37 script :38 – cp CI / objects / heap /* Lab8 / heap /39 – cd Lab8 / heap /40 – rm -f Heap .o heap rheap41 – make42 – test -f heap .o43 – test -f heap44 – test -f rheap45 – ./ heap46 – ./ rheapIn the above script, we can see there are a few different keywords which define different components of the pipelinescript. To begin, for consistency, we are defining three stages of testing and execution (which we dont necessarilyhave to use all of, but can). We have used them all at some point during the semester for our pipelines.The stages of the pipeline execution flow are broken down into three stages in this script: setup, build, and test.While these can be expressive, theyre also categorical labels and can be almost anything youd like. These three aresimple and somewhat standard, so we continue to use them. These stages will execute in the order presented here.Notice that those lines begin with a -. This is the default way of executing commands.The rest of the script is broken down into jobs. Each job has some parameters associated with it, followed by ascript. The stage parameter defines which stage this job should occur in. Jobs which occur in the later defined stagesare dependent on the previous stages to complete, which means the only way the build stage is executed is if everyjob in the setup stage passes successfully. Therefore, in this case, we can see that check-file-structure must passif we expect the run-birthday or run-heap to begin. Jobs which are set to execute in the same stage will usuallyexecute in parallel.The tags section of each job will tell GitLab which GitLab pipeline runners (threads specifically for finding pendingjobs and running them) this pipeline is allowed to use. In the case of the CS GitLab server, we will always tell it touse ugrad (undergraduate server) runners, which will force the system to run our script on Timberlea (or Bluenosein the case of a fallback situation). This will always need to be set this way in your pipeline scripts or you may neverget a runner.Once your stage and tags are set, you can provide a script for the runner to execute. This script is a list of Unixcommands (similar to a bash script file) and these commands will execute in order. The script section is the mainsystem which Will cause your pipeline to reach a Passed or Failure state. Each script is executed, one after the theother. Every script command executes and GitLab waits to receive its exit code. You may remember from previouslabs that an exit code of 0 is considered success. If every script command returns an exit code of 0, then the entirejob will pass. If the runner receives an exit code of anything other than 0, it will immediately fail.6Lets look at the run-heap job here:1 run – heap :2 stage : test3 tags :4 – ugrad5 script :6 – cp CI / objects / heap /* Lab8 / heap /7 – cd Lab8 / heap /8 – rm -f heap .o heap rheap9 – make10 – test -f heap .o11 – test -f heap12 – test -f rheap13 – ./ heap14 – ./ rheapThis job occurs during the test stage and executes with a ugrad runner. Once a runner is found, it begins its script.The pipeline begins execution at the root of the repository. At line 6 it copies all of the contents of the CI/objects/heapdirectory into the Lab8/heap directory. This gives the heap contract code (and the pipeline itself) accessto any of the necessary object and Output files for testing purposes. At line 7, the pipeline changes its directory tothe Lab8/heap directory. At line 8 and 9, we force-remove the required object and executable files for the heap,and then run make to re-create those files. We then use the Unix test command to ensure the make command hasgenerated the heap.o, heap, and rheap files on lines 10-12. Once we verify those files exist, we execute heap on line13, and rheap on line 14.The test Command is a Unix command which returns 0 if the file or directory its looking for exists. Setting the -foption tells it to look for a file and the -d option tells it to look for a directory. If the file or directory at the givenpath does not exist, it exits with a 1, which will make the pipeline fail. In general, the test main functions we providefor your programs will return a 0 on success and some other positive number if they reach a fail state, which causesthe job (and thus the pipeline) to fail.In this lab we will be asking you to create your own pipeline testing scripts to ensure everything is being producedthe way you expect it. It could be worthwhile to look back through the various lab repositories to see how the other.gitlab-ci.yml files were written so you can have some better insight into how to create your own pipeline scripts. Youmay also find it useful to produce expected outputs and compare them. There are several recent labs which havecompared output files. You may also find it useful to check those script files to see how the comparison is performed.Lab 8s Birthday contract specifically compares story files and may be a good reference.75 Lab 10 Function ContractsIn this lab you will be responsible for fulfilling two lab contracts: the Adventure contract and the Deus Ex contract.Each contract is designed to test you on some of the things youve learned throughout the instruction portion of thislab.For those of you who are concerned, when deciding which naming conventions you want to use in your code, favourconsistency in style, not dedication to a style that doesnt work.The contracts in this Document are worth the following points values, for a total of 10.Contract PointsAdventure 6Deus Ex 4Total 1085.1 Adventure5.1.1 ProblemYou will write a program that will simulate hero adventures in a variety of configurations.5.1.2 PreconditionsYou are required to complete a program which:1. Is capable of handling Heroes as outlined in the Heroes section.2. Is capable of handling Locations as outlined in the Locations section.3. Is capable of having a hero challenge a location as outlined in the Challenge a Location section.4. Is capable of executing each heros adventure in a thread pool.5. Is capable of outputting the information in the Postconditions section.Your program should read in the heroes and locations from the heroes.lot and locations.lot files. Once this is done,you can run a thread pool of hero adventures until all of the adventures have concluded. Once the adventures haveconcluded, print the desired outputs to the screen.A single thread in this contract is considered a full adventure for a single hero. The adventure is defined by somecollection of locations that the given hero must attempt to challenge, one after the other, in order. If the hero issuccessful, they will reach level 200 after completion of the final location on their path.An adventure path is a series of locations in a specific order. For this contract you will be required to run programswhich test each hero against paths created such that they are in the following orders:1. Level Path: Locations should be ordered by Level, from smallest level to largest.2. Power Path: Locations should be ordered by Power rating, from smallest rating to largest.3. Subtlety Path: Locations should be ordered by Subtlety rating, from smallest rating to largest.4. Strategy Path: Locations should be ordered by Strategy rating, from smallest rating to largest.5. Charm Path: Locations should be ordered by Charm rating, from smallest rating to largest.You may perform all paths in a single program or in multiple programs, although if you do them all in a single programmake sure you dont mix the paths. Your heroes should all run the same path before you print the final outcomes.You should be Careful not to mix the results of the adventure paths. For example, you shouldnt be printing hero AsStrategy path outcomes with hero Bs Power path outcomes.Note that using a heap can be a useful method for sorting things, assuming you construct the proper comparefunction. Recall that we get a min-heap if our compare(A, B) function is always returning negative integers whenB A. You can use this to your advantage to write compare functions for your heaps which are capable of creatingthe paths mentioned above.5.1.3 PostconditionsYour programs should be capable of creating and executing threads. All of the functions should be capable of executingwithout crashing.Your program(s) should produce two files for each path: PathName alive and PathName dead, where PathNameis the name of the path which was executed (level, power, subtlety, strategy, charm). Both files shouldcontain a list of heroes, one hero per line. You may find it necessary to sort your files for the purposes of testing withyour pipeline, as threads will often execute out of order between multiple runs, thus executing the various heroesadventures slightly differently each time. In the alive file you can include the heros name, followed by each of theirattributes in the order of Strength, Agility, Intelligence, Charm:Rosalina the Vigilant 92 95 76 92In the dead file, you should include the same information, but additionally on each line you should include the levelthe character was at their death, and the location in which they died:Rosalina the Vigilant 22 25 6 22 0 The Dread CatacombsThe above outputs are just examples and may not necessarily reflect the actual outputs, but should reflect the formatting.If you use floating point values, your outputs may be slightly different, but still valid.The last test you should perform is to choose one of your paths and execute it with different sized thread pools. Executeyour simluation on a single path for all thread pool sizes in [1, 10] and time each simulation (use sys/time.h toaccess the gettimeofday function, which can provide you with microsecond times; man gettimeofday and Googleare your Friend here). Print the time taken for each simulation in microseconds to the screen.The heroes.lot and locations.lot files, which contain the heroes and locations data, can be found in CI/objects/adventure.5.1.4 RestrictionsNone.95.1.5 File RequirementsYour header files should contain your forward declarations, struct definitions and typedefs, as well as any libraryimports (includes) you may need. Always protect your headers with a define guard. You will need to write amain function for each program you provide, as well as a Makefile which successfully compiles all of your code.You are also required to provide a .gitlab-ci.yml file so your code is properly tested in a pipeline of your own design.Your source files, header files, and makefile should be placed in the Lab10/adventure/ directory in your GitLabrepository. Also be sure to include any libraries you need from previous labs or solutions.5.1.6 TestingTo test your code, you should create a pipeline file. Create any necessary expected outputs for your programs andstore them in CI/objects/adventure directory. When your pipeline executes, cop”
添加老师微信回复‘’官网 辅导‘’获取专业老师帮助，或点击联系老师1对1在线指导。
