Microsoft's C++ bigotry - Page 14


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 14 of 43 FirstFirst ... 4121314151624 ... LastLast
Results 196 to 210 of 633

Thread: Microsoft's C++ bigotry

  1. #196
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 20:47:06 +0000, Mike Mitchell wrote:

    > On Thu, 23 Jan 2003 01:19:51 +1100, Jason Sobell iGadget
    > <igadget_@hotmail.com> wrote:
    >
    >>How often do you call a function that takes and returns no parameters? This
    >>is the only time GoSub can be used, unless you are storing your data in
    >>global variables

    >
    > Eh? I don't think you can quite understand how GoSub is used! You just
    > whack a chunk of code at the foot of your procedure (could be
    > elsewhere, but that's where I place it), stick a label at the start
    > and a Return at the end. Then you GoSub LabelName, the code in the
    > GoSub block is executed and hits Return, sending you back to the
    > statement following the GoSub call. All variables known to the
    > procedure which contains your GoSub code are also known to the GoSub
    > code, i.e. you don't have to pass anything!


    Doh! Is that what GoSub does?
    Sorry, 'Global' variables was very bad wording. I meant variables that are
    in scope for the whole of your function.
    Unless you want your GoSubed section of code to do exactly the same thing
    every time (such as print the same thing to a debug window) you must be
    referencing variables in the current scope of the routine. If you modify
    them (as though passing them ByRef to a subroutine) it can all start to get
    very confusing and messy, and for the sake of maintainability and
    readability I would prefer to sacrifice a miniscule performance overhead
    and make it a function.

    > However, if instead of GoSub you wrote a separate Sub or Function,
    > you'd have to pass arguments to it to replicate the variables which
    > are already known within your procedure. So, if you needed to execute
    > some standard piece of code ten times as your procedure is being
    > executed overall (we're not in the GoSub code yet!), you have three
    > choices: (a) Duplicate the code throughout the procedure, (b) Call a
    > GoSub block, or (c) Call an external Sub or Function. Sometimes option
    > c is right; sometimes option b is very handy. Option a is almost never
    > wise.


    At least with Option C you have a clear indication of the parameters that
    are being affected, a reusable function, and more readable code.
    "Hmm.. let me scan through this GoSub routine to see what variables it's
    modifying in the code above"
    OK for *tiny* GoSub routines, but not for anything else.

    Perhaps we should ask Microsoft to give us inline Macros, as these would do
    the same thing only with more flexibility

    Cheers,
    Jason

  2. #197
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "David A. Rothgery" <drothgery@alum.wpi.edu> wrote in message
    news:MPG.189701aed8d71f18989744@news.devx.com...
    > Gary Nelson <gn@contanet.es> wrote:
    > > David,
    > >
    > > > Yeah, but the problem was that defaults to ByRef and 16-bit Integers

    were
    > > > stupid (the change to 32-bit Integers really should have been made in

    VB4;
    > >
    > > Why? Exactly what difference does it make?

    >
    > Because in a language strictly tied to a platform, Integer should be the
    > optimal integer size on the platform


    2 points in response to that

    1. Basic isn't tied strictly to one platform.

    2. There's nothing in the Basic documentation over 25 years that gives
    defines Integer in that way. If you want to restrict it just to VB, there's
    nothing in the VB documentation over 10 years that defines integer in that
    way (until VB.NET, which invented this requirement). In all the
    documentation that has ever been produced by Microsoft about any of its
    versions of Basic, Integer has always been defined as a 16-bit signed
    integer datatype. Nothing more, nothing less. The C documentation over the
    same period *does* define int more or less in the way you describe, but that
    is C, not Basic. Do other languages now have to follow the assumptions of C?

    3. Even C# doesn't define int in the way you describe, the C# language spec
    says "The int type represents signed 32-bit integers with values
    between 2147483648 and 2147483647." Hmmm. If they move to a 64-bit platform
    where 64-bit integers are faster, do you think that ECMA will allow that
    change? I don't think so.

    > (and no, Jonathan, implementing
    > Integers as 32-bit integers behind the scene and making them act like
    > 16-bit integers would not be a good idea; you'd have a base integer type
    > with very strange behavior, so experienced programmers would use Long
    > for everything).


    I wasn't going to suggest it. But if Long is faster than Integer, and the
    docs say so, I see no problem with using Long. In fact, I do that in my own
    code.

    That said, if you want to have a datatype that is defined as "The fastest
    integer type for the system, whatever length that hapens to be" then I have
    no problem with such a datatype being defined and given a new name. Call it
    SysInt or something like that. No need to change the meaning of an existing
    keyword to achieve that. Of course, if you regard VB.NET is as a wholly new
    language with no intention to bring along the existing VB6 codebase, then
    ignore all I've said, as it's not relevant to that situation.

    >
    > > > the ByRef default never should have happened

    > >
    > > Why? I never had any problems with it.

    >
    > Lots of people claim that they never had any problems with GOTOs,
    > GOSUBs, C-style pointers, or self-modifying code, but it doesn't keep
    > them from being errors waiting to happen either.


    There's one thing about this enthusiasm for cleaning the language. Every
    time you remove or change the behaviour of an existing construct, you cause
    code that worked before to throw errors when compiled or run in the new
    version. Errors are bad things to introduce in a product you want repeat
    buyers for.

    --
    Regards
    Jonathan West


  3. #198
    Dan Barclay Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 09:07:37 +1100, Jason Sobell iGadget
    <igadget_@hotmail.com> wrote:

    >On Wed, 22 Jan 2003 15:15:22 -0600, Dan Barclay wrote:
    >> On Wed, 22 Jan 2003 14:19:34 -0600, Paul Clement
    >>>
    >>>I used it in old line coded basic, which had no Subs or Functions, but there was never any reason to
    >>>use it in QuickBASIC or any variant of the structured BASIC language. It is outdated just as GoTo
    >>>is.

    >>
    >> Oh, so GoTo is scheduled for removal? Didn't know that. I suppose it
    >> makes about as much sense though. I've been outta touch but I'm glad
    >> you're keeping up with 'em.

    >
    >I also doubt if GoTo will be removed. The GoSub has almost direct
    >replacements, but GoTo doesn't, and there are sometimes situations where
    >GoTo gives enormous simplification (possibly at the expense of structure).


    GoSub does not have almost direct replacements either. You can code
    without it, but not by substituting a direct or near direct
    replacement.

    You can also code without GoTo''s and there are people who say you
    should do that. Eliminating it makes as much sense. Considering
    there are people who don't know how to use them properly, they should
    be protected!

    >
    >>> Duplicate code fragments are a virus in code that lives through years
    >>> of maintenance. It's a hard fact that, at some point, one copy of the
    >>> fragment will be fixed or enhanced and others will be missed. Its
    >>> proper usage is as a code-only container for eliminating duplicate
    >>> code fragments.
    >>>
    >>>Problem is it isn't a container but a containee that affects the flow of logic within its container.

    >>
    >> Certainly it is a container, and it works quite well. You *really*
    >> should learn something about it.

    >
    >Very arguable. It's not really a container, because it has no effect on
    >scope of variables.


    Nope, it's a code container. A container doesn't have to hold or
    affect variables any more than a container has to hold code (a class
    with no code).

    > It is a flow control statement in the same manner as
    >GoTo, but we could all argue semantics...


    How do you get that? GoSub is a call and has a return (was Return) .
    GoTo is a dead jump.

    >The only advantage over a Subroutine is that it retains the scope of all
    >the variables that the calling function has.


    Correct. There are times when that differences allows you to easily
    wrap repeated code without having to fuss with complex parameter
    lists. Again, repeated code is dangerous to long term maintenance.
    If you want to help devs create maintainable code, eliminate cut/paste
    from the editors!

    >Having said all this, there are situation where using GoSub would save time
    >and resources, particularly in large complex (spaghetti?) routines that
    >have not been broken into structured subroutines and using large numbers of
    >variables.


    It's useful in smaller routines as well. Organized code is a mindset,
    not a function of the programming language. Considering and using all
    the tools is necessary.

    > It certainly is frequently a killer of readability and
    >maintainability, and I know that I won't miss it, but then that's just my
    >way of coding.


    Absolutely not, if you use it correctly. It even helps *improve*
    readability when used right. If you have a long Case statement, for
    example, you can sometimes keep the entire Select on one screen (or at
    least reduce the real-estate) by pushing Case code to a GoSub.

    Again, it's all in how you learn to use it.

    We can make all these same arguments about misused inheritance or
    classes. They're all tools. Used right, they're helpful. Used wrong
    they create a mess that nobody can understand. Don't confuse
    "political correctness" with usefulness.

    Think about it.

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)/(#1!)
    Error 51
    Error 3
    Error 9
    ....

  4. #199
    Dave Guest

    Re: Microsoft's C++ bigotry


    "Tom Shelton" <toms@dakcs.com> wrote:
    >That's not a hack... ReDim maybe slightly slower in VB.NET, but it is also
    >slow in VB6 especially as your array gets larger. It has never been good
    >practice to ReDim arrays 1 element at a time. And if you want a dynamic
    >container - System.Collections.ArrayList.
    >


    Well, Redim Preserve in VB.NET is hundreds of times slower than VB6. If MS
    wants developers to upgrade then maybe they should just get some of those
    MS developers from the VB6 team to pass on some of their knowledge instead
    of telling customers to do it a different way. I don't see what the resistance
    is - ReDim Preserve is a bona fide part of VB.NET - don't tell me I have
    to suffer it's horrible performance as a penalty for using it. VB6 had a
    very efficient ReDim Preserve - just use the same **** high-level algorithm
    VB6 used to implement it.





  5. #200
    Mark Hurd Guest

    Re: Microsoft's C++ bigotry

    Phil Weber wrote:
    > I really think that's key. I wonder how difficult it would be to create a
    > .NET compiler for VB6 syntax? I'm considering starting an open source
    > project to do that. Any takers?


    The first step is to get an exact definition of the language. I've only heard
    of proprietary yacc/bison grammars. I assume you'd prefer to do it in VB.NET,
    so yacc/bison may not be that useful anyway.

    But some exact EBNF definition is needed as a base, even if you are going to
    hand-code an OO parser.

    Nevertheless, I'd be interested in helping, but I can't promise any real help
    in the short term future as we're releasing a new VB6 program in the next
    week...

    You might want to borrow the VB.NET parser that mono(?) are working on and
    roll it back to VB6...

    Regards,
    Mark Hurd, B.Sc.(Ma.) (Hons.)



  6. #201
    Mark Hurd Guest

    Re: Microsoft's C++ bigotry

    Patrick Troughton wrote:
    > I've been one of VB.NET's biggest supporters (beta 2 rollbacks
    > notwithstanding)


    As I see it, without the beta 2 rollbacks, no one in their right mind would
    consider /importing/ any significant body of VB6 code to VB.NET.

    Issues like GoSub, Mid$, binary file I/O and other fundamental changes,
    continue to make this the case for many code bases.

    VB.NET is a good, fun language, but it is *NOT* VB7, more like VB8 or 9 :-)

    It *is* a good excuse to rewrite your code, if you can afford it. And, yes, I
    expect you'll use less code to produce the same or better result, but then I'd
    expect any competent programmer to solve the problem better the second time
    around, even if they used VB6 again.

    Regards,
    Mark Hurd, B.Sc.(Ma.) (Hons.)



  7. #202
    Mark Hurd Guest

    Re: Microsoft's C++ bigotry

    Patrick Troughton wrote:
    > idiotic .NOTters like DB, KP, MM, GN


    You *might* get away with saying some "idiotic complants" are attributed to
    some of them, but only one might be an idiot (and I haven't read/recalled
    enough GN posts to comment).

    I haven't seen any *complaints* from DB I don't agree with, KP just seems
    rather bitter (there's a better description but I can't think of it atm :-( )
    and MM hasn't changed...

    Some concepts of B.A.S.I.C have been lost that didn't need to be, and if
    you're going to complain it is much better to complain about all of the
    changes, so that you might get the ones that matter undone.

    The simplest example I see is the lost idea of a Sub being like a new command.
    Dan mentioned this and he got talked down to like it was some silly similie MM
    goes on with for too long. We lost it because of the three different ways to
    call a routinethe one that was changed was the simplest, most BASIC like...

    Anyway, this is not the time to rehash this again...

    Regards,
    Mark Hurd, B.Sc.(Ma.) (Hons.)



  8. #203
    Kent Guest

    Re: Microsoft's C++ bigotry


    Pat,

    There is no need to argue, It's true you and I see things much differently.
    Development still uses VB6 on a daily basis for maintenance but will most
    likely not touch .Net. We do a lot of business with county governments and
    many of them have taken a no Microsoft stance and are very strict about it.


    This has caused us some hardship and a couple of deals. On the other hand
    though we just had one customer complain about the Java runtime getting installed
    on one of their servers... It was only a minor complaint and they accepted
    the system, but it goes to show that it's not only the developers who feel
    strongly about this issue. I'm not saying .Net will fail, but I don't think
    VB will be the showcase language of the platform and it will most likely
    wither and die in the shadow of C#

    Kent

    "Patrick Troughton" <Patrick@Troughton.com> wrote:
    >
    >Hi Kent,
    >
    >You're deluding yourself if you think VB.NET isn't here to stay. The fact
    >is that .NET is already success, and getting bigger and bigger every day.
    >Every month, more and more companies are adopting .NET. Just in the last
    >few weeks....
    >
    >Allstate Insurance....
    >http://www.microsoft.com/resources/c...eStudyID=13648
    >
    >CNET...
    >http://www.microsoft.com/resources/c...eStudyID=13550
    >
    >Nasdaq Stock Market, Inc....
    >http://www.microsoft.com/resources/c...eStudyID=13543
    >
    >Volvo Cars....
    >http://www.microsoft.com/resources/c...eStudyID=13469
    >
    >This is in addition to the hundreds and hundreds of companies who are already
    >using .NET.
    >
    >In fact, .NET is now being used for everything from web sites to nuclear-powered
    >aircraft carriers (PC Magazine, "Mobile Application Tools", October 15th,
    >2002).
    >
    >I can personally say that I know of another huge company that started on
    >a *major* VB.NET project just a few weeks ago. I can't give out the name,
    >but it has over 5,000 stores in 60 different countries throughout the world.
    >I can almost guarantee that everyone in this newsgroup has heard of it,

    and
    >has probably shopped there a few times, too. I suspect that when the app
    >is done, you will probably hear about it somewhere. I'm not under NDA with
    >this company, but I'll let them announce it when they're ready.
    >
    >Even software vendors are embracing .NET because it's so much easier to

    work
    >with....
    >http://news.devx.com/cgi-bin/dnewswe...em=45350&utag=
    >
    >ZDNET reports that .Net is one of the top job skills in demand....
    >http://zdnet.com.com/2100-1104-978922.html
    >
    >.NET has won numerous industry awards...
    >
    >PC Magazine's 18th Annual Technical Excellence Awards
    >Best Development Tool: Visual Studio .NET
    >http://www.pcmag.com/article2/0,4149,140708,00.asp
    >
    >Software Development Magazine
    >Jolt Award for Best Libraries, Frameworks, and Components Microsoft .NET
    >Framework
    >http://www.sdmagazine.com/jolts/
    >
    >Productivity Award for Best Languages and Development Environments Microsoft
    >Visual Studio .NET http://www.sdmagazine.com/jolts/
    >
    >Those of you who have read my posts before know that I have few friends

    and
    >family in the IT industry. Just this weekend, I met up with a couple friends
    >from a consulting firm. They tell me that their .NET business is booming
    >and that their bench is filled with Java programmers who are starting to
    >worry that they don't have any clients.
    >
    >I've been one of VB.NET's biggest supporters (beta 2 rollbacks notwithstanding)
    >since Day One and .NET has exceeded even my expectations.
    >
    >Kent, I'm not going to argue with you. If there's one thing I've learned
    >from this newsgroup is that people make up their minds before posting, and
    >rarely change them, no matter what you say or how much proof you have.
    >
    >So this will be my last post to this thread. If you're anything like the
    >other .NOTters, you will probably want to flame me or resort to personal
    >insults since .NOTters were never able to defend their ideas with logic

    or
    >facts.
    >
    >The only thing I can say is if the .NOTters had listened to me two years
    >ago, they would be laughing all the way to the bank, too. And if they don't
    >start picking up .NET, they shouldn't be surprised when they're out of a
    >job a few years from now....
    >
    >Later....
    >
    >/Pat
    >--------------------------
    >It's the platform, stupid.
    >--------------------------
    >
    >"Kent" <KP@KP.org> wrote:
    >>
    >>Pat,
    >>
    >>It should have been a no brainer for the monopolists to realize all by

    them
    >>selves that a VB7 with managed extensions was needed. The fact that they
    >>didn't provide a migration path then and still don't today speaks volumes
    >>to the level of commitiment they have provided to the VB community.
    >>
    >>They don't listen and they don't care... yet. If things keep going the

    >way
    >>they are, they soon will. You're defense of them is not helping any.

    Admit
    >>the problems exist and say you won't stand for it. Point out the alternatives...
    >> Hit em where it hurts most, that's how you make change.
    >>
    >>Kent

    >


  9. #204
    Tom Shelton Guest

    Re: Microsoft's C++ bigotry


    Dave <dave_doknjas@yahoo.ca> wrote in message
    news:3e2f35ec@tnews.web.devx.com...
    >
    > "Tom Shelton" <toms@dakcs.com> wrote:
    > >That's not a hack... ReDim maybe slightly slower in VB.NET, but it is

    also
    > >slow in VB6 especially as your array gets larger. It has never been good
    > >practice to ReDim arrays 1 element at a time. And if you want a dynamic
    > >container - System.Collections.ArrayList.
    > >

    >
    > Well, Redim Preserve in VB.NET is hundreds of times slower than VB6. If MS
    > wants developers to upgrade then maybe they should just get some of those
    > MS developers from the VB6 team to pass on some of their knowledge instead
    > of telling customers to do it a different way. I don't see what the

    resistance
    > is - ReDim Preserve is a bona fide part of VB.NET - don't tell me I have
    > to suffer it's horrible performance as a penalty for using it. VB6 had a
    > very efficient ReDim Preserve - just use the same **** high-level

    algorithm
    > VB6 used to implement it.


    Well, I've never timed it so I don't know how accurate your hundreds of
    times is.... And as far as I know they both use the same algorithm, I think
    this is more about the memory allocation/copy routines then the algorithm
    used by ReDim.

    The fact is any significant speed loss with array resizing probably because
    even in VB6 I almost always allocate my arrays in chuncks (you should get a
    hold of Rod Stephens VB algorithm book). You may want to take some time
    and recode your array diming code in VB6 - if your working with good sized
    arrays I'd be willing to bet you will see a pretty code performance
    improvement.

    If I get a chance tommorow I'll test this....

    Tom Shelton



  10. #205
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
    >
    > >In most instances it can be easily replaced by a Sub or Function.
    > > If performance was an issue, as you indicate in your following points,
    > > I'm surprised that you continued to use GoSub.

    >
    > It could be replaced by a Sub or a Function, but that would be to
    > completely miss the point of GoSub! The one way GoSub was extremely
    > useful was when you had a piece of standard code in a procedure and
    > you had to execute it again and again.


    Speaking of missing the point, why bother using Functions or Subroutines
    at all? Why were they introduced?

    > So you can replace the several lines of code at multiple places in
    > your procedure with just a GoSub MyRoutine, and it makes the code far
    > more readable. Also, no overhead is lost through continually passing
    > arguments to a Sub or Function which would have to be called again and
    > again instead of using GoSub.
    >
    > This is why GoSub was and is absolutely the right choice in certain
    > circumstances.


    Its more like you learned coding methods in one language, and wanted
    to use those same methods in a different language. Rather than find out
    what works well in the new language, you defend your old habits. Of
    course coming from you, no one should be surprized. But I'm curious,
    perhaps you have a machine that computes differently than most.

    Make a Native EXE (fast code option) out of the code below, and report
    your findings, just to check if it matches what the rest of us see....

    LFS

    Option Explicit
    Private Declare Function GetTickCount Lib "kernel32" () As Long
    Const Runs As Long = 999

    Private Sub Form_Load()
    Dim tick&, i&

    tick = GetTickCount
    For i = 1 To 1000
    Test1
    Next i
    tick = GetTickCount - tick
    MsgBox "Gosub took: " & CStr(tick)

    tick = GetTickCount
    For i = 1 To 1000
    Test2
    Next i
    tick = GetTickCount - tick
    MsgBox "Subroutine took: " & CStr(tick)

    End Sub


    Private Sub Test1()
    Dim a%, b%, c%, d%, e%, f%, g%, h%, i&
    Dim tmp%
    For i = 0 To Runs
    GoSub SubTest
    Next
    Exit Sub

    SubTest:
    tmp = a
    a = b
    b = c
    c = d
    d = e
    e = f
    f = g
    g = h
    h = tmp
    Return

    End Sub


    Private Sub Test2()
    Dim a%, b%, c%, d%, e%, f%, g%, h%, i&

    For i = 0 To Runs
    SubTest a, b, c, d, e, f, g, h
    Next

    End Sub

    Private Sub SubTest(a%, b%, c%, d%, e%, f%, g%, h%)
    Dim tmp%
    tmp = a
    a = b
    b = c
    c = d
    d = e
    e = f
    f = g
    g = h
    h = tmp
    End Sub





  11. #206
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 18:00:45 -0600, Dan Barclay wrote:
    > On Thu, 23 Jan 2003 09:07:37 +1100, Jason Sobell iGadget
    > <igadget_@hotmail.com> wrote:
    >
    >>On Wed, 22 Jan 2003 15:15:22 -0600, Dan Barclay wrote:
    >>> On Wed, 22 Jan 2003 14:19:34 -0600, Paul Clement
    >>>>
    >>>>I used it in old line coded basic, which had no Subs or Functions, but there was never any reason to
    >>>>use it in QuickBASIC or any variant of the structured BASIC language. It is outdated just as GoTo
    >>>>is.
    >>>
    >>> Oh, so GoTo is scheduled for removal? Didn't know that. I suppose it
    >>> makes about as much sense though. I've been outta touch but I'm glad
    >>> you're keeping up with 'em.

    >>
    >>I also doubt if GoTo will be removed. The GoSub has almost direct
    >>replacements, but GoTo doesn't, and there are sometimes situations where
    >>GoTo gives enormous simplification (possibly at the expense of structure).

    >
    > GoSub does not have almost direct replacements either. You can code
    > without it, but not by substituting a direct or near direct
    > replacement.


    Why not? A Gosub to a routine that modifies intA and intB can be replaced
    with Call DoWhatever(intA, intB).
    Is there a syntactically identical alternative? No.

    > You can also code without GoTo''s and there are people who say you
    > should do that. Eliminating it makes as much sense. Considering
    > there are people who don't know how to use them properly, they should
    > be protected!


    Yes, that is an 'ivory tower' attitude, but if we really wanted to protect
    people from themselves we would make every PC user take a competency test
    before giving them a keyboard
    There is no flow control based alternative to GoTo. You would have to add
    flags and conditional statements.

    >>
    >>>> Duplicate code fragments are a virus in code that lives through years
    >>>> of maintenance. It's a hard fact that, at some point, one copy of the
    >>>> fragment will be fixed or enhanced and others will be missed. Its
    >>>> proper usage is as a code-only container for eliminating duplicate
    >>>> code fragments.
    >>>>
    >>>>Problem is it isn't a container but a containee that affects the flow of logic within its container.
    >>>
    >>> Certainly it is a container, and it works quite well. You *really*
    >>> should learn something about it.

    >>
    >>Very arguable. It's not really a container, because it has no effect on
    >>scope of variables.

    >
    > Nope, it's a code container. A container doesn't have to hold or
    > affect variables any more than a container has to hold code (a class
    > with no code).


    As I said. It is a pointless argument about semantics. By this argument you
    can say that GoTo is a container too, so I'm not interested.

    >> It is a flow control statement in the same manner as
    >>GoTo, but we could all argue semantics...

    >
    > How do you get that? GoSub is a call and has a return (was Return) .
    > GoTo is a dead jump.


    Please, read the statement properly. GoSub is a procedural language
    statement designed to provide process flow in languages that had line
    numbers and no concept of user defined functions.

    >>The only advantage over a Subroutine is that it retains the scope of all
    >>the variables that the calling function has.

    >
    > Correct. There are times when that differences allows you to easily
    > wrap repeated code without having to fuss with complex parameter
    > lists. Again, repeated code is dangerous to long term maintenance.
    > If you want to help devs create maintainable code, eliminate cut/paste
    > from the editors!
    >
    >>Having said all this, there are situation where using GoSub would save time
    >>and resources, particularly in large complex (spaghetti?) routines that
    >>have not been broken into structured subroutines and using large numbers of
    >>variables.

    >
    > It's useful in smaller routines as well. Organized code is a mindset,
    > not a function of the programming language. Considering and using all
    > the tools is necessary.
    >
    >> It certainly is frequently a killer of readability and
    >>maintainability, and I know that I won't miss it, but then that's just my
    >>way of coding.

    >
    > Absolutely not, if you use it correctly. It even helps *improve*
    > readability when used right. If you have a long Case statement, for
    > example, you can sometimes keep the entire Select on one screen (or at
    > least reduce the real-estate) by pushing Case code to a GoSub.
    >
    > Again, it's all in how you learn to use it.
    >
    > We can make all these same arguments about misused inheritance or
    > classes. They're all tools. Used right, they're helpful. Used wrong
    > they create a mess that nobody can understand. Don't confuse
    > "political correctness" with usefulness.


    I don't give a **** about 'political correctness' in a language, and
    suggesting that's the reason for people disliking GoSub is rubbish.

    Please post some code to show how useful it is. I'm quite happy to use it
    in my VB6 apps if I find a use for it. I've struggled to find a need for it
    in the last 10 years, but I'm open to suggestions.

    Cheers,
    Jason

  12. #207
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Jason Sobell iGadget" <igadget_@hotmail.com> wrote in message
    news:jblcnw2q1z7$.d24fesw4e48d.dlg@40tude.net...
    > On Wed, 22 Jan 2003 18:00:45 -0600, Dan Barclay wrote:
    > > On Thu, 23 Jan 2003 09:07:37 +1100, Jason Sobell iGadget
    > > <igadget_@hotmail.com> wrote:
    > >
    > >>On Wed, 22 Jan 2003 15:15:22 -0600, Dan Barclay wrote:
    > >>> On Wed, 22 Jan 2003 14:19:34 -0600, Paul Clement
    > >>>>
    > >>>>I used it in old line coded basic, which had no Subs or Functions, but

    there was never any reason to
    > >>>>use it in QuickBASIC or any variant of the structured BASIC language.

    It is outdated just as GoTo
    > >>>>is.
    > >>>
    > >>> Oh, so GoTo is scheduled for removal? Didn't know that. I suppose it
    > >>> makes about as much sense though. I've been outta touch but I'm glad
    > >>> you're keeping up with 'em.
    > >>
    > >>I also doubt if GoTo will be removed. The GoSub has almost direct
    > >>replacements, but GoTo doesn't, and there are sometimes situations where
    > >>GoTo gives enormous simplification (possibly at the expense of

    structure).
    > >
    > > GoSub does not have almost direct replacements either. You can code
    > > without it, but not by substituting a direct or near direct
    > > replacement.

    >
    > Why not? A Gosub to a routine that modifies intA and intB can be replaced
    > with Call DoWhatever(intA, intB).
    > Is there a syntactically identical alternative? No.


    There are three cases that I can think of where Subs are at a disadvantage
    compared to a well-implemented GoSub

    1. If there are a very large number of parameters being processed, the
    overhead of passing them in the parameter list of a Sub may be excessive. At
    present, the only alternative (using module-level or global variables)
    unnecessarily increases the scope of those variables and so increases the
    risk of coupling.

    2. The Gosub is the only means in VB of providing a nested routine, whose
    scope and visibility is limited to only the Sub or Function that contains
    it. Keeping the scope of routines and variables limited is generally
    regarded as a GoodThing, and VB.NET has started moving in that direction by
    allowing variables to have a scope less than an entire routine.

    3. If a complex algorithm which is a pure calculation not dependent on the
    platform it is running on was coded in an early version of Basic using
    Gosubs, it continues to work and its performance is adequate, there should
    be no need or purpose in rewriting it. RAD development is most R when you
    can use existing code that is already tested and working.


    > > You can also code without GoTo''s and there are people who say you
    > > should do that. Eliminating it makes as much sense. Considering
    > > there are people who don't know how to use them properly, they should
    > > be protected!

    >
    > Yes, that is an 'ivory tower' attitude, but if we really wanted to protect
    > people from themselves we would make every PC user take a competency test
    > before giving them a keyboard


    That is an attitude I have heard very often among programmers - "don't give
    people tools that are easy to use - idiots will try to use them!" I've heard
    it said by C++ programmers about VB, and from VB and SQL programmers about
    Access. Something similar was said about the first assembler languages -
    that use of the machine should not be substituted for thought and effort on
    the part of the programmer. Needless to say, it's not a point of view I have
    much time for. If it were generally accepted, we would still be coding in
    raw machine code.


    --
    Regards
    Jonathan West


  13. #208
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    David,

    > > In a world tending toward platform independent languages that is a null
    > > argument. So when Windows 64 comes out we change all the definitions

    > again?
    >
    > Perhaps


    Does 'Perhaps' mean you are not sure? I believe the question requires a yes
    or no answer.

    > though 32-bit values on most 64-bit platforms don't have the
    > performance issues that 16-bit values do on most 32-bit platforms

    (certainly
    > the Itanium and the Athlon 64/Opteron don't).


    So, does that mean that the meaning of the name was changed based only on
    performance issues?

    Why not call it the QuickInt or something like that?

    As for performance. For most practical purposes there is very little
    difference between using a 16 or 32 bit value as a counter. The difference
    will only be noticed in very tight loops where the values of the loop are
    extreemely high. Anyone doing that type of optimization knows exactly what
    he is doing and knows which data type to use.

    Gary



  14. #209
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Paul,

    > PRB: Poor Performance with the GoSub Statement
    > http://support.microsoft.com/default...b;en-us;174808
    >
    > In most instances it can be easily replaced by a Sub or Function. If

    performance was an issue, as
    > you indicate in your following points, I'm surprised that you continued to

    use GoSub.

    In my book, performance is always perceived performance. If a function takes
    ..01 of a second or .001 of a second to execute, there is no perceived
    performance difference to the user, unless the function is in a tight loop
    and executed hundreds of thousands of times. I do a lot of optimizing, but I
    have never run into a case where there was an observable slowdown due to
    using Gosub. If it were observable I would have gotten rid of it long ago.

    > Problem two: Binary file I/O
    >
    > Besides changing the syntax, which I can live with, but I don't

    understand
    > why it was necessary, it now runs at half speed. Since I have very

    intensive
    > file I/O that is extremely important to me. If Binary file I/O is not

    part
    > of the core language, what is?
    >
    > As far as I know it's still part of VB.NET. Maybe you could be more

    specific as to what you are
    > doing and over what period of time (the significance) the speed

    measurements are being taken.

    Simple Example:
    dim TemStr as string
    TemStr=Space(1000)
    open "Test.txt" for binary as 1
    do while not eof(1)
    get 1,,TemStr
    loop
    close 1

    Make sure you have a good sized file (100 MB for example) and time those
    lines. Convert to VB.Net and time again. It goes at 50% the speed.

    Unless of course you use the new stream class, in which case speed is about
    the same as VB6. What is the problem with the stream class? The code must be
    rewritten to adapt it to the class.

    > Well Mid is supported but once again you may want to indicate specifically

    what you are doing. It
    > could simply be the .NET environment and not the actual function.


    I've got many big recursive loops that makes intensive use of the Mid
    statement. The problem is not with the environment. The problem is that
    Vb.Net uses immutable strings. Therefore each Mid statement creates a new
    string. In VB6 the same string is overwritten again and again, thus the
    speed advantage over VB.Net.

    >And, it's possible the VB.NET
    > variation may be relatively easy to implement with a performance

    improvement.

    The code must be rewritten in order to gain the performance improvement. And
    worse yet, StringBuilder does not have a MID statement, so a workaround must
    be created.

    > Just these three problems are enough to stop my show, and all three are

    part
    > of the core language.
    >
    > Yes, only one of which is obsolete. As I mentioned the actual .NET

    environment may be as much as a
    > factor as anything else.


    And the other two are sufficiently damaged so as to make them the same as
    obsolete. For my practical purposes none of them can be ported, all must be
    rewritten.

    Gary



  15. #210
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Tom,

    > Take file I/O. Gary keeps complaining about how slow it is - and it is if
    > you use the VB.NET intrinsic functions. But if you take the time to

    figure
    > out the stream classes in System.IO, which are not all that difficult,

    then
    > you would find that it is just as fast.


    Again the problem is the ton of code I've got. Doing new work with the
    stream classes is easy, rewriting all the binary access I've got is not. If
    I could push my code over to Net, then little by little I could move to the
    newer ways of doing things, but I can't take a 50% performance hit in the
    meantime.

    By the way, the reason I've mentioned this several times is that it seems
    very arbitrary that the new stream classes are up to speed, but the old
    binary access is half the speed. What is MS doing here? If the new streams
    are fast, why isn't the binary access going the same speed? Is it
    intentionaly slow?

    Gary



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center