10 ms·

I recently went ahead and purchased theyr3 full product line, because I figured there are several I would end up wanting to use and it was just cheaper that way

I recently went ahead and purchased theyr3 full product line, because I figured there are several I would end up wanting to use and it was just cheaper that way. The reason I bought it though, was specifically for CLion. I figured having a full featured IDE would make it much easier to browse and understand large C or C++ projects, but sadly it seems to only support CMake projects.

FpUser 7y ago
I also tried their CLion and was somewhat disappointed. Slow in places, sometime stalls, bugs here and there. Ended up using CodeLite and Qt designer
- big_chungus 7y ago
  I have used CLion, and would say JetBrains did an excellent job with making a C IDE. The issue is that C is not much of an "IDE language"; my experience has always been to just use a text editor (vim or vscode), and it seems to be the same for most C devs I know. Looking at newer languages, they seem to pair closely with IDEs; I'm still not a big IDE guy, but most use them for python, java, etc. I'm not enough of an expert to quantify the reasons behind this, but I think it's hard to build a stand-out good IDE for a language with which IDEs often aren't used or are just used as glorified text editors.
  - madhadron 7y ago
    > The issue is that C is not much of an "IDE language" This isn't an issue with the language so much as it is with the build systems, includes, library paths, and tooling. Compare to Java (set the classpath to exactly the artifacts you want and IntelliJ uses its own build system unless you explicitly tell it otherwise), Python (set up a virtualenv with exactly what you want and PyCharm handles its own builds, insofar as Python builds). In C on Windows and Unix you have to figure out how to find and address includes and libraries in a cross platform way. CMake is probably the best bet. If they were in the position of, say, TurboC back in DOS days where they provided stdlib and you added everything else you wanted, they could do as good a job as for Java.
    - dehrmann 7y ago
      > This isn't an issue with the language so much as it is with the build systems, includes, library paths, and tooling. Exactly. #include "header.h". But where is it? Depends on compiler flags. Java has the same problem, but luckily has only ~2 build systems that are well-supported by IDEs.
      - madhadron 7y ago
        Java doesn't really have the same problem. It has the classpath, and that's it, across all platforms. Nor do the big IDEs use ant, maven, or gradle as their internal build system, though most of them support controlling them.
- dagmx 7y ago
  If you haven't tried it recently, I'd give it another try. They've had significant speed improvements with 2019.3, whereas 2019.2 was very slow
  - stargrazer 7y ago
    Yeah, there was some improvement. But the issue for me is building a C++ app which requires Linux headers, Boost headers, and Wt, CLion seems to wants to take four cpu's for a hot trip. Even with a bunch of the code helpers turned off. VSCode with CMake, clangd, and C++ code filter seems to work for the little I've used it so far. Havn't quite taken the leap of faith in VIM, clangd to see if that is suitable.
- w0utert 7y ago
  One thing I've found with CLion is that you really, really want to edit the JVM settings for the IDE. By default it starts with a 2GB memory limit for the JVM, which even for small projects will severely drag down performance, e.g. my MBP would run very hot, spin the fans and the IDE would get very laggy. Increasing the JVM settings to allocate 8GB completely solved this.
  - ncmncm 7y ago
    An editor that needs (even) 2GB to be blindingly fast is a failure.
    - winrid 7y ago
      That's fine, because it's an IDE and a new dev machine tends to have more than 16gb of ram.
      - ncmncm 7y ago
        Some machines, and some people, have other uses for RAM than the text editor.
      - FpUser 7y ago
        No it is not fine. The only impression I get from glorified notepads consuming gigabytes of RAM is the ever increasing desire to send them to /dev/null where they belong. My opinion of course
    - w0utert 7y ago
      It's not the editor part that uses all this RAM I suppose, but the code parser and indexer that by default includes scanning & interpreting all your dependencies (system headers, boost, other third-party frameworks). There is a clang process that has the full AST for all of your code + its dependencies in the background all the time, so you can get search, index, autocomplete, syntax check, refactor etc. that actually works compared to the half-baked solutions you get with VIM plugins (and I've tried all of them). I guess you can switch all of that off of course, but that's what makes it an IDE and not an editor. I think the memory tradeoff is perfectly fine for this kind of application.
- ncmncm 7y ago
  There is absolutely no excuse for any editing product to be perceptibly slow. A single ordinary, commodity CPU core can sort 100M of totally random ints in 5 seconds. The amount of work any editor legitimately needs to do to provide you editing support is trivial, in comparison, by any measure.
fctorial 7y ago
This minimal cmake file should setup the ide for any project, the build will have to be ran externally though. You can setup the ide to debug external binaries as well, as long as it has source information (was built from the current project sources with debug info). cmake_minimum_required(VERSION 3.0) project(prog) include_directories(.) file(GLOB_RECURSE sources *.h *.cpp *.c *.hpp) add_executable(prog main.c) variables might have to be tweaked a bit.
ausjke 7y ago
I purchased the whole product line as I think Jetbrain's product is excellent, the only complain from me is this CLion Cmake requirement, could be more versatile, and supports non-Cmake projects(or even single files without makefiles), even Geany does better than CLion as far as c/c++ is concerned. Please make CLion better for C/C++

FpUser 7y ago

I also tried their CLion and was somewhat disappointed. Slow in places, sometime stalls, bugs here and there. Ended up using CodeLite and Qt designer

big_chungus 7y ago
I have used CLion, and would say JetBrains did an excellent job with making a C IDE. The issue is that C is not much of an "IDE language"; my experience has always been to just use a text editor (vim or vscode), and it seems to be the same for most C devs I know. Looking at newer languages, they seem to pair closely with IDEs; I'm still not a big IDE guy, but most use them for python, java, etc. I'm not enough of an expert to quantify the reasons behind this, but I think it's hard to build a stand-out good IDE for a language with which IDEs often aren't used or are just used as glorified text editors.
- madhadron 7y ago
  > The issue is that C is not much of an "IDE language" This isn't an issue with the language so much as it is with the build systems, includes, library paths, and tooling. Compare to Java (set the classpath to exactly the artifacts you want and IntelliJ uses its own build system unless you explicitly tell it otherwise), Python (set up a virtualenv with exactly what you want and PyCharm handles its own builds, insofar as Python builds). In C on Windows and Unix you have to figure out how to find and address includes and libraries in a cross platform way. CMake is probably the best bet. If they were in the position of, say, TurboC back in DOS days where they provided stdlib and you added everything else you wanted, they could do as good a job as for Java.
  - dehrmann 7y ago
    > This isn't an issue with the language so much as it is with the build systems, includes, library paths, and tooling. Exactly. #include "header.h". But where is it? Depends on compiler flags. Java has the same problem, but luckily has only ~2 build systems that are well-supported by IDEs.
    - madhadron 7y ago
      Java doesn't really have the same problem. It has the classpath, and that's it, across all platforms. Nor do the big IDEs use ant, maven, or gradle as their internal build system, though most of them support controlling them.
dagmx 7y ago
If you haven't tried it recently, I'd give it another try. They've had significant speed improvements with 2019.3, whereas 2019.2 was very slow
- stargrazer 7y ago
  Yeah, there was some improvement. But the issue for me is building a C++ app which requires Linux headers, Boost headers, and Wt, CLion seems to wants to take four cpu's for a hot trip. Even with a bunch of the code helpers turned off. VSCode with CMake, clangd, and C++ code filter seems to work for the little I've used it so far. Havn't quite taken the leap of faith in VIM, clangd to see if that is suitable.
w0utert 7y ago
One thing I've found with CLion is that you really, really want to edit the JVM settings for the IDE. By default it starts with a 2GB memory limit for the JVM, which even for small projects will severely drag down performance, e.g. my MBP would run very hot, spin the fans and the IDE would get very laggy. Increasing the JVM settings to allocate 8GB completely solved this.
- ncmncm 7y ago
  An editor that needs (even) 2GB to be blindingly fast is a failure.
  - winrid 7y ago
    That's fine, because it's an IDE and a new dev machine tends to have more than 16gb of ram.
    - ncmncm 7y ago
      Some machines, and some people, have other uses for RAM than the text editor.
    - FpUser 7y ago
      No it is not fine. The only impression I get from glorified notepads consuming gigabytes of RAM is the ever increasing desire to send them to /dev/null where they belong. My opinion of course
  - w0utert 7y ago
    It's not the editor part that uses all this RAM I suppose, but the code parser and indexer that by default includes scanning & interpreting all your dependencies (system headers, boost, other third-party frameworks). There is a clang process that has the full AST for all of your code + its dependencies in the background all the time, so you can get search, index, autocomplete, syntax check, refactor etc. that actually works compared to the half-baked solutions you get with VIM plugins (and I've tried all of them). I guess you can switch all of that off of course, but that's what makes it an IDE and not an editor. I think the memory tradeoff is perfectly fine for this kind of application.
ncmncm 7y ago
There is absolutely no excuse for any editing product to be perceptibly slow. A single ordinary, commodity CPU core can sort 100M of totally random ints in 5 seconds. The amount of work any editor legitimately needs to do to provide you editing support is trivial, in comparison, by any measure.

fctorial 7y ago

This minimal cmake file should setup the ide for any project, the build will have to be ran externally though. You can setup the ide to debug external binaries as well, as long as it has source information (was built from the current project sources with debug info). cmake_minimum_required(VERSION 3.0) project(prog) include_directories(.) file(GLOB_RECURSE sources *.h *.cpp *.c *.hpp) add_executable(prog main.c) variables might have to be tweaked a bit.

ausjke 7y ago

I purchased the whole product line as I think Jetbrain's product is excellent, the only complain from me is this CLion Cmake requirement, could be more versatile, and supports non-Cmake projects(or even single files without makefiles), even Geany does better than CLion as far as c/c++ is concerned. Please make CLion better for C/C++