Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit


CSE-111  Winter 2022  Syllabus  Advanced Programming

1.  General Information

The generic part of the syllabus contains detailed information about prohibiting cheating, due dates and times, submitting assignments, and verification of the sub- mit.  Read it carefully, as you will be held responsible for it.

Directory :   The  directory  /afs/cats.ucsc.edu/courses/cse111-wm/  and  its subdirectories contain all assignments, handouts, examples, old exams, etc.

Assignments:   All assignments must be submitted electronically by using the submit  command  when  logged  into  one  of the  Linux  servers (unix.ucsc.edu).  Assignments submitted via email will not be accepted.  Files copied into the submit directory by any means other than the submit command (e.g., via mkdir, cp -R, FileZilla, etc., will be deleted and not accepted.

Due Dates :   Due dates are announced in the README files in the course direc- tory.  You must frequently check the README.  Emailed programs will not be accepted.  Late submissions or makeups will not be accepted except in case of emergency (illness or injury) requiring a physician’s attention.

Cheating:   Cheating will not be tolerated.  See the secion on cheating in the generic part of the syllabus.  Read the UCSC Academic Miscon- duct Policy for Undergraduates :

https://ue.ucsc.edu/academic-misconduct.html

Grades :   The final grade will be determined by the following :

Programming assignments :      52%

(4 programs * 13% each)

Midterm exam :                          21%

 

Final exam :                                27%

(two hours)

To pass the course, it is necessary to pass both the pro- gramming and examination components ofthe course.


2.  Course Description from Catalog

CSE-111.   Advanced  Programming.   An  introduction  to  object-oriented  tech- niques of software development including data abstraction, inheritance, polymor- phism, and object-oriented design.  Extensive practice using a computer to solve problems, including construction of graphical user interfaces and a multithreaded client/server application.  Formerly CMPS 109.  Prerequisite(s) :  CSE 15 and CSE 15L ;  or CSE 13S and CMPM 35 ;  or CSE 13E and CMPM 35 ;  or ECE 13 and CMPM 35 ;  or CSE 101.

3.  Textbooks and References

Textbooks  are recommended reading, but there will  not be  specifically required readings.

(1) The C++ Resources Network :  Use this site to find specific information about various classes in the standard library.

http://www.cplusplus.com/

(2) Bjarne Stroustrup : A Tour of C++, second edition. Addison-Wesley, 2018.

(3) Stanley B. Lippman, Josée Lajoie, Barbara E. Moo :  C++ Primer, 5th edi- tion. Addison-Wesley, 2013. A good primer discussing C++11.

(4) Bjarne Stroustrup :  Programming Principles and Practice  Using C++, second edition.  Addison-Wesley, 2014.  ISBN 0-321-99278-4.  This is an ele- mentary textbook for a first course in C++.  The previous edition will also work, or any other C++ textbook you may already have.

(5) C++ Core Guidelines :

https://github.com/isocpp/CppCoreGuidelines/

blob/master/CppCoreGuidelines.md

(6) Google C++ Style Guide :

https://google.github.io/styleguide/cppguide.html

(7) Avoid any book that does not discuss C++11, and look for a note about C++11 displayed  prominently  on  the  cover.   Any  C++  book  not  discussing  C++11 should be considered obsolete.  Prefer books discussing C++14 or C++17.  Bet- ter yet, C++20.

(8) C++11 : The New ISO C++ Standard FAQ :

http://www.stroustrup.com/C++11FAQ.html

(9) Bjarne Stroustrup :  The C++ Programming Language, 4th edition.  Addi- son-Wesley, 2013.  This is the revised definitive description of C++11.

(10) Nicolai M. Josuttis :  The C++ Standard Library, 2nd edition : A Tutorial and Reference.  Addison-Wesley, 2012.  A specific tutorial on the library, with C++11.

(11) David Vandevoorde, Nicolai M. Josuttis, Douglas Gregor :  C++ Templates: The Complete Guide, 2nd edition. Addison-Wesley, 2018.

(12) JTC1/SC22/WG21 — The C++ Standards Committee :  Latest publicly avail- able  draft :  N3797  Working  Draft,  Standard  for  Programming  Lan- guage C++.  2013-10-13.

http://www.open-std.org/jtc1/sc22/wg21/

http://www.open-std.org/jtc1/sc22/wg21//docs/papers/2013/n3797.pdf

(13) Bjarne  Stroustrup :   The Design and Evolution of C++.  Addison-Wesley,

1994.  This is a historical document where Stroustrup discusses his design philosophy and how it derived from C with Classes.

(14) P.J. Plauger, Alexander Stepanov, Meng Lee, David Musser :  The C++ Stan- dard  Template Library.  Prentice-Hall, 2001.  Detailed description of the implementation ofthe STL, showing detailed code examples.

(15) Scott Meyers, http://www.aristeia.com/books.html


4.  Detailed Syllabus.

This  course  is  about  programming  in  C++.   Avoid  any  reference  that  does  not include C++11 information.  Prior programming knowledge of the C programming language is assumed.

(1) C vs C++.  Some differences :  Input/output, strings, vectors instead of stan- dard I/O, character and other arrays.  Fundamental data types.  Using the Standard Template Library (STL).

(2) Functions :  pass by value, reference, and const reference.  Namespaces.

(3) Classes :  interface and implementaton.  Header files and file guards.  Member functions.  Operator and function overloading.

(4) Input and output streams.  User-defined I/O operators.  Formatting I/O.

(5) Vectors and free store.  Memory management Constructors and destructors. Copying and assignment of objects.  Pointers and references.  Shared_ptr and Unique_ptr.

(6) Vectors and arrays.  Copy and move constructors, and copy and move assign- ments.  Destructors.  Explicit constructors.

(7) Inheritance polymorphism and object-oriented programming. Abstract classes. Virtual functions.  Overriding functions and operators.  Multiple inheritance as interfaces.

(8) Template polymorphism  and generic programming.   Containers  and inheri- tance.   Range  checking  and  resource  management.   Exceptions :   defining, throwing, and catching.

(9) Containers and iterators in the standard library.  Vectors, lists, and strings. Algorithms and maps.

(10) Threads.  Sockets.  Client/server applications.

(11) Miscellaneous other topics :  TBA.

5.  Students with Disabilities

If you qualify for classroom accommodations because of a disability, please submit your  Accommodation  Authorization  Letter  from  the  Disability  Resource  Center (DRC) to me as soon as possible, preferably within the first week of the quarter. Contact DRC by phone at 831-459-2089 or by email at [email protected] for more infor- mation.

6.  Pair Programming

You may do pair programming if you choose.  You are responsible for choosing a partner with whom you can work.  Read the guidelines in the directory pair-pro- gramming/.

7.  Submit Checklist

Also read the submit checklist in submit-checklist/.


8.  Generic syllabus

$Id: generic-syllabus.mm.so,v  1.12  2021-11-01  04:18:57-07  -  -  $

This is an attachment that I use for the syllabus in all of my courses.  Any contra- dictions between what follows and what is written in the course-specific syllabus is resolved in favor of the course-specific syllabus.

9.  Disability accommodations

It is UCSC policy to assist students with disabilities.  If you qualify for accommoda- tions because of a disability, please submit to me your Accommodation Autho- rization Form from the Disability Resource Center (DRC) right away.  Contact

DRC at :

Disability Resource Center   146 Hahn Student Services   1156 High Street                   University of California        Santa Cruz, CA 95064-1077

Student responsibilities are as follows:

Email: [email protected]

Phone: (831) 459-2089

Fax: (831) 459-5064

(1) Students contact the DRC to determine their eligibility for accommodations. When approved by DRC, they will receive their Accommodation Authorization form.

(2) Students then notify their instructor during office hours or after class of their accommodations,  and  provide  their  instructor  with  their  Accommodation Authorization  Letter.   This  should  be  done  during  the first  week  of the quarter.

(3) Please note that it is the  student’s responsibility to  contact the instructor about authorized accommodations.  For disability-related testing accommoda- tions, arrangements must be made at least three weeks before each test or exam.

10.  Academic integrity and cheating

Cheating will not be tolerated.  Cheating is defined as giving or receiving unpermit- ted aid in any programming assignments, examinations, or other course work that is used by the instructor as a basis of assigning grades.  Incidents of cheating will be reported to the Provost of the student’s college and to the School of Engineering for disciplinary  action.   Cheating in  any part of the course may lead to failing the course and suspension or dismissal from the University.

Be warned that the School of Engineering has a policy of being highly intolerant toward cheating and/or academic dishonesty.  All students shall read the UC Santa Cruz Academic Integrity web pages :

http://www.ucsc.edu/academics/academic_integrity/.

Students are expected to maintain high standards of academic honesty.  That means that any work submitted by a student which is not completely his/her own is not acceptable.   The  only  exceptions  are :   code  provided  by  the  instructor  or  TA, whether given in class or provided in the instructor’s course directory, and code

taken from the assigned textbook.  Specifically, what is not acceptable is swapping code.  ‘‘Just working together’’ is not an acceptable excuse.  Helping each other with general questions is OK and that is one ofthe uses ofthe newsgroup.

Pair programming :  For those courses where pair programming is explicitly per- mitted, it is not cheating for the two partners of a pair to share code, they are devel- oping their projects using a single code base.  See the guidelines for pair program- ming in another directory.  It is cheating if the code between different pairs is exces- sively similar.

Any code not written by the student must be acknowledged in the README submitted with the assignment.  Submitting code not written personally by the student and which is not acknowledged in the README is always cheating, whether or not the code would be otherwise authorized.  Submitting code not written personally by the stu- dent, even if acknowledged in the README, is cheating if it pertains to parts of assign- ments that the student is expected to write individually.  This refers to programs received from anyone, even tutors, or found on the web or other open-source code sources.  And if an argument toward honesty does not convince you, note that if you can surf the web to find some code, so can others too, and they may then submit the same code you do.

Getting help from tutors in developing programs is of course expected.  Tutors, in the course of their duties, may provide small code fragments, or explain to students how to rewrite their code, or how to debug existing code and modify it in order to get it working.

11.  Final exam

From the Registrar :  Final Examination Policies and Schedule.  Final exami- nations are given during the exam week period at the time announced in the Sched- ule of Classes, usually in the same room used for class meetings during the quarter. Final examinations are required in all undergraduate courses.   . ..  When a final examination is one of the regular requirements in a course, no one taking the course may be individually exempted from it.  Travel plans for vacation are not an emer- gency, and should not be made without checking the final examination schedule.

12.  Assignment specifications and the final grade

Late  assignments will not be  accepted  except under  extremely unusual  circum- stances and then only with adequate formal documentation.  Make-up tests and exams will not be given, and workarounds for missed tests and exams will be per- mitted only in case of emergency, such as illness or hospitalization requiring the attendance of a physician.

13.  Due dates and times

A unix.ucsc.edu account is required in order to submit assignments.  All assign- ments will be submitted electronically via the Linux timeshares and must work on these machines in order to receive a grade.  Submitting an assignment via email is not acceptable.

Graders are required to be logged into the ITS Learning Technologies Linux servers (unix.ucsc.edu, etc.), machines when doing any part of the grading.  Whether or not

an assignment ‘‘works’’ with another operating environment will not influence an assignment score in any way.  Students may develop their work with any operating environment they have access to, but must port their programs to ITS LT Linux before submitting them.

Exactly when are assignments due ?  Assignments are to be submitted electronically using the submit command any time on or before the date specified as the due date. That includes up to and including 23:59:59 of the specified due date.  The time of the lecture is not relevant to the time an assignment is due.  In practice, however, you can get away with submitting assignments even later, up until the time that the submit directory is locked with a Unix command.  This will done  sometime the morning after the listed due date.

Waiting until the last minute to submit is not a good idea, since after midnight is gremlin time.  Gremlins are heavily armed with very sharp pointers.  This leaves the exact cutoff time somewhat fuzzy.  If you submit the same assignment more than once, the later submission will override the earlier one.

Not knowing how to use the submit command is not an excuse for failing to submit an assignment.  It is your responsibility to learn how to use it as well as how to use AFS well in advance of the due date.  Once you have done the submit, verify that you have submitted everything that needs to be submitted.

14.  Submitting assignments

Firstly, it is important for you to understand how to submit an assignment.  Waiting until the due date to find that out will likely mean that you will not be able to sub- mit, and hence will score zero.

Submit homework with the command :

submit volume project  files ...

The volume name is the registrar’s catalog code, a hyphen, the instructor’s initials, a period, the quarter, and the two-digit year.  Using submit without operands dis- plays the possible submit volumes.  If you specify a submit volume without a project name, the available project names will be displayed.

Finally, in order to verify that your submit is complete, and that the grader will be able to do the build, create a new directory in your personal file space, copy all of the files you have submitted and then perform your own test build.