This is the Clemson ACM Repo. We are the local chapter of the Association for Computing Machinery at Clemson University in Clemson, South Carolina. We do cool computing stuff for cool computing people!
This repository contains resources developed to aid with doing cool stuff in Computer Science. The main projects are as follows:
- the Hackpack is a concise and extensive cheatsheet/guide designed to be used during ACM style programming competitions. If you already know your data structures and algorithms, go here.
- The Hackpack++ is an extensive guide that includes all of the great info from the hackpack, but also includes a bit more detail so that you could use it as a learning tool for the different techniques.
- We compile the two different versions of the hack pack from the same code base. Check the hack pack section for an explanation.
Depending on what you are doing you will need different tools:
git
- for tracking changesg++
- all code samples are in C++98 with C++11 listed as notedawk
- text processing tool needed for version directivespdflatex
- The Hackpack body is written in LaTeXmake
- Make is to automate compilation and testing of the documentsperl
- required to support renaming in version directivesfind
- the gnu version of find is required supporting extended posix regular expressions for supporting version directives. On OSX thefindutils
package from homebrew can be used
For all projects and improvements:
- Choose an issue from the issue tracker
- Fork the repo to your personal account
- Make your changes to your personal copy
- When the code is complete, create a pull request in GitHub from your copy to ours
- When the pull request is reviewed and approved, the code will be merged by one of the owners into master.
If you have any questions related to the issues in the tracker, comment on the issues and mention one of the owners.
All examples assume a topic called foo
and a sample problem bar
:
-
All file names should be lowercase with
-
(hyphens) separating the words in a file. For example,ten-commandments.tex
instead ofTenCommandments.tex
-
All sample contest problems should be in a subdirectory called
problems
and in a further subdirectory based on the problem name. For example if the topicfoo
has a problembar
the path to the code sample could befoo/problems/bar/bar.cpp
. -
In the rare circumstance that your finished product is one
tex
file, place it ingeneral
instead -
See how the
set
material is laid out for reference. It is instructures/set
-
foo
the name of the branch wherefoo
is being worked on -
foo.tex
the hackpack documentation on the algorithm -
foo.cpp
reference code for the foo data structure in C++ if applicable -
bar.in
sample input for foo.cpp if applicable -
bar.out
sample output for foo.cpp if applicable -
bar.exe
untracked compiled binary DO NOT ADD THIS. It makes it easier to spot in the.gitignore
. -
bar.py
a version offoo.cpp
in python if applicable. Alternate versions of algorithms in languages other than C++ should be written after the C++ code is written -
bar.example
files such as.vimrc
that do not have an extension normally -
bar.bats
Automated test case written in bats -
bar-test.cpp
An automated unit test written in cpp -
bar-test.in
Data for the automated unit test -
bar-test.out
Expected output for the automated unit test
Documentation should be written in LaTeX
:
For each item in the Hackpack, please include the following in clearly delineated subsections:
- Name and Brief Description of the topic
- Data structures should have a "Reference" section with a code sample of only commonly used functions
- A list of possible uses and applications
- 2-3 possible contest problems; preferably of varying difficulty
- Sample code that answers one of the contest problems
- Please use the
\acmlisting
for code listings. A caption and label should be specified. If applicable, line ranges should be specified to limit the amount of text displayed. - It would be preferred if each set of sample code had some lessons learned to point out some key elements of the implementation
- References using BibTeX where applicable
- Should be "compiled" properly by make
- Each sentence must be on a separate line.
- The condensed version of the hackpack should have the following removed:
* Introductions to the topic.
* Guidelines directing the reader to different sections of the hackpack.
* References to contest problems including statement, sample io, and
lessons learned, but solutions should remain.
* As much as possible, index tags should __NOT__ be removed.
Code Must meet the following standards:
-
Code should be indented with tabs and not exceed 80 characters per line.
-
Code must compile under contest conditions:
g++ -g -O2 -std=gnu++0x -static $*
-
Code must be delivered with the passing unit tests.
-
Code must be commented with detailed explanations and asymptotic notation where applicable
-
Code must be concise but not at the expense of readability
-
Source code must solve a problem: It should solve a specific problem and include all relevant IO and supporting code. The algorithm should not be in a vacuum.
-
The condensed hackpack version should have the following removed:
- Comments that are not critical to the readers understanding
- All library and
#include
code that can be found in other sections of the hackpack - All input and output code that is not critical to the readers understanding
All code must have tests that meet the following requirements
-
All tests should be written using the bats framework, and use
tap
compliant mode. See thestructures/set
section for an example. -
Test at least the upper and lower boundaries of the allowed inputs.
-
Testing files should be postfixed by
-test
prior to the extension. For example,foo.cpp
test files should be calledfoo-test.cpp
andfoo-test.in
respectively -
Tests should be runnable by calling
make test
in the directory of the source- The tests should return 0 in the case that all test cases passed
- The tests should return 2 in the case that any test cases failed
The hack pack is from one source built into two versions: one slim (hackpack
)
and one tome-like (hackpack++
, or as denoted in the build scripts,
hackpackpp
). But how? By a combination of awk
and dark magicks, authors can
use an extremely limited set of C-preprocessor-like #ifdef
s to denote a block
of text or code as part of one version or the other. Here's an example:
// #ifdef hackpackpp
cout << "This is the Hack Pack: plusplus edition!" << endl;
// #endif
// #ifdef hackpack
cout << "This is just the regular hack pack." << endl;
// #endif
The first cout
will only appear in the hackpack++'s code listing, and the
second will only appear in the normal hackpack. Note that the #ifdefs
are
commented out: as long as the line ends with the if directive, they'll work
properly. You might want to comment them out so that they don't break the compilers.
Make sure you have a new line after each directive somewhere!
Here's a list of filetypes where the if directives will work:
.tex
.cpp
.py
example
The hack pack uses a Makefile for building our PDF output. Here's a rundown of the make rules you'll probably be using:
make clean
wipes out the build directory if you don't have a version oflatexmk
that supports the-outdir
flag, and cleans it up withlatexmk -c
if you do.make hackpack
builds the slim version of the hackpack intobuild/hackpack.pdf
.make hackpackpp
builds the bulky version of the hackpack intobuild/hackpack.pdf
.make show
launchesevince
(a pdf viewer) to preview the hackpack.
Contact one of the members of the Hackpack Developers groups with any questions.