What is Reddit's opinion of
clang?
From 3.5 billion Reddit comments
➔ clang website
By popularity on Reddit, this Service is:
100 reviews of this app found across Reddit:
> It has to read c and c++
Writing a C++ parser is pretty fiendishly difficult. Heck, writing a C parser is far from trivial. But all is not lost - your best bet is to look at clang & LLVM which were designed to make their C++ parser accessible to third-party tools. See http://clang.llvm.org/docs/ExternalClangExamples.html and http://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/ for places to get started.
Bottom line - this project will be difficult, but it's not impossible, so long as you don't attempt to write your own parser.
This is a very complicated question. For a comparison, you can see http://clang.llvm.org/comparison.html although it's fairly old. It does give an indication of many of the reasons the project was started. GCC switching to GPLv3 is a major reason (same with libc++ vs libstdc++).
As for popularity, the reason is:
- Modern codebase written in C++
- Modular compiler separates frontend from codegen very cleanly.
- Usable a standalone library - can be integrated into any other tool
- Performance is competitive with GCC (LTO is currently the only place GCC is leading significantly at this point I believe)
At this point, there's also a lot of momentum since it's the default compiler for iOS & OSX development, & really the only one unless you're building GCC yourself. Additionally, Google is investing heavily in it as well due to the modular architecture, meaning they can build tools to process C/C++ code on an automated large scale.
GCC has been making strides in making itself competitive (switching to C++, trying to make itself more modular, etc).
GCC currently is more portable than Clang (Windows support being the major hole currently in clang) & more popular in the Linux world. Clang is popular on BSD.
GCC or clang are both great for C++ development as they are conforming C++14 implementations. Visual Studio is a little bit lagging but it's catching up. I would choose the default toolchain for the platform you are on. On Linux, GCC. On OSX (& most/all BSD variants) clang. On Windows, Visual Studio.
What I'd really like to see is a flag I can enable to the compiler such that my program simply aborts if it engages in any such undefined behavior. Even if the resulting binary runs must slower, this could be enabled for certain debug/test builds, and would help to squeeze any undefined behavior out of my programs.
EDIT: just discovered clang's -fsanitize flag, which does much of what I am looking for.
If you take a look at the clang code-base, obviously a very nicely done C++ compiler -- you can see the contrast with the ML family of languages.
Simple sum types that would take a couple of lines in Haskell or ML are spread over 150 of lines or so of C++! Example: <code>DeclGroupRef</code>.
It is roughly equivalent to Haskell's:
data GroupRef a = Single a | Group [a] deriving (Functor, Foldable, Traversable) type DeclGroupRef = GroupRef Decl
It's ironic that you'd say that, because one of the goals of the Clang project is to be usable as a library that other people can use to make tools, like syntax highlighers, autocompleters, linters, code reformatters, etc. Several of those have already resulted in real products, like clang complete, clang-format, cpp11-migrate, and so on.
That doesn't list clang at all, which is odd. For those who are interested, clang has full c++98 and c++2003 support, and http://clang.llvm.org/cxx_status.html is its c++0x status, some bits have started to work but there is obviously more to do. Also, libc++ from the llvm guys has a good bit of work started as well, it supports 98% of the new C++ standard library (although its only been fully tested on OS X) http://libcxx.llvm.org/ is a link for the library if your interested.
>There was a recent upset on the Twitter-verse.
Oh noes, not the Twitter-verse, home of well-reasoned debate!
>This is a request for code that cannot be implemented in any current compiler
I found the link in the blog post much better than the post itself:
http://clang.llvm.org/docs/Modules.html#problems-with-the-current-model
It at least acknowledges these issues:
> [...] the system headers themselves may require some modification, if they exhibit any anti-patterns that break modules. Such common patterns are described below. > > [...] > > Missing includes - Headers are often missing #include directives for headers that they actually depend on. [...] > > Headers that vend multiple APIs at different times - Some systems have headers that contain a number of different kinds of API definitions, only some of which are made available with a given include. [...] There is no sane way to map this header to a submodule.
Thanks, at least someone noticed the elephant in the room, even if this only happens near the end of the otherwise optimistic and forward-looking text.
I can't comment how it is for Linux folks, but both these things occur in spades with Windows Platform SDK. Until someone does a humongous job of reworking the headers to be amenable to modules, the entire feature on Windows will be just something you do with your own code or maybe with non-platform-specific libraries.
With all of the benefits that clang & LLVM provides over GCC, is there a good reason to continue to use GCC for projects?
EDIT: Why am I being downvoted? This is an honest question, I'm really interested in what benefits GCC has over LLVM & Clang.
>I think the build is configured to include debug symbols for some reason.
>Not sure.
Line 18 in your cmakelists
set(CMAKE_CXX_FLAGS_RELEASE "-DAK_OPTIMIZED=1 -g")
Don't use -g if you don't want debug info. Compiler manuals should be read before you add any CFLAGS/CXXFLAGS whatsoever.
https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Debugging-Options.html#Debugging-Options http://clang.llvm.org/docs/ClangCommandLineReference.html#kind-and-level-of-debug-information
Since Clang has existed, for the most part. Unfortunately for Clang some of the areas it does better (such as automatic vectorization) don't really matter for the kernel.
http://www.phoronix.com/scan.php?page=article&item=llvm-clang-39&num=1
Clang's own comparison page mentions that GCC supports more targets.
There is a very good reason for this.
> A further difference between IDEs and batch compiler is that they often impose very different requirements on the front-end: they depend on high performance in order to provide a "snappy" experience, and thus really want techniques like "incremental compilation", "fuzzy parsing", etc. Finally, IDEs often have very different requirements than code generation, often requiring information that a codegen-only frontend can throw away. Clang is specifically designed and built to capture this information. > http://clang.llvm.org/features.html
What you are probably looking for is C++ modules:
"original" specification
Standard Paper
A VS2015 quick intro
I assure you that I'm not talking about the templates. Because the operations I speak of are in C11 and C11 doesn't have templates.
See here:
http://en.cppreference.com/w/c/atomic/memory_order
No templates:
// Thread 1: r1 = atomic_load_explicit(y, memory_order_relaxed); // A atomic_store_explicit(x, r1, memory_order_relaxed); // B // Thread 2: r2 = atomic_load_explicit(x, memory_order_relaxed); // C atomic_store_explicit(y, 42, memory_order_relaxed); // D
During last week's meeting in Issaquah, some new features requested through National Body comments were merged into the draft Standard. See the latest 3 entries of corresponding the Clang progress table. So depending on whether gcc also incorporated those features, they are the first to be C++17 ready.
Contribute to Clang! Not only will you code be looked at by friendly C++ experts, but you will learn more than enough about C++. And you're helping to make the C++ world a better place.
Clang modernize does a few things.
But keep in mind that they tried very, very hard to make C++11 backwards compatible. With only a few obscure exceptions everything should just compile. There's few good reasons to go back and rewrite (presumably working) code just to make it more C++11-style.
Most of the developers that write these kinds of tools are only really interested in modern C++. There are quite a few tools that do the exact opposite of what you want (i.e. detect that something like your second example could be a ranged for and modernize it) despite that being more difficult and requiring heuristics.
Translating auto and ranged for shouldn't be too difficult. Trying to convert variadic templates sounds like a can of worms, but it may be possible if the resultant source code is intended only for compilation and not for editing (though beware of the way forwarding will break down without rvalue references).
The best way to implement this would probably be as a clang tool. clang's LibTooling is probably the most appropriate approach. clang will give you an AST representing the input program and you can make your adjustments when outputting this back into C++. Ranged for statements are actually already transformed into normal for statements using the equivalency provided in the standard. Auto would be handled by removing AutoType sugar from a declaration's type.
Chromium ships a prebuilt clang binary. It's just upstream clang built at a known-good revision that we bump every two weeks or so.
This is the only supported compiler for building Chromium.
The C++1z implementation status page for Clang says "no" for P0127R2
The C++1z Support in GCC page doesn't even list P0127R2 (or its predecessor P0127R1).
Especially with the LLVM/clang infrastructure. Up-to-date compilers and linkers, great error reporting, lots of extra goodness like the static analyzer, and APIs to write your own tooling if you want.
Qt Creator also uses LibClang, because of the promise of a stable interface.
LibTooling is the C++ library that should be used.
The fine manual has the gory details.
If you aren't familiar with them, the address-sanitizer tools from clang are a great alternative to valgrind in some scenarios (specifically in performance-critical apps where you can't handle the overhead from valgrind). There is also a Thread-Sanitizer to help detect data race conditions in multi-threaded environments.
Visual C++ 2015 Update 1 has experimental support. Clang does, as well, but I don't know if it follows the current technical specification.
I prefer the term "realistic". It's in Apple's interest to not maintain a compiler alone, but not to put the entire OS X up on GitHub. It's in Google's interest to not maintain a browser alone, but they won't publish their search algorithms. They're acting in their own interests, and we get a compiler and a browser for free.
And it works: both Chromium and clang are best-in-class, with clang being the only C++ compiler that can actually track standard proposals in realtime. Compare MSVC and Internet Explorer.
That could work, but writing a clang plugin is a better fit in my opinion. If you were to use libclang, you would have to deal with rewriting the source and then compiling the rewritten source only. Also, reporting errors at the correct locations in the original source would be difficult.
Apple has also open sourced ARC and an ARC migration tool to the clang part of the llvm compiler project.
As a result, you now have more options in getting bugs addressed, getting questions answered, and seeing the source code itself.
There does seem to be a lot of refactoring going on with Objective-C memory management in clang (and I believe ARC will be refactored to better fit the clang pipeline). So, it's very likely the version in llvm 3.0 today is not the same as what you get with Xcode today. But I'm guessing these will converge at or before WWDC (and llvm 3.1).
It's a decent summary, but not up to date re: clang.
For example, clang supports delegating constructors, where're this table indicates clang doesn't. Clang support is shown at http://clang.llvm.org/cxx_status.html.
The table also omits a very useful feature, range-based for loops.
> Wrong.
Uh what? How is "Clang is a frontend for LLVM" wrong exactly? Are you saying clang's own website is wrong?
> ## clang: a C language family frontend for LLVM
> The goal of the Clang project is to create a new C, C++, Objective C and Objective C++ front-end for the LLVM compiler.
even more so in the context of talking about porting the compiler and comparing that portability to pcc: porting Clang alone is utterly useless as Clang can not generate binaries without LLVM behind it.
as to
> In fact, I think having Clang as a frontend to GCC would be quite interesting.
Yes, interesting in the same way watching babies fall down stairs is interesting. Stairs with spikes. And razor blades. Rusty razor blades.
Is there a canonical list of these?
Maybe http://clang.llvm.org/docs/UsersManual.html#options-to-control-error-and-warning-messages but I don't see -Wstrict-prototypes in the list. Looks like clang does have -Weverything.
This is also why the C++ community is busy trying to design a better module system. See for example the proposal A Module System for C++ by Gabriel Dos Reis, Mark Hall and Gor Nishanov, 2014:
> The lack of direct language support for componentization of C++ libraries and programs, combined with increasing use of templates, has led to serious impediments to compile-time scalability, and programmer productivity. It is the source of lackluster build performance and poor integration with cloud and distributed build systems. Furthermore, the heavy-reliance on header file inclusion (i.e. copy-and-paste from compilers’ perspective) and macros stifle flowering of C++ developer tools in increasingly semantics-aware development environments. > > Responding to mounting requests from application programmers, library de- velopers, tool builders alike, this report proposes a module system for C++ with a handful of clearly articulated goals. The proposal is informed by the current state of the art regarding module systems in contemporary programming languages, past suggestions [4, 6] and experiments such as Clang’s [2, 5], and practical constraints specific to C++ ecosystem, deployment, and use. The design is minimalist; yet, it aims for a handful of fundamental goals > > 1. componentization; > 2. isolation from macros; > 3. scalable build; > 4. support for modern semantics-aware developer tools. > > Furthermore, the proposal reduces opportunities for violations of the One Definition Rule (ODR), and increases practical type-safe linking. An implementation of these suggestions is currently underway.
The Clang-specific feature mentioned in this introduction is documented there.
They're implementing SEH, and C++ exceptions, and they will be compatible with MSVC. Take a look here, it may not be up to date. If you want to follow the development of these features more closely, you can always subscribe to the LLVM/Clang mailing lists.
There have been many requests over the years to allow GCC to export the AST (Abstract Syntax Tree, it's internal representation of your code. A middle ground between your actual source, and the target binary) in order to allow for the use of GCC in things like source highlighting, syntax checking, tag completion, and more. He has repeatedly shot down these requests as they would make it far easier for companies to use GCC in a proprietary way without technically violating its licensing.
For example, with AST export Microsoft could write a plugin for Visual Studio that allows it to use GCC as a compilation and auto-completion backend, and by never actually including any licensed source code in their backend plugin, it would not violate the license of GCC.
LLVM however has no problem with this, as seen by such plugins as YouCompleteMe for Vim, More info here
I see this as two different visions of "Free"
Personally, I subscribe to the BSD vision of free, which is what I see as true freedom. Anyone is able to use any BSD licensed material for any use, public or private See here. GPL/GNU is a vision of free, that requires all subsequent code based on the original licensed code to be released under the same license essentially.
This is why systems like the Sony PS4 is based on BSD rather than Linux, as they are able to make any changes they need and not release them, or be required to provide the source code upon request (Another GPL requirement, as seen in Linksys router firmware).
On the other hand, BSD allows companies like Sony to fork the LLVM/Clang to build the in house compiler stack for the PS4, and then release some of their changes back to the project, but keeping their proprietary stuff in house only. This would be against the GPL
It's worth noting that Clang has module support for C. There were a number of proposals put forth for the new C/C++ standards and modules was one of them.
It's by no means a standard, but last I checked it was usable. http://clang.llvm.org/docs/Modules.html
You can make C slightly more "modern" with extensions offered by clang. Since Clang targets Obj-C as a primary interest, you can get blocks and some more advanced lamdbas/builtins for cheaper. I wouldn't really recommend doing this past demo apps though - you could potentially tie yourself to the version of the compiler you use.
clang also maintains a list of their statuses for the committee defect reports, and libc++ maintains similar lists for the library.
That's a bit cruel to say. Clang only announced full C++1998/2003 implementation status two weeks ago.
http://clang.llvm.org/cxx_status.html
The fact that they're already 60% the way through C++11 is pretty good. They just haven't done much of the "concurrency" part of C++11 (of which this __transction_atomic is a related C extension).
Clang has a rewrite API for refactoring, not sure how apple handles it. I'll take a look... From what I can gather apple's refactoring tools are using Clang's rewrite API.
Here's a link to llvm/Clangs documentation, but there is likely a better description, I don't use it, just am aware of it's existence and use by other tools.
http://clang.llvm.org/doxygen/dir_000042_000001.html
Nice, a Jenkins plugin... https://wiki.jenkins-ci.org/display/JENKINS/Clang+Scan-Build+Plugin
What about this (taken from http://clang.llvm.org/docs/MSVCCompatibility.html):
>Third, MSVC accepts some C++ code that Clang will typically diagnose as invalid. When these constructs are present in widely included system headers, Clang attempts to recover and continue compiling the user’s program. Most parsing and semantic compatibility tweaks are controlled by -fms-compatibility and -fdelayed-template-parsing, and they are a work in progress.
Valgrind, and also with newer gcc and clang I would definitely recommend the Address sanitizer
Wikipedia also has some compiler-agnostic (clang or gcc) examples of using the sanitizer: https://en.wikipedia.org/wiki/AddressSanitizer
> Any iOS programmer worth their salt should know the inner workings of ARC and why/how it does what it does.
I hope you mean knowing when it's appropriate to release objects, and not know the technical spec, because those are two very different things.
> C/C++ work with 8/16/32/64 bit numbers. There is no mechanism for handling multiword quantities which are not in the 8/16/32/64 bit set
Can't you just do
struct uint48 { uint64_t x:48; } attribute((packed)); If your compiler always promotes the bitfield to a 64 bit number you can also use
struct uint48 { uint32_t x; uint16_t y; } attribute((packed)); and overload the operators you need.
> In C, the output of an NxN multiply is an N-bit number.
That's actually not true. When both operand of an arithmetic expression are of the same integer type they get promoted to int (or unsigned int if int isn't big enough.)
Besides, most compilers have builtins that do multiprecision arithmetic quite nicely. See here for Clang's.
> Handling of overflow detection and carry bits is not available in C
But most compilers do offer it as an extension.
For your last point, there are a ton of fixed point template libraries out there for C++, some of them very simple. MFixedPoint is one example. If you can't use any of the existing libraries on your platform, it's not very difficult to write your own.
Well, appropriately enough, Apple's Clang is a compiler toolkit which compiles the "capital C" languages (C, C++, Objective C, Objective C++) using the LLVM intermediate representation for optimization and native code emission.
The blitzkrieg line is most likely the reference to its centralized, operative and frequently updated development (the last two lines are particularly interesting).
AFAIK the last paper on modules is [0].
Richard Smith seems to be working hard on Clang's modules implementation [1], but if IIRC clang's approach started from Douglas Gregor's work on ObjectiveC modules, so it differs significantly from [0].
There should be a TS in the works, the mailing list of SG2 seems dead tho.
[0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf
Usually, when you exaggerate, it means that you have a poor argument, and as far as I can see, the argument is quite exaggerated:
compile time scalability issue is eliminated by include guards and precompiled headers
fragility can happen, but honestly, how often does one deal with it?
"conventional workarounds" applies largely to C, not C++, because in C++ one needs macros much less and can use namespace
tool confusion - TBH, this is the only valid complaint, first sentence of it. The rest really is about badly made headers.
I mean, honestly... world has been written with #include. So people obviously can do it. Sure, make something better, but get real first :-).
tl;dr: I voted "Yes, but it's not very urgent", which, at that moment, was on 11%, 34 Votes. :-)
This depends a lot on the platforms you target. MSVC is only relevant for one (or few) target platform(s) and not the only compiler that can target that platform.
I definitely agree if you're making a library that is distributed as source form and intended to be compiled for MSVC. If you're distributing binaries, there's no compelling reason to use MSVC (unless one or more developers insist on using the IDE).
Soon Clang+LLVM can build MSVC compatible object and library files (works but not quite ready for prime time), so we're running out of excuses to actually use MSVC for library development. Some people do prefer the MSVC IDE, though. See: http://clang.llvm.org/docs/MSVCCompatibility.html
On the other hand, MSVC does support vectors and vector intrinsics. Writing c = add4f(a, b) is not much worse than writing c = a + b. At least it's a lot better than writing float c[4]; add4f(a, b, c);.
The MSVC C compiler frontend is so much worse than all the other alternatives that I'd really rather not support it if I have a choice. At work we compile our C code in C++ mode to avoid some of the annoyances (like mixed statements and variable declarations). Unfortunately, it doesn't seem like MSVC is going to improve their C compiler in the near future.
MSVC is getting less and less relevant, the sooner I can stop thinking about it (either stop supporting it or they improve their frontend) the better.
I may be a masochist, but I do Windows development on a Linux box. I cross compile with GCC or Clang, share the binaries over Samba and use GDB extended-remote to debug remotely. Works either by having a virtual Linux VM inside your Windows box (or vice versa if you don't need native access, e.g. native 3d hw APIs) or having a separate Windows machine for testing. I'd rather use the same tools for all the platforms I target.
Apple's Objective-C compiler has defaulted to Clang for a number of years now, so it was the Swift compiler vs Clang.
Clang supports Objective-C and Objective-C++, in addition to C and C++. Apple moved away from GCC quite a while ago.
I would like to point out that there has been a movement initiated by Clang in the C++ compilers to move away from compiler-versions toward compiler-capabilities.
The old way:
#if (GNUC == 3 && GNUC_MINOR >= 3) || (GNUC > 3) #endif
The new way
#if __has_feature(cxx_rvalue_references) #endif
As you can see, this is much easier to read, and self-documenting to boot.
Of course, it does not address the need to skip the items that are not suitable before attempting to parse them; but you no longer need all those >, <, <=, >=!
This is actually one of the advantages of the clang compiler, which will give errors about what you probably did wrong rather than what the parser had trouble with: http://clang.llvm.org/diagnostics.html
> Valgrind still rocks thanks to helgrind though
There is also ThreadSanitizer (but it's still under heavy development and not included in the 3.1 release). It started out as a valgrind-based tool and is now being rewritten to do compile-time instrumentation like AddressSanitizer: http://clang.llvm.org/docs/ThreadSanitizer.html
Apple stopped contributing to gcc when it moved to GPL v3 due to patent clauses and instead focused all their energy on clang and LLVM. Clang is doing quite well in terms of C++11 adoption, so it's really not relevant that the system gcc is an ancient and crusty gcc 4.2 (the last series that was GPLv2.) It's really only there for backwards compatibility. Clang was designed to be a drop-in replacement for gcc, at least to the extent that it supports most of the commonly used gcc command line arguments and many of the commonly encountered GNU C/C++ language extensions.
Despite what it says here, Apple's 3.0 version of Clang does not support unicode string literals. It would seem that Apple branched off their 3.0 version of upstream Clang before that support was ready, calling it 3.0 anyway. Since that comment was written, upstream Clang released the actual 3.0 which should support it, so if you build a vanilla Clang (instead of using the Xcode bundled not-3.0 version) then it should work.
I wouldn't say that C++ Modules (N4610) are like mini-pch files. They address the main goal of precompiled headers but they provide much more than build throughput improvements.
Precompiled headers are a build-time technology and don't have any real integration with the language. C++ Modules enhance the language to allow definition of an interface. Enabling the component developer to define an interface means that the consumer doesn't need to deal with any random internal state that never should have been exposed in the interface.
Maybe you're confusing C++ Modules, the current TS, with Clang Modules, the cross-language build-system technology built as a huge improvement over PCH files?
Edit: Changed first paragraph based on the discussion following.
For me, it was more helpful to break it in an interesting place (e.g. someplace in SemaOverload) and look at the stack trace that got me there. Open bugs might be a good entry point, too. They also have some internals docs
Clang's Documentation also mentions this [1]:
> clang currently contains some support for other architectures (e.g. Sparc); however, significant pieces of code generation are still missing, and they haven’t undergone significant testing.
> Any standard compliant compiler should refuse to compile it.
Clang and GCC both permit VLAs and will allow them by default in C++ code. Since widespread and high-quality compilers allow it, it's probably an oversimplification to say that any standard-compliant compiler should refuse to compile them (even though it's technically correct).
Very cool project!
> objc blocks are all boxed and Rust's closures don't always have to be boxed
Yeah, the implementation of blocks is quite complex.
> autocomplete
For me YouCompleteMe is the best.
> refactoring
There isn't yet a stable tool for refactoring via clang yet, except for the formatter and the modernizer, so if you were looking for things like "rename", "extract methods" the answer, at least in my knowledge, is no. You can find them here. Anyway the "go to definition" is implemented and YouCompleteMe supports it.
> It'll take compilers 2 years before they catch up with that standard after it's finished. Probably longer, lol :P.
Clang has already implemented all of the draft C++14 standard.
You can never tell, that's the problem. There is a version of gcc for the Ps3, but it's always a few versions behind, so it will support some C++11 features, but not all. I haven't checked, but with the X360 compiler being VC++ based, it probably supports the same stuff as its x86 counterpart. On the iPhone, if you use C++ you have to compile with clang, which doesn't yet support all features.
You can't really presume that any particular features are available on all platforms. So you'll have to find out specifics about what you're know you'll be working on and stick to that limited feature set, or code yourself into a corner when you later decide to support something like the 3DS (that was just an example piece of hardware because Nintendo have historically used CodeWarrior, but it could be any new hardware).
visual studio and clang also support support quite a bit themselves
This. In case you have a project with CMake setup, just pass -DCMAKE_EXPORT_COMPILE_COMMANDS=On and just simlink compile_commands.json to the source directory (see How To Setup Clang Tooling for more information). Also, .clang-tidy config is pretty useful, I recommend creating that.
> hardening options on the install screen
That's just sysctls that enable some specific simple things sort of related to security.
HardenedBSD meanwhile is compiled with all the cool compiler security features (CFI, SafeStack), implements ASLR and W^X and more…
OpenBSD is nice when you only care about security, but it doesn't have ZFS/jails/DTrace/etc. — it feels somewhat "empty" without these features :)
clang-format plugin for Visual Studio: http://llvm.org/builds/
I actually don't know if it does this kind of code styling, but it's worth checking.
edit: Actually, according to clang developers, it is clang-tidy job to do this kind of thing:
http://clang.llvm.org/extra/clang-tidy/checks/readability-identifier-naming.html
And there's a VS plugin for that too:
https://github.com/llvm-mirror/clang-tools-extra/tree/master/clang-tidy-vs
According to the documentation it will flag if you attempt to dereference the pointer after move, but won't flag if you get the pointer value itself to do something like a null check. http://clang.llvm.org/extra/clang-tidy/checks/misc-use-after-move.html
I just haven't seen editors get it 100% right. However, for C* languages, clang-format does a great job of reformatting. The emacs integration is great, as well. M-x clang-format-region and M-x clang-format-buffer reformat the code right in your buffer so you don't have to deal with filenames.
That's what came to mind for me as well. The term to google is ARC(automatic reference counting).
One important difference is that Swift/Objective C have proper compilers, so have pretty good understanding of object lifetime.
And, now that I've reviewed the link, I now recall how complicated ARC is. It gives me a new appreciation for Rust.
Because it uses tsan and tsan doesn't support things other than 64-bit:
http://clang.llvm.org/docs/ThreadSanitizer.html
> ThreadSanitizer is supported on Linux x86_64 (tested on Ubuntu 12.04). Support for other 64-bit architectures is possible, contributions are welcome. Support for 32-bit platforms is problematic and is not planned.
For C++: g++ and clang are the "standard" free choices for desktop platforms (and probably also represent the state of the art in imperative compilers). IIRC the windows SDK also includes a compiler, if you're on windows.
Given that you're just starting out, you may be referring to a larger set of tools as a "compiler" (or you might not, I'm just trying to cover all cases). If gcc and clang don't look like what you were looking for, then if you say what platform you're on and what capabilities you're missing, we can probably direct you to what you need.
It's cool to see more compilers support modules. It looks quite a bit different than the clang module system though. On the face of it, it looks more invasive to your code base as well, I guess I have to spend more time reading the full paper.
> Nobodies implemented it
Except clang. Microsoft, AFAIK, has an experimental implementation too (used internally though); but I can't find a link to the information on it now.
What do you mean that it doesn't work properly? Windows support for clang has come a long way in recent years. At the very least, a frontend tool, such as a reflection parser, should work.
> do I need to download something in order to run these programs?
Yes, you need a C compiler. Some operating systems (Mac and Linux) come with one installed already, either gcc or clang. On Windows, you'll need to download one.
If you aren't on Linux, there are two rough approaches you can take:
Text files and the command line. Here, you'll edit code in Notepad or whatever other text editor you like. To compile and run your program, you'll open a terminal or command prompt and run the compiler and then invoke your program. This is a good approach if you're a bottom-up learner who wants to understand how each piece works.
An IDE. This gives you a very nice application to both edit and run your code. It's what many professional programmers use all day. It's the best approach if you want something that can get you going quickly and give you lots of feedback.
You sound like you're on Windows, so I'd recommend installing Visual Studio Express, the free version of Microsoft's very nice, very powerful IDE. I believe it has C/C++ support.
When did GCC and clang add support for export templates? The current clang status page states that export templates are not supported. Searches for GCC show that the GCC maintainers are not interested in implementing it either.
> I do not see how C++ can get rid of header.source split in reasonable time-frame.
The how is clear: C++ modules, which have been in the work for a long time. (clang has an experimental implementation) Though it's still unclear whether modules will ship with C++17. My guess is they'll end up in the next major C++ version after 17.
C++ concepts (likely to be in C++17) will make C++ generics more sane (C++ "concept" ~= Rust "trait").
The unsafety of use-after-move and iterator invalidation will never get fixed, but is this really enough of a problem to make C++ programmers learn to deal with the borrow checker?
Depends. From Clang:
> Each module is parsed as a standalone entity, so it has a consistent preprocessor environment. This completely eliminates the need for __underscored names and similarly defensive tricks.
But:
> Headers (particularly C++ headers) expose the full complexity of the language. Maintaining a stable binary module format across architectures, compiler versions, and compiler vendors is technically infeasible.
So yes and no. It depends on what you're "hiding" and why. If you're talking about private class members, then no, nothing changes. If you're talking about the morass of preprocessor tokens and include-order dependencies, then yes, those "private" details get privater.
> On Windows in particular, the interop standard is COM, and that gives cross-language ABI, api versioning, process isolation, component monitoring if you use COM+ and more.
If you want to do that you can, but clang's 'interop standard' is being ABI compatible. For example on OS X linking clang built object files and gcc 4.2 (the version that used to be the OS X platform compiler) object files is supported. Clang intends to support the same thing with MSVC on Windows.
http://clang.llvm.org/docs/MSVCCompatibility.html
http://blog.llvm.org/2014/07/clangllvm-on-windows-update.html
Why not both?
i like developing with clang because it compiles significantly faster (about 30% faster for my project, which when you're talking about >10 minutes to compile from scratch that's a big deal). I also love using clang-format for formatting and refactoring code - it simplifies code reviews by eliminating the need for any arguing about the right way to format code.
However, we run tests with both gcc and clang - because they occasionally catch different errors - and when providing binaries we use whichever one produces the best binaries - which is often gcc.
Clang used to have dramatically better error messages. Since then, gcc's have gotten much better. Competition is good!
And Clang implements the vast majority of these extensions, precisely so that Clang can replace gcc.
There are only a handful of real goofball extensions in gcc that are not supported by Clang.
Yes they all mean "fix it". The selection actually varies with the compiler and the edition of c you're using. here's the clang manual http://clang.llvm.org/docs/UsersManual.html that may shed a little light
I agree that it would be a large change, but it certainly would be very helpful to users.
A proper solution is obviously not trivial, but it's certainly is not intractable either. This is probably one of the most common time wasters for the developer, as you see a lot of silly errors all the time and you have to spend those extra seconds parsing them in your head.
I think a good example of the impact is Clang vs. GCC error reporting. Right now, Clojure reports errors like GCC and it causes pain and frustration to all the users on daily basis.
Apple is not updating their branch of GCC past 4.2.1 because of the license in versions of GCC after that (GPLv3). For compilers direct form Apple, Clang is your best bet. The version in Xcode 3 is pretty old, but the one in Xcode 4 is 2.8 I believe. The beta of Xcode 4.2 has a more recent build of Clang as well.
If you truly want the latest and greatest, you'll have to build GCC or Clang from source. I've done both before by hand, and in the case of GCC, through MacPorts. Clang is dead simple to build, with a 4 step process to get to working binaries. Compared to GCC, which made me want to kill small animals trying to satisfy dependencies.
Pretty much because clang is awesome in helping new and veteran programmers alike. Just look at its awesome error messages for instance: http://clang.llvm.org/diagnostics.html
Also its static analyzer rocks, it validly caught three bugs in a small program that I thought was perfect and working.
Basically it is awesome. Check it out.
Great article. I generally compile all of my projects with -Wall (to show all warnings). It's saved me a lot of time and effort with debugging my code.
It's worth mentioning that Clang gives some really good color-coded warnings. The new releases work quite wonderfully, too.
If you're using cmake you can add the option -DCMAKE_EXPORT_COMPILE_COMMANDS=ON to create a clang compilation database. Tools like rtags can give you IDE like features using this database, like showing the preprocessed C++ code.
Using the void pointer you can cast it using the bridge keyword so something like this. `MyObject *object = (bridge MyObject *)context` where context is your void pointer. You can find the documentation on this here: http://clang.llvm.org/docs/AutomaticReferenceCounting.html
you need a C compiler, Possibly C++ You should probably read this: https://stackoverflow.com/questions/6394755/how-to-install-gcc-on-windows-7-machine#6395050 and improvise if you don't have Windows 7
If you can't compile it with that try Klang, it's a more modern implementation http://clang.llvm.org/
Modules as specified in the TS generate object files and interfaces. Of course, no TS is adopted as written.
Maybe you're thinking of Clang modules which are precompiled headers on steroids?
deoplete_clang and clang_complete are different tools that do the same job, they feed deoplete with C/C++ sources.
To configure deoplete_clang for QT you need a .clang file on the root of your project that looks like this:
[ { "directory": "/home/user/llvm/build", "command": "/usr/bin/clang++ -Irelative -DSOMEDEF=\"With spaces, quotes and \-es.\" -c -o file.o file.cc", "file": "file.cc" }, ... ]
You have to customize it with your QT include path, and your build file, etc...
Take a look at the documentation for how to configure it.
deoplete_clang also supports single line flags, like they show here
Each completer plugin will require you to write a similar configuration so that deoplete (or whatever auto completer you want to use) can find the source files that live outside your project folders.
Profile Guided Optimization may help, if it's available to you.
>size*newcap < newcap
This isn't sufficient. Suppose size = 7 and newcap = 2**62, then size * newcap will overflow to 3 * newcap.
Checking for overflow in C is actually a pain, but fortunately GCC and Clang both support checked arithmetic builtins.
http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
Clang is also the name of the whole thing - see e.g. the web site. Not the case for CL, and in particular what you said is suggestive of a common I've-only-used-the-compiler-on-machines-that-were-set-up-for-me confusion. If you're particularly poking a finger at one particular component of the thousands that from Visual Studio and calling it the compiler, maybe it should actually be the compiler?
EDIT - Just thought - maybe you're thinking of a different (compiler-specific) meaning of "front end". Yes, Clang is the "front end" whereas LLVM is the "back end". LLVM converts from an intermediate representation to target code. Clang converts C++ to intermediate code and asks LLVM to do the rest. In this sense, a "front end" is the bit that parses and understands particular source languages.
CL.EXE isn't the front end of Visual C++ in that sense. It literally has no compilation-specific logic at all, last I checked - it interprets some command-line options and farms out the work to the real compiler (including front end).
Confession - it's a long time since I used Visual Studio in any version (the last version I used regularly was 2008) so I could be mis-remembering.
so you want your code not to compile because you forgot to link a bug number when doing a // TODO in your code ? Or because your includes are not sorted alphabetically ?
I'm not an expert, but even though the problem is not quite the same, I suspect cling has to solve many of the same sub-problems as an incremental parser would need to. E.x. line by line parsing, and mutating the AST of a single translation unit.
Though perhaps dealing with the parse tree is harder?
Also clangs goals explicitly call out IDE integration and incremental parsing: http://clang.llvm.org/features.html (not that it means they've achieved it)
That's kind of a meaningless question. Implementations add support for new features piecewise. Version X of compiler Y might support features A through G of C++11, features M through Q of C++14, and a few features of C++1z. Each implementation generally maintains a table of when each feature was implemented in which version. Here is the table for clang. Note that this refers to the official version numbers. Apple of course doesn't ship LLVM releases, they maintain a fork, so they use their own version numbering scheme, so you may have to do some work to track down the version correspondence. It's probably safe to assume that Xcode 7 was branched from LLVM 3.7-ish, and it almost certainly has full C++14 support since that's been in Clang for some time. (Although library support and language support are two different things and sometimes the difference is elided, such that you'll see things like "C++14 feature complete" when it really only refers to the language features and not the standard library.)
> The underlying issue is it always rewrites all of the code
No, it does not, it only rewrites the code that you tell it too. In particular within emacs you can tell it to only rewrite the lines that you indent, or within svn and/or git you can tell it to only rewrite the lines that you edited (which is what for example Chromium and LLVM do, both million LOC code bases).
> I don't know if I like that, but there's no way to do that in ClangFormat.
Yes, there is: http://clang.llvm.org/docs/ClangFormatStyleOptions.html there are actually multiple options to control that but my original question remains, if none of them worked for you, did you file a bug report?
> but ClangFormat tries to fit as many things as it can into one line and I personally hate that.
There is actually a lot of options to to tell clang-format not to do that: AllowXXXOnASingleLine.
Idk, to me it sounds like either you didnt tried hard enough, or you didnt reported the bugs that you found. In both cases, it seems to be your own fault.
With Coati we actually do the same thing. You can also feed the compile commands from the compilation database directly to clang tools - so the integration works quite well. Listing a projects headers is a different story. As CMake only provides you with the include directories you could either list all headers found in these directories or you could try to feed the compile commands to a clang-tool and use the preprocessor callbacks (http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html) to detect all the headers that are really included somewhere.
If you're looking for an alternative to valgrind, you might want to check out clang (http://clang.llvm.org/), which includes "sanitizers" that can detect memory errors, albeit using a different approach (compile-time instrumentation vs. run-time interpretation).
Recent versions of gcc also include sanitizers sourced from clang. I've written a short article discussing valgrind, clang and gcc that you can find here: http://btorpey.github.io/blog/2014/03/27/using-clangs-address-sanitizer/
> Seems to be a "work in progress"
Indeed, that's why I'm interested in hearing about people who have tested it.
FWIW, you can see the status here: http://clang.llvm.org/docs/MSVCCompatibility.html
It seems to be at a point where it should be fairly usable.