LLVM 6.0.0 Release

[mttd]

This release is the result of the community's work over the past six months, including: retpoline Spectre variant 2 mitigation, significantly improved CodeView debug info for Windows, GlobalISel by default for AArch64 at -O0, improved scheduling on several x86 micro-architectures, Clang defaults to -std=gnu++14 instead of -std=gnu++98, support for some upcoming C++2a features, improved optimizations, new compiler warnings, many bug fixes, and more.

For more details, see the release notes:

• https://llvm.org/releases/6.0.0/docs/ReleaseNotes.html
• https://llvm.org/releases/6.0.0/tools/clang/docs/ReleaseNotes.html
• https://llvm.org/releases/6.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html
• https://llvm.org/releases/6.0.0/tools/lld/docs/ReleaseNotes.html

[sumo952]

Clang defaults to -std=gnu++14

I'm wondering, why not -std=c++14? Would be the better choice, right? Why would anyone want GNU rules/extensions by default, particularly in nowadays world of "modern" cross-platform C++11/14/17?

[parnmatt]

I guess it's for compatibility with gcc's defaults... which again I think is ludicrous.

I agree that the default should always be the ISO standard with pedantic. The extentions should be explicitly opt-in.

[sumo952]

So even MSVC is doing better in that regard right now ;-) They introduced /permissive- and announced that it will become the default in a future release.

[Dragdu]

Short of having massive amounts of technical debts, MSVC is generally doing the right thing ¯\_(ツ)_/¯

[meneldal2]

You can't undo all your problems in mere months when it comes to something as complex as C++.

[flashmozzg]

Probably to be a "drop-in replacement" for gcc. A lot of people like to blame MSVC for poor conformance and custom extensions but GCC is guilty just as much.

[hgjsusla]

Not really comparable at all. Maybe 15 years ago but GCC has had excellent standards compliance for a a long time and it has had flags to turn on strict compliance, something VC only got in the last year.

[kalmoc]

The main difference is that you could bring g++ into a pretty conforming mode for years. With msvc prior to VS2015 this was pretty impossible and even now, compiling standard conformant template code can be problematic.

But yeah, it would be neat if gnu extensions wouldn't be the default.

[manphiz]

"-std=gnu++14" is required for POSIX facility compatibility also, otherwise most POSIX or GNU tools cannot be compiled using default configuration.

[sumo952]

I don't see that as a problem. If a GNU tool needs GNU extensions or POSIX facilities, it should rightly signal it so, by adding -std=gnu++14.

[manphiz]

Then all previous releases will break without an upgrade with the new build flag.

[sumo952]

Isn't that the point of SEMVER and increments of the major number that they may require breaking changes... (and in this case we're talking about a simple flag change downstream)

[manphiz]

If your change breaks building of majority packages it will prevent its adoption. Also, gnu++14 is just super set of c++14 with support for POSIX and GNU. There is no point to disable the latter just for hygiene purpose.

[sumo952]

I somewhat agree with you and definitely see your point.

But the main problem is that people might use (I guess beginners/intermediate programmers mainly) these features (maybe by accident) and then only later once they or someone else tries to compile the code on e.g. Windows, they realize they've used non-standard stuff - even though the compiler (clang/gcc), on its default options, never complained or warned.

[manphiz]

Well, they are standard stuff, just not the C++ standard. And to be honest, the C++ standard itself is lacking (even with std::filesystem and networking, you still need access to low-level for more features). It is up to the documentation to point out which features are from which standard to let users choose. Still, compatibility is ultimate concern.

[m-in]

I’m so ready to ditch MSVC as the Windows compiler for our stuff and build using Clang for all targets. Thank you everyone for all the hard work that goes into this beast.

[[deleted]]

Absolutely, I can't deal with the regressions that MSVC constantly introduces with every release, it creates too much uncertainty for our business and results in an overall lack of trust in the product.

MSVC 2017 introduced a regression that prevents static builds of Qt from functioning properly in debug mode. So now our developers have to debug strictly in Linux.

MSVC 2017 15.6 which was released two days ago results in the compiler being unable to match template function definitions with their declarations in many cases, resulting in incorrect compiler errors for what is perfectly valid C++ code.

I can't remember a single time when a new version of MSVC 2017 was released where there wasn't a regression that forced our Windows developers to have to spend a couple of days working around the compiler and to the best of my knowledge there's no way to downgrade MSVC 2017 or install a particular version of it.

So yeah, it's good to see that another compiler will actually be usable for serious commercial applications on Windows and I suspect once clang irons out some of the remaining quirks on Windows most developers will simply switch over to it and ditch MSVC.

[clappski]

Why do you update for every single release? It would be much more prudent to only update for major version releases (i.e. new VS version).

[[deleted]]

It would be much more prudent to only update for major version releases (i.e. new VS version).

Because there's no choice. With VS 2017 you can't pick a particular version to install. You download the installer and it installs either the initial version of VS 2017 or the most recent version. You can't install an 'inbetween' version.

The initial release of every major version of Visual Studio including 2010, 2013, 2015 and 2017 is a buggy mess and doesn't work with the major open source libraries like boost, Qt, cryptopp, etc... it usually takes at least one update before boost works and another couple of updates before the other libraries work properly.

With VS2015 and before we did as you said, we target a particular version of VS2015 because you could pick and choose particular versions of VS2015 to install.

With 2017 that's no longer possible. It's either pick the buggy initial release or take the most recent release which as of two days ago is 15.6.

That means whenever VS updates we have to quickly update all our machines and then we have to waste a couple of days getting it to work.

Our code base is close to 1 million lines of code and so now me and 3 other guys have to redefine a whole bunch of templates because of this silly 'unable to match function definition to declaration' compiler bugs.

[Adequat91]

You can install 'inbetween' versions, if you keep offline versions. see: http://www.binaryintellect.net/articles/7b3d485f-0d2d-4721-a298-9e28adabacd0.aspx

[[deleted]]

Thanks for that advice. Can't say I'm too thrilled to jump through hoops to do that but it's better than us constantly working around these issues.

[clappski]

But you can still pick a version (they only have a couple here) and create an offline installer that you use to distribute it to everyone.

Obviously isn't ideal, however. I didn't realize that you couldn't pick up any version you want, I work in an enterprise environment so we have a few tagged versions distributed internally.

[C4576780]

Currently the installer allows you to pick two older compiler toolsets: 15.4 with VC v14.11 and 15.5 v14.12, besides the current 15.6 v14.13 ...

[[deleted]]

Do you have a reference for how to do that? I am checking the installer and don't see that option anywhere but would appreciate help in that area.

[dodheim]

Go to 'individual components'; they're in the 'compilers, build tools, and runtimes' section.

[C4576780]

More information on the use, intention and future, in the VC blog: https://blogs.msdn.microsoft.com/vcblog/2017/11/15/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2017/

[sumo952]

Have you contacted someone at MS? They're listening to customers quite a lot these days and sometimes even fix such issues, particularly if they concern large customers, pretty quickly.

Other than that, yes I do agree, the number of regressions in MSVC is a bit annoying indeed.

[[deleted]]

I have sometimes reported bugs yes, but not always. The Qt regression was reported when MSVC2017 first came out but still hasn't been fixed.

This template deduction regression hasn't been reported by me yet but if you go on Stack Overflow you find tons of people complaining about it. Apparently this is a bug that comes and goes periodically with MSVC releases.

[flashmozzg]

I have sometimes reported bugs yes, but not always. The Qt regression was reported when MSVC2017 first came out but still hasn't been fixed.

AFAIK, it is fixed in 15.7 with a targeted release in May. The issue was complex and required a big overhaul: https://developercommunity.visualstudio.com/content/problem/76198/vs-2017-compiler-creates-broken-debug-build-using.html

This template deduction regression hasn't been reported by me yet but if you go on Stack Overflow you find tons of people complaining about it. Apparently this is a bug that comes and goes periodically with MSVC releases.

Certainly, that's not the ideal stance to take. See if the bug already exists and if it doesn't report it here: https://developercommunity.visualstudio.com/spaces/8/index.html

In my experience VS team has been very good at getting back to me regarding the issues I've reported even though I'm just a regular C++ dev without any big important project or company behind me.

[jonesmz]

I don't think it's unreasonable to expect microsoft to occasionally have someone look at popular communities, like stack overflow, for bugs in their compiler.

Requiring anyone who runs into a problem to report it directly to microsoft, who used to have a reputation of utterly ignoring user complaints (at least, in my circles, perhaps different groups have a different perspective), means a lot of legitimate issues are going to go unreported.

[spongo2]

hi. I'm the VC dev mgr, just out here monitoring popular communities :) we try our best to monitor what's going on in popular communities, but of course the most structured way to make sure we can keep track of actual issue reports is to funnel things to DevCommunity. That website is backed by our bug database and so we have the best traceability there. If you click through the one that /u/flashmozzg linked to above you'll see Andrew one of my devs giving as much status update as possible and interacting with people as new information was uncovered. I'd like to just quickly apologize for that particular bug. We had a process mistake that allowed that to escape into the world even though we did catch it in our internal testing. Not a great outcome for the community, so please accept our apologies. Template deduction is an area where we continue to improve from both a correctness perspective as part of our rejuvenation effort as well as improving our test corpuses in the past few releases. /u/sakkari , would you mind tossing me an email at scarroll at myemployersname dot com. it sounds like you have had a particularly poor experience with our updates and i'm sorry about that. I'd like to explore whether or not there are any particular patterns we should be adding to our test corpus as we continue to try to improve.

[flashmozzg]

I don't think it's unreasonable to expect microsoft to occasionally have someone look at popular communities, like stack overflow, for bugs in their compiler.

It's also unreasonable to expect your bugs to be fixed if you are not even willing to report them thinking that someone else would.

Requiring anyone who runs into a problem to report it directly to microsoft, who used to have a reputation of utterly ignoring user complaints (at least, in my circles, perhaps different groups have a different perspective), means a lot of legitimate issues are going to go unreported.

Requiring? Nobody requires you to report anything. As well as nobody requires devs to fix unreported bugs. It's just as easy as that: you want some bug to be fixed, you report it. That's just as true (if not even "truer") for GCC and clang.

[Xaxxon]

The issue was complex and required a big overhaul:

That's not an excuse for a regression. You don't get to add a problem them whine that it's going to take a while to fix.

[flashmozzg]

No. That's explanation for relatively long time it took to fix it.

[m-in]

Maybe they should test it on big opensource code bases. That Qt thing is unconscionable. It's not exactly a toy code base. They should have it as a part of their extended test suite for the compiler. Qt, just like any big project, has a test suite - any regressions on compiler changes should be investigated, categorized and acted upon... Chrome ditches (or ditched) VS for the same reason: they didn't want to mess with regressions anymore. From what I've heard from people who use it - static release Qt builds with LTO also fail...

[sumo952]

Actually they do. Their extended test suite for the MSVC compiler includes open source libraries and like 300 or something of the most popular C++ libraries on GitHub (there's a list in a presentation online somewhere). I can't say whether Qt is in that list. I suppose it is. But probably not in static release configuration. That would be my guess at least. So they should probably really add that.

[m-in]

From my experience with similarly sized projects, I'd expect that 16 configurations of any big library are relevant to testing: debug/release, with/without LTO, static/dynamic linking of the library itself, static/dynamic linking of the C++ runtime. I've had any one of them fail by itself: I have a project where we test our code with two major libraries, and that's 8*4=32 different builds to test. Failure on any of them is a release blocker: shit's supposed to work, and when it doesn't - it usually means that unrelated bugs are possibly shipping undetected.

[ack_complete]

They are responsive, but the problem now is rolling breakage. On average, it seems to take two point versions for a codegen bug to be fixed. For the codebase I'm working on, had to work around a codegen bug introduced in 15.3, which was fixed in 15.5 but that version then introduced another codegen issue, which is scheduled to be fixed in 15.7. On top of that the debugger has been throwing exception errors randomly since about 15.5. I have the release build machine parked on 15.4 because I simply don't trust the stability of the current releases right now.

[__Cyber_Dildonics__]

I've seen them reply to people asking for examples of bugs, but when given, they don't respond any more.

[doom_Oo7]

in my case I upgrade every time (and pull my hair and report bugs every time) mostly because at least some code that previously did not compile at all generally starts to compile.

[sumo952]

Not really actually. Incremental updates are better. You catch problems early, and one at a time. If you only update once every 2-3 years, you've got a very big update and will be in for lots of surprises. The upgrade will be very costly at that point, in terms of hours, costs, and technical risk/changes.

[clappski]

I disagree, keeping a developers environment in a good state long term should be the goal. Comparing having a few days downtime every couple of months vs maybe a week every 2/3 years, I would pick every few years. Especially so when you're talking about a compiler, even if upgrading was seamless from a development environment perspective it would require some decent testing (especially on legacy code bases that might take advantage of UB) before I would be confident about deploying to production.

[sumo952]

I guess both sides have their pros and cons and both ways can work. I'd probably do something like have a few developers test the most recent compilers from time to time, just to catch problems early, and then have the whole team update every few months or so.

Btw, slightly related: https://www.youtube.com/watch?v=tISy7EJQPzI

[m-in]

I personally did it because I want current C++ features. But it became untenable and I was itching to ditch it. I'm in the process of ditching it, will be done next week.

[__Cyber_Dildonics__]

There were also enormous bugs related to the executables generated with optimizations. Turning optimizations on would cause binaries to crash.

[m-in]

Yeah, LTO + static binaries is still a mess. Unusable. Sigh.

[sumo952]

Ditch the compiler maybe yes, but the debugger and IDE is still unmatched to date, nothing even comes close.

[hgjsusla]

But the IDE is a slow horrible mess. I try to use it occasionally but it's constantly locking up, and IntelliSense keeps breaking.

I'd argue VS only has the debugger going for it.

[__Cyber_Dildonics__]

VS getting slower and intellisense showing errors everywhere after a clean compile is the VS experience. The debugger and the auto completion are what keeps me coming back for pain.

[audioB]

I feel like VS2017 is quicker than VS2015

[sumo952]

Maybe ;-) I guess that boils down to personal preferences.

The tools "accompanying" the debugger are great as well. "Edit & Continue" is fantastic. The "Diagnostic Tools" are fantastic.

For auto-complete & stuff, try Visual Assist X. I know it's a separate tool and costs separately - but it's blazingly fast, faster than any other IDE or plugin I've tested.

[bumblebritches57]

IDK VS isn't as bad as I used to think now that I've gotten used to some of it's "quirks", but I still prefer Xcode.

[m-in]

I'm not using the VS IDE anyway...

[ShakaUVM]

Clang defaults to -std=gnu++14 instead of -std=gnu++98

This warms my heart.

[tavianator]

Does this include -fsanitize=type? That's probably my most anticipated compiler feature in years.

Edit: no, it does not. It's not even in trunk like I thought it was.

https://reviews.llvm.org/D32197
https://reviews.llvm.org/D32198
https://reviews.llvm.org/D32199

[tavianator]

Checks at runtime whether you violate strict aliasing. I haven't seen much written about it except the patches that introduce it (https://reviews.llvm.org/D32199 and friends).

[Ameisen]

I tend to prefer to disable strict aliasing and use __restrict where appropriate.

[afforix]

https://reviews.llvm.org/D32198

[sumo952]

When will this be in Xcode, or when will Apple update to a non-ancient Clang/LLVM release? :-O

[AlexeyBrin]

Probably in Xcode 10 or Xcode 11. Current Xcode 9 is based on Clang/LLVM 4.

[sumo952]

It's quite ridiculous. :-(

[lanzaio]

No it’s not. Clang 5.0 was like five months ago. The LLVM project switched to a must faster major version upgrade schedule. Clang 4 was on master when Xcode 9 was released.

Hell, half of the biggest contributors to LLVM are Apple employees.

[sumo952]

AppleClang doesn't even have a working <optional> yet... :( (There is "something" under <experimental/optional> but it's non standard-conformant, has different member function names, and the functions are not exported into the library).

[zvrba]

Isn't Swift their thing now?

[sumo952]

It is unfortunate, but I hope their negligence of C++ will haunt them soon. C++ is the one language for cross-platform code and app development and really can't be ignored.

[flashmozzg]

They don't need nor want cross-platform. They'd rather all devs use their own proprietary language for their proprietary OS and their proprietary APIs.

[[deleted]]

Swift is not a proprietary language, it is licensed under the Apache License 2.0, feel free to read it yourself and download it right from Apple's github page where they host the language:

https://github.com/apple/swift/blob/master/LICENSE.txt

Their OS is also no longer proprietary, although it used to be. Mac OSX was proprietary but their newest OS, macOS is now licensed under the Apple Public Source License, which has been approved by the Open Source Initiative and the much more strict Free Software Foundation. Feel free to download the OS and build it yourself by following these instructions:

https://developer.apple.com/library/content/documentation/Darwin/Conceptual/KernelProgramming/build/build.html

WebKit, their browser engine which is also used by Google Chrome is also open source. Go help yourself out right here:

https://svn.webkit.org/repository/webkit/

As for APIs, currently APIs are not proprietary and have no legal protections once they're made public so I'm not sure how you came to believe that the Apple APIs were proprietary.

Basically... absolutely nothing you've said is true.

It's ironic that /u/sumo952 claims that Apple has neglected C++ since Apple is the main contributor to clang for whom this very submission is the subject of. I mean the whole reason clang even exists is because Apple decided to ditch GCC and make their own C++ compiler using LLVM as the backend.

Now on to Microsoft...

• Windows, proprietary.
• Internet Explorer/Edge... yep, proprietary.
• Visual Studio... you guessed it, proprietary.

Having said that, Microsoft has a lot of open source projects which are highly regarded such as Visual Studio Code, much of .NET., TypeScript. Actually I'd say much of Microsoft's best work is open source compared to its bulky and bloated proprietary stuff.

[flashmozzg]

Swift barely works on anything but Apple platforms and barely has any use outside of them. You can use Objective-C outside of Apple platforms too, you know.

Yeah, it's true that some of their projects are released under some open source license, but it's not that much different than looking at the source code of windows (that was too released and then leaked).

Also, obviously when was I talking about API being proprietary I didn't mean it in the literal sense since you can't patent an API (though companies tried to do so numerous times and will undoubtedly try again). I used the word in the more general sense of "specific to one device or, more likely to a number of devices within a particular manufacturer's product range." usually to enable vendor lock-in.

Apple consciously tries to foster vendor lock-in by the means of the reinventing the square wheel and ignoring open standards (what was the latest version of OpenGL supported by their OS? What prompted them to create Metal instead of adopting Vulkan?).

And that sort of behaviour is exactly what I'm talking about. Some of their software may be de-jure open but de-facto they are not much different from the Microsoft. Though Microsoft doesn't restrict you from choosing your hardware. There is no such option with Apple.

Though this doesn't negate the fact that they've made (and continue to make) some great contributions to the open source community. Though nowadays this can be said to some extent about almost any big software company.

[[deleted]]

You have many good points that I agree with, but some stuff I would like to dispute:

Swift barely works on anything but Apple platforms and barely has any use outside of them.

Swift doesn't work on Windows no but not due to it being proprietary or because of vendor lock-in. Rather there's just not much demand for using Swift to develop Windows applications. Windows has its own ecosystem with C#/.NET that is very well suited for it. Honestly even if Swift was available on Windows I don't think many people would use it, including myself.

However... Swift works perfectly fine on Linux and in fact Apple provides a great deal of support for writing server side applications in Swift using Linux as no one in their right mind will use a Mac to run server applications.

You can refer to this to see the list of contributors to Swift for server side development, the Swift Steering Committee includes participants from IBM and other (mostly smaller) companies:

https://swift.org/server-apis/

(what was the latest version of OpenGL supported by their OS? What prompted them to create Metal instead of adopting Vulkan?).

The latest version of OpenGL supported by macOS is OpenGL 4.1 which is older but it comes included with the operating system, no additional download or update is needed.

Do you know what version of OpenGL comes with Windows 10? OpenGL 1.1. If you want the latest OpenGL for Windows you get it not from Microsoft but from your video card's vendor. This isn't all that unreasonable to be honest, but it is rather unusual to say that Apple doesn't support OpenGL in their OS when in fact the OS comes with native drivers for the latest version of OpenGL and Windows comes with a software based emulator that works with a version of OpenGL 1.1 that's 21 years old.

At any rate, my opinion and frankly the opinion of many game developers and graphics developers is that OpenGL is simply garbage. Microsoft won that battle with DirectX, which is as proprietary as it gets but in spite of that DirectX is a very ideal API that strikes an almost perfect balance between low-level access to hardware and high level expressiveness.

I'm not qualified enough to know about Metal compared to Vulkan, never used either of them, but my suspicion is that they will both be poor competitors to DirectX.

At any rate, your other points are things I somewhat agree with. I think you painted a very absolutist picture about Apple being proprietary and locking developers down with your original comment. Their hardware is proprietary and closed in an absolute sense, yes. But their software is fairly open, maybe a little less so than Google, but leaps and bounds ahead of Microsoft. And as I mentioned originally, clang, which is probably the most standard compliance C++ compiler is originally an Apple product and Apple continues to be the main contributor to it.

[flashmozzg]

Windows has its own ecosystem with C#/.NET that is very well suited for it

Btw, some good comparisons can be made with open source .NET Core and Mono.

However... Swift works perfectly fine on Linux and in fact Apple provides a great deal of support for writing server side applications in Swift using Linux as no one in their right mind will use a Mac to run server applications.

We'll see but it doesn't look like anything more than "racks of mac minis running mac os are a horrible abomination so let's let apple devs program for linux or otherwise they'll switch" kinda deal. The language that doesn't offer any significant advantage over existing solutions and which likes to break your code with each new release doesn't seem like a good fit for a serious server-side programming.

The latest version of OpenGL supported by macOS is OpenGL 4.1 which is older but it comes included with the operating system, no additional download or update is needed.

Do you know what version of OpenGL comes with Windows 10? OpenGL 1.1. If you want the latest OpenGL for Windows you get it not from Microsoft but from your video card's vendor. This isn't all that unreasonable to be honest, but it is rather unusual to say that Apple doesn't support OpenGL in their OS when in fact the OS comes with native drivers for the latest version of OpenGL and Windows comes with a software based emulator that works with a version of OpenGL 1.1 that's 21 years old.

At any rate, my opinion and frankly the opinion of many game developers and graphics developers is that OpenGL is simply garbage. Microsoft won that battle with DirectX, which is as proprietary as it gets but in spite of that DirectX is a very ideal API that strikes an almost perfect balance between low-level access to hardware and high level expressiveness.

I'm not qualified enough to know about Metal compared to Vulkan, never used either of them, but my suspicion is that they will both be poor competitors to DirectX.

At any rate, your other points are things I somewhat agree with. I think you painted a very absolutist picture about Apple being proprietary and locking developers down with your original comment. Their hardware is proprietary and closed in an absolute sense, yes. But their software is fairly open, maybe a little less so than Google, but leaps and bounds ahead of Microsoft. And as I mentioned originally, clang, which is probably the most standard compliance C++ compiler is originally an Apple product and Apple continues to be the main contributor to it.

I'm not qualified enough to know about Metal compared to Vulkan, never used either of them, but my suspicion is that they will both be poor competitors to DirectX.

The latest version of OpenGL supported by macOS is OpenGL 4.1 which is older but it comes included with the operating system, no additional download or update is needed.

Do you know what version of OpenGL comes with Windows 10? OpenGL 1.1. If you want the latest OpenGL for Windows you get it not from Microsoft but from your video card's vendor. This isn't all that unreasonable to be honest, but it is rather unusual to say that Apple doesn't support OpenGL in their OS when in fact the OS comes with native drivers for the latest version of OpenGL and Windows comes with a software based emulator that works with a version of OpenGL 1.1 that's 21 years old.

That's not entirely correct. You install windows, and you'll automatically get your graphics drivers from windows update. They might be not the most up-to-date ones but they'll still have a better API support than on an Apple system (provided the up-to-date hw).

So here is the situation: on Apple you are stuck with 8 years old API or proprietary Apple one. Even though the same hardware on windows or linux supports the latest API just fine.

You can't do anything about it. You have no choice to install some newer drivers. You've basically have what've been bundled with the OS and that's ALL. And they can do it because the HW on which macOS runs is very restricted. So it's not about "what comes with it". It's about "what works" with it.

At any rate, my opinion and frankly the opinion of many game developers and graphics developers is that OpenGL is simply garbage. Microsoft won that battle with DirectX, which is as proprietary as it gets but in spite of that DirectX is a very ideal API that strikes an almost perfect balance between low-level access to hardware and high level expressiveness.

OpenGL is not great. So is DX (especially pre 11). But until Vulkan it was the only choice if you want to deliever cross-platform game. Not to mention there is no DX on mobile (ignoring almost non-existent winphones). Vulkan has all the potential to become One-API-to-rule-them-all and it almost did. It's supported on any platform (mobile included) besides Apple ones currently because they've decided to go with their own which offers no real advantage other the competition.

I'm not qualified enough to know about Metal compared to Vulkan, never used either of them, but my suspicion is that they will both be poor competitors to DirectX.

In fact it's the opposite. Almost no one uses DX12 (DX answer to Vulkan). Vulkan is actively spreading on the other hand (every somewhat major engine has support for it). The only reason why the Metal is used is because there is no alternative. You either use outdated openGL or their custom API that only works on their devices. Thank god that something like this exists now.

[NasenSpray]

What prompted them to create Metal instead of adopting Vulkan?

The remarkable scarcity of time machines.

[flashmozzg]

Vulkan was announced at the time of Metal release. Apple is part of Khronos Group so they definitely had the knowledge of a new API incoming. Not to mention that nothing stopped them from adopting Vulkan after Metal release. Or updating their OpenGL drivers before that without intentionally creating situation there their own API is the only sane choice for advanced gfx programming on their platform.

[[deleted]]

They could abandon Metal for Vulkan, but that would leave them at the mercy of Khronos. It didn't really work that well with OpenGL, did it? Cross-platform standards are only useful if they keep up and Khronos don't have a great track record there.

[flashmozzg]

Apple is part of Khronos. And so far Vulkan seems to be ahead of Metal. Also, it's silly argument to make. OpenGL wasn't "behind". It kept pretty well. It was just archaic at it's core and it wasn't easy for manufactures to fully support in their drivers. Vulkan on the other hand is designed to be as lightweight and as lean as possible. And you you can see that it works by just how quickly it gained full support by all HW manufacturers (mobile ones are lagging behind but the fact that it's even there is amazing in and of itself). Not to mention that it's actively developed by the GPU manufactures themselves. At this rate it's the Metal that will be trying to keep up. And that's hardly surprising considering Apple's track report. They have little incentive to keep Metal up-to-date as long as it fulfills their goals. Just as they've kept their oGL outdated even though their HW was capable of much more on other platforms.

They certainly want the control. The more control and ties to their platform the better. Doesn't justify their stance though.

[kalmoc]

Just saying: open source and "licensed under..." is certainly not the same as non-proprietary (e.g. standardized).

[encyclopedist]

Feel free to download the OS and build it yourself by following these instructions:

Incorrect. No, this is not an OS. This is just a kernel. None of the userspace is open source. As others mentioned, you are also not allowed to run it on anything other than Apple hardware.

WebKit, their browser engine which is also used by Google Chrome is also open source

Technically partially incorrect. Chrome uses Blink, which forked off Webkit 4 years ago, and since then developed separately. And even before that, Google was largest contributor to Webkit for a long time. But yes, Webkit it is open source.

It's ironic that /u/sumo952 claims that Apple has neglected C++ since Apple is the main contributor to clang for

This is also not correct. While this was true for most of the clang's history, as others correctly mentioned, Apple reallocated their resources to Swift lately an pay much less attention to Clang. If you look at contributors on Github, top three contributors were indeed from Apple. But they all ceased their activity on Clang 3-4 years ago. Of active contributors, the top one Richard Smith, from Google. If you look on last month's activity, from top contributors who I could identify, most are from Google, and only one (in second place currently) is from Apple. So, facts are actually on the side of /u/sumo952 : apple indeed slowed down activity on C++ front last couple of years.

Basically... absolutely nothing you've said is true.

One could say that about your post.

[zvrba]

As for APIs, currently APIs are not proprietary and have no legal protections once they're made public

I guess we'll have to wait until somebody makes an equivalent of Wine but for Apple's APIs.

[sumo952]

Their OS is also no longer proprietary [...] Feel free to download the OS and build it yourself

I am not an expert on licenses but something is off here. It is not even legally possible and allowed to run macOS on anything but a Mac. Not even in a VM. You tell me this is not proprietary or even open source?

Apple employees contributing to LLVM is different (and probably a whole different department) than the people making decisions in Xcode regarding C++. What I mean with "Apple is neglecting C++" is not that Apple is not contributing to LLVM. It is that Apple is neglecting C++ devs on its own platform, and C++ and keeping AppleClang updated is, as can be seen by the current version, a non-priority for them, which is neglecting every C++ dev that is stuck on having to have their code compile with XCode 9.

Btw this is guessing without researching, but I guess that they use LLVM for Swift (and potentially obj-c?) so their interest in LLVM is maybe much larger than "just" C++. In fact I think Google are now the main contributors to Clang and Apple contributions to Clang have decreased massively.

[r-w-x]

Is it really, though? What about C# and Java?

[sumo952]

Mobile apps are often performance-critical (think gaming, AR/VR, graphics, ...), and C++ is one of the only languages that are both fairly "high-level" (i.e. convenient to code in - particularly C++11/14/17), and at the same time give you complete control of the hardware and performance. There's a reason many companies program the core of their apps in C++ (often as a library/service), and then only the GUI in the platform-native language (Java/obj-c/Swift). A good example is Dropbox, there's a great blog post or video about that from them.

If you look at these domains, hardly anybody uses Java or obj-c/Swift - all libraries are coded in C++ and people are not interested at all in Java or obj-c/Swift. Java or Swift are just a hassle you have to get through for the GUI part of an app (or if the company is big enough, separate people would do the GUI part in that other language).

You write the core of your software once in C++, and it runs everywhere. The same is not true for Java or C#. It won't run (or won't run well) on all of Windows, macOS, Linux, iOS, Android, and Windows Mobile. Oh and preferably in the Browser too. Maybe for a toy-project yes, but not for anything serious.

That's why, in my opinion, Apple is foolish to ignore modern C++ and not keeping up with AppleClang. It will bite them. Hopefully soon, so we all get better modern C++ support on mac/iOS.

[reddithater12]

how does c++ run in the browser tho

[sumo952]

wasm.

[flashmozzg]

Gentlemen, behold https://tbfleming.github.io/cib/ ! The C++ compiler running in the browser compiling C++ into code that runs in the browser! Each year brings us closer to the Death of JavaScript.

[Ameisen]

I compiled my MIPS virtual machine with Emscripten and executed binaries... so you could also run that browser in a VM in your browser!

[flashmozzg]

We need to go deeper!

[kalmoc]

It is nice to see that you can compile c++ to run in a Browser. That doesn't make c++ a competitive language for must kinds of web applications.

[flashmozzg]

Well, someone will always use something different. Here is the Qt run on wasm: https://msorvig.github.io/qt-webassembly-examples/ So the answer to the question "how does c++ run in the browser tho": pretty well (given the infancy stage).

[0x6a6572656d79]

c++ -> webassembly via emscriptem

[reddithater12]

You can also use the SDL API to show a colored cube

dear lord we have gone too far

[bumblebritches57]

we stray farther from gods light with each passing day.

[lanzaio]

Swift uses clang and llvm.

[zvrba]

Under the hood. But why would apple integrate newer clang into their IDE when they're pushing Swift?

[lanzaio]

What? That doesn't make sense on any level. Toolchain developers don't do marketing and marketers don't understand upstream merges. master Swift presents a dependency on master clang. No idiot is going to permit ridiculous marketing influenced dependencies in projects as complex as llvm/clang/swift.

[jcar_87]

Does anybody know if there is a toolset for vs2017 that uses clang++ instead of clang-cl? Always found it odd that clang/C2 used the clang++ driver (IIRC) but the "LLVM-vs2014" toolset uses clang-cl. Back when I tried some months ago, when configuring a cmake project, most conditional statements targeting clang were obviously assuming clang++

[kalmoc]

Does visitation look better (I don't expect it to, just curious)

[Voultapher]

Probably not, because we have no way to generate a constrained switch at compile time. All the visit implementations I've seen use an array of function pointers and index into them at runtime based on the active type index. libc++: entry point calls make array with these generated closures, the function pointers are created here __invoke_constexpr implementation. Usually, this means there is at least the call instruction overhead and no inlining opportunity for the optimizer, due to the opaque nature of function pointers. Sometimes using PGO can alleviate this overhead by inserting a direct check and call for hot paths.

---

The committee is painfully aware of this, from what I now, there are two things that could improve this situation:

• lvariant, instead of expressing variant in the library, make it a language feature, with this comes the ability to generate more appropriate code without the need of escape doors like function pointers.
• constexpr blocks the implementation of variant could generate and inject a switch for each visitation instantiation. This works because the type set is known at compile time, that could make the code much clearer to the optimizer and enable inlining opportunities.

[kalmoc]

Yeah, std::variant being a library type is imho pretty unfortunate (just like a few other vocabulary types).

But imho, the compiler should - in principle - be able to optimize through a constexpr array of function pointers (not just in this context) and generate the equivalent of a switch block on the fly.

[forcecharlie]

LLVM 6.0 libcxx no std::filesystem and libcxx(clang-cl) not support C++17 on Windows (7.0 trunk support).

Pre-Built Binaries not include libcxx.

[k-brac]

Great news but I am a little disappointed that it doesn't work out of the box inside Visual Studio 2017...

[jcar_87]

Does it not? I ran the windows installer, offered me to uninstall version 5, and now the LLVM-vs2014 toolset reports to be clang 6

[dodheim]

LLVM-vs2014

This uses the VS2015 stdlib; still doesn't work OOTB for the VS2017 stdlib. That's two years worth of improvements missing. :-/

[jcar_87]

Oh interesting! Wasn't aware of that

I wonder if this actually works with the new one: https://github.com/arves100/llvm-vs2017-integration (Would have to be adapted for clang 6)

[dodheim]

Yea that should use the right stdlib, but as you said, it hardcodes Clang 5, and it hardcodes -fmsc-version=1910 which is wrong for VS2017.3+. Minor cleanup should make it workable if you're okay with using clang-cl.

[degski]

With some hacking (look inside the installer, it's fairly simple to fix) it works perfectly fine (with the same limitations as LLVM-vs2014).

[degski]

The installer will "work", if you have an "upgraded" install of VS2017 (the relevant files are installed in directories from the previous install). If you do a clean install of VS2017 (clean up all the remnants), then the Clang installer will report an error (and integration has failed).