<em id="rw4ev"></em>

      <tr id="rw4ev"></tr>

      <nav id="rw4ev"></nav>
      <strike id="rw4ev"><pre id="rw4ev"></pre></strike>
      合肥生活安徽新聞合肥交通合肥房產生活服務合肥教育合肥招聘合肥旅游文化藝術合肥美食合肥地圖合肥社保合肥醫院企業服務合肥法律

      COMP26020代做、代寫C++設計程序

      時間:2023-12-08  來源:合肥網hfw.cc  作者:hfw.cc 我要糾錯


      COMP26020代做、代寫C++設計程序
      COMP26020 – Assignment 2
      Library Management Software in C++
      A. Assignment
      The goal of this assignment is to implement a set of C++ classes that aim to be used in a library management
      software. The library holds documents of different types (novels, comics and magazines) with various attributes
      (title, author, etc.) and users can borrow and return documents.
      • library.h has the different classes definitions including inheritance relationships as well as the
      prototypes for all classes’ methods.
      • library.cpp contains the implementations of the classes.
      • test-suite.cpp, catch.h, and catch.cpp implement a test suite that checks the correctness of the
      library code.
      The code in your repo has everything already implemented and it’s 100% functional and (mostly) correct!
      Wait. What’s the point of this assignment then?
      Well, the code was written by someone who only watched some of the videos in the first week and then gave up.
      As such, the code is more C than modern C++, it does not use the standard library, and it does not follow any of
      the C++ design approaches. Ah, and it also has a few memory leaks. This is not good C++ code.
      Your actual goal is to rewrite library.{cpp,h} using the concepts and approaches we covered in the lectures.
      This includes:
      • RAII
      • new/delete considered harmful
      • C-arrays, C-strings considered redundant
      • C++ standard library containers, utilities, and algorithms
      • Improved type safety
      • Using linters, static analyzers, and the C++ Core Guidelines to uncover errors and bad coding patterns
      Your rewrite should not change the externally visible behaviour of the library classes: any possible external
      function calling any of the public member functions in library.h should behave the exact same way it did before
      the rewrite. In practice this means that:
      a) You are allowed to edit only library.h and library.cpp
      b) You are not allowed to remove existing public member functions in library.h
      c) You are not allowed to change the visibility of existing member functions
      d) You are not allowed to change the argument types or the return value types of public member functions
      in library.h (with one exception, see below)
      e) Your member functions need to return the exact same thing they would have returned originally.
      On the other hand, you are free to:
      a) add new member functions (private, protected, or public)
      b) change the internal implementation of any member function
      c) Add/remove private member variables in library.h or change their types.
      The only allowed change of types in function prototypes is between types that are implicitly convertible. For
      example, an int with allowed values 0/1 can be replaced by a bool. The testing code is also designed to treat all
      different kinds of strings as interchangeable. If you’re not sure, test it.
      B. How to approach the assignment
      As is, the code is extremely unsafe. Try to use (modern) C++ capabilities that attack that problem first. If you do it
      correctly, you will be able to remove large parts of the code, eliminate some warnings, and multiple guidelines
      suggestions. This will make it much easier to identify any remaining issues and understand what is causing the
      various warnings.
      A related advice is to keep thinking about whether you actually need every piece of code in your code base. If you
      can remove some function/loop/code-block without affecting the functionality of the program, remove it.
      Test your code after every single change you make. Does it still compile? Does it still pass the tests? If you made a
      mistake somewhere, it’s better to find out immediately rather than after another 5-10-20 changes.
      Warnings from the compiler, clang-tidy and the static analyzer are often interconnected and multiple warnings are
      just symptoms of the same bad design choice. In such cases, try to eliminate the actual problem, not each
      symptom individually.
      C. Building and testing
      Test Suite
      To run and test your implementation you are given a basic test suite in the form of a C++ file, test-suite.cpp. It’s
      a C++ program (i.e. it contains a main function) that includes library.h. It instantiates/manipulates objects from
      all the library classes and performs sanity checks. This program uses the Catch1
      test framework and requires two
      additional source files to be compiled: catch.cpp and catch.h. You can compile the program manually:
      $ g++ -std=c++17 test-suite.cpp library.cpp catch.cpp -o test-suite
      and execute the test suite with:
      $ ./test-suite
      You don’t need to understand the testing code fully, but if you get failed tests, it might be useful to check the code
      that is associated with the failed test in order to understand what went wrong. Overall, the suite is divided into
      tests cases enclosed into TEST_CASE() { ... } statements. A test case will fail when one of the
      REQUIRE( <condition> ) or CHECK( <condition> ) statements it contains fails, i.e. when condition evaluates
      to false.
      To complete the assignment you do not need to understand the content of catch.h and catch.cpp.
      Passing all tests does not mean your code is 100% correct. Your solution is 100% correct only if the public
      behaviour of all public methods remains exactly the same under all possible usage scenarios2
      . When marking, we
      will test whether your code is correct with a special test suite containing additional cases. So, make changes
      carefully. If you are not certain about some change, add your own test case to test that change or discuss it with
      us in the lab.
      Make
      For your convenience, we provide a Makefile that can help you automate building and testing your code.
      To build the whole test suite and check the library code for warnings:
      $ make
      To run the gcc static analyzer
      $ make analyze
      1 https://github.com/catchorg/Catch2
      2 You can assume that input arguments are always valid though: no null pointers, number values are within valid ranges,
      filenames are legal, etc.
      To run the C++ core guidelines checker and parts of the clang static analyzer:
      $ make guidelines
      You can change the three variables at the top of the Makefile to match your setup. CXX should point to your C++
      compiler. Make sure it’s one from the last 3 years, supporting C++ 17. Also, note that make analyze will only work
      with g++>=10.0. Use your compiler’s static analyzer, if you’re using another compiler. TIDY chooses which clangtidy to use. The default is to use one in the system path.
      Workflow options
      1. Lab workstations locally
      The lab Linux workstations are already setup in the exact same way as the machine where your code will be
      tested. So, it’s the easiest option to use and you will be 100% certain that if your code runs correctly for you, it will
      run correctly for us too.
      2. Lab workstations remotely
      Same advantages as above but you can connect to them from home (through VPN) or from other university
      locations. You will need an ssh client, such as openssh (Linux) or PuTTY (Windows). To connect set the remote
      hostname to one in the range e-10cki18001.it.manchester.ac.uk to e-10cki18060.it.manchester.ac.uk.
      For example in Linux you can do:
      $ ssh -Y <username>@e-10cki18001.it.manchester.ac.uk
      If the command says that it cannot find a route to the host, try a different hostname in the valid range.
      3. Your own Ubuntu Installation (VM or not)
      For Ubuntu 22.04 (preferred):
      $ sudo apt install make g++-11 clang-tidy-12
      For Ubuntu 20.04:
      $ sudo apt install make g++-10 clang-tidy-12
      and edit Makefile to say CXX := g++-10
      With these changes you should be getting results similar to what you would get in the lab. But keep in mind that
      we will not be able to help you if you run into any problems caused by differences in the setup.
      4. Other systems
      This is the riskiest option. We will not be able to help you with any technical issues. It’s also possible that your
      system displays different behaviour than the lab workstations. For example, we have seen multiple cases where
      the submission does not compile on our side because of a missing header file, but does compile on the student’s
      side because their compiler indirectly included that header. So, be aware of the risks and try to test your code on a
      lab workstation before submission.
      The main thing to do is to install an appropriate compiler and clang-tidy. After that set CXX and TIDY in the
      makefile to point to your compiler and clang-tidy respectively.
      Building and running the test suite only requires a relatively modern C++ compiler so this should be easy to get
      working correctly. make analyze will only work with g++ > 10.0. If you don't have access to an appropriate version,
      check whether your compiler has a static analyzer you can use. make guidelines requires clang-tidy. If you're using
      Visual Studio, you could use the C++ Core Check instead.
      If you don't have a recent g++ or clang-tidy, consider connecting to the lab workstations and testing your code
      there following the instructions above.
      D. Submission
      Deliverables, Submission & Deadline
      There are two deliverables: the completed library.cpp and library.h files. The submission is made through
      the CS Department’s Gitlab. You should have a fork of the repository named “26020-lab2-S-CPlusPlus_<your
      username>”. Make sure you push to that precise repository and not another one, failure to do so may result in
      the loss of some/all points. Submit your deliverables by pushing the corresponding files on the master branch and
      creating a tag named lab2-submission to indicate that the submission is ready to be marked.
      The deadline for this assignment is 08/12/2022 6pm UTC.
      Submission Checklist
      1. Does your submission compile successfully on the lab machines?
      2. Does your code pass all tests?
      3. Have you committed all local changes? Check using git status.
      4. Have you pushed your changes to the right repository?
      5. Have you tagged your latest commit with “lab2-submission”?
      Marking Scheme
      The exercise will be marked out of 10, using the following marking scheme:
      • The program is functional, and passes the basic test suite /1
      • The program passes all extended tests /1
      • The code takes advantage of C++ capabilities to make the code clearer and more concise /1
      • The library code follows RAII principles /1
      • The library code uses Standard Library containers and data types whenever appropriate /2
      • The library code uses Standard library algorithms whenever there is a clear benefit from doing so /1
      • The library code does not produce significant warnings when compiled with -Wall, -Wextra, -Wpedantic,
      or the static analyzer and it does not suffer from memory errors /1
      • The library code follows the C++ Core Guidelines (at least the ones that we discussed in the lectures, as
      well as the ones tested by clang-tidy) /1
      • The code is clear, well commented, and follows good practices /1
      Plagiarism/Collusion
      This is an individual coursework exercise. You should not share your code with others, you should not try to see or
      copy the source of anyone else, and you should not work together with other people. Exchanging ideas can also
      be collusion3
       and it will definitely treated as such if the submissions are unreasonably similar.
      All submissions will be checked using a standard code plagiarism detection program, as well as a checker tailored
      to this assignment. We will manually examine any submissions that are flagged. If their similarities are because
      they contain the code we gave you or because they applied the same obvious changes, then there will be no
      further action. If this is not the case and their similarities are extremely unlikely to be due to chance, they will
      either be penalised or forwarded to a disciplinary panel.
       C S Guidance UoM-wide Guidance Academic Malpractice Procedure
      3 Academic Malpractice Procedure – 3.1.2.3:“The methods of collusion may include, but are not limited to, sharing of work,
      ideas or plans by social media or other electronic communication means, and/or physical sharing of work, ideas or plans.”
      E. FAQ (Check blackboard for updates)
      0. I have the X problem on my Y laptop If you are not confident that you can fix your problems easily, just connect
      to the lab workstations and work there. This is the point of lab
      workstations to begin with: a single hardware/software configuration
      where the code is guaranteed to run and you can be confident that we will
      get the same results you get when we test your code.
      1. "unrecognised command line option -
      fanalyzer"
      Do you have g++ > 10 installed? If you don't have g++ on your platform,
      find the static analyzer of your compiler or try the g++ static
      analyzer installed on the lab workstations
      2. command g++-11 not found You don't have g++-11. Either install it or modify CXX in the Makefile to
      point to the binary of your preferred compiler
      3. Do I need make guidelines and make analyze? No, you can identify all code issues without using the two tools. But why
      make your life difficult? Just use the lab workstations.
      4. Do I need to eliminate all warnings from
      make analyze and make guidelines?
      Probably not. Some warnings might be bogus. Use your judgement. Also
      suppressed warnings in make guidelines are about library code, so it's
      beyond the scope of this coursework
      5. If I eliminate all guideline warnings, will I get
      the full mark?
      Probably not. clang-tidy does not enforce all guidelines, so there will be
      issues with your code that it will not complain about.
      6. How will I know that I have fixed the code?
      What does the perfect solution look like?
      There is no way of telling you that without giving you an exhaustive list of
      what you need to do. But if you attack the big problems that I kept talking
      about in the lectures (i.e, "new considered harmful", RAII, "C-arrays
      considered redundant", avoiding explicit bounds checking), you should
      already be close to a perfect solution.
      7. Can I modify the argument types of any
      member functions?
      Normally no. Straightforward substitutions like bool instead of an integer
      that holds binary values, or std::string / std::string_view instead of cstrings are normally okay. The testing code is written in a way that it will
      handle such cases gracefully. Other substitutions might change the public
      interface and thus break the testing code.
      If you just want to change how you use a function internally, just overload
      the function with a version that has your preferred argument types.
      8. "cc1plus: warning: analysis bailed out early" This only indicates that the code is too complex for the static analyzer. You
      can ignore it.
      9. Can I mix raw and smart pointers? Yes. Smart pointers are meant to be used only for owning data. Replacing
      non-owning raw pointers with smart pointers is usually wrong.
      10. Can we add a destructor for class X, even if
      it was not originally declared in library.h? Can
      we remove the destructor for class Y, even if
      was originally declared? Can we remove a
      copy/move constructor/assignment operator?
      Yes, yes, and yes. The class has the set of five special methods whether
      you declare them explicitly or not (unless you set them to deleted of
      course). Assuming you don’t do anything that affects visibility, there is no
      change to the public interface. The only change is whether the special
      methods are explicit or not
      11. Can we remove/modify/add private
      variables?
      Yes. The testing code cannot see private variables or functions, so any
      changes you make cannot affect the tests.
      12. The test suite reports something like:
      test-suite.cpp:201: FAILED:
       REQUIRE( some_fnct() )
      with expansion:
       false
      REQUIRE checks whether whatever is in the following () evaluates to true
      or 1. The message indicates that some_fnct() returns the wrong value. Try
      to figure out why.
      13. Can I change the arguments/return
      values/methods to const?
      Definitely not the return values. External code might depend on them
      being non-const, even if they are not meant to be modified. Modifying
      arguments and methods should be okay.
      14. Can I change an argument from pointer to
      reference?
      NO! Pointers and references have similar properties but they are not
      syntactically interchangeable. If I call a function passing it a pointer and
      you change that function to get a reference, then the testing code will not
      compile correctly.
      15. When I run make guidelines I get this error:
      clang-tidy: not found
      The makefile cannot find the system clang-tidy. Install one.
      16. Can I cut everything in library.h and paste it
      in library.cpp?
      NO! This will break make and modular compilation in general, i.e. your
      code will not compile when tested. Also it's an awful coding practice.
      17. Can we use standard library header X/Y/Z? You are allowed to use any standard library header you want, as long as
      that header exists in C++ 17. It's not a great idea to use some of these
      headers, but it will not break the testing code.
      18. "No space left on device"! What happened? You've ran out of space. If you are using a lab machine, you don't have
      unlimited space in your university's home folder. Use du -sm * from the
      command line in your home folder to figure out what’s using all your
      space. If you see something that you don’t need and it takes a lot of space,
      delete it and try again.
      19. My tagged commit did not modify library.
      {cpp,h} but an earlier commit did. Will this
      cause a problem?
      No, it will be fine. Our code will clone your whole repo at the point in time
      you tagged it, not just the files you committed when you tagged it. Out of
      this clone, we will copy library.{cpp,h} into our own folder where we will
      build it with our own Makefile.
      E. Appendix
      Class Hierarchy
      The library.h header defines 5 classes which are briefly presented below. Note that more detailed information
      about the methods is present in the header’s source code in the form of comments.
      • Document is an abstract class defining attributes and methods common to all the documents that can be
      held in the library. Attributes include the document’s title and quantity held in the library. It defines
      various methods for printing the document’s information on the standard output, getting its concrete type
      (novel/comic/magazine), and various getters/setters including methods for borrowing/returning the
      document from/to the library.
      • Novel, Comic and Magazine represent the concrete types of
      documents. Each inherits from Document as depicted on the figure
      on the right. They differ slightly in attributes: a novel and a comic
      have an author, while comics and magazines have an issue number.
      Each class also defines the relevant getters/setters.
      • The last class, Library, represents the library i.e. a collection of
      documents. The documents are held in an array of Document pointers. The library class defines various
      methods for actions such as adding, removing, searching, borrowing, returning documents, printing the
      library content on the standard output or dumping it in a CSV file.
      Documents/Library Printing and CSV Output Formats
      The print() method, when called on a novel, prints on the standard output the novel’s attributed in this format:
      Novel, title: Monstrous Regiment, author: Terry Pratchett, quantity: 1
      For a comic:
      Comic, title: Watchmen, author: Alan Moore, issue: 1, quantity: 10
      And for a magazine:
      Magazine, title: The New Yorker, issue: 1, quantity: 20
      The print() method called on a library containing these 3 documents produces:
      Novel, title: Monstrous Regiment, author: Terry Pratchett, quantity: 1
      Comic, title: Watchmen, author: Alan Moore, issue: 1, quantity: 10
      Magazine, title: The New Yorker, issue: 1, quantity: 20
      The dumpCSV() method called on the same library produces a file with the following format:
      novel,Monstrous Regiment,Terry Pratchett,,1
      comic,Watchmen,Alan Moore,1,10
      magazine,The New Yorker,,1,20
      Document class hierarchy

      請加QQ:99515681 或郵箱:99515681@qq.com   WX:codehelp

      掃一掃在手機打開當前頁
    1. 上一篇:CPT109程序代做、代寫C/C++編程語言
    2. 下一篇:代寫COMP3023、C/C++語言編程代做
    3. 無相關信息
      合肥生活資訊

      合肥圖文信息
      挖掘機濾芯提升發動機性能
      挖掘機濾芯提升發動機性能
      戴納斯帝壁掛爐全國售后服務電話24小時官網400(全國服務熱線)
      戴納斯帝壁掛爐全國售后服務電話24小時官網
      菲斯曼壁掛爐全國統一400售后維修服務電話24小時服務熱線
      菲斯曼壁掛爐全國統一400售后維修服務電話2
      美的熱水器售后服務技術咨詢電話全國24小時客服熱線
      美的熱水器售后服務技術咨詢電話全國24小時
      海信羅馬假日洗衣機亮相AWE  復古美學與現代科技完美結合
      海信羅馬假日洗衣機亮相AWE 復古美學與現代
      合肥機場巴士4號線
      合肥機場巴士4號線
      合肥機場巴士3號線
      合肥機場巴士3號線
      合肥機場巴士2號線
      合肥機場巴士2號線
    4. 幣安app官網下載 短信驗證碼 丁香花影院

      關于我們 | 打賞支持 | 廣告服務 | 聯系我們 | 網站地圖 | 免責聲明 | 幫助中心 | 友情鏈接 |

      Copyright © 2024 hfw.cc Inc. All Rights Reserved. 合肥網 版權所有
      ICP備06013414號-3 公安備 42010502001045

      成人久久18免费网站入口