Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #9438 > unrolled thread

Debugger Recommendation

Back to article view | Back to comp.lang.c++

Contents

  Debugger Recommendation Joseph Hesse <joeh@gmail.com> - 2011-08-29 09:40 -0500
    Re: Debugger Recommendation Victor Bazarov <v.bazarov@comcast.invalid> - 2011-08-29 11:01 -0400
    Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-29 19:19 +0200
      Re: Debugger Recommendation "Waldek M." <wm@localhost.localdomain> - 2011-08-29 21:37 +0200
        Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-08-30 07:51 +1200
          Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-29 22:52 +0200
            Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-08-30 08:56 +1200
              Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-29 23:00 +0200
                Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-08-30 09:21 +1200
                Re: Debugger Recommendation Nobody <nobody@nowhere.com> - 2011-08-30 04:58 +0100
          Re: Debugger Recommendation "Waldek M." <wm@localhost.localdomain> - 2011-08-31 21:45 +0200
            [OT] Re: Debugger Recommendation Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-10 02:17 -0500
              Re: [OT] Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-10 10:00 +0200
                Re: [OT] Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-10 21:14 +1200
                  Re: [OT] Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-10 11:26 +0200
                    Re: [OT] Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-10 21:33 +1200
                Re: [OT] Re: Debugger Recommendation Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-10 06:32 -0500
              Re: Debugger Recommendation Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-10 06:59 -0700
                Re: Debugger Recommendation Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-10 09:39 -0500
        Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-29 22:51 +0200
          Re: Debugger Recommendation "Waldek M." <wm@localhost.localdomain> - 2011-08-31 21:11 +0200
            Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-31 22:17 +0200
              Re: Debugger Recommendation "Waldek M." <wm@localhost.localdomain> - 2011-09-01 07:26 +0200
          Re: Debugger Recommendation dan <dan.campbell+nospam@gmail.com> - 2011-09-09 21:30 -0500
      Re: Debugger Recommendation DeMarcus <use_my_alias_here@hotmail.com> - 2011-09-22 08:57 +0200
        Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-22 09:16 +0200
          Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-22 19:46 +1200
          Re: Debugger Recommendation DeMarcus <use_my_alias_here@hotmail.com> - 2011-09-22 11:15 +0200
    Re: Debugger Recommendation Paul <pchristor@yahoo.co.uk> - 2011-08-29 22:02 -0700
      Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-08-30 11:09 +0200
        Re: Debugger Recommendation Paul <pchristor@yahoo.co.uk> - 2011-08-30 05:26 -0700
          Re: Debugger Recommendation Oliver Jackson <chexmofo@hotmail.com> - 2011-08-30 08:25 -0700
            Re: Debugger Recommendation Paul <pchristor@yahoo.co.uk> - 2011-08-30 10:34 -0700
    Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-11 20:37 +0000
      Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-12 00:40 +0200
        Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-12 21:58 +0000
          Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-13 00:52 +0200
            Re: Debugger Recommendation Juha Nieminen <nospam@thanks.invalid> - 2011-09-13 06:40 +0000
              Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 10:26 +1200
                Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 00:57 +0200
                  Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 11:13 +1200
                  Re: Debugger Recommendation Lynn McGuire <lmc@winsim.com> - 2011-09-14 18:16 -0500
                    Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 11:36 +1200
                  Re: Debugger Recommendation Juha Nieminen <nospam@thanks.invalid> - 2011-09-15 06:35 +0000
                    Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 09:29 +0200
                      Re: Debugger Recommendation Juha Nieminen <nospam@thanks.invalid> - 2011-09-15 07:46 +0000
                        Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 09:58 +0200
                          Re: Debugger Recommendation Juha Nieminen <nospam@thanks.invalid> - 2011-09-15 09:57 +0000
                            Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 19:30 +0900
                              Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 14:28 +0200
            Re: Debugger Recommendation yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-13 13:29 +0000
              Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-14 08:42 +1200
              Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 10:37 +0100
                Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 19:36 +0900
                Re: Debugger Recommendation yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-19 09:42 +0000
                  Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-19 10:59 +0000
            Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-13 20:09 +0000
          Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 10:11 +0100
            Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-16 21:29 +0000
      Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 10:08 +0100
        Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 21:23 +1200
          Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 11:38 +0200
            Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 21:41 +1200
          Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 10:43 +0100
        Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 11:34 +0200
          Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 21:54 +1200
          Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 11:44 +0100
            Re: Debugger Recommendation jacob navia <jacob@spamsink.net> - 2011-09-15 18:56 +0200
              Re: Debugger Recommendation yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-19 09:53 +0000
                Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-19 22:34 +1200
                  Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-19 11:13 +0000
                    Re: Debugger Recommendation yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-22 11:41 +0000
                      Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-23 07:45 +1200
          Re: Debugger Recommendation Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-16 21:24 +0000
        Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 18:55 +0900
          Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 22:03 +1200
            Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 19:29 +0900
              Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 23:13 +1200
                Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 20:15 +0900
                  Re: Debugger Recommendation Ian Collins <ian-news@hotmail.com> - 2011-09-15 23:22 +1200
          Re: Debugger Recommendation Rui Maciel <rui.maciel@gmail.com> - 2011-09-15 11:52 +0100
            Re: Debugger Recommendation Miles Bader <miles@gnu.org> - 2011-09-15 20:13 +0900
            Re: Debugger Recommendation Marc <marc.glisse@gmail.com> - 2011-09-15 14:19 +0000

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#10145

On 09/15/11 09:08 PM, Rui Maciel wrote:
> 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.  Nonetheless, if there was a
> decent debugger that adequately supported C++ then "many C++ users" would
> use it, including for stuff where valgrind and other tools are employed.

Not having a decent debugger (not an opinion of gdb as I don't use it) 
has the benefit of forcing the developer to write better unit tests.  I 
learned that lesson writing PHP :)

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10147

Le 15/09/11 11:23, Ian Collins a écrit :
>
> Not having a decent debugger (not an opinion of gdb as I don't use it)
> has the benefit of forcing the developer to write better unit tests. I
> learned that lesson writing PHP :)
>

And what about program maintenance?

When there are no unit tests and even no documentation?

When you have things like the source code of gcc (to name an easily
verifiable example) where the only commentary in a ten thousand
line file is the GNU copyright notice?

Try to understand, for instance, how gcc sets up the chain
of tables that must be generated to implement exception
handling in C++ from the source code.

Even if the source code is in C (what eliminates the horror of C++ 
complexity) it is almost impossible to follow.

[toc] | [prev] | [next] | [standalone]

#10148

On 09/15/11 09:38 PM, jacob navia wrote:
> Le 15/09/11 11:23, Ian Collins a écrit :
>>
>> Not having a decent debugger (not an opinion of gdb as I don't use it)
>> has the benefit of forcing the developer to write better unit tests. I
>> learned that lesson writing PHP :)
>>
>
> And what about program maintenance?

The comment was partly a joke...

But it does hold true for new development.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10150

Ian Collins wrote:

> Not having a decent debugger (not an opinion of gdb as I don't use it)
> has the benefit of forcing the developer to write better unit tests.  I
> learned that lesson writing PHP :)

That may be true, as not having a car has the benefit of forcing the would-
be driver to do a bit more exercise and develop his stamina.  That is, the 
consequences may be good but the work that they require wouldn't otherwise 
be needed.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#10146

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.

One thing he forgets too is that there is a completely forgotten class
of developers called "maintenance programmers". Those people that earn
their life taking care of code they did not wrote could not exist if
there weren't debuggers around. You are confronted to a MASS of code
of several ten thousands or hundred thousand lines of C++ code written
by different people in different environments with different styles.

Now, if you can with a right mouse click "go to the definition" of that
dammed variable instead of wadding through hundreds of lines of grep
output in different directories and sorting for five minutes the
relevant info you will never accept a debugger like gdb.

Besides, C++ is a write only language in most cases. In complex C++
systems there is really NO WAY to know which class is the relevant
current object (the implicit this) among several dozens of possibilities
scattered in different files. I have tried to follow the resolution
algorithm in the standard, but it is quite difficult to do a topological
sort of the involved classes in your head, then picking the right
candidate. And even if you do it, chances are that you picked the
WRONG one (as the developer did that wrote that code) and the bug
you are trying to fix is repeated in your mind.

> Nonetheless, if there was a
> decent debugger that adequately supported C++ then "many C++ users" would
> use it, including for stuff where valgrind and other tools are employed.
>

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.


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.

Debuggers are an essential tool in languages with overloaded specifiers
where beginning with a certain level of complexity is impossible to
follow and understand what the program is doing (unless you are the 
original developer) by just reading the source code.

[toc] | [prev] | [next] | [standalone]

#10152

On 09/15/11 09:34 PM, jacob navia wrote:
>
> Now, if you can with a right mouse click "go to the definition" of that
> dammed variable instead of wadding through hundreds of lines of grep
> output in different directories and sorting for five minutes the
> relevant info you will never accept a debugger like gdb.

That is a function of the IDE, not the debugger.

> 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.
>
> 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.

The are other (free and not so free) tools available for Linux (and 
Unix), but the Linux tool developers have to spend a disproportionate 
amount of their time chasing kernel changes.  Which is why many non-GNU 
tools only support a subset or distributions (IBM and Sun/Oracle are two 
examples).  To quote the lead developer of one tool chain "porting to a 
new Linux release is often like porting to a new OS"

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10161

jacob navia wrote:

> Exactly.
> 
> One thing he forgets too is that there is a completely forgotten class
> of developers called "maintenance programmers". Those people that earn
> their life taking care of code they did not wrote could not exist if
> there weren't debuggers around. You are confronted to a MASS of code
> of several ten thousands or hundred thousand lines of C++ code written
> by different people in different environments with different styles.
> 
> Now, if you can with a right mouse click "go to the definition" of that
> dammed variable instead of wadding through hundreds of lines of grep
> output in different directories and sorting for five minutes the
> relevant info you will never accept a debugger like gdb.
> 
> Besides, C++ is a write only language in most cases. In complex C++
> systems there is really NO WAY to know which class is the relevant
> current object (the implicit this) among several dozens of possibilities
> scattered in different files. I have tried to follow the resolution
> algorithm in the standard, but it is quite difficult to do a topological
> sort of the involved classes in your head, then picking the right
> candidate. And even if you do it, chances are that you picked the
> WRONG one (as the developer did that wrote that code) and the bug
> you are trying to fix is repeated in your mind.
> 
>> Nonetheless, if there was a
>> decent debugger that adequately supported C++ then "many C++ users" would
>> use it, including for stuff where valgrind and other tools are employed.
>>
> 
> 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.  


> 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.  If, instead, there are cheaper/free options available that are good 
enough then people tend to switch to them, no matter what OS they use.  For 
example, even linus himself used BitKeeper for a considerable amount of 
time, although there were a lot of FLOSS revision control software around 
that time, including distributed revision control software such as Git.  
MathWorks also sells linux versions of MATLAB, in spite of Octave, and 
Wolfram also sells linux versions of Mathematica, in spite of Maxima, Yacas 
and others.  If we look at other platforms, Windows users, who aren't know 
for having any political opinion meddle with their software choices, were 
also quick to dump any paid browser in favour of free (as in beer) 
alternatives, such as IE.

So, this isn't a case of any political view requiring people to stop paying 
for software.  It's a case of having cheaper (and, in this case, even free) 
alternatives that do their job well enough.  That is, it's the classical 
supply and demand model working exactly as expected.


> Debuggers are an essential tool in languages with overloaded specifiers
> where beginning with a certain level of complexity is impossible to
> follow and understand what the program is doing (unless you are the
> original developer) by just reading the source code.

Unfortunately, at least according to my personal experience, being the 
original developer also doesn't cut it, at least in cases that involve 
software written a considerable time ago.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#10177

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.

[toc] | [prev] | [next] | [standalone]

#10278

In article <j4tan3$so0$1@speranza.aioe.org>,
jacob navia  <jacob@jspamsink.org> 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.... 

:-)

[toc] | [prev] | [next] | [standalone]

#10279

On 09/19/11 09:53 PM, none Yannick Tremblay wrote:
> In article<j4tan3$so0$1@speranza.aioe.org>,
> jacob navia<jacob@jspamsink.org>  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

[toc] | [prev] | [next] | [standalone]

#10281

On Mon, 2011-09-19, Ian Collins wrote:
> On 09/19/11 09:53 PM, none Yannick Tremblay wrote:
>> In article<j4tan3$so0$1@speranza.aioe.org>,
>> jacob navia<jacob@jspamsink.org>  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   .

[toc] | [prev] | [next] | [standalone]

#10381

In article <slrnj7e8vf.1bg.grahn+nntp@frailea.sa.invalid>,
Jorgen Grahn  <grahn+nntp@snipabacken.se> wrote:
>On Mon, 2011-09-19, Ian Collins wrote:
>> On 09/19/11 09:53 PM, none Yannick Tremblay wrote:
>>> In article<j4tan3$so0$1@speranza.aioe.org>,
>>> jacob navia<jacob@jspamsink.org>  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

[toc] | [prev] | [next] | [standalone]

#10404

On 09/22/11 11:41 PM, none Yannick Tremblay wrote:
> In article<slrnj7e8vf.1bg.grahn+nntp@frailea.sa.invalid>,
> Jorgen Grahn<grahn+nntp@snipabacken.se>  wrote:
>> On Mon, 2011-09-19, Ian Collins wrote:
>>> On 09/19/11 09:53 PM, none Yannick Tremblay wrote:
>>>> In article<j4tan3$so0$1@speranza.aioe.org>,
>>>> jacob navia<jacob@jspamsink.org>   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

[toc] | [prev] | [next] | [standalone]

#10201

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   .

[toc] | [prev] | [next] | [standalone]

#10153

Rui Maciel <rui.maciel@gmail.com> writes:
> 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.

Hmm, gdb works pretty well with C++ AFAICT (yeah, I've used VS too).
Granted, much better in recent years than it used to.

> Nonetheless, if there was a decent debugger that adequately
> supported C++ then "many C++ users" would use it, including for
> stuff where valgrind and other tools are employed.

No, I think that's not true.  Valgrind is very different than a
debugger, and is useful for different things.

Having a debugger that integrated valgrind, and for instance, would
let one examine the program state when a particular erroneous
operation occured (e.g., reading uninitialized data) would be useful.

However, many of the most common uses of valgrind (e.g., leak
detection) are inherently "historic" in nature:  they tell you a
problem occured (memory leaked), and some related historical
information (where the leaked memory was allocated).  In order to
usefully use a debugger on the interesting bits -- the historical
information -- you'd have to have a complete trace of all execution
history, and that's simply too expensive to record in most cases.

-Miles

-- 
  Dinanzi a me non fuor cose create
se non etterne, e io etterno duro.
Lasciate ogne speranza, voi ch'intrate.

[toc] | [prev] | [next] | [standalone]

#10157

On 09/15/11 09:55 PM, Miles Bader wrote:
> Rui Maciel<rui.maciel@gmail.com>  writes:
>> 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.
>
> Hmm, gdb works pretty well with C++ AFAICT (yeah, I've used VS too).
> Granted, much better in recent years than it used to.
>
>> Nonetheless, if there was a decent debugger that adequately
>> supported C++ then "many C++ users" would use it, including for
>> stuff where valgrind and other tools are employed.
>
> No, I think that's not true.  Valgrind is very different than a
> debugger, and is useful for different things.
>
> Having a debugger that integrated valgrind, and for instance, would
> let one examine the program state when a particular erroneous
> operation occured (e.g., reading uninitialized data) would be useful.

That's how dbx works, access and leak checking are integrated in the 
debugger and you can specify which classes of errors (read/write to/from 
unallocated/uninitialised and so on) case a break.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10158

Ian Collins <ian-news@hotmail.com> writes:
>> Having a debugger that integrated valgrind, and for instance, would
>> let one examine the program state when a particular erroneous
>> operation occured (e.g., reading uninitialized data) would be useful.
>
> That's how dbx works, access and leak checking are integrated in the
> debugger and you can specify which classes of errors (read/write to/from
> unallocated/uninitialised and so on) case a break.

What does it do in the case of a leak (and similar "historical"
analysis)?

The point of the leak is not the point of detection, but it's the
_former_ which is interesting.  As recording the entire state of a
program for every allocation is probably too expensive for any
non-trivial program, it doesn't seem there's much the debugger can do
other than act as a convenient "show me this source file location"
tool....

-Miles

-- 
Fast, small, soon; pick any 2.

[toc] | [prev] | [next] | [standalone]

#10164

On 09/15/11 10:29 PM, Miles Bader wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>>> Having a debugger that integrated valgrind, and for instance, would
>>> let one examine the program state when a particular erroneous
>>> operation occured (e.g., reading uninitialized data) would be useful.
>>
>> That's how dbx works, access and leak checking are integrated in the
>> debugger and you can specify which classes of errors (read/write to/from
>> unallocated/uninitialised and so on) case a break.
>
> What does it do in the case of a leak (and similar "historical"
> analysis)?

Dumps the stack traces to the point of allocation at program termination.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#10165

Ian Collins <ian-news@hotmail.com> writes:
>>> That's how dbx works, access and leak checking are integrated in the
>>> debugger and you can specify which classes of errors (read/write to/from
>>> unallocated/uninitialised and so on) case a break.
>>
>> What does it do in the case of a leak (and similar "historical"
>> analysis)?
>
> Dumps the stack traces to the point of allocation at program termination.

Hmm, so exactly what valgrind does...

-miles

-- 
Education, n. That which discloses to the wise and disguises from the foolish
their lack of understanding.

[toc] | [prev] | [next] | [standalone]

#10167

On 09/15/11 11:15 PM, Miles Bader wrote:
> Ian Collins<ian-news@hotmail.com>  writes:
>>>> That's how dbx works, access and leak checking are integrated in the
>>>> debugger and you can specify which classes of errors (read/write to/from
>>>> unallocated/uninitialised and so on) case a break.
>>>
>>> What does it do in the case of a leak (and similar "historical"
>>> analysis)?
>>
>> Dumps the stack traces to the point of allocation at program termination.
>
> Hmm, so exactly what valgrind does...

Yes.  One advantage of integration is the IDE driving the debugger can 
convert the traces to hyper-links into the source.  It can also output 
the traces on a running process as it detects them.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web