CS 112 - Week 15 Lecture 1 - 2022-12-06

TODAY WE WILL
*   announcements
*   little tidbit: "modern" type-casting in C++
*   quick intro to Git (with a little GitHub)
*   prep for next class

*   Should be working on Homework 11 --
    *   first attempts due by 11:59 pm Friday, Dec 9

*   any improved bits for Homeworks 8-11 need to be
    submitted by 11:59 pm SUNDAY, Dec 11

    so example solutions for Homeworks 8-11 can become
    reachable on Canvas around 12:01 am on MONDAY, Dec 12

*   FINAL Exam: 12:40 pm THURSDAY, Dec 15 in BSS 317

*   THURSDAY, Dec 8 - we'll review for the Final Exam!

    FRIDAY's (Dec. 9's) lab will be OPTIONAL --
    I'll be there to answer questions about Homework 11,
    parts you may be improving on HWs 8-11, Final Exam questions,
    etc.!

=====
little tidbit: "modern" type-casting in C++
=====
*   covered a bit in Chapter 4 of Savitch...!

*   type-casting: asking for a value of one data type
    to be converted, or cast, into its roughly-equivalent
    value of another data type

    (casting an int to double, casting a double to an int, etc.)

*   there's an "older" syntax for this,
    and a newer, now-preferred syntax, and that's what we're
    lightly mentioning here

    *   indeed, C++ now has FOUR "modern" type-casting operators...!

    *   the most basic, considered safest, is a so-called
        static cast:

	static_cast<desired_type_to_cast_to>(value_to_cast)

        static_cast<int>(3.0)

        int thing;
	...
	static_cast<double>(thing)

    *   from a StackOverflow answer, still reachable at:
        https://stackoverflow.com/questions/103512/why-use-static-castintx-instead-of-intx

        "static_cast is an operator that's intended to be
	a valid conversion in the language, or that
	an appropriate constructor makes possible"

*   so, this provides a more elegant way to, say,
    avoid integer division:

    double my_fun(int my_int1, int my_int2)
    {
        ...
	double desired_result =
	    (static_cast<double>(my_int1) / my_int2);
	...
    }

*   so: more elegant, and the programmer's intent is more
    clear, than a kluge like multiplying an int by 1.0, for example!

======
LIGHT intro to git and GitHub
======
*   git - a popular distributed version control system
    *   invented by Linus Torvalds (yes, of Linux fame)

*   GitHub - a website, a web-based HOSTING service for
    software development projects that use git

    (so is GitLab)

*   can download a free local version of git from
    a number of places --

    for example,
    desktop.github.com
    ...tries to detect your OS and gives you a link
       to download such an appropriate version of git

*   BASIC git command structure:

    git desired_cmd desired_args

    you can often access the man page for a particular
    git command using:

    man git-desired_cmd

*   git config command can let you configure various
    bits of user info and settings...

    // set desired_thing to desired_val across all
    //    my local repositories

    git config --global desired_thing desired_val

    *   some common stuff it is good to set:

        git config --global user.name "Sharon Tuttle"
	git config --global user.email "st10@humboldt.edu"

   *   want to see your configuration setting?

       git config --list

*   a REPOSITORY is an archive of the files related to
    some project (typically source code and related documents)

    *   often called a REPO for short

*   to make a new directory that is itself a repo:

    git init desired_directory_name

    to make the directory you are in right now a repo:

    (within that directory)
    git init

*   you can see the current status of your repo:

    git status

*   you can see the version history for the current
    branch using:

    git log

*   one RECOMMENDED approach to version control:
    "do small commits often...
    ...BUT, try to only commit things that COMPILE and WORK
       (try to leave the repo in a good state)"
    
   *   do some work
       hey, I got a thing to work!
       commit that
       repeat

       in more git-based terms:
       work, then "stage", then commit

*   when you have a file you have changed,
    you first stage it or add it to the repo,

    ...then you can commit all the staged/added files at once;

    *   how do you stage a file?

        git add file_name1 file_name2 ...

    *   how do you commit all the currently-staged files?

        git commit -m "description of this commit"

        GOOD PRACTICE IS TO INCLUDE USEFUL SHORT DESCRIPTIVE
	COMMIT MESSAGES!!!!!!!!!!!!!

=====
*   SAY you have cloned a repo -- made a copy of that repo in
    a certain way;

    you can push new committed changes in your LOCAL (cloned)
    repo back to the remote main, the repo you cloned from,
    using

    git push origin main

*   BY THE WAY:

    git diff desired_file
    ...lets you see the differences between a current fiule
    and its committed version