My problem is they've done a terrible job of making it scale up to large code bases. I work on the chromium tree -- CLion is completely useless on it. I have a dual 24-core xeon with 128GB of RAM and SSD and I've given it a wackload of memory, and it becomes completely inoperable, freezing all over the place.
Awful because I have such muscle memory for the JetBrains tools, and such a fondness for them.
I've gone back to using Emacs, but now with Eclim. I just couldn't get into VSCode.
The same IntelliJ can't compete with Eclipse on handling large scale projects.
CLion gets all the bad from IntelliJ .
On this point of view, Visual Studio 2019 has improved much more on a performance perspective and can still handle large scale projects.
So far, I prefer VS and QtCreator, which have also a free license too. I don't understand why CLion hasn't a Community Edition just like IntelliJ
For comparison: I work on something a magnitude smaller: https://github.com/CleverRaven/Cataclysm-DDA/ ... about ~360,000 LOC. CLion is pretty great for that.
I'm curious, have the VM garbage collection and allocation settings been adjusted? In other words, not just the memory limits but also switching to a different garbage collector and the GC control mechanisms adjusted? I've been reading up on the collectors. As far as I can tell the G1 collector is strongly indicated when you go above a 4 or 8GB heap. It then has a number of settings to adjust. I got really good and smooth performance out of it - few and short enough pauses that I was at peace with CLion - but seemingly I set the garbage collection to be "too continuous" which caused constant CPU usage when I used that profile in Pycharm on a Python project. Had to switch Pycharm back to a more, uh, classical GC setup. (I didn't reconfigure to rein it back in as it was unnecessary in that context. I'm sure it's possible.) The JVM and the GC are a rather interesting beast.
Just curious :)
CLion seems to struggle in particular with the presence of the out / generated source directories in Chromium. Even when asked not to index (exclude), the mere presence of the directory seems to bog it down.
The tool also needs to have a more flexible notion of source roots/include roots. I should be able to notify it that a directory is an #include root without having it try to index every .c file etc. underneath there. I should be able to select a group of directories and say "these have headers, but they're relative to path X, rather than themselves" etc.
It's even worse when adding in our internal repositories on top.
Also having a back and forth on a ticket about their support for compiler_commands.json; the one generated by ninja for Chromium simply doesn't work for me. Their person says it works for them, though. I don't know how. Right now I manually create a CMakeLists.txt with the directories I need.
But one thing that is discouraging about CLion is that even directories that you explicitly tell it not to index as source seem to still be looked at and indexed in some fashion, so a huge number of files just drags it down to a halt. My coworker was able to get decent performance by creating an empty directory and symlinking in only the directories he is working on. Simply having directories with large quantities of files is enough to drag it down.
It's very disappointing, as its my tool of choice. I feel handicapped without it.
At the moment that's my number one issue with CLion.
I really really hope they can fix this because at my work I'm trying to get CLion working. The Codebase is quite large and I have to turn inspections off or else input freezes and won't be responsive for up to 30 seconds. It's at times unusable.
When it works it's amazing but it still has some ways to go.
This statement is false. It's way too broad a claim to hold up. With all due respect I'd consider it harmfully incorrect.
Counterexample: I use CLion to work on Cataclysm: Dark Days Ahead. It's ~360,000 lines of pretty hairy C++. It's fine.
There may be conditions that make a stricter definition of the claim true. I don't know what those conditions would be. A link to Jetbrains' definition of the issue would be good.
Obviously there are (many) reasons for that. What you think is hairy might not be that hairy, in terms of parsing, to a compiler or static analyzer. If you're like most game developers, you use a simple subset of C++ that's C-like, which might explain why you're lucky.
Maybe the word 'tiny' was excessive. It might not affect someone's homework, but in my case it definitely does have performance issues for my relatively small one-man projects. I'm not bashing the tool; I'm a paying user too. But no one can deny the many performance issues, and indeed the focus of the next major release is precisely to start addressing those.
It's a question of for-all-x vs. there-exists-x. I acknowledge that there exist x'es that are small projects that make CLion hang.
I just wanted to make sure it was known that it's not all x'es. And that there exist y's that are large projects that don't hang. Cataclysm DDA is not a simple codebase :)
I also used AppCode extensively, that one actually behaved pretty well, overall.
So I am not really surprised by CLion's performance/stability issues. I have a long love/hate type thing around this with Jetbrains.
I hope they can get these things sorted out.
I often wonder if they wouldn't be better rewriting in a non-GC'd language. Rust or something.
I've run into this issue, also. It's not Visual Studio levels of constant freezing, but it definitely pauses once in a while. Seems to mostly occur when I'm developing on Windows, though.
EDIT: Wanted to add that it's definitely a regression. I've been using CLion without the pauses for years.
That being said, having worked on chromium myself I can attest to the size of the code base being such that pretty much every tool shits itself.
Also, what range of CPUs is your xeon on? Buying a current-gen consumer chip could yield a huge performance uplift if it's not from this gen.
You can generate a compiler_commands.json from ninja for these tools. I don't have the command handy -- but you can google for it.
They all perform quite admirably when compared to CLion, unfortunately.
That said, nothing stops a 32 bit VS building/debugging a 64 bit process. I was doing this 10+ years ago.
MS doesn't support running VS at all on Linux/Mac, and probably won't ever, or for a very long time out. Use VS Code, instead. Yes, you can target Linux/Mac from Windows running VS, but VS wont run on the same OS.
Is there some reason you would expect a 64-bit Visual Studio port before a Linux port?
The only advantage I can see to staying 32-bit is that Windows on ARM64 only has an x86 emulator, not x86_64.
I think there’s a 0% chance of a Linux port: VS Code is the cross-platform/future dev environment for Microsoft. But I wouldn’t be surprised to hear that a 64-bit Visual Studio is coming soon to Windows.
I think it's just the C# code editor process that's still only 32-bit.
Have you tried "rr" for instance?
That's the only reason why they don't do it.
That's my choice now. I need something that can navigate easily in a code base, I don't really like learning all the oddities around emacs and vim (even though I am a bit competent at vim) and I don't see what is so bad in using a mouse.
At first I thought annoying to have to manually edit the .includes and .config to add the includes and the macro I needed in our complex, hard-to-parse CMake based project, but now I really enjoy the freedom it gives.
Go, Rust, and even Java are all way better in this department - the tools are standard enough that you only have to make a choice if you are doing something less common. I would love a Dropwizard-like bundle that just gives me a pre-set-up config with everything I need to write a C++ CLI app or daemon.
Plus, you'll get a properly configured project with automatic dependency tracking.
I don't understand why CMake isn't used by default. (or Meson)
C++ in a nutshell :D
I don't know about endless. CMake is supported in almost every IDE toolchain these days, so there's your build generator. Compiler choice may as well be down to the platform you're developing on.
> I'm a professional C++ programmer, but setting up a development environment required so many choices
Me too, and it's about as complicated as Java or any other language I've worked in.
> I would love a Dropwizard-like bundle that just gives me a pre-set-up config with everything I need to write a C++ CLI app or daemon.
Visual Studio, CLion, QtCreator all do this. They'll even add your main.cpp to your CMakeLists.txt for you.
Now, if we're talking dependency management on Windows, I'm all about griping there. vcpkg is not quite the drop-in solution Microsoft makes it out to be.
That is currently my number one grievance, 2nd is lack of tooling that matches C++ for Windows/.NET developers.
Yes we do, all the time on Windows, as .lib, .dll or plain COM (now UWP).
Dynamic libraries and COM are an OS ABI, as such compiler agnostic.
And for compiler specific versions, well known libraries do bundle pre-compiled libraries to latest three versions of e.g. VC++, ICC and C++ Builder.
Watching the same crates being compiled over and over across projects isnt' fun. And the workaround with a common workspace only kind of helps.
IDE is awesome.
Debugging tools are rawsome.
Build tools can be... Well you've got choices.
Workspace setup is easy
Yep, I think this is my main gripe with C++ on Windows right now. vcpkg is meant to work with CMake or Visual Studio, but you still have to manually tell it where your toolchain file is - which means it's additional work for the rest of your team. In Visual Studio, it's seamless.
On Windows, it's gotten to the point where I try to build dependencies as part of the build chain and hope the tooling is smart enough to not rebuild them a million times. Would be really nice if Windows 10X (or whatever) could come with a package manager or integrate vcpkg.
At first I thought you meant this obscure little language: https://en.wikipedia.org/wiki/C%2B%2B/CLI
Sadly thanks to their management mistakes and the trend of wanting everything for free, only a select few know how it actually feels in practice.
C++/CX + XAML came close to it, but got replaced by C++/WinRT, which is still catching up to C++/CX tooling.
As a cross-platform C++ Builder replacement, I have been using wxFormBuilder and wxWidgets in the past. There are some manual steps, but it let's you build a GUI quickly, hook up event handlers and then write implementation code in a derived class, so that stuff generated by GUI editor doesn't rewrite your code.
Thanks for the wxFormBuilder and wxWidgets reference, I always saw them as a MFC wannabe and don't have any experience with them.
There are third-party components (for example the open-source Qwt ), but probably fewer than you find for VCL :)
Qwt is not the same as the commercial support from component oriented companies, including the UI/UX care of some components.
The forum can be a bit quiet sometimes but you'll likely get a response. Bug reports and stackoverflow questions also might get some help.
Much preferrable to me than the MFC stuff I had to use at work for years. wxWidgets is actually nice to use and can have bind/connect instead of macros for event handling, as well as CallAfter(...) for easy firing of events from background threads etc.
wxFormBuilder is nicer than Qt Designer but they are both essentially based on the same core idea of designing a dialog visually and then wiring everything by hand (code).
In another comment above i go into more details, but i guess you already know most of that :-P.
It is interesting that Qt as an API feels more polished, but the designer is barebones whereas wxWidgets as an API is a bit more clunky but the designer is much more polished (wxFormBuilder is the most common one, though there is also wxSmith which is a commercial designer that is supposedly better - though i never used it myself). In comparison at least, wxFormBuilder does have its own warts.
Though you use both in essentially the same way you'd use MFC with Dialog Resource Editor in Windows 3.0 - just with a bit more features and an easier API. But the core ideas behind the workflow remains the same.
In C++ Builder, even the original version from 1996, is much easier to work with because you design the UI and assign the handlers in a visual way. You are also working with live objects instead of stand-ins (when you create a control or other -nonvisual- component, you compile it into a DLL and the IDE loads and creates an instance of that DLL that you are editing through the rich RTTI it has - this relies on extensions to Delphi/C#-like C++ language). Your form is serialized as a resource inside the executable and deserialized when it is instantiated.
The IDE uses RTTI (remember that this is richer than C++'s regular RTTI) to manipulate the objects, create event handlers (just double click a button or click on a menu and the IDE will create the methods for you - update the header file, write the method body, associate the handler with the event, etc). When you drop a component in a form, it will automatically add any necessary header file #include's at your code (later versions of C++ Builder will also automatically add any necessary includes if you use any function the IDE knows of - like a stdlib function or a function from another file).
In general the IDE will do most of the work for you, you focus on the "meat" of your applications and any busywork/pumbling/boilerplate is handled by the IDE.
I have heard that QtCreator does provide something similar, but from the very little i've used it, it looks that these "whispers" come from people who haven't really used (or understood) C++ Builder as it feels more like how Visual Studio integrated the Resource Editor that back in the day used to be a standalone application inside its UI but still acts as if it was a separate application, than a really interwoven integration like VCL (C++ Builder/Delphi's framework) and C++ Builder have. But truth be told, i have used QtCreator very little to judge properly - i'll need to do a more in-depth experiment (though again, i never had to do that with C++ Builder or Delphi).
(as a sidenote, in general i have a bias against anyone that only focuses on the form designer aspect of C++ Builder/Delphi when comparing it to some other supposedly similar tool as the form builder is only the tip of the iceberg that only works as well because of the rest of the iceberg beneath it)
Now if modern C++ Builder wasn't such an overpriced DRM-infested PITA it'd be nice. Though like with Delphi, if $whoeverownsittoday decided to release a cheap (similar to their mid-90s prices) DRM-free version (especially on a box, though i'm ok with an installer or ISO i can keep on my own media) i'd (most likely) buy it instantly.
Though their community editions are free (but with a bad license that says you can use it only if you make up $5k annually and still needs activation that can go away at any time they feel like) so if you just want to play around they're fine.
That said, great tool.
I highly recommend rtags (even if it's not stricly LSP)
- compilers: Intel compiler
- IDEs: SlickEdit, GNOME Builder, KDevelop, Eclipse, Netbeans
- Build systems: Bazel, Meson
- Static analysis: Klocwork, Coverity Scan
- Fuzzer: American Fuzzy Lop
- Memory debuggers: Valgrind, AddressSanitizer
- Profilers: DTrace, VTune, Vampir
- Documentation: Doxygen
- Debugging (and more): edb, x64dbg
- Reverse engineering: Radare, Cutter, IDA, Ghidra
And rmsbolt (compiler explorer for emacs)...
Also MXE - cross-compile environment: https://mxe.cc/
- cppcheck is sometimes updated also
- clazy : https://github.com/KDE/clazy
It does a more deep analysis into the control flow, whereas clang-tidy does (mostly?) comparatively simpler checks on the AST.
Besides that, most bugs found by static analysis are platform independent so you should be able to use any static analyzer you get your hands on as long as your code is cross-platform.
Plus VC++ debug builds do bounds checking, even for .
The OP failed to mention there's a freeware edition.
> It provides the Microsoft Foundation Class (MFC) library which gives access to the Win32 APIs.
Last time I used MFC was around 2003. Last time I used Win32 APIs was today. MFC doesn't give access to anything besides MFC.
So covers most people, but could be a pain if you’re in a big company that otherwise doesn’t do much engineering.
"Give me 15 minutes and I'll change your opinion on GDB" was one of the most life changing videos I've watched. It's on youtube or text version here: https://undo.io/resources/cppcon-2015-greg-law-give-me-15-mi...
I know on the older spectrum of the audience here, but that is an effective workflow for me. But, as a nearly 40 yr old, the command-line is very natural to me. I actually get irritated when I have reach for a mouse to complete an action.
Maybe I'm too young (28), but how I read your and the parent's comment is "My workflow has been working fine, why improve it?" which sounds weird to me. There's always room for improvement.
It would be fairly quick to put something in your vimrc to pop open a small split on the side, run a build command, and show an output. You could also probably pop open a terminal (new vim has the :term command) and maybe script that? If not cmake, it shouldn't be too difficult to replace cmake with something else. I've always found I can get better results from vim that more exactly what I want, but I've got to kind of want it and be willing to write some script to do it. The results are better, but there's more up-front investment.
I have seen a few gdb plugins but at least my experience is that they are extremely wanting.
Do people just not use debuggers around here?
Frankly a lot of times I know where I need to investigate my in my code. But it is annoying to switch to vim, find the file and line number, go back to gdb then do `b my/file/structure/is/long:1825`. That gets hectic in large projects.
edit: My current setup I used vim+zsh+tmux. So I don't mind having gdb in a new pane that isn't a vim pane, but I just want colors and some of the basic features. I don't need everything that the IDEs do, just the basics.
Basically hold down the 'Alt' and 'Control' keys and then press 'j'.
If you don't want to have to toggle it every time you launch gdb, then you can create a ~/.inputrc file with the following contents:
set editing-mode vi
For colors - GDB 8.3 added source code syntax highlighting, but it was just released this year and may not be the version on your Linux distribution.
Regarding vim, have you tried the termdebug plugin that ships with vim?
I haven't used it, but it might meet your needs.
Works pretty great!
Really it's a great library.
I have been use to package managers from other languages.
The 'case sensitivity' bug was created in 2017, is still open. I think it's connected to a case sensitivity flag in filesystem which is used in the system. So, since 99% of Linux systems use case-sensitive fs, it's not usable on Linux.
Another example is a dependency on a package called ‘jsonformoderncpp’, which I use by ‘#include “nlohmann/blah.h”’ - the package name is arbitrary, even if you have to refer to the dependence using the package name in your build system rather than the canonical name I don’t see how that would be an issue (even with FindPackage or whatever you use in CMake)?
still looking for some online c++11 course these days, udemy had none that looking good.