Hacker News Reader

Comment by mschuetz | Hacker News Reader

C++11, 14 and 17 finally made me fall in love with C++. It's almost like having a nice and easy scripting language with the added bonus of static typing and a huge performance boost.

There are a few things that I'm still not quite happy with.

* It's still incredibly cumbersome to set up a project

* Setting up a proper build system is tedious, especially if you're targeting multiple platforms.

* I'm missing some "functional" methods attached to the collections, e.g. find, filter, map, some, each, ... Afaik some of them exist as functions that take 2 iterators and a lambda but that's just plain ugly and unreadable. Instead of

    std::find_if(list.begin(), list.end(), condition});

I'd like something like

    list.find(condition);

View on HN

Have you tried CMake for setting up you C++ projects? It hide pretty much all the dirty details of find libraries and linking against libraries.

If you already have a compiler installed, you can go from nothing to knowing how to build a library, executable and an installer for multiple platforms in just a couple of hours with the CMake tutorial: https://cmake.org/cmake-tutorial/

Incidentally, it looks like Visual Studio 2017 will support CMake: https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-sup...

If anyone wants me to test anything in particular, I've got that RC on my laptop - although the setup for 2017 is much nicer than anything that came before.

CMake itself can be confounding if you want to do anything slightly unusual.

While CMake is better than anything I've seen, I still find it awful given it doesn't let you move your project to another folder...

I fear that you must be doing something very wrong... Or you did not find the rights word to explain your issue (to me).

Do you mean that you, then, have to rebuild your project from scratch?

I agree that CMake is better than handwriting a Makefile, it is still absolutely shit compared to Rust's build system or the straightforwardness of sourcing external dependencies with Maven or Gradle in Java.

If I want to use an external library in a C++ project, I need to:

* download it from the website / GitHub

* build it from source

* add the library into my CMake file.

Whereas in Gradle, I add a single line to one file and the library is installed on my next build attempt. Full stop. There are no more steps.

C++ makes it searingly painful to get a project going. I'm honestly afraid to add any new libraries to my projects because I know that (at minimum) that means I'm sacrificing an afternoon to resolving new errors.

Although I generally agree with you (CMake is a pain), I wouldn't say that this problem is caused by the language itself.

That you have to compile anything yourself is a byproduct of the fact that different platforms have different ABIs, combined with the lack of proper package management on platforms like Windows.

What I find the most enervating about CMake is that somehow everyone agreed (at least to some degree) to use the worst cross-platform build tool in existence. Instead of a build system based on solid principles we got a "hack your own build" starter kit in which you have to look for dependencies yourself ^1 combined with a build script language that is worse than the languages it set out to replace. How can anyone honestly be happy when switching from makefiles to this monstrosity?

^1 And no, the FindX scripts never work properly everywhere.

Personally, I agree about CMake and its horrible scripting language, and I like Scons a lot more. It's Python-based so it's easy to work with and flexible, and not nearly as ugly as CMake.

I think CMake took off, because it has no dependencies, works with any IDE and can be extended to do anything.

I have been in places where demanding python just wouldn't work. Either a specific version was needed for something else and managing the dependencies was a pain or we were already reliant on other scripting languages. I think this kills any other language as a build tool.

There are zealots for every IDE and some IDEs require special project files. If your build system doesn't seamlessly integrate most then it couldn't have made it. Scons never worked with IDEs I liked, Know how to get it cowkring with QtCreator? Other will demand vs2015r3 integration, how do you do that?

Then then there are the build systems you didn't mention, but the minimalistic ones. There was even one that was entirely stateless, but it was also too inflexible for most real builds.

CMake very carefully walked a thin line that dodged all these issues and the fact it is a giant pile of global mutable shared state simply doesn't for all but the largest builds.

>I agree that CMake is better than handwriting a Makefile

Really? I feel the opposite. At least when I write makefiles by hand I understand them fully.

Cmake just confuses me, I'm not sure it's such and improvement.

I have tried to look at CMake a couple time and always found it very...inflexible? Currently I have a hand-written Makefile which:

- automatically collects executables to build from the .cpp files in two distinct directories

- uses the CPP preprocessor to only link in the object files in the rest of the project associated to headers used directly or indirectly by the executable .cpp files

- allows me to select the compiler using an environment variable

- allows me to pre-define some common options for the three supported compilers (e.g. to disable specific warnings with ICPC and increase the template instantiation depth for Clang)

- allows me to specify whether I want to rebuild everything or just a single executable and whether this should be copied into the external directory contained in my $PATH

Yes, putting this together was a bit of work (208 lines for the Makefile, 34 for the dependency generator and 15 for the script which puts the current output of `git diff` into a CPP #define), but now it only rebuilds the things needed, only links in the object files needed and allows me to quickly test multiple compilers. Getting all this with CMake seemed extremely difficult when I last looked at it.

Addendum: I should add that my only external dependency is Boost and LAPACK and I essentially ask the user to point me at their Boost base directory and plug in their LAPACK link line -- this works well for the target audience (fellow physicists who are used to all sorts of horrible toolkit installation processes), but I understand it may be annoying to the more general public (or if you have more external dependencies).

Unified call syntax would have allowed something like a function of the form f( list, condition ); to be called as list.f( condition ). I don't think it made it into C++ 17 though. It's too bad because that would have allowed some really powerful extending of existing code. C# has this already. I hope that it makes it into C++20 https://isocpp.org/blog/2016/02/a-bit-of-background-for-the-...

Also, you can do stuff like auto blah = with( list ) << sort( ) << filter( predicate ); now. It's not in the std lib but it is doable

C# doesn't have unified call syntax, it has extension methods. You're right in that they do allow you to write a function that takes an argument and call it as if it wasn't on that argument, but it doesn't have UCS generically, just as a special case.

You are technically correct, the best kind. The ability is similar though, although I can see some fun C++ code with templates to apply it to all types. Then, if allowed, something like int i; i.print( ); could happen.

Although I agree that it would seem natural to have such a method in a standard container class, I would like to make a couple of observations.

First, there are containers that do have a find() method, std::map, for example (although not on a condition). It could be a wrong impression, but to me this tells something. Perhaps, if I intend to do a search, I might be better off using a different structure (rather than a list) that is more suitable for searching, or maybe a different - more efficient - algorithm (such as binary_search(), if applicable).

Second, if you use a container as a part of your own class, defining a find() method is trivial.

I have no doubt that there are other, more technical reasons for the standard library being the way it is, for example, the idea of separation of algorithms from containers by means of iterators.

The reason is that `std::find` is O(N) while `std::map::find` is O(1).

It doesn't affect your point, but std::map::find is O(log n). std::map is ordered and is typically a tree.

Yes, except the canonical map is—surprising the users of other collection frameworks—an ordered, balanced tree. So std::map::find() is O(ln n) while std::unordered_map::find() is O(1).

Find probably wasn't the best example but even with find, I sometimes want to look for an item in a vector with 20 elements. In cases like that, I'm fine if find() has to apply a comperator to every element until it finds the first that matches.

And functions like map (apply function to each element of a collection), filter (return new collection with all elements that match a condition) and possibly some others have to be applied to all elements in a collection anyway.

> Second, if you use a container as a part of your own class, defining a find() method is trivial.

It is, but I'd rather not have to define 20 trivial things when I start a new project.

This might interest you then http://www.modernescpp.com/index.php/the-new-ranges-library

That's good news, thanks.

Yeah I'm pretty excited about it. Though I'm curious, and maybe someone more experienced can help me out, how it will change performance. Because won't this be a little slower?

> * Setting up a proper build system is tedious, especially if you're targeting multiple platforms.

There is a tool called waf (https://github.com/waf-project/waf) which is getting way too little love, but is really the perfect build system for C and C++ projects:

    from glob import glob
    def options(ctx):
        ctx.load('compiler_cxx')
    def configure(ctx):
        ctx.load('compiler_cxx')
    def build(ctx):
        ctx.program(source = glob('src/*.cpp'), target = 'your-program')

That build script will work with all major compilers (Visual Studio, gcc, clang, mingw) out of the box.

I do use CMake as my build system, It is like torture ! literally, I always liked waf, I am curious why not many people use it ? it is incredible, I have very high hopes for waf and Meson.

The built-in rules are nice but have you tried doing anything fancy with waf? I wanted to define a rule that would transform an input file into a output file using a tool that was built from source at build-time, then use that output file as a dependency for a unit test. After spending a full week mucking around with waf, I gave up.

CMake was much easier for me to understand. Sure, the language is hot garbage, but the mental model of how it functions is simpler. I did something similar to the above and it took an afternoon of learning.

I do use CMake as my build system, It is like torture !

I don't want to diminish your experience, but I think you might be doing something wrong there. It doesn't need to be torture.

I'm having the same problem with CMake. Adding a third party library was an intense challenge. CMake isn't easy.

Now that you've done it, how long will it take you to add a third-party library next time?

As a user who primarily uses SCons, I feel like my opinion of Waf is reasonably fair.

1. Developers trying to use Waf never realized that they were supposed to check-in the python BLOB into the repository rather than using a system package. Consequently developers would find a lot of regressions in the syntax for builds.

2. Developers had to add the root of the project to their ${PATH} for it to work properly. This may not seem like much... but if you don't know better, it takes people by surprise.

3. Build scripts simply broke between Waf versions too often. Perhaps you can blame this on package mantainers... or maybe distribution maintainers.

4. There was never an overwhelmingly compelling case for `waf configure`. `cmake CMakeLists.txt` borrowed syntax from the C preprocessor which people were comfortable with. `autotools` had thousands of recipes for `./configure`. And adding configuration options to `scons` via command line options always worked just fine.

5. Using the Python language encouraged developers to implement actions which were not idempotent resulting in changes which were not properly tracked by Waf.

6. The code provided no obvious benefits to SCons aside from a little speed, and it was light years slower than CMake, autotools, or simple GMake.

1 & 3. You are supposed to ship the waf script with the code. It's 100kb so it's not a huge burden to check it into your repo. I'm very sure it is explained in the waf book: https://waf.io/book/

2. Either run "chmod +x waf ./waf build" or "python waf build" Adding directories to $PATH isn't necessary.

4. I think the use case for configuring and building with the same tool is very compelling. Like:

    def configure(ctx):
        ctx.check_cfg(package='gtk+-2.0',
                      args='--cflags --libs',
                      uselib_store = 'GTK-2.0')
    def build(ctx):
        ctx.program(source = 'blah.c', 
                    target = 'blah', 
                    use = 'GTK-2.0')

This will add a configure check using pkg-config ensuring that gtk+ is installed. Then due to the use declaration in the call to the program() method, the correct compile and link flags will be added.

Because it is all in one tool, it is very easy. Other build systems complicates it by keeping configure and build separate.

5. True, but I prefer more power over less.

6. Tomas Nagy published some benchmarks here: http://www.freehackers.org/~tnagy/bench.txt Waf was 12 times faster than SCons and about 20% slower than make.

If you are willing to try CMake (which I know has sparse documentation), browse this repository:

https://github.com/Akagi201/learning-cmake

It's not perfect, but teapot tries to address the first two points (cumbersome to make a new project and cross-platform builds). http://teapot.nz

Microsoft has open-sourced their LINQ C++ implementation [1] which allows you to do things like this (from their repo) :

    random_device rd;   // non-deterministic generator
    mt19937 gen(rd());
    uniform_int_distribution<> dist(4, 18);

    // for testing purposes, produce byte stream that from lines of text
    auto bytes = range(0, 10) |
        flat_map([&](int i){
            auto body = from((uint8_t)('A' + i)) |
                repeat(dist(gen)) |
                as_dynamic();
            auto delim = from((uint8_t)'\r');
            return from(body, delim) | concat();
        }) |
        window(17) |
        flat_map([](observable<uint8_t> w){
            return w |
                reduce(
                    vector<uint8_t>(),
                    [](vector<uint8_t> v, uint8_t b){
                        v.push_back(b);
                        return v;
                    }) |
                as_dynamic();
        }) |
        tap([](vector<uint8_t>& v){
            // print input packet of bytes
            copy(v.begin(), v.end(), ostream_iterator<long>(cout, " "));
            cout << endl;
        });

    //
    // recover lines of text from byte stream
    //

    auto removespaces = [](string s){
        s.erase(remove_if(s.begin(), s.end(), ::isspace), s.end());
        return s;
    };

    // create strings split on \r
    auto strings = bytes |
        concat_map([](vector<uint8_t> v){
            string s(v.begin(), v.end());
            regex delim(R"/(\r)/");
            cregex_token_iterator cursor(&s[0], &s[0] + s.size(), delim, {-1, 0});
            cregex_token_iterator end;
            vector<string> splits(cursor, end);
            return iterate(move(splits));
        }) |
        filter([](const string& s){
            return !s.empty();
        }) |
        publish() |
        ref_count();

    // filter to last string in each line
    auto closes = strings |
        filter(
            [](const string& s){
                return s.back() == '\r';
            }) |
        Rx::map([](const string&){return 0;});

    // group strings by line
    auto linewindows = strings |
        window_toggle(closes | start_with(0), [=](int){return closes;});

    // reduce the strings for a line into one string
    auto lines = linewindows |
        flat_map([&](observable<string> w) {
            return w | start_with<string>("") | sum() | Rx::map(removespaces);
        });

    // print result
    lines |
        subscribe<string>(println(cout));

[1] https://github.com/Reactive-Extensions/RxCpp

Reply on news.ycombinator.com