这是一篇关于C++代写的作业案例分享

2019/11/17 CMPT 454 Database Systems II – Project Milestone 0
https://www.cs.sfu.ca/~tzwang/teaching/cmpt454-fall19/project/milestone0.html 1/4
CMPT 454 Project Milestone 0: Group Formation and
Environment Setup
Total marks: 100
Overall percentage: 2%
Due: Sept 13 (23:59)
1. Group Formation [20 marks]
The project can be completed individually or in a group (no more than 4 people). Working in groups is strongly recommended. You can post messages in Piazza to nd group members. There will be
multiple project milestones, each requiring a separate submission via CourSys. For each milestone you are allowed to work with the same or a different group.
Note: Per our course policy, everyone in the same project group will receive the same grade. It is your own responsibility to choose your project group members wisely, and ensure that everyone in the group does his/her fair amount of work. We (instructor and TAs) do not enforce things like workload distribution. This (working and coordinating with other people) is part of what you learn by doing a group project.

By nishing this project milestone, you will get prepared to start working on your project. There are also important details and rules that are enforced for the entire project. So please read and follow instructions here very carefully. If you are doing a group project, every group member should be equally familiar with the details and rules here.

2. Setting up Your Code Repository [45 marks]
It is vitally important that you are familiar with version control tools, in particular Git, to be able to complete this project and make submissions in subsequent milestones. If you do not already know how to use Git, follow the Git website and Pro Git book are great resources to understand Git.
Once you are comfortable with Git, create a private Git repository named “yase” at SFU CS
Instructional GitLab (aka “CSIL GitLab”) for your project.
Notes:
Your repo must be private and remain so even after the course concludes (i.e., forever). Violating this rule is equivalent to plagiarism (allowing others to copy your code) and is subject to penalty
that will lead to 0 mark for the entire project as a starter.
You are not allowed to use public repos (e.g., GitHub, BitBucket); similarly, hosting your code using these services will be treated as a plagiarism case where you are allowing others to copy your work, which automatically results in 0 mark.
You can set your repo to be private (i.e., only visible to yourself and invited members) by setting the “Visibility level” option to “Private” on CSIL GitLab’s project creation page.
2019/11/17 CMPT 454 Database Systems II – Project Milestone 0
https://www.cs.sfu.ca/~tzwang/teaching/cmpt454-fall19/project/milestone0.html 2/4
Each group should only create one repo. You can have one member create the repo and other members can be invited as maintainers to gain full access to the repo.
The address to your repo should look like https://csil-git1.cs.surrey.sfu.ca/[SFU ID]/yase.
All of your future submissions will be done through committing to your CSIL repository by the deadline with a link to your repo submitted through CourSys. Submissions in any other form (e.g.,
email) will not be accepted.
Your project code (to be written later in the semester) must run on Linux and be written in C++11.
We grade your code on Linux and will not try to modify your code to make it compile/run Linux.
You are strongly encouraged to use Linux throughout the entire semester for your project.
After creating your repo, grant both the TAs (SFU Computing IDs: cpchen and jianqiuz) and instructor (SFU Computing ID: tzwang) “developer” access to your code repo. You can do this by following “Settings -> Members” in CSIL GitLab.
Next, set up your Git congurations so that your commit messages will contain your identity, including your full name and SFU email as shown in the below code snippet. If you have already done
this before, you can skip this step.
$ git config –global user.name “Your Name”
$ git config –global user.email “Your SFU email”
Now, clone your own repo and make a rst commit by creating an AUTHORS le that lists all the group members in. Note that the le’s name must be verbatim AUTHORS (i.e., not AUTHORS.txt, or authors or anything else). Each member must occupy a new line and be listed in the format: Full Name,SFU Computing ID. Provide a meaningful commit message, such as “Add group member list.” This commit must be done in the master branch of your repo. Remember to do a git push to actually check in the change to the remote GitLab server! If you fail to do so, we will not be able to get your submissions, i.e., same as no submission.
3. Linking with the Baseline Repository [20 marks]
To get prepared for future project milestones and tasks, link the baseline code repo to your repo using git remote (note: do not fork it!). This will make it easy for you to pull future updates from the base code repo, as it will be updated incrementally with new tasks and code skeletons that you will need to complete each project milestone. In the future, you will need to “merge” new skeleton code to your repo. To start, issue the following command at the root level of your code repo:
$ git remote add base git@csil-git1.cs.surrey.sfu.ca:cmpt454-fall19/yase.git
Then issue the following commands to actually get the code into your repo:
$ git fetch –all // Get updates from remote repositories
// Merge code in the base remote repo’s master branch to your own repo.
// Note the remote repo’s name (base) is the same as the one added in the previous git remote add command.
$ git merge base/master –allow-unrelated-histories
2019/11/17 CMPT 454 Database Systems II – Project Milestone 0
https://www.cs.sfu.ca/~tzwang/teaching/cmpt454-fall19/project/milestone0.html 3/4
Now in your own repo, you should see a le named CHANGELOG and a directory named Dummy. The next step is to actually check in your code to the remote repo so your TAs/instructor can fetch it for grading:
$ git push
In the future when new project milestone tasks are released, you can simply issue git fetch && git merge base/master to get the latest updates from the baseline repo to your own repo. Note that all the remote repo information you set up here is local, i.e., it will not be remembered by your remote repo permanently. So if you change to use another machine or environment, you will need to repeat the above steps (git remote and other commands) to set it up. Next continue to nish setting up the environment so you can build the project.
4. Setting up Your Environment and Building the Code [15 marks]
Dependencies: The code depends on the glog, gags, gtest libraries for logging, handling commandline parameters and testing, and CMake for conguring and building. You will need to have these
libraries installed in your system (or build your own). If you are using CSIL server/computer, then all these packages should have already been installed. Each Linux distribution has its own package manager so you will need to nd out yourself. Below are guidelines for Arch Linux and Ubuntu.
For Arch Linux users: The following command will get you all set directly: $sudo pacman -S cmake gtest gflags google-glog. Proceed to the “Building the code” section.
For Ubuntu users: To install these libraries in your own Ubuntu system, issue the following commands:
$ sudo apt-get install cmake
// Note the ‘dev’ suffix
$ sudo apt-get install libgoogle-glog-dev libgflags-dev libgtest-dev
On certain versions of Ubuntu, you need to do some extra work to build gtest by yourself if the test packages only contains source code stored under /usr/src/gtest. If this is the case (you can tell by looking at /usr/lib or /usr/lib64 and see if libglog.so* exist; if so, skip and proceed to the “Building the code” section), follow the steps below:
$ mkdir ~/gtest && cd ~/gtest // Create a gtest folder in your own directory
$ cd gtest
$ cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=on /usr/src/gtest //
Build a shared library
$ make -jN // Replace N with the number of threads you’d like to use for
compiling
Then issue sudo make install if you are using your own machine. If you are using CSIL machine,you may skip this step, and change your top-level CMakeLists.txt to include the library install path
using -L/home/[username]/gtest when linking with gtest (i.e., tell the compiler where to nd libgtest.so). This can be done by adding the following to the top-level CMakeLists.txt:
link_directories(“/home/[username]/gtest”). Finally, in some environments you may need to also add -lpthread to your CMakeLists.txt (e.g., by adding a new line link_libraries(“-lpthread
-pthread”).
2019/11/17 CMPT 454 Database Systems II – Project Milestone 0
https://www.cs.sfu.ca/~tzwang/teaching/cmpt454-fall19/project/milestone0.html 4/4
Building the code: Once you have all the dependencies set up, use the following commands to build the project:
// Create a separate directory to build the project
$ mkdir build && cd build
// Configure the build. Note: choose one out of the three options (Debug,
Release, or RelWithDebInfo)
$ cmake -DCMAKE_BUILD_TYPE=Debug/Release/RelWithDebInfo ..
$ make -jN
5. Submission
First, form your group on CourSys. Note that even if you are doing the project alone, you need to create a group on CourSys. Then submit the URL of your code repository in CourSys. Make sure you are familiar with the course policies. Especially, we do not accept late submissions or submissions by means other than specied here.
Note: make sure all of your changes ready for grading are pushed to the default branch (typically master, unless you changed it in GitLab). When grading, we do not pull any branch other than the default branch.