what happen to break-modifycode-continue

  • Thread starter Thread starter William
  • Start date Start date
W

William

VB6 had the ability to pause your execution while debugging, messing with
the code, and continue executing right from where you left off. Is DotNet
ever going to have this capability? I really miss it.
 
Hi William,
VB6 had the ability to pause your execution while debugging, messing with
the code, and continue executing right from where you left off. Is DotNet
ever going to have this capability? I really miss it.
Click to expand...

No you do not miss something, break, edit (not for everything) and continue
will again be in the next version. However as soon as you are used to it you
will see that it is not such a big issue.

However just my thought the last part.

Cor
 
* "William said:
VB6 had the ability to pause your execution while debugging, messing with
the code, and continue executing right from where you left off. Is DotNet
ever going to have this capability? I really miss it.
Click to expand...

Currently, that's not possible. By default, it's not event possible to
edit code in the text editor if the project is in run mode. You can
change that in the IDE's settings, there is an option that will allow
you to edit code when debugging. Notice that this will not be the same
as edit & continue as it doesn't apply the changes when continuing the
execution.

Real edit & continue as known from VB6 will be back in VB 2005 (Whidbey)
which will be made available next year. This is a VB-only feature that
is not available in C#. The feature is currently already available in
the beta versions of VB 2005.
 
You have obviously never used this feature when debugging. When running a
long program that is crashing near the end of the program, being able to
edit and continue is a major productivity enhancer.

Mike Ober.
 
You have obviously never used this feature when debugging. When running a
long program that is crashing near the end of the program, being able to
edit and continue is a major productivity enhancer.
Click to expand...

You do mean that all people (not only me) who already are using VB2002 and
VB2003 for a long time now are improductive developper?

Cor
 
No, I mean that edit and continue will increase your productivity even more.
I didn't say VS 2002 and 2003 developers weren't productive, just that edit
and continue is a productivity enhancer.

Mike.
 
* "Cor Ligthert said:
You do mean that all people (not only me) who already are using VB2002 and
VB2003 for a long time now are improductive developper?
Click to expand...

Not necessarily, but with edit & continue debugging experience is much
better and faster debugging/development is possible.
 
For those of you who aren't aware of this, MS-Visual C++ 6.0 and the earlier
MS Macro Assemblers also had primitive edit and continue. You could edit
code lines and change the value of scaler variables (stack and register
based). I would think that in a "managed" environment such as .NET, Edit
and Continue would be the de-facto debugging standard. .NET's managed
memory and CRL intermediate code make this an ideal environment for Edit and
Continue. The basic implementation would be to mark "source code
statements" in the CRL and replace them as blocks when the source is
changed. You can dump references to objects when the object value is
changed. In either case, you're simply orphaning data in the debugger and
the garbage collector will clean up after you. Obviously, there will be
instances where edit and continue features simply cannot work - warn the
user and let them make the choice to keep the edits or continue with the old
code.

This is a huge oversight by MS to not realize that this is a programmer
productivity enhancer and include this as a fundamental feature of the IDE.

Is this feature hard to implement - yes. But having worked both with and
without edit and continue debuggers, it's worth its weight in gold when
debugging long tasks. For short programs, it doesn't make that much
difference because the restart time isn't too bad.

Mike.
 
long program that is crashing near the end of the program, being able
to
Not necessarily, but with edit & continue debugging experience is much
better and faster debugging/development is possible.
Click to expand...
Do you mean that C# is an improductive languate?

Cor
 
* "Cor Ligthert said:
Do you mean that C# is an improductive languate?
Click to expand...

Tha lack of E&C is one of the reasons why I don't like C# and I have
still problems writing VB.NET code. Something is missing. I have
developed a fairly large class library in VB 2005 preview versions with
E&C and I was happy to be more productive. Much more productive.
 
Cor, since you have obviously spent way too much time reading between the
lines of incomplete project/product requirement documentations, I'll spell
it out for you once more:

Edit & Continue is a productivity enhancer. Its relative value increases as
the project size and runtime increases. From your comments it is easy to
infer that you have never used E&C debuggers.

This is not to say that you aren't productive in your language of choice,
but that you would be _MORE_ productive if your language and development
environment of choice provided E&C debugging.

Mike Ober.
 
Hi Michael,

I have used it, and I find it usefull, however the negative part of it is,
because it is a partial tool, it leads quickly to dirty programs where a
quick correction stays because it works. Maybe there are people which are
themselves very diciplinair in that, I am not.

But I did not say that they should not reintroduce it, I am full on the VB
part where I find the IDE much better than with C# and when E&C can be done
without that it adds extra to runtime code than there is nothing to what is
against it.

I agree that my argument in the first allinea is an often by C# adepts told
statement.

Cor
 
Cor,

You are absolutely correct that it can be used to create sloppy code. It
can also be used to fix "one off" errors and correct variable and object
values so that debugging can continue as well as the code that created these
errors. Many times code errors are limited to a single line. Design errors
are a different story and E&C cannot be used to fix these, but it can be
used to correct the current state of the software so you can finish the
debug run and then go back and fix the error. You can write sloppy code
without it as well, but that doesn't mean we should dump C++, VB, C#, JAVA,
etc. and go back to machine language. E&C is a tool that should be part of
the VS IDE, simply because it can have such and impact on productivity on
top of the language itself. As I stated before, many MS development
environments had some form of E&C prior to .Net. Even the lowly "debug.exe"
from MS-DOS 1.1 had E&C for register variables. .Net's managed memory and
code features scream out for E&C throughout the environment, not just in
VB.Net.

Mike Ober.
 
Back
Top