Add Contiguous integration to the repo for better standards

[jatindhankhar]

Add CI to monitor correct building of the project, also helps in detecting compile time errors for pull requests and helps catching trivial errors, almost every cool project on Github is using one. I suggest Travis CI

Some resources that might help Travis CI + Clang + CPP 11

Travis CI + GCC + CPP 11

Another resource

[sftrabbit]

Great idea. It is definitely on my to-do list (currently doing a manual rebuild and deploy). Thanks for the links.

[jatindhankhar]

:+1:

[sftrabbit]

I would like to do continuous deployment as well as integration. This project involves two repos though (CppSamples-Web and CppSamples-Samples) - anybody know if you can have Travis-CI trigger a build when either repo is updated?

Edit: Looks like maybe this would work if I used git submodules. Then I just need to push updates the submodule.

[jatindhankhar]

Glad you found the right way. I am not a expert :sweat_smile: , so can't help much .

[sftrabbit]

I've implemented continuous integration/deployment for the website itself, which basically pulls in the samples, builds the site, and then pushes it to the GitHub Pages repository where it is hosted. I'll soon do some CI for this samples repository, but I need to think of a better way to test the samples (not just seeing if they compile). (sorry, just putting my thoughts here to keep note)

[DarkerStar]

Just a suggestion off the top of my head:

Given the simplicity of the tests, incorporating a proper test and mock framework is probably insane overkill. You could probably get by with simple hand-cranked tests in each sample file. Also it would probably be better if each sample was entirely self-contained - and thus self-testing. Trying to shadow the sample tree with a test tree just seems like an unnecessary pain.

The sample format already looks like this:

// preamble

<sample code>

// text

<hidden code>

If you specify that the "sample code" has to be a function, and the "hidden code" has to be a legal main function that calls the sample code function, you could then further specify that the main function has to do tests on the sample code.

For example (borrowing from the count() sample):

// Count occurrences of value in a range

# include <iostream>
# include <algorithm>
# include <vector>

template <typename Range>
int count_occurrences_of_3(Range const& range)
{
    int count = std::count(std::begin(range),
                           std::end(range),
                           3);

    return count;
}

// Sample description
// ...
// ...
// ...

int main()
{
    auto result = 0;

    std::vector<int> numbers = {1, 2, 3, 5, 6, 3, 4, 1};

    auto e1 = std::count(std::begin(numbers), std::end(numbers), 3);
    auto r1 = count_occurrences_of_3(numbers);
    if (r1 != e1)
    {
        std::cout << "[count-values-in-range] test 1 failed; expected [" <<
            e1 << "], got [" << r1 << "]\n";
        ++result;
    }

    // Maybe other tests...

    return result;
}

Now you can test by building the sample cpp file, and running it. The non-zero exit status will alert your CI tool - whatever you use - that there was an error, and you get some info on stdout about what went wrong. And because everything after the sample text comment block is invisible on the site, you could add as many tests as you like, or make the tests as complex as you please.