«

Le 15/09/11 12:44, Rui Maciel a écrit :
>>
>> Developing a reasonable debugger like MSVC's one requires a big and
>> dedicated team that is paid to do that. Gdb development is a proof
>> that free tools can only reach certain levels of complexity before
>> it is impossible to do them in their free time.
>
> I don't believe this is the case. GDB actually works quite well if it's
> used in programs written in C. According to my experience, and as far as I
> can remember, the only cases where GDB fails to be very useful with C++
> programs are the ones where STL containers or overloaded operators are
> involved.
>

Excuse me but unless you are programming a toy system in C++, STL and
overloaded operators are just everywhere... I just can't even imagine
a complex C++ program without using the STL/overloaded
functions/operators what have you.

>
>> But the poligtics of linux require that development tools should be
>> free ( no money for anybody in it). The consequence is obvious for all
>> to see: You get what you pay for.
>
> This isn't true. If a specific tool is useful enough then, no matter what
> OS they use and even what political views they have, people will gladly pay
> for it.

Not in linux. The only alternative to gdb is TotalView, and it is
expensive since there are few customers.

Eclipse was done by a team financed by IBM. And you see the result, it
is better than most IDEs in Linux.

On Thu, 2011-09-15, jacob navia wrote:
> Le 15/09/11 11:08, Rui Maciel a écrit :
>> Jorgen Grahn wrote:
>>
>>> You might want to know that many C++ users rarely or never use a
>>> traditional debugger[1]. I'm one of them -- I used gdb for a while last
>>> Friday, but the time before that was many years ago.
>>>
>>> On Unix, you need to be able to debug core dumps but when dealing with
>>> running programs it's more important to know tools like
>>> - the compiler
>>> - valgrind
>>> - strace and ltrace,
>>> and knowing how to write unit tests. All of that is IMHO more
>>> important than live debugging.
>>
>> It can be said that one of the reasons why "many C++ users" tend not to use
>> a debugger in linux is that gdb doesn't work well with C++, and once we
>> ignore gdb there isn't much left to consider.
>
> Exactly.

That may be part of it, yes. I don't know for sure though. Noone has
pressured me to use a debugger, and part of the reason *might* be that
there's no single monster debugger for my environments.

But in my experience this isn't C++-specific. I don't see many C
programmers using debuggers either.

> One thing he forgets too is that there is a completely forgotten class
> of developers called "maintenance programmers".

I *am* a maintenance programmer.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Thu, 2011-09-15, Rui Maciel wrote:
> Jorgen Grahn wrote:
>
>> Do you have a point of some kind? Let me also repeat the part you
>> neglected to quote:
>>
>> [1] Not trying to start the debugger-versus-no-debugger war again. Just
>> stating a fact. And no, I don't have any idea how many "many" is.
>
> Actually, you haven't expressed a fact, only an opinion. Unless you can
> actually demonstrate in an objective way that " many C++ users rarely or
> never use a traditional debugger" and that your definition of "many" refers
> to a relevant part of the C++ community, you can't claim it's a relevant
> statement with any relation to reality, let alone a fact.

Well, it's my opinion that it is a fact. This isn't Wikipedia ...
And again: no, I don't have any idea how many "many" is.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

In article <4e71c76b$0$24022$>,
Rui Maciel <> wrote:
>none wrote:
>
>> I believe the point that Jorgen was trying to make is that:
>>
>> - You should use compilers capabilities to help verify your code.
>> - You should write unit tests and try to have high code coverage.
>> With good unit test, a lot less debugging is required.
>> - You should use tools like valgrind on your unit test and on your
>> full program. Valgrind will often detect errors in one short run
>> that will only be noticed after a "long time" in the field.
>
>Unit tests help run some tests to check if components work as expected and
>valgrind helps with memory leaks. By employing those, a programmer wouldn't
>need a debug if all the problems that a programmer could ever stumble on
>were only due to a combination of components failing preconceived tests and
>memory leaks. This isn't true.

Euh... Not sure of your point. Obviously, unit tests will only test
what they test. If some things are not tested, then they haven't been
tested and you will need to diagnosed the error in a different way.
Using a debugger is a possible way.

However, the fact that you will never be able to cover 100% of
possible failure scenarios with unit test does not change that good
use of unit tests will help detecting errors early and reducing time
and effort required to do step-by-step debugging.

Note: I never claimed that unit tests + valgrind finds *all* bugs.

>Sometimes a program simply behaves
>unexpectedly, and a programmer is therefore faced with the need to run a
>program step by step, evaluating the outcome of each step, to be able to
>understand what is happening and why is it happening.

Yes, agree sometimes you need to uswe the debugger. In fact, I have
sometimes even run my unit tests in a debugger.

> Unit checks don't do this, neither does valgrind.

Unit tests don't do what a debugger do. They are a different tool.

>Without a debugger, all you end up having is a
>nasty cycle of sprinkling your code with cout/cerr, recompiling it and
>running the program to analyze the output of your set of cout/cerr. And
>this is a less than adequate solution to a frequent problem.

I disagree with your use of pejorative qualifier here. The so-called
"printf" debugging can often be much more efficient than the use of a
debugger. It depends.

Generally, I would not put raw cout but use a macro that can be turned
on and off but regardless this is far from an invalid technique.

In article <j4tan3$so0$>,
jacob navia <> wrote:
>
>Eclipse was done by a team financed by IBM. And you see the result, it
>is better than most IDEs in Linux.

Pet-peeve but I am still unsure if Eclipse is better than something
like kdevelop or Code::Block. As far as I know, only Eclipse swallow
all of the memory available on your system, then attempt to put
a phone order to a local computer shop for more RAM and then crash if
it fails to be able to mail order more and more and more and more
RAM....

On 09/19/11 09:53 PM, none Yannick Tremblay wrote:
> In article<j4tan3$so0$>,
> jacob navia<> wrote:
>>
>> Eclipse was done by a team financed by IBM. And you see the result, it
>> is better than most IDEs in Linux.
>
> Pet-peeve but I am still unsure if Eclipse is better than something
> like kdevelop or Code::Block. As far as I know, only Eclipse swallow
> all of the memory available on your system, then attempt to put
> a phone order to a local computer shop for more RAM and then crash if
> it fails to be able to mail order more and more and more and more
> RAM....

That's a built in feature of the JVM, not Eclipse!

--
Ian Collins

On Mon, 2011-09-19, yatremblay@bel1lin202.(none) (Yannick Tremblay) wrote:
> In article <4e71c76b$0$24022$>,
> Rui Maciel <> wrote:
....
>>Without a debugger, all you end up having is a
>>nasty cycle of sprinkling your code with cout/cerr, recompiling it and
>>running the program to analyze the output of your set of cout/cerr. And
>>this is a less than adequate solution to a frequent problem.
>
> I disagree with your use of pejorative qualifier here. The so-called
> "printf" debugging can often be much more efficient than the use of a
> debugger. It depends.
>
> Generally, I would not put raw cout but use a macro that can be turned
> on and off but regardless this is far from an invalid technique.

You can always find someone who disagrees in new and interesting ways...

I too see the merit in printf debugging, and happily use it.

But if your "can be turned on and off" implies trace messages which is
part of the code base, then I'm not so sure it's generally a good idea.

Trace messages everywhere makes the code harder to read, and when you
do need them, chances are the ones you need don't exist, and the ones
that *are* there are so many that you can't enable them without
drowning in text.

I'd rather have logging (to Unix syslog) of a few well-defined events,
and insert specific trace messages only during debugging.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Mon, 2011-09-19, Ian Collins wrote:
> On 09/19/11 09:53 PM, none Yannick Tremblay wrote:
>> In article<j4tan3$so0$>,
>> jacob navia<> wrote:
>>>
>>> Eclipse was done by a team financed by IBM. And you see the result, it
>>> is better than most IDEs in Linux.
>>
>> Pet-peeve but I am still unsure if Eclipse is better than something
>> like kdevelop or Code::Block. As far as I know, only Eclipse swallow
>> all of the memory available on your system, then attempt to put
>> a phone order to a local computer shop for more RAM and then crash if
>> it fails to be able to mail order more and more and more and more
>> RAM....
>
> That's a built in feature of the JVM, not Eclipse!

Not sure about that -- Eclipse seems to be extremely hungry even for a
Java application.

(Went to a demo a few years ago. The guy gave figures; he said it was
common to have Eclipse eating a gigabyte or two of virtual memory.
But he also felt it was worth it. IMHO that's a valid view, even though
I'm happy enough with Emacs myself.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

In article <slrnj7e8vf.1bg.grahn+>,
Jorgen Grahn <grahn+> wrote:
>On Mon, 2011-09-19, Ian Collins wrote:
>> On 09/19/11 09:53 PM, none Yannick Tremblay wrote:
>>> In article<j4tan3$so0$>,
>>> jacob navia<> wrote:
>>>>
>>>> Eclipse was done by a team financed by IBM. And you see the result, it
>>>> is better than most IDEs in Linux.
>>>
>>> Pet-peeve but I am still unsure if Eclipse is better than something
>>> like kdevelop or Code::Block. As far as I know, only Eclipse swallow
>>> all of the memory available on your system, then attempt to put
>>> a phone order to a local computer shop for more RAM and then crash if
>>> it fails to be able to mail order more and more and more and more
>>> RAM....
>>
>> That's a built in feature of the JVM, not Eclipse!
>
>Not sure about that -- Eclipse seems to be extremely hungry even for a
>Java application.
>
>(Went to a demo a few years ago. The guy gave figures; he said it was
>common to have Eclipse eating a gigabyte or two of virtual memory.
>But he also felt it was worth it. IMHO that's a valid view, even though
>I'm happy enough with Emacs myself.)

In days gone by, Emacs-hater used to claim that the acronym meant:
Eight Megabytes And Constantly Swapping. It still is a lot more
resources hungry than vi but I can now afford 8Mb

Maybe we can work out the memory eating acronym for Eclipse

Yannick

On 09/22/11 11:41 PM, none Yannick Tremblay wrote:
> In article<slrnj7e8vf.1bg.grahn+ id>,
> Jorgen Grahn<grahn+> wrote:
>> On Mon, 2011-09-19, Ian Collins wrote:
>>> On 09/19/11 09:53 PM, none Yannick Tremblay wrote:
>>>> In article<j4tan3$so0$>,
>>>> jacob navia<> wrote:
>>>>>
>>>>> Eclipse was done by a team financed by IBM. And you see the result, it
>>>>> is better than most IDEs in Linux.
>>>>
>>>> Pet-peeve but I am still unsure if Eclipse is better than something
>>>> like kdevelop or Code::Block. As far as I know, only Eclipse swallow
>>>> all of the memory available on your system, then attempt to put
>>>> a phone order to a local computer shop for more RAM and then crash if
>>>> it fails to be able to mail order more and more and more and more
>>>> RAM....
>>>
>>> That's a built in feature of the JVM, not Eclipse!
>>
>> Not sure about that -- Eclipse seems to be extremely hungry even for a
>> Java application.
>>
>> (Went to a demo a few years ago. The guy gave figures; he said it was
>> common to have Eclipse eating a gigabyte or two of virtual memory.
>> But he also felt it was worth it. IMHO that's a valid view, even though
>> I'm happy enough with Emacs myself.)
>
> In days gone by, Emacs-hater used to claim that the acronym meant:
> Eight Megabytes And Constantly Swapping. It still is a lot more
> resources hungry than vi but I can now afford 8Mb
>
> Maybe we can work out the memory eating acronym for Eclipse

That can't be done, "Eclipse" is missing the J for Java!

--
Ian Collins