«

On 08/ 4/10 06:41 AM, Balog Pal wrote:
> "cpp4ever" <>
>>>> Thanks for reminding of one of many reasons for adopting Linux at home,
>>>> and letting Windows be consigned to history.
>>>
>>> Even going downhill as described it will take another century to reach
>>> down the linux level... Which holds position stable in the stone age.
>>> Okay, not in all areas -- some tools like ddd used to work a decade ago,
>>> that is no longer the case, so it is an evading chase.
>>>
>>> (For reference I'm currently working in a linux shop, and use VS2008
>>> eunning in a virtualbox as the main devtool. With all the drawbacks of
>>> that hybrid it is still way better compared to what collegues are using
>>> (what is a wide range of tools). I hoped for better, but in vain.)
>>>
>>
>> Not my experience, although I've not tried Microsoft C++ dev tools in
>> years, I've found plenty of tools that work fine on Linux. But if you're
>> used to the Microsoft way of doing things then I suppose Linux could
>> seem difficult.
>
> What I'm used to is not "MS tools" but the ability to access the
> information that is there. Like navigation in the code (declarations,
> definitions, callerr/callee graphs, members, types, etc). Auto opening
> the related files, placing the cursor where needed, with ability to
> navigate back.
>
> Not really anything that is "rocket science" or what was not known to
> tools for decades. The best approximation I found on linux was Eclipse
> CDT, but with all it have it still lacks a plenty, and the interface is
> simply nuts. I asked people on expert foruns for advice on tools, and
> looked after everything suggested. No luck. What could you suggest that
> works?

Netbeans is the alternative kitchen sink IDE.

> My other pain is debugger -- is the world really stuck with gdb?

Most Linux devs are happy with it. I use OpenSolaris which opens up
another world of observability tools. OpenSolaris also has a better
debugger (dbx) and the best profiling and analysis tools I know
(especially for multi-threading).

There is a different mindset amongst Unix/Linux developers and windows
developers which does make the transition form one environment to the
other difficult.

--
Ian Collins

Ian Collins <ian-> writes:
>> My other pain is debugger -- is the world really stuck with gdb?
>
> Most Linux devs are happy with it. I use OpenSolaris which opens up
> another world of observability tools. OpenSolaris also has a better
> debugger (dbx) and the best profiling and analysis tools I know
> (especially for multi-threading).
>
> There is a different mindset amongst Unix/Linux developers and windows
> developers which does make the transition form one environment to the
> other difficult.

Indeed. gdb is a fine debugger for the most part; it's obviously
lacking in the "mousey-clicky" department, but it's extremely powerful
in other ways. Which you like better generally has an awful lot more to
do with _what you're used to_ than the actual capabilities.
[although not in all cases -- the original gdb, for instance, was a huge
improvement over the buggy feature-poor versions of sun dbx it competed
against in the late 80s / early 90s]

I use VS's debugger on occasion -- usually because there are VS-heads
here at work who are just not up to some debugging tasks, and I have to
do it for them -- and it drives me _nuts_. To me, the VS debugger seems
horrible, almost unusable, mostly because it's hiding behind a fairly
opaque GUI (despite having a regular user beside me to answer usage
questions).

As an example, there are many occasions when VS will display an address
(say, in a memory dump or something), and I want to see what's at that
address, interpreted in a different way. In gdb, I can almost always do
this using an expression that operates on the previous value, or by
using command-line editing to tweak a previous command. In
VS... there's often simply no obvious way to do it -- even the obvious
GUIey cut-and-paste solution doesn't work, because copying simply isn't
supported in many contexts, and after much gnashing of teeth, consulting
with other users, looking in the menus/doc/etc, I often just end up
typing the damn value in by hand. This sort of "information displayed,
but not otherwise usable" situation crops up _all the time_ when I use
VS for debugging (and it's not like I don't try to find a way to do it
-- I ask regular users, spend time searching the menus, look at the
docs, etc, but usually to no avail).

That kind of thing just smacks of very poor design to me, and makes me
wonder if the VS debugger implementors actually ever use it for
debugging or at least any debugging beyond the simple everyday sort...

Grrrr

-Miles

--
Success, n. The one unpardonable sin against one's fellows.

On Aug 3, 8:35*pm, Miles Bader <mi...@gnu.org> wrote:
> As an example, there are many occasions when VS will display an address
> (say, in a memory dump or something), and I want to see what's at that
> address, interpreted in a different way. *In gdb, I can almost always do
> this using an expression that operates on the previous value, or by
> using command-line editing to tweak a previous command. *In
> VS... there's often simply no obvious way to do it -- even the obvious
> GUIey cut-and-paste solution doesn't work, because copying simply isn't
> supported in many contexts, and after much gnashing of teeth, consulting
> with other users, looking in the menus/doc/etc, I often just end up
> typing the damn value in by hand. *This sort of "information displayed,
> but not otherwise usable" situation crops up _all the time_ when I use
> VS for debugging (and it's not like I don't try to find a way to do it
> -- I ask regular users, spend time searching the menus, look at the
> docs, etc, but usually to no avail).

I don't know about "all the time". The only such place I can imagine
is a standard message box that you get e.g. when an assertion fails.
But in the actual debugger window you can always copy text, whether
it's in one of the "Autos", "Locals", "Threads", etc. windows, or in
the little textbox that pops up when you hover the mouse over an
identifier.

Got any other points? Because other than that your rant seems like a
typical case of Unix/C pro-command-line anti-GUI anti-progress anti-
evolution hacker syndrome.

Jerry Coffin wrote:
> In article <nqN4o.42877$>,
> says...
>
> [ ... ]
>
>> Overall, if it wasn't such a resource hog (read
>> crappy software engineering at best, designed that way on purpose at
>> worst) so that it would be responsive on paltry 2.4 GHz, 4 Gig RAM
>> machines, it would be then not crappy software.
>
> Mostly it's read as: "a lot of it was rewritten in C#."

If that is the reason, then it surely moves C# into the realm of
scripting languages rather than system-level or low-level and C++ is then
safe from obsolescence from it.

"Miles Bader" <>
>> There is a different mindset amongst Unix/Linux developers and windows
>> developers which does make the transition form one environment to the
>> other difficult.

Maybe in general, does not apply to me, as I started programming well before
windows gor widespread, got used to all kinds of tools on DOS, embedded
systems, etc. (Btw Borland's Turbo debugger showed that you can create a
handy debugger for the text screen that is about the workflow...)

> Indeed. gdb is a fine debugger for the most part; it's obviously
> lacking in the "mousey-clicky" department, but it's extremely powerful
> in other ways.

Sure, a shovel is an extremely powerful tool to dig a hole, you can do it
exactly your way. Why bother with machines that can do the same faster and
save time?

I don't use debugger so often, when I do, it is to inspect the state. So I
need to see the value of all kind of variables and the call stack. And
certainly the source related to the stack trace. With gdb you must use
extreme amount of typing to see just a portion of what is obviously needed.
And can't realisticly see the relevant pieces at once.

What turns a trivial 2-minute session into a hour one nightmare. Also,
other debuggers save context of the session, so next time you have the
environment ready with all the watches, breakpoints, etc. gdb used to at
least keep the command history, that is no longer the case on lucid .
Also I mentioned some front-ends like ddd that at least aimed to cover the
actual use cases did work, now all you get is a blocked interface so you
must ssh in from a different machine for a pkill.

I agree that i met too many people being happy with gdb, but all of them had
the same attitude: they did not care about the wasted time.

> Which you like better generally has an awful lot more to
> do with _what you're used to_ than the actual capabilities.

Do you count the pace of progress in the 'capability' category?

> I use VS's debugger on occasion -- usually because there are VS-heads
> here at work who are just not up to some debugging tasks, and I have to
> do it for them -- and it drives me _nuts_. To me, the VS debugger seems
> horrible, almost unusable, mostly because it's hiding behind a fairly
> opaque GUI (despite having a regular user beside me to answer usage
> questions).

You can summon a command window if the ability to do the work in one click
is so frigtening.

> As an example, there are many occasions when VS will display an address
> (say, in a memory dump or something), and I want to see what's at that
> address, interpreted in a different way.

> In gdb, I can almost always do
> this using an expression that operates on the previous value, or by
> using command-line editing to tweak a previous command.

Can't imagine yor context, the same thing works in the watch window. The
difference is just that it stays there.

Though reinterpreting data leads to the wild, isn't it the more usual case
when you just want to inspect the state of your objects natively?

> In VS... there's often simply no obvious way to do it -- even the obvious
> GUIey cut-and-paste solution doesn't work, because copying simply isn't
> supported in many contexts

Can you give examples?

> , and after much gnashing of teeth, consulting
> with other users, looking in the menus/doc/etc, I often just end up
> typing the damn value in by hand.

LOL. So typing annoys you for that corner situation. Now imagine how I
feel using gdb, when I need to do typing and typing ant more redundant
typing and typing again for everything, everytime? Instead of having the
watched variables just there, the call stack in its window, hower tho mouse
over a variable to show the value? Then just step, step, and still see the
result?

On 4 aug, 08:37, Miles Bader <mi...@gnu.org> wrote:
> Sousuke <s0s...@gmail.com> writes:
> > Got any other points? Because other than that your rant seems like a
> > typical case of Unix/C pro-command-line anti-GUI anti-progress anti-
> > evolution hacker syndrome.
>
> Why, because I think VS's debugger is kinda crappy? *That's an issue
> with VS, not with "GUIs/progress/evolution" (the fact that you conflate
> the three is telling of course...).

He asked for points and your point is that "it is kinda crappy"? Hehe?

Looking at all these kdbg, ddd and what there are about debugging with
GUI in Linux then these get things done but are weaker. If you say
that all should use emacs + gdb feels sort of like anti-progress
indeed.

> I'm not "anti-GUI," I'm "anti-bad-GUI" -- and sadly, there are many,
> especially in "expert" tools like debuggers, where conventions that
> might make sense with novice-focused apps (where GUIs shine) simply get
> in the way.

What exactly gets in the way? Multiple, customizable views at the
situation you are in that update with each step you make?

Or ... for example lets compare? Imagine that you do not have a tool
that measures test coverage. You have to do it manually with
debugger.
Visual studio:
1) Set all functions to break (F9 or click per breakpoint right in
editor).
2) Run unit tests (pick configuration UnitTest 2 clicks and F5 to
run).
3) Clear covered breakpoints (click to clear, F5 to run ahead ).
4) See list of places not yet covered with tests (Alt-F9 breakpoint
window).

Yes, i can teach it to novice with 5 minutes. Now describe same work
with your "expert" emacs and gdb symbiosis and how you teach that to
novice? Is debugger an "expert" tool of job security by obscurity?
Does it create job positions that no one wants?

On Aug 3, 9:02 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 08/ 4/10 06:41 AM, Balog Pal wrote:

[...]
> > My other pain is debugger -- is the world really stuck with gdb?

> Most Linux devs are happy with it.

I never cared much for it, but now that I have to use Visual
Studios... The Microsoft debugger has to be the worst I've seen
to date.

[...]
> There is a different mindset amongst Unix/Linux developers and
> windows developers which does make the transition form one
> environment to the other difficult.

From experience, however: the Unix developers I know who work
under Windows generally have CygWin installed. And are
considerably more productive than the expert Windows developers.

--
James Kanze

* James Kanze, on 04.08.2010 16:19:
> On Aug 3, 9:02 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>> On 08/ 4/10 06:41 AM, Balog Pal wrote:
>
> [...]
>>> My other pain is debugger -- is the world really stuck with gdb?
>
>> Most Linux devs are happy with it.
>
> I never cared much for it, but now that I have to use Visual
> Studios... The Microsoft debugger has to be the worst I've seen
> to date.

How so? It's about the best there is. Until recently gdb couldn't even trace
into constructors, and it's generally erratic, while MS' debugger is dependable.

I suspect a PEBKAC problem when you dimiss the generally best debugger around as
"worst".


>
> [...]
>> There is a different mindset amongst Unix/Linux developers and
>> windows developers which does make the transition form one
>> environment to the other difficult.
>
> From experience, however: the Unix developers I know who work
> under Windows generally have CygWin installed. And are
> considerably more productive than the expert Windows developers.

Most Windows developers have *nix tools installed, including a *nix shell.

CygWin has it all in one package but isn't very good (really).


Cheers & hth.,

- Alf

--
blog at <url: http://alfps.wordpress.com>

On Aug 4, 9:27*am, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
> * James Kanze, on 04.08.2010 16:19:
>
> > On Aug 3, 9:02 pm, Ian Collins<ian-n...@hotmail.com> *wrote:
> >> On 08/ 4/10 06:41 AM, Balog Pal wrote:
>
> > * * *[...]
> >>> My other pain is debugger -- is the world really stuck with gdb?
>
> >> Most Linux devs are happy with it.
>
> > I never cared much for it, but now that I have to use Visual
> > Studios... The Microsoft debugger has to be the worst I've seen
> > to date.
>
> How so? It's about the best there is. Until recently gdb couldn't even trace
> into constructors, and it's generally erratic, while MS' debugger is dependable.
>
> I suspect a PEBKAC problem when you dimiss the generally best debugger around as
> "worst".
>

At the risk of wading into another mine-is-bigger-than-yours flame war
(et tu James?), nobody has mentioned WinDbg so far? Visual Studio's
integrated debugger has made some strides in the past few years, but
WinDbg/CDB/NTSD troika has always matched up to whatever gdb can do
for quite a while.

On Aug 3, 6:35*pm, Miles Bader <mi...@gnu.org> wrote:

> Indeed. *gdb is a fine debugger for the most part; it's obviously
> lacking in the "mousey-clicky" department, but it's extremely powerful
> in other ways. *Which you like better generally has an awful lot more to
> do with _what you're used to_ than the actual capabilities.
> [although not in all cases -- the original gdb, for instance, was a huge
> improvement over the buggy feature-poor versions of sun dbx it competed
> against in the late 80s / early 90s]

Speaking of dbx, did anyone ever port dbxtra/dbXtra to Linux? dbxtra
was
oldSCO's variant of dbx, it could run in either line mode, or screen
(curses) mode, and it did some nice things, such as cleanly handling
forked processes. dbXtra was the GUI version.