QtCreator is brilliant, I just wish the Qt company would stop trying to hide it away! It's getting harder and harder to find the download link on their website.
You can drill down in Diskitude by right clicking. I agree it's not as nice as Daisy Disk, but it's the best I've found for Windows (for my tastes) and you can't beat the price...
Gosh there are a lot of these programs, aren't there?
For some reason I find it really hard to read these tree map visualisations. I know the theory and all that, but for me they just aren't an intuitive way of displaying that kind of information. For me a radial graph (i.e. pie chart like) is much easier to grok - I don't even have to think about it, I just get it. Seems like there must be plenty of people who don't think the same way though, given how many different tree map disk viewers there are out there!
Interesting! What would you say makes it better than the others? I'm working on something similar but as-yet-unannounced and I'd love to know if we're tackling the right problems...
Maybe the effort just isn't where you're looking? Intel provides the Threading Building Blocks library for C++; some top notch debugging & profiling tools with multi-threading support; very good documentation; and they do quite a bit of community outreach to educate about and promote multi-threaded programming. (I'm not affiliated with them, just grateful for all of that stuff!)
SIMD = Single Instruction Multiple Data, meaning the same instruction being applied to multiple different values simultaneously. That's exactly what GPUs do.
The important difference is that not everything in Unreal is GC'd, only UObjects. Internally the rendering, animation, networking and other high-performance subsystems don't use GC because they can't afford the overhead. Being able to opt in to GC where it's useful is great, being forced to use it everywhere can be a hassle.
I really wish the Qt Company would stop bundling QtCreator as a required component of the Qt SDK.
I use QtCreator as my main IDE & think it's great, so of course I install new versions as soon as they become available. I compile & test against several different versions of Qt though and every single one of them lumbers me with an additional out-of-date copy of my IDE. This bugs me - more than it probably should.
> I have long wanted to see programmers experiment with taking this IDE thing much further. Almost every other authoring tool has an opaque file format, manipulated via one or more views. E.g. when a digital artist wants to create and manage a complex 3D scene, they use a tool like Maya. They're not fussed about whether they can read the file format!
Interesting choice of example, because over the last few years open formats like Pixar's USD (https://graphics.pixar.com/usd/docs/index.html) have been emerging for managing complex 3D scenes - precisely because of problems with opaque file formats.
That said, we're now seeing more and more things like Unreal Engine's Blueprints, Apple's "Swift Playgrounds" and so on. I think your wish is slowly coming true.
It's so the scanner operators can tell there's nothing hidden underneath your laptop. I'm not sure whether the laptop case (or just the battery?) can actually block the scanners, or it just makes the output image harder to interpret. Either way, I guess they want to be sure...
I think that was true back when he wrote the words, but less so now. Even if you're not noticing a delay, code that completes quicker is generally code that uses less power and you can still notice the effect on your phones battery life - or on the size of your monthly bill from your data center.
All of you complaining about this proposal not being based on Vulkan seem to be overlooking the fact that Vulkan is actually quite cumbersome to use. Metal, on the other hand, is a really well designed API and in my opinion strikes just the right balance between performance and usability. If it was available for non-Mac platforms too, it would be my first choice of graphics API every time. So for me, a cross platform web graphics API based on Metal is really quite an exciting prospect - much more so than one based on Vulkan - and I applaud Apple for proposing it.
I've recently had to deal with some code that did this for work (and also used operator* for dot product) and it made the equations incredibly difficult to read. Please don't make the mistake of doing this in your own code.
The term you're looking for here is a depth matte. It's a technique that's been in use for many years now, but of course it's only as reliable as your depth data so it's just one of the many tools in a compositor's tool belt.
Doesn't it bother you that you can provide the same value to your employer as someone in Brisbane, but only get paid a fraction as much for it merely because you're in Sri Lanka?
I'm a remote worker too (and I'm very happy with the way my current employer handles it). As long as I'm available at the times and places my employer needs me to be, why should they have any say in where I live or how I spend my money? I want to be able to manage my quality of life myself, not have it decided for me by someone else!
I like that you guys are being open about this, but the way you calculate compensation leaves a pretty bad taste in my mouth. I very much dislike the idea that you, as an employer, are deciding what proportion of their income your employees should be spending on rent. You're also effectively saying that work done by someone who lives in a cheaper location is less valuable to the company than the same work done by someone who lives in a more expensive location. Maybe all employers do this and the only difference is that you guys are being honest about it, but still... yuck.
> It's hard to refute directly because there isn't any motivation or reasoning presented, only prescriptions (the author cites their "experience" in comments), so the best I can do is point out that most of it is really bad advice.
If you want to refute it, why not say what you think is wrong with each of the prescriptions instead of just saying "most of it is bad"?
Personally I agree with most of the prescriptions but there's one I disagree with completely and another that I'd add a caveat to.
The one I disagree with is using c headers instead of their c++ wrappers. Some of the c++ wrappers do actually add value (e.g. cmath adding templated versions of abs, etc) and it's easier for me to remember a single consistent rule ("use the c++ wrappers, always") rather than a list of which ones to use the c++ wrapper for and which to use the c header for.
The one I'd add a caveat to is the one about not using anything from the STL that allocates: I think that's good advice under some circumstances, but not all. The STL containers are really useful for getting something up and running quickly, so I think it's fine to use them in that case and only switch to custom containers once allocation shows up as a hot spot in your profiling.
As a caveat to the caveat, I would add that STL classes should only ever be used as an internal implementation detail, never exposed as part of an API. This is because the implementation of the STL classes can change, causing binary incompatibility. For example, Microsoft changed their implementation of std::string between Visual Studio 2008 and 2010 (if I remember correctly; and possibly again since?); if you have a library compiled against the older std::string you can't use that in a project being compiled against the newer std::string and vice versa - unless you have the source for the library and can recompile it. Using your own classes protects you from that because it puts you in control of when the ABI changes.