Microsoft's C++ bigotry - Page 15


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 15 of 43 FirstFirst ... 5131415161725 ... LastLast
Results 211 to 225 of 633

Thread: Microsoft's C++ bigotry

  1. #211
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

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


    Very good point here. In fact I often (in the past) used GoSub just for this
    purpose. It makes code much more readable.

    I've been eliminating this type of code now (to make it more portable) and
    it is much more difficult to read.

    Gary



  2. #212
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Jason,

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


    I would just like to add two details to what Jonathan mentions about the
    benefits of Gosub over Subs.

    On point 2: "Keeping the scope of routines and variables limited is
    generally
    regarded as a GoodThing"

    Whenever I have code that can be used from different places in the
    program I always put it into a sub or function, but when the code is local,
    keeping it within a sub by using gosub keeps the modules much cleaner. All
    of the subs and functions within the module are significant. The elimination
    of Gosub will now force me to create a lot of nonsensical subs.

    I would add another advantage to using gosubs. In VB6 you don't have to
    restart VB when you add a gosub, but you do have to restart VB to add a sub
    or function. When you are deep into a big program that alone can save a
    significant amount of time.

    Gary




  3. #213
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Larry,

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


    Functions and Subs do things that Gosub doesn't and can't do. Just as
    Classes do things that Functions and Subs can't do.

    But I think you knew that.

    Gary



  4. #214
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Jason,

    > 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


    What does GoSub have to do with a function that takes and returns no
    parameters?

    > Binary file handling is a very low level function, but I'm not sure if
    > you'd class it as a core part of the language.


    Is that a joke? Binary file handling has been a part of the Basic language
    since it first apeared. If VB didn't handle binary files I would have
    changed languages long ago.

    > Noooo... not the old Mid$ complaint again. We already covered this in

    depth
    > and I still don't believe it's a valid argument.
    > We found a way to perform the same function that your VB6 was performing,
    > and it ran twice as fast, but you didn't want to change the calling code

    to
    > use a different data structure.


    I think you are missing the point. Paul said that the changes in VB.Net
    didn't affect the core language. If I have to rewrite the code, I consider
    that the core language has changed. True, Mid exists, but it is not
    functional.

    Gary



  5. #215
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 15:15:22 -0600, Dan Barclay <Dan@MVPs.org> wrote:



    >Correct. The decision was to de emphasize its usage, which is one of the reasons they suggest using
    >Subs and Functions as they had no plans on optimizing it.

    LOL. Your argument is that they made it slow on purpose? Ya know,
    before VB7 came out I wouldn't have believed this but now you've
    cleared up a lot of confusion for me.

    Uh, no I don't think they made it slow on purpose but my guess is that you probably believe that
    there was some conspiracy theory to implement it that way so that it could be deprecated.

    Everyone at MS was out to get GoSub! ;-)


    I was misinformed that they accidentally created an ugly hack to get
    around With and some other gotcha's, then were too scared to touch it
    once they got it working. Silly me for believing that!

    They kinda backed themselves into that hack because of the
    interpreter. The sad part is that, now that they're using a pure
    compiler, they could have gone to source substitution. It would have
    been dead simple, and performance overhead would have been zero.
    ****, I offered to implement it if they'd provided a preprocessor
    hook(s) for the Basic[sic] compiler.

    Again, silly me, I didn't realize that they wanted to sabotage it!
    So, *** do I know!

    I think you know that answer to that one.


    > Gary is not alone, by a long shot, in his use of GoSub. It's a useful
    > construct. Like *any* other, it can be misused (care to survey .cls
    > files of typical projects???). If you've never learned to use GoSub
    > (or classes!) properly, that's unfortunate but it does not mean they
    > are bad things that you should expect Microsoft to protect you from.
    >
    >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.

    You bet.


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

    Well if you consider Do...Loop and While...Wend etc. containers then I guess GoSub is as well. ;-)

    It can't hold data specific to its function and it isn't a parent to its code. It's a code
    navigational structure.


    >It causes the code to branch down and then back up through the code in its container - a prime
    >example of spaghetti code.

    LOL. You've *got* to be kidding. This is exactly what Subs and
    Functions do, by your definition, except that they also carry their
    own variable space. We've gotta stop that Sub branching, yessireee.

    Nope. They do not inherently branch down, bypassing a chunk of code, and then return when they're
    finished.

    I can't imagine that you need to be drawn a road map documenting the flow of logic between a GoSub
    and Subs or Functions. You've been doing this stuff long enough to know that.


    Hmmm... have you been implementing your GoSubs using GoTo's and
    branches? Like I said, maybe you should learn something about it.

    Perhaps you should learn about Subs and Functions so you can discriminate between them and GoSub.
    Are you finished now?


    Sounds like all you want in your toolbox is a hammer. Why do you
    insist that everybody else leave their screwdrivers at home as well?

    How about using the more efficient tool? Accepting the fact that GoSub was significantly slower
    (regardless of what MS intended it to be), why still use it? Or do you use a screwdriver to pound in
    nails?

    >
    > In most places I use them it would require extensive parameter lists.
    > The idea is to eliminate duplicated code fragments for maintenance
    > reasons, but to replace them with equally long parameter lists or,
    > (God forbid) module level variables would only trade one problem for
    > another.
    >
    >Well I think you know from our past discussions that I will never buy this. First GoSub is a
    >branching mechanism.

    Branching mechanism? That's why it was initially implemented with
    Call/Ret, huh?

    Does it matter?


    >Branch and returns (used instead of Subs and Functions) lead to some rather
    >confusing and difficult to debug code. It also unnecessarily increases the size of Subs and
    >Functions, causing the same types of problems.

    Nope.

    Please see my previous discussion (which you snipped) regarding taking
    the effort to properly use it.

    Doesn't matter. As I said before it directly affects the flow of logic in your Sub or Function. The
    execution of code in the Sub or Function flows in both directions which makes code more difficult to
    work with.


    Oh, and while you're at it maybe you should educate some of the idiots
    on how to use classes before someone gets the bright idea that we
    should be protected from those as well.

    Except they aren't inherently poor structures.


    Holy cow! Just think of the crap someone is going to write using
    inheritance!!! ****, I was planning to use that some day and now
    they'll probably remove it because it has sharp edges.

    >If you are worried about long parameter lists, you can use a parameter array.

    Same issue. It adds complexity where none is needed. Keep it
    simple...

    You use GoSub and you're complaining about complexity? ;-)


    > Hmmm... if they've made Mid$() slow, using your argument of GoSub,
    > perhaps this means they're about to drop it?
    >
    >Yes, but the migration path for those Visual Basic functions are likely to remain for quite a while
    >(as they did for GoSub in "Classic" VB).

    Has MS said to migrate from Mid(), or is that just your opinion?

    No it was a return of sarcasm.


    Paul ~~~ pclement@ameritech.net
    Microsoft MVP (Visual Basic)

  6. #216
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 11:59:04 -0000, Jonathan West wrote:
    > "Jason Sobell iGadget" <igadget_@hotmail.com> wrote in message
    > news:jblcnw2q1z7$.d24fesw4e48d.dlg@40tude.net...

    [Snip]
    >> 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.


    Point 1 is a very unusual situation. Modifying more variables than you want
    to pass to a function? If the variables were closely bonded they would
    probably be in a structure or a class, but obviously there could be a
    situation... Chances are that it would be a spaghetti code routine.
    Performance could be a plus point (which I mentioned somewhere yesterday)
    but apparently is not because of the VB6 implementation.

    Point 2 sounds like another scope argument. Not sure how it's relevant, and
    not convinced it even makes sense. A feature with no scope impact is good
    because..? A system that has no concept of data-hiding is good because..?

    Point 3 is a dodgy version compatibility comment, but seems to boil down to
    "It's easier if it works in v2 the same as v1"

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


    And it's not an argument I particularly agree with, which is why I
    mentioned your comment "Considering there are people who don't know how to
    use them properly, they should be protected!"

    Cheers,
    Jason

  7. #217
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 12:53:45 -0000, Gary Nelson wrote:

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


    Er... you said earlier that you avoid using the Subs for performance
    reasons, Paul commented that it was very slow, so now you tell us that
    although it's slower, it's the *perceived* performance that's important?

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


    So, again we are back to a code compatibility issue that is based on the "I
    want it to be faster but I don't want to adopt the faster way of doing
    things"?

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


    They are not *damaged*, they work in a different way. Having to rewrite
    sections of code is a pain, but the time you've spent writing these
    postings would probably have easily covered the conversion work.
    As Larry once so quaintly put it, "You have to learn to think outside the
    box".

    Cheers,
    Jason

  8. #218
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 13:28:18 -0000, Gary Nelson wrote:

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

    >
    > I would just like to add two details to what Jonathan mentions about the
    > benefits of Gosub over Subs.
    >
    > On point 2: "Keeping the scope of routines and variables limited is
    > generally
    > regarded as a GoodThing"
    >
    > Whenever I have code that can be used from different places in the
    > program I always put it into a sub or function, but when the code is local,
    > keeping it within a sub by using gosub keeps the modules much cleaner. All
    > of the subs and functions within the module are significant. The elimination
    > of Gosub will now force me to create a lot of nonsensical subs.
    >
    > I would add another advantage to using gosubs. In VB6 you don't have to
    > restart VB when you add a gosub, but you do have to restart VB to add a sub
    > or function. When you are deep into a big program that alone can save a
    > significant amount of time.


    True, which is another reason I compared VB6 to wirewrap. You can bodge in
    another GoSub function to your colossal monolithic application during debug
    instead of designing your solution in advance

    Cheers,
    Jason

  9. #219
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 20:47:06 +0000, Mike Mitchell <kylix_is@yahoo.co.uk> 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!

    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.

    This argument against passing parameters to Subs or Functions is so ridiculous. It's a fundamental
    feature of writing structured code. There is nothing fundamental with respect to GoSub. It's an
    inherent spaghetti code branching mechanism. It was useful back in the days when BASIC didn't
    support code containers, but it's now outdated.

    I learned along time ago that you avoid writing code structures where the flow doesn't execute from
    top to bottom (with the exception of looping mechanisms where code execution is controlled). And
    this was in the age when BASIC supported only GoTo and GoSub, no Sub or Function code structures -
    the reason why my choice of language at the time was Pascal.

    Divide and conquer. It works for me and when looking at the code of others it's always the easiest
    to decipher and debug.


    Paul ~~~ pclement@ameritech.net
    Microsoft MVP (Visual Basic)

  10. #220
    Dave Guest

    Re: Microsoft's C++ bigotry


    "Tom Shelton" <tom@mtogden.com> wrote:
    >
    >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
    >


    I'm aware of the *old* (VB3 era) problem with ReDim Preserve and it seems
    that you and Rod dropped your performance tests around then. In VB6 it is
    incredibly fast - so fast that redimming in blocks was a waste of time, not
    to mention kludgy programming. As a result of tests I did a few years ago
    I removed the kludgy chunky array redimming in VB6. Please try a test - if
    you're redimming in an extensive loop you'll see that VB.NET is horribly
    slow.

    If you're too pressed for time, here's some test code - run it on both VB6
    and VB.NET before assuming I'm an idiot:

    Dim iTest As Integer
    Dim iArray() As Integer
    For iTest = 1 to 100000
    ReDim Preserve iArray(iTest)
    Next iTest


  11. #221
    David A. Rothgery Guest

    Re: Microsoft's C++ bigotry

    Gary Nelson <gn@contanet.es> wrote:

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


    Just guessing, but there's probably a fair amount of overhead in either
    using streams to get behavior _exactly_ like VB6, or using COM interop
    to get at the old implementation.

    --
    Dave Rothgery
    Picking nits since 1976
    drothgery@alum.wpi.edu
    http://drothgery.editthispage.com

  12. #222
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 12:29:52 -0000, "Gary Nelson" <gn@contanet.es>
    wrote:

    >Why not call it the QuickInt or something like that?


    Why not call it a "number"? In other words, let's just have variants,
    okay? They work, don't they? I always thought variants were pretty
    rough and approximate nasty little things only to be used by VB Script
    merchants. And then I started writing VB Script...

    Honest, for a lot of uses, variants are the biz! Memory is cheap, disk
    space is cheap. Let's hear it for variants, ra ra ra! (Bags I the
    frilly skirt and the pom-poms!)

    MM

  13. #223
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

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

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


    But what about a GoSub block that modifies or reads intA, intB, strC,
    dblD, gets some values from arrays E, F and G, and also makes use of a
    local constant? You going to pass that lot to a Sub just to remain a
    purist?

    MM

  14. #224
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 11:59:04 -0000, "Jonathan West" <jwest@mvps.org>
    wrote:

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


    Let me assure people who are still, or expect to be, coding in
    B.A.S.I.C. (including the VB version) that GoSub is NOT slow! For
    business usage it is absolutely fast enough. Obviously, if one were
    using VB for the SETI project, say, then maybe GoSubs would be
    optimised out. But, like so much in quick, easy, facilitative
    computing, it's horses for courses, and this horse wins most of my
    races!

    MM


  15. #225
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 11:59:04 -0000, "Jonathan West" <jwest@mvps.org>
    wrote:

    >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'm sure that what those people really mean to say is, don't give
    ordinary people the tools we use, otherwise they might make us look
    ordinary! Especially C++ers can't seem to stomach the fact that VB can
    so often deliver a far better solution. Better in terms of it being
    completed on time and within budget. Better in terms of it providing
    the desired solution. Better in being amenable to cognisance by other,
    new programmers with minimal previous exposure. Better in its being a
    felxible solution that can be easily modified. I reckon the C++ers
    working on the VB.Net project must have felt a frisson in their pants
    as they were aware all the time what a good kicking they were giving
    to diehard (but hitherto faithful and trusting) VBers, like me.

    Anyway, programming has got a LOT farther to go before it can truly
    become a commodity than any average worker can utilise. VB was the
    start of it; Microsoft (or Cooper Research) could have taken it to the
    next stage, which in my opinion isn't where it's at now with VB.Net.

    MM

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