agree - what's more, the author is really talking about blaze, where everything "just works" because there are massive dedicated resources maintaining it. He literally admits that he likes the copy-pasta-no-think-about-it:

> Surprisingly, I didn’t need to fiddle with blaze, nor did I have to understand how it worked. I could copy some build targets and edit the dependency list, and the build worked as expected.

Sure, systems that just work are great, until they break.

bazel on the other hand, not so much. Heaven help you if it doesn't support your use-cases - you will wish you had Google to maintain your build.

yes - I use coc + clangd and there is no comparison with cscope. The level of accuracy you get with clangd is significantly better than tags/cscope. The main thing you need to make clangd work properly is an accurate compile DB. Yes, you can general/coarse compile settings, but the accuracy drops off for a project of any size. I also suggesting staying reasonably up-to date with clangd releases since they are adding important features/fixes with each release.

it's also generally preferred because it can avoid certain narrowing conversions in construction: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines...

as to how clangd sees your current translation unit, it comes down to the compile_commands.json (which is per-TU settings) or the more general compile settings in the config file(s) (https://clangd.llvm.org/config.html). If you need to change your TU settings, you could have a simple scheme that symlinks compile_commands to different files depending on build type and then restart the server. I've not typically needed to do this (I tend to just stick with a debug build compile DB...), but it's something you could do pretty easily.

There is one clangd process per editor process. If you have multiple projects with distinct compile_commands you might be able to come-up with a scheme to switch between DBs and relaunch clangd. Alternatively, you could try merge all compile_commands together, but I'm not sure the effort would be worth it -- just running separate vims seems like it makes the most sense to me.

For switching between branches, you can typically regenerate the compile commands DB pretty easily (if you use cmake...), but it's really only necessary if there are big differences in files and/or compile settings between branches.

..yes - in particular, boost::asio which will provide a sensible transition to std::net (networking TS) when it's available.

I think visit is what you want (http://en.cppreference.com/w/cpp/utility/variant/visit), unless I misunderstand what you mean by "pattern match"

I used to keep pretty good track of what's been happening in c++, at least as C++11 was being formalized, and I've read a good fraction of Effective Modern C++, but...

I can't make heads or tails out of half of the code in that example. C++ has become extremely hard to grok.

I mean, take these two lines:

    template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
    template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;

What's even going on there? Inheriting from a variadic list of classes? `using` a variadic list of parent functions, I guess? The second line looks like it's defining a constructor function for the overloaded() struct, but it's not implemented anywhere?

In the end there's magic code that looks like pattern matching, but I have no idea how they got there.

> What's even going on there?

The first line defines 'struct overloaded' derived from all of its template parameters. Template parameters are supposed to be functors (lambdas), so we use their operator()'s in 'overloaded'.

The second line defines a template deduction guide for the 'overloaded' constructor, which says: take types from the constructor arguments and use them as the class template parameters.

The idea is to be able to construct 'overloaded' like this:

    overloaded{[](ArgT1 arg){/*lambda1*/},
               [](ArgT2 arg){/*lambda2*/}, ...};

The key here is that a parameter pack T... can be actually unpack into expressions, for example:

    template<class ...Args>
        void g(Args... args) {
            f(const_cast<const Args*>(&args)...); 
     // const_cast<const Args*>(&args) is the pattern, it expands two packs
     // (Args and args) simultaneously
     
            f(h(args...) + args...); // Nested pack expansion:
       // inner pack expansion is "args...", it is expanded first
       // outer pack expansion is h(E1, E2, E3) + args..., it is expanded
       // second (as h(E1,E2,E3) + E1, h(E1,E2,E3) + E2, h(E1,E2,E3) + E3)
    }

Taken from: http://en.cppreference.com/w/cpp/language/parameter_pack

So for

    template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; }

if you used this like

    overloaded<X, Y, Z> foo;

it would expand to

    struct overloaded : X, Y, Z {
        using X::operator(), Y::operator(), Z::operator();
    } foo;

EDIT: Removed stuff about the function since I was only guessing and Alexeiz answered it. The only thing I’ll add is that you can construct structs like this:

    struct Foo { int x; float y; };
    Foo foo {1, 2.3};

overloaded is constructed from the three lambdas in the same way. I guess the deduction guide is needed because the compiler cannot deduce the template parameters from that initializer form, so the deduction guide tells it to use the types of the lambdas for the types of the template parameters.

More information on deduction guides: http://en.cppreference.com/w/cpp/language/class_template_arg... (specifically, look for “Class template argument deduction of aggregates typically requires deduction guide” in the notes section for an example very like the overloaded one)

> Successful remote workers are disciplined and self-motivated. No boss is eyeing them from across the office to see whether they’re working. They alone are responsible for structuring their workdays.

This sounds like precisely the kind of person I want to work with, regardless of whether they are remote or co-located.

> I say let people work from home but make sure they have the option of an office.

...or provide a stipend to be used to help pay for local co-working spaces, if that's your preference. I can certainly understand how some people might need alternatives to the monotony of WFH, but making everyone commute to some crowded business district/downtown is whole other set of nuisances and inefficiencies.

I studied to be an S.E. for 7 years (undergrad/grad) and practiced for a little over a year before I gave it up for software. First, the pay was atrociously bad given they years of schooling. Seriously, I couldn't justify doing it if I didn't absolutely love it because I was barely getting by.

Furthermore, S.E. in practice is pretty boring -- lots of repetitive calculations. Yes, there is room for software automation, but that kind of automation is never rewarded - so much of the tasks just seemed to be coordination and paper shuffling. Beyond that, working on projects often meant waiting years to see anything come of it - think about how long it takes to get a large project from concept (design) to completion. In most markets it's a very long timeline.

That said, if I were to have stayed in S.E. I would have focused on smaller projects (with shorter timelines) and I would have tried to specialize in field engineering (being on-site) since that's where most of the real problem solving happens.

Luthiery specifically for me - it's a hobby currently and the thing I think about the most when I'm programming. The tooling and jig making aspect of woodworking is also very satisfying to my engineering tendencies.

I have to plug David Hurds "Left-brain lutherie" here! It's a physicist's attempt to demystify the building of guitar-family instruments, and in addition to providing a pretty in-depth look at the major components of an instrument's sound, provides many immediately practical tips on construction - for example, how to choose the proper soundhole size.