the 5 things I miss most in CLion
Here they are:
1. no working debugger (gcc 4.8.2 on Mint 17 Linux)
2. no working debugger (did I say that already?)
3. no sorting in overview window. Using the overview for navigation in a file with, say, 30 methods is useless. I end up using manual find all the time
4. no full qualification of members in overview for implementation file (cpp). If you have member functions from different classes, you cannot tell them apart
5. no indication about call location in call hierarchy view. You get the methods where the call occurrs, but if its a large method, its Ctrl-F again.
I am a paying customer, but you will hear me swearing at Clion several times per day as a former Eclipse/Java user. It would be so easy to implement some of these features. Getting a functional debugger may be a little harder, but there are people out there that can do it (look at QtCreator).
-Chris
Please sign in to leave a comment.
Please, find my comments below:
1. no working debugger (gcc 4.8.2 on Mint 17 Linux)
2. no working debugger (did I say that already?)
Could you provide more details in our tracker: https://youtrack.jetbrains.com/issues/CPP? Are you using a bundled debugger or some other one? Are you able to debug with that particular debugger without CLion? What error CLion shows? Describe, please, what you were doing and what did you get.
3. no sorting in overview window. Using the overview for navigation in a file with, say, 30 methods is useless. I end up using manual find all the time
What do you mean under 'overview window'?
By the way, most all the tool windows in CLion supports the quick search - just start typing what you are looking for:
Also there are Search by class name or symbol name, that can be helpful in terms of navigation.
4. no full qualification of members in overview for implementation file (cpp). If you have member functions from different classes, you cannot tell them apart
5. no indication about call location in call hierarchy view. You get the methods where the call occurrs, but if its a large method, its Ctrl-F again.
Could you please explain the use case? Anyway you could simply navigate to this call entry from the hierarchy view. Or you can change the scope of the search if you don't what to see all the callers from all classes in your prj. Will this help?
@debugger: I will not enter this into the tracker. You do it if you care. Thank you. The debugger I am talking about is the standard debugger that Clion uses on my platform. I have not reconfigured anything in Clion. QtCreator (the real IDE alongside which I am using Clion for editing purposes) does the same, and works well. I suggest you simply try your debugger integration on all common linux platforms, rather than writing fancy blog entries about the merits of debugging in Clions. I repeat: there is no debugger integration in Clion on Linux Mint 17 with gcc 4.8.2.
@overview window. What I call overview is what you call structure. Sorting is an essential feature if the file is large, particularily if, like me, you dont like having having to type CTRL-F and/or a search term. I want to navigate by looking. Typing is not an alternative
I have already entered most of the stuff into the tracker half a year ago. Nothing happened.
Below an example of the structure view alongside a CPP implementation file. Note that the file contains implementation code for 2 different classes, and standalone functions. However, the method signatures dont show to which class they belong, which makes navigation nearly impossible, particularily if classes have methods of the same name (and signature). Look how other IDEs handle this (QtCreator is a good example). for your convenience, I have included an image of the same view in QtCreator right below
Clion Structure view:
QtCreator outline view:
@no indication about call location. Also this is already in the tracker for a long time. I'll again illustrate with some screenshots. If you want this in the tracker, go ahead and transfer it.
Clion call hierarchy: note that all I see is that the method GStreamerMediaPlayer::handleSegmentEnd is called 2 times inside method GStreamerMediaPlayer::iSeek. When I click on iSeek, I am placed at the top of the method, which happens to be 500 lines long. There is no way to find the individual call locations, other than typing CTR-F and searching for the method name (going back to paper age tools, so to say)
In Eclipse: the individual call locations are highlighted. Clicking on the "callerTest" line in the Call Hierarchy view repeatedly takes me to the next call location.
christian@gsvitec.com wrote:
Of course it's your choice to not open an issue in the tracker. However, I will let you know that Clion debugging works fine on my Linux Mint 17.1 (Rebecca) with gcc 4.8.2.
good for you. What I was trying to transmit is 2 things:
1. debugger does not work on my machine, with standard OS install, where other IDEs have no problems. I have 25 years of working with debuggers and IDEs behind me, haven't ever seen one that has such problems, either
2. the phrase "put it in the tracker" (sometimes prefixed with "I dont understand") is so cheap. I have invested enough work already in making this post
I've asked about the tracker only because it's a more convenient way to report/follow problem's progress. But let's continue here, if it's more convenient to you. Could you please show us the Settings | Build, Execution, Deployment | Toolchains page screenshot? As you see, for some users debugger is working successfully on Linux Mint, so let us help and find what's the problem in your case. Hopefully we can solve it.
I agree that showing a class name in File Structure, as well as location in call hierarchy can be useful. Thanks for the explanation and use case. It's more clear now. I've uploaded your screenshots to the tracker.
heres the toolchains page:
and here the settings:
however, thinking about it twice, I would rather point to the specifics of my application than to the OS (or the above configuration, which is the least likely candidate) for a reason for the malfunction. The application is heavily multithreaded (GStreamer based) and fairly large. Maybe that is what throws Clion off the track.
I just tried it again: the first breakpoint was hit, however stepping was quite slow. After that, breakpoints were not honored any more (even though the code path went by them), and shortly after that the application was terminated, and a "command timeout" message appeared on the console. A second try let me debug for a few minutes with 2 breakpoints, but as soon as I let the application run for a few moments without hitting a breakpoint, it was again terminated. To repeat: the application runs without problems when started outside the debugger, and it can be debugged perfectly with my other IDE.
Beyond that: the impossibility to inspect the "this" pointer alone is a reason to not to use this debugger integration. After all, the "this" pointer (i.e., the state of the object that is executing) is the first and foremost thing you will want to look at
Thanks you very much for the detailed responce and screenshots. Looks like this is the same as: https://youtrack.jetbrains.com/issue/CPP-1403. We are loooking at this problem constantly and thinking about the solution. Still we can't reproduce the problem stable enough that makes it a bit difficult to fix. But it's in our short term roadmap for sure.
I can reproduce it anytime, it really shouldn't be hard for you, either. Just pull some complex open source project (e.g., a GStreamer-based Mediaplayer like Amarok), build it and debug. I am sure you'll hit it soon.
Sorry to say, but as long as these problems exist, I consider the debugger integration non-existent, the product as pre-beta, and the license I bought as a form of crowd-funding.
some more debugger experiences: even on a small (however multithreaded) project, hitting
the pause button causes program and debugger termination.
Christian,
does the problem still happen in CLion 1.0.2?
yes, thats what I am using
Experiencing exactly the same on OSX Yosemite, Clion 1.0.2, embedded gdb.
Application with 4 threads with 2 breakpoints set before running it: first breakpoint hit, second breakpoint hit, then clion becomes slow, doesn't display any of the local variables and breaks out of debugging with a timedout exception as in the following log excerpt.
Gdb process remains alive and must be manually terminated with a kill -9:
2015-05-20 16:45:57,035 [ 0] INFO - #com.intellij.idea.Main - ------------------------------------------------------ IDE STARTED -----------------
-------------------------------------
2015-05-20 16:45:57,118 [ 83] INFO - #com.intellij.idea.Main - IDE: CLion (build #CL-141.871.28, 18 May 2015 00:00)
2015-05-20 16:45:57,118 [ 83] INFO - #com.intellij.idea.Main - OS: Mac OS X (10.10.3, x86_64)
2015-05-20 16:45:57,118 [ 83] INFO - #com.intellij.idea.Main - JRE: 1.8.0_40-internal-b64 (JetBrains s.r.o)
2015-05-20 16:45:57,118 [ 83] INFO - #com.intellij.idea.Main - JVM: 25.40-b25 (OpenJDK 64-Bit Server VM)
2015-05-20 16:45:57,126 [ 91] INFO - #com.intellij.idea.Main - JVM Args: -Dfile.encoding=UTF-8 -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB=
50 -ea -Dsun.io.useCanonCaches=false -Djava.net.preferIPv4Stack=true -Xverify:none -Xbootclasspath/a:../lib/boot.jar -Xss2m -Xms256m -Xmx2000m -XX:MaxPermSize=3
50m -XX:ReservedCodeCacheSize=96m -XX:+UseCompressedOops -Djb.vmOptionsFile=/Applications/CLion.app/Contents/bin/clion.vmoptions -Didea.java.redist=custom-jdk-b
undled -Didea.home.path=/Applications/CLion.app/Contents -Didea.executable=clion -Didea.platform.prefix=CLion -Didea.paths.selector=clion10
2015-05-20 16:45:57,163 [ 128] INFO - #com.intellij.idea.Main - JNA library loaded (64-bit) in 36 ms
2015-05-20 16:45:57,174 [ 139] INFO - #com.intellij.idea.Main - initializing environment
.
.
.
2015-05-20 16:48:25,947 [ 148912] INFO - #com.jetbrains.cidr.cpp - Building: /Applications/CLion.app/Contents/bin/cmake/bin/cmake --build /Users/abigagli/Library/Caches/clion10/cmake/generated/f8cda5b3/f8cda5b3/Debug --target CP -- -j 4
2015-05-20 16:48:31,537 [ 154502] INFO - brains.cidr.execution.debugger - Debugger started
2015-05-20 16:49:27,736 [ 210701] WARN - brains.cidr.execution.debugger - Command timed out
com.jetbrains.cidr.execution.debugger.backend.DBTimedOutException: Command timed out
at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.executeCommand(GDBDriver.java:2194)
at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.executeCommand(GDBDriver.java:2183)
at com.jetbrains.cidr.execution.debugger.backend.gdb.GDBDriver.getVariables(GDBDriver.java:1272)
at com.jetbrains.cidr.execution.debugger.CidrStackFrame$3.run(CidrStackFrame.java:146)
at com.jetbrains.cidr.execution.debugger.CidrDebugProcess$MyCommandProcessor.consume(CidrDebugProcess.java:681)
at com.jetbrains.cidr.execution.debugger.CidrDebugProcess$MyCommandProcessor.consume(CidrDebugProcess.java:674)
at com.intellij.util.concurrency.QueueProcessor$2$1.run(QueueProcessor.java:110)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:107)
at com.intellij.util.concurrency.QueueProcessor$2.consume(QueueProcessor.java:104)
at com.intellij.util.concurrency.QueueProcessor$3$1.run(QueueProcessor.java:215)
at com.intellij.util.concurrency.QueueProcessor.runSafely(QueueProcessor.java:238)
at com.intellij.util.concurrency.QueueProcessor$3.run(QueueProcessor.java:212)
at com.intellij.openapi.application.impl.ApplicationImpl$8.run(ApplicationImpl.java:400)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jetbrains.ide.PooledThreadExecutor$1$1.run(PooledThreadExecutor.java:56)
It is year 2021, 6 years after the original post and (probably) "putting stuff in the tracker", the "Structure" view still can't show class names that methods belong to.
Dmt Avt I guess you've created the ticket CPP-25944, thanks. We'll check if can address it. Please if you see something you really want to get into CLion, go to the tracker and vote/create requests. It helps us prioritize things as we have limited resources.
Anastasia Kazakova - wow, you've got some serious cross-reference skills! :)
Interestingly, I tried searching the tracker and it looks like almost every other language supported by Jetbrains' IDEs had a similar ticket at some point about class names / namespaces / etc in Structure view.
I also feel like I might be missing something, maybe there is some alternative better way to navigate code /visualize code in large cpp files?
Dmt Avt There are actually several related issues, not fully duplicating each other. We'll try to address CPP-14224 in the next release. Let's see if we meet any common hidden issues there)