I don't understand the hate for merging up. I've worked with the 'cherry-pick into release branches' model, and also with an automated merge-upwards model, and I found the automerge to be WAY easier to deal with. If you make sure your automerge is integrated into your build system, so a failing automerge is a red build that sends emails to the responsible engineers, I found that doing it this way removed a ton of the work that was necessary for cherry-picking. I can understand not liking the slightly-messier history you get, but IMO it was vastly better. Do you have other problems with it, or just 'unreadable' histories and work happening on release branches? Seems like a good trade to me.
I mean... for what it's worth, I'd never seen it before, I would never have seen it without the manual intervention, and I loved it and think it's perfect for HN. I don't think we really need a 'fundamental fix' for anything, seems to be Working As Intended (tm) ;)
Seconded this, this is my setup on both Windows and Linux and works for me across multi-million-line C and C++ codebases. It's quite finicky to get set up on Windows at first (or at least, it was for me last time I tried), but once you have irony-mode working with libclang, you don't need to think about it ever again, except for changing a couple compiler flags here and there.
My one complaint is that clang's MSVC mode is imperfect, and sometimes suggests some strange things (or produces some false negative/positive in syntax checking). But they've been getting much better lately and it's never caused me much pain.
e: also, second what a sibling said - combo this with flycheck-mode and you have yourself a full-blown C++ IDE in emacs ;)
Yep, I'm a huge fan of this for this reason. I've spent a lot of time in my life messing around with cmake, scons, custom bash scripts... you name it, trying to get around C++'s shitty dependency management. And then recently I picked up Ruby, for the first time in a year or two, to write a little chat bot... 'gem install' is flawless across my Windows desktop and my Linux laptop, easy to depend on a specific version, easy to upgrade, etc. Tbh I'm pretty jealous.
e: does anyone know if this has any relation to Boost's b2? I know that was originally based off of jam which is not related but the name is so similar I can't help but think I'm missing something :(
Sure - I didn't really mean to imply that starting at main() every time was the way to go about things. I guess my point is just that I find it's usually a lot more useful to methodically explore than it is to sit and hypothesize. I dunno, I suppose (like a sibling suggested) it's pretty much the same thing, but I feel like I usually prefer to bust out the debugger as soon as I have any inkling of where the problem could be, rather than spending lots of time beforehand thinking about it.
This is a surprisingly accurate description of the general sort of debugging technique I've gotten better at as I get better at programming. I find that logically it tends to make more sense to me to start with a high-level function, and step over its component function calls/loops one by one, inspecting the program state and diving into any that seem to be producing strange results. But overall, I definitely just find it's a lot more effective to start from a broad 'does everything look okay at this point?' than from a narrow 'I think the problem is this'.
Because `i` isn't an int, it's an initializer_list, and you almost never want to actually create an initializer_list instead of an int? Seems pretty understandable to me.
This was what I was going to say but I figured it was a pretty common sentiment :) The thing that really gave me confidence was finding someone who was willing to take me on and mentor me when I was figuring things out, it makes a massive difference really quickly.
I'm not 100% certain of all the details but isn't that exactly what Google tried, and failed, to assert originally? If I remember correctly, the 'fair use' argument only came up after Google lost on the 'can't copyright an interface' argument, and the real travesty here is not that Google are being denied fair use (because, you're right, it's not fair use), but that Oracle's copyright claim over the Java API ever held up at all.
It's the nature of the chords you're able to play - you're given the 1-7 chords of a specific mode (the most common ones are the major and minor modes, the notes of those modes make the major and minor scales of a key - but there are several more in this thing which is pretty cool). So basically the only chords you can combine are ones that are in the same key, and they'll pretty much all sound good, just with a different kind of feeling.
While I think that's true, it's also orthogonal to the 'belt' concept [1] they're using, which I think GP was referring to.
I'm also curious about the state of the Mill - judging by the forums on their website they've been basically dark for about a year and a half now, though Ivan Godard claims that everything is still moving along, just slightly slower than expected.
True, but I still think it can be done better, and the time will only get more ripe for it as more longtime players quit (source: all my friends quit Dota and we've been playing since beta or soon after).
I disagree at least on one point - I've also played Dota a fair bit in the last few years, and as for Dota, I think parent might be pretty on the money when they say games are moving away from traditional MOBAs. The format is great, but in its 'traditional' form (three lanes, jungle, etc), there's only so much you can do with it. I think the market is pretty ripe for innovation on that format, and Dota won't be able to keep up when it happens.
I also agree with parent in that 'Blizzard just blew the doors off the market by revitalizing a game format that Valve invented' - I honestly think it's hard to argue that point. Overwatch is conceptually very, very similar to TF2, and must be doing some damage to its playerbase (though I haven't checked any stats on that at all so I might just be talking shit).
So obviously YMMV, but I was born in '92 and my roommate and I listened through basically this whole thing last night - and we both agree with you, the '80s was where it was at.
Maybe a bit off-topic, but I just want to clarify - lambdas only include dynamic allocation if you convert them to an std::function, right? I was under the impression that 'auto f = []{...}' did no heap allocation, but converting to an std::function could, depending on the size of the closure.
Well that's interesting - the only difference between you and I was YouTube, and I'm a married man over 32 making 52,000+. (I have YouTube because Google installed it by default on my phone but I disabled it so I didn't count - also, I'm a 23-year old male who makes a lot less than 52,000/year :D )
Ohh, are 'dead' comments different from ones that have just been downvoted into mostly-grayness? In that case I don't actually see them, I just see undead comments :) thanks for clarifying