views:

751

answers:

6

Hi,

Here a code to demonstrate an annoying problem:

class A {
public:
    A():
     m_b(1),
     m_a(2)
     {}
private:
    int m_a;
    int m_b;
};

This is an output on Console view:

make all 
Building file: ../test.cpp
Invoking: GCC C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"test.d" -MT"test.d" -o"test.o" "../test.cpp"
../test.cpp: In constructor 'A::A()':
../test.cpp:9: warning: 'A::m_b' will be initialized after
../test.cpp:8: warning:   'int A::m_a'
../test.cpp:3: warning:   when initialized here
Finished building: ../test.cpp

The problem is that in Problems view I'll see 3 separate warnings (lines in output containing warning word), while indeed there're 4 lines in output describing a one problem.

Is there're something I'm missing?

Additional question. Maybe it's in Eclipse spirit, but is there a way to make Console view clickable as most IDE does (e.g. Visual Studio, emacs ...)

Thanks Dima

+5  A: 

There are multiple lines in the warning because each line refers to a different line of code. The problem being warned about is what's happening to the m_b that's declared on line 9, it's because of the fact that m_a on line 8 is declared before m_b is, but it's caused by what's happening in your initializer list, which starts on line 3.

With gcc it's possible for warnings that aren't related to each other to appear one after the other (i.e., a bunch of unrelated stuff all wrong in main), so Eclipse can't tell from the output whether those are separate warnings or all related to the same issue.

Meredith L. Patterson
But the lines indeed are related. Each individual warning line doesn't give a clue what is the problem. For example line "../test.cpp:3: warning: when initialized here" - itself the line is non sense, since it's out of context. Also line "../test.cpp: In constructor 'A::A()':" which is part of the problem doesn't appear in "Problems" view at all
dimba
I also think that the CDT error parser could be more clever and see the relation (extracted by the indention of the warning messages after "warning:"). But it may also be a problem to visualize those related errors in the Eclipse IDE (which is originally designed to develop Java programs that may not have such related errors [I don't know]). I also find it hard to track those related errors in Eclipse...
rstevens
idimba, perhaps my wording above was unclear. These three lines, which appear sequentially, are related; it is *also* possible for unrelated warnings to appear sequentially, so Eclipse can't tell the difference, and assumes they are separate warnings.As for the "In constructor..." line not appearing, the error parser probably isn't looking for that pattern.
Meredith L. Patterson
I understand that parser works as designed and that lines can be related or not related. The problem is in concept. The IDE gives us a tool to see errors in more convenient way, to sort them, etc. The problem is that coupling of gcc with the feature doesn't work well. So the question is how we should work with this "broken" feature - compilation output is not clickable, Problems view is sometimes messy.
dimba
This is another example of CDT being heavily GCC-biased. Since GCC present errors as list of location+message pairs, CDT assumes that all other compilers behave like that. In the GCC case there is no possibility of being any smarter than just presenting all errors in a linear list, but other compilers with the possibility of actually relating errors in a meaningful way have no way of presenting that to the user.
JesperE
So, if we agree that there's a problem, how you overcome it? Maybe there's way to make Console view clickable, or make it possible that records/lines in Problems view can present several surrounding lines, or jump from Problems view line to corresponding line in Console view?
dimba
@JesperE: If you look at the output in the OP you see that some of the messages are indented after the "warning:". This seems to be the GCC way to tell us that the errors are related. This could easily be recognized by the CDT error parser!
rstevens
@idimba: I personally never use the problems view (because it is not clickable and cyrptic) but I find the "in-file" error marking much more useful. This is my main tool and only if this does not help (because of related errors) I go to the console view.
rstevens
A: 

I understand that eclipse can't tell if the compiler errors are related or not, but why does it have to sort them alphabetically? If it just kept it in the same order that they were found by the compiler then it would be fine:)

Tom
This is not even close to an answer. Remember that StackOverflow (and its whole family) does not work like a forum. If you have a question post a question, if you like to comment upon a question add a comment to the question. Answers are for actual answers. (I think this blurb is most suited as a comment)
NomeN
And to answer the question in there, you can sort the problems on its location in stead of alphabetically by clicking the 'location' header.(You'll see the arrow move to this header, clicking again will invert the sort)
NomeN
Sorry just saw your answer. I looked for the add comment button on the previous answer and couldn't see it. Thanks for you response, I did find the sorting options in the end and it helps a lot but still effects the sorting within a file.
Tom
A: 

Fields get initialised in the order they are declared in the class. The compiler is helping you by telling you that the constructor is initialising then in the wrong order. This can cause strange errors, if the order of initialization matters.

David Allan Finch
The question wasn't "Why am I getting this compiler warning?" The question was "Why is Eclipse showing me the compiler warning in this particular way?"
MatrixFrog
A: 

Thanks David, but I think you may have misunderstood me. I was referring to the fact that the 'Problems' view in eclipse sorts the compiler errors alphabetically by default. As Dima was saying this causes problem with gcc error messages which are spread over two lines such as

1) error: 'such and such' is protected

2) within this context

as all the 'within this context' lines get separated from the variable they are referring to.

HOWEVER, I just found the option to change the sorting order of the compiler errors, the little downwards pointing triangle at the top of the view (only just worked out this is where you set the options for the view as I am new to eclipse). If you play around with this it will help but will still not be able stop errors in the same file from being jumbled (why isn't there an option just leave them as they were?)

Cheers, Tom

Tom
I've done a little more research, and you are right, sorting on location removes the sort on file, and sorting on file garbles the location sort...stupid. However, in the preferences of the view there is a field "Creation Time" that is hidden by default, make this visible and sort on this field will sort the problems by the time they were encountered during compilation and thus also per file. One caveat, problems from older compilations may not be listed with the problems from newer compilations. But this won't be a problem if you work neatly and remove all problems before recompiling.
NomeN
@NomeN if that is an answer to the original question (which it sounds like it is) then post it as an answer, not a comment.
MatrixFrog
+1  A: 

According to the last comment on this bug report you should be able to click on the console view to jump to code in CDT 7.0.

It might be worth checking out the milestone builds to see if the grouping of error messages is better. If not raising a bug to attempt to group related messages wiuldne a good idea.

Richard Miskin
I'll check it. I use CDT 6.x while there're already exists release candidate of CDT 7.x, as u mentioned.
dimba
A: 

I suppose it's because CDT is still a bit immature and probably it can't parse g++ output in the best possible way. Line ../test.cpp: In constructor 'A::A()': doesn't contain a line number so CDT can't place error marker in test.cpp editor and probably this issue affects Problems view.

There are more troubles with Problems view. For example you can delete only visible errors from the view, so if you'll get more than default 100 items you have to sequentially delete it hundred by hundred. Also errors are not automatically removed after clean, if error occured inside independent header file. Just be indulgent, they are improving CDT from release to release.

Additional question - What do you mean by "to make Console view clickable"?

doc
There's a "view" calls Console, where you see output of make file.
dimba
But what does mean "clickable"?
doc