Microsoft's C++ bigotry - Page 22


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 22 of 43 FirstFirst ... 12202122232432 ... LastLast
Results 316 to 330 of 633

Thread: Microsoft's C++ bigotry

  1. #316
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 18:08:29 -0000, "Jonathan West" <jwest@mvps.org> wrote:


    "Paul Clement" <UseAdddressAtEndofMessage@swspectrum.com> wrote in message
    news:l7p23vck94shgkheh1e3lhov6229o5u4qg@4ax.com...
    > On 23 Jan 2003 11:22:16 -0800, "Kent" <kp@kp.org> wrote:
    >
    >
    > If that is the migration path, then no one should be surprised that some
    existing
    > shops and customers refuse to use VB.Net.
    >
    >
    > And that's why those of us who support .NET believe that much of the
    complaining about
    > incompatibility is simply a red herring and that the dislike for it
    extends beyond this issue.

    What do you think the issue is then, since you don't believe what we are
    saying?

    I don't think I said I didn't believe you. I just think there is more to the dislike of the
    environment than compatibility.

    I guess the question is, if you were able to port your app perfectly would you still be interested
    in working with and learning the new extensions, new rules, and new environment? I'm somewhat
    dubious of that.


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

  2. #317
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Paul Clement" <UseAdddressAtEndofMessage@swspectrum.com> wrote in message
    news:nf333vkbr0otnf1osn182g3h4afuq163ih@4ax.com...
    > On Fri, 24 Jan 2003 18:08:29 -0000, "Jonathan West" <jwest@mvps.org>

    wrote:
    >
    >
    > "Paul Clement" <UseAdddressAtEndofMessage@swspectrum.com> wrote in

    message
    > news:l7p23vck94shgkheh1e3lhov6229o5u4qg@4ax.com...
    > > On 23 Jan 2003 11:22:16 -0800, "Kent" <kp@kp.org> wrote:
    > >
    > >
    > > If that is the migration path, then no one should be surprised that

    some
    > existing
    > > shops and customers refuse to use VB.Net.
    > >
    > >
    > > And that's why those of us who support .NET believe that much of the
    > complaining about
    > > incompatibility is simply a red herring and that the dislike for it
    > extends beyond this issue.
    >
    > What do you think the issue is then, since you don't believe what we are
    > saying?
    >
    > I don't think I said I didn't believe you. I just think there is more to

    the dislike of the
    > environment than compatibility.
    >
    > I guess the question is, if you were able to port your app perfectly would

    you still be interested
    > in working with and learning the new extensions, new rules, and new

    environment? I'm somewhat
    > dubious of that.


    You're just using a different form of words to say you don't believe me.
    What reason do you have to think that? Do you have any particular post of
    mine that suggests that?

    --
    Regards
    Jonathan West


  3. #318
    Larry Triezenberg Guest

    Re: Microsoft's C++ bigotry

    LOL (sorry, couldn't help myself)

    "Dan Barclay" <Dan@MVPs.org> wrote in message
    news:7gc03v0cjqqqp1s7f8rg3264kn9782flth@4ax.com...
    > On Fri, 24 Jan 2003 01:15:49 +1100, Jason Sobell iGadget
    > >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"

    >
    > I'll be danged. What a concept! I wish I'd have though of that
    > myself.




  4. #319
    Larry Triezenberg Guest

    Re: Microsoft's C++ bigotry

    There are also examples where it's better, so what's your point exactly?

    "Larry Serflaten" <serflaten@usinternet.com> wrote in message
    news:3e3164a6@tnews.web.devx.com...
    > More times than not, it is not needed, and there are better ways to get

    the
    > job done. In the case of Gosub, a separate procedure is often a better
    > route. In the case of Variants, strongly typed variables are often a

    better
    > route. There are other such examples...




  5. #320
    Dan Barclay Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 09:52:34 -0600, Paul Clement
    <UseAdddressAtEndofMessage@swspectrum.com> wrote:

    >On Thu, 23 Jan 2003 14:18:29 -0600, Dan Barclay <Dan@MVPs.org> wrote:
    >
    >
    >
    > >It can't hold data specific to its function and it isn't a parent to its code. It's a code
    > >navigational structure.
    >
    > The same would be true for masm Call/Ret as well, eh?
    >
    >No. A Sub or Function doesn't affect the flow of code (navigation) in the calling routine - it
    >simply suspends execution until control is returned. A GoSub/Return does control the flow of
    >execution - it is part of the functioning code in the Sub or Function which contains it. That is the
    >problem.


    You've got to be kidding. Sub/Function *transfers* control. Just
    like GoSub.


    >
    >
    > >
    > > >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.
    >
    > Really? Every sub/function and GoSub I've seen does exactly this.
    >
    >A Sub, Function or method call to an instanced Class does not do this. If you have a snippet code
    >that demonstrates your claim you are welcome to post it.


    Trace any Sub/Function at any level (source, IL, or cpu). From a
    language standpoint, only level at source matters but it turns out
    that for sub/function (and Class, btw) it does it at all levels.

    > >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.
    >
    > You're right. I've done it once before, and I understand it fairly
    > well. Heck, I even wrote a class once.
    >
    >Well then I guess you understand the distinction after all.


    Yes, from a structure standpoint the distinction is variable scope and
    framing, not flow behavior.

    > >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?
    >
    > If it were fixed (it can be) and were faster than Sub/Function, would
    > you argue that I should be using GoSub instead of Sub/Function??
    >
    >Nope, because of the inherent problem of creating spaghetti code. And if the GoSub implementations
    >you are referring to are as straightforward as you say they are I see no reason why they can't be
    >converted to an actual container such as a Sub or Function. If the GoSub implementations are not as
    >straightforward, then you will likely have a maintenance problem when someone else has to review
    >your code.


    B B But you were arguing "How about using the more efficient tool"
    (see above). Learn what you're talking about and figure out some
    argument.

    > Performance is the decision point only on "hot" code that has high
    > impact on your overall app's performance. In the remaining 99.9% of
    > code, maintenance and readability are more appropriate decision
    > points.
    >
    >It's much cheaper to buy the performance that you may sacrifice in order to write more readable
    >code, than to pay someone to maintain, convert, or fix code that is difficult to decipher.


    That was exactly my point. Glad you "got it".

    > > > 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?
    >
    > Only if you think it's a branching mechanism. GoSub does not create a
    > logical branch. It executes code as if it were inline, returning to
    > the next statement.
    >
    >Well no I don't consider a call to a Sub or Function a branching mechanism. Branching occurs within
    >a code container.


    Branching occurs with branching operations, whereever they happen to
    be. Non branching occurs with nonbranching operations, wherever they
    happen to be.

    Just because a statement is in a code container does not mean that
    it's a branching operation.

    > > >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.
    >
    > Nope, it does not affect the logic.
    >
    >I said it affects the "flow" of logic.


    It does not affect the logic. *** is "flow of logic" if it's not
    logic based?

    > > 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.
    >
    > That's what you and I think. There are some folks who don't agree
    > with us. I've found, from experience, that those folks sometimes get
    > the ear of the implementors.
    >
    >Well they're wrong. ;-)


    Certainly somebody is!

    > > 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? ;-)
    >
    > GoSub is a far more simple construct than even Sub/Function, much less
    > classes or inheritance. Do not confuse power with simplicity. In
    > fact, the more powerful features are generally the more complex.
    >
    >I guess we're going to have to just disagree on this point. The concept of GoSub is simple, the
    >implementation causes code maintenance headaches.


    LOL. Classes and inheritance don't??? ROTFLMAO!

    Dan

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

  6. #321
    Dan Barclay Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 10:05:15 -0600, Paul Clement
    <UseAdddressAtEndofMessage@swspectrum.com> wrote:


    >OK, I'm confused. How do you execute a GoSub statement if it's after an Exit Sub or Function.


    You're kidding, eh? *Please* say you're kidding. This could explain
    a lot.

    Sub MySub()

    GoSub DoDaSub

    Exit Sub

    DoDaSub:
    Return

    End Sub


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

  7. #322
    Larry Triezenberg Guest

    Re: Microsoft's C++ bigotry

    Yes, you're saying that you don't believe him. Perhaps that's not what you
    meant.

    There are lots of developers that I know using VB6 who would love to upgrade
    and get to some of the new bells & features and keep current. Then they
    look at the cost of moving the existing codebase and .NET becomes something
    interesting to look at in your spare time but not suitable for real work
    (real work often involves real applications and those real applications
    often already exist but require modifications/extensions/enhancements). So,
    ..NET goes into the project queue for when there is time/money to rewrite the
    application AND/OR there is _sufficient_ need for the new features to
    require the expense of time/money to rewrite the existing codebase. That
    raises the bar much higher than just taking a couple of weeks to upgrade and
    being able to move on into taking advantage of some of the new features.

    "Paul Clement" <UseAdddressAtEndofMessage@swspectrum.com> wrote in message
    news:nf333vkbr0otnf1osn182g3h4afuq163ih@4ax.com...
    > I don't think I said I didn't believe you. I just think there is more to

    the dislike of the
    > environment than compatibility.
    >
    > I guess the question is, if you were able to port your app perfectly would

    you still be interested
    > in working with and learning the new extensions, new rules, and new

    environment? I'm somewhat
    > dubious of that.




  8. #323
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On 24 Jan 2003 08:52:38 -0800, <vb.@127.0.0.1> wrote:

    >Why don't you test it and find out? That's what real programmers do, Mike.


    Because I don't want to, but I thought others might have done. How
    about yourself? Are you a real programmer, or just an IP address?

    MM

  9. #324
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Larry Triezenberg" <ltriezenberg@pathsys.com> wrote

    > There are also examples where it's better, so what's your point exactly?


    You are welcome to provide one...

    LFS



  10. #325
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Larry Serflaten" <serflaten@usinternet.com> wrote in message
    news:3e31b75a@tnews.web.devx.com...
    > "Larry Triezenberg" <ltriezenberg@pathsys.com> wrote
    >
    > > There are also examples where it's better, so what's your point exactly?

    >
    > You are welcome to provide one...


    I already did. Dan described it in more detail. How many times do you need
    it repeated before you decide to read it?

    --
    Regards
    Jonathan West


  11. #326
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 09:52:34 -0600, Paul Clement wrote:

    > On Thu, 23 Jan 2003 14:18:29 -0600, Dan Barclay <Dan@MVPs.org> wrote:
    >
    >
    >
    >>It can't hold data specific to its function and it isn't a parent to its code. It's a code
    >>navigational structure.
    >
    > The same would be true for masm Call/Ret as well, eh?
    >
    > No. A Sub or Function doesn't affect the flow of code (navigation) in the calling routine - it
    > simply suspends execution until control is returned. A GoSub/Return does control the flow of
    > execution - it is part of the functioning code in the Sub or Function which contains it. That is the
    > problem.


    Not quite sure what you are saying here, but a Call/Ret in assembler is the
    equivalent of a GoSub except that you have access via the stack to the
    address of the calling routine.
    But... programming practise is to push a series of parameters (addresses or
    values) onto the stack before you make that call, so the called routine can
    access variables passed by the caller.
    This makes the structure exactly the same as a Sub or Function, and is how
    a Sub or Function is implemented in most languages.

    Doing a Call in assembler to a routine and allowing it to modify global
    variables is perfectly possible, but a very bad idea because you quickly
    lose track of the structure of your program and have the equivalent of
    spaghetti.
    I know this as fact because I wrote games (commercially) in assembler for 6
    years.

    GoSub has no equivalent of the "Use these variables" pointer (the Stack
    Pointer in assembler) so you must use variables that are global to the
    calling code.

    Arguing individual aspects of this is pointless. Well all know the syntax
    for GoSub, and some people want to keep it because they use it frequently.
    I don't and would strongly discourage people because it gives a small
    saving in time (and arguably performance) for a big loss in readability *in
    all but the very simplest implementation*.

    Yes, people can find individual instances where it might have an advantage,
    but they are few and far between.
    So we accept that it's gone and "move on"

    Cheers,
    Jason

  12. #327
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 14:06:14 -0600, Dan Barclay wrote:

    > On Fri, 24 Jan 2003 10:05:15 -0600, Paul Clement
    > <UseAdddressAtEndofMessage@swspectrum.com> wrote:
    >
    >
    >>OK, I'm confused. How do you execute a GoSub statement if it's after an Exit Sub or Function.

    >
    > You're kidding, eh? *Please* say you're kidding. This could explain
    > a lot.


    [Snip]

    Actually, Paul was right.
    You put your GoSub *routine* after the Exit, not your GoSub statement

    Read his previous posting properly.
    He is arguing that GoSub is not a container because it's inline, and he is
    correct. How about this:

    Sub Main()
    Dim a As Integer

    a = 0
    GoSub DoDaSub
    a = 1

    DoDaSub:
    Debug.Print "Hi, a=" + CStr(a)
    If a > 0 Then Exit Sub
    Return
    End Sub

    Yuk! I hope nobody would ever write code like this in their application.
    If we code it in the manner that BASIC originally intended (before we were
    given those lovely text labels instead of line numbers)

    1 a = 0
    2 GoSub 5
    3 a = 1
    4
    5 Debug.Print "Hi, a=" + CStr(a)
    6 If a > 0 Then Goto 8
    7 Return
    8

    or how about

    a = 0
    GoSub DoDaSub
    a = 1
    DoDaSub:
    Debug.Print "Hi, a=" + CStr(a)
    If a = 0 Then Return


    Is this getting any more readable yet?
    I think we can safely say that GoSub is *NOT* a container of any sort.

    Cheers,
    Jason

  13. #328
    Karl E. Peterson Guest

    Re: Microsoft's C++ bigotry

    Phil Weber <pweber@nospam.fawcette.com> wrote:
    > "Why should C++ developers enjoy such ease of migration to .NET,
    > while VB developers (of whom there are arguably many more) are forced
    > to rewrite their code?...The message seems clear: If your application
    > is 'mission-critical', don't use VB." --
    > http://www.philweber.com/net/2003/01/14.htm#a40


    **** straight. Straight, that is, out of Microsoft's playbook...

    "Moving on to comment on languages, Gates said that Microsoft's code base was still
    90% C or C++, and as such the company has a continuing commitment to these
    languages."

    Bill Gates on the future of programming languages
    http://www.vsj.co.uk/news/display.asp?id=108

    He couldn't even be bothered to discuss C# himself, apparently, handing the mic over
    to Hejlsberg at that point. No mention, whatsoever, of VB -- classic *or* corrupt.

    Later... Karl
    --
    [Microsoft Basic: 1976-2001, RIP]



  14. #329
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Jonathan West" <jwest@mvps.org> wrote
    > >
    > > > There are also examples where it's better, so what's your point exactly?

    > >
    > > You are welcome to provide one...

    >
    > I already did. Dan described it in more detail. How many times do you need
    > it repeated before you decide to read it?



    No you did not provide an example, you explained where Gosub might
    be advantagous in 3 situations, and later took one back. As I said then,
    you can use a module to limit scope, so it turns out the only good reason
    left is because that what was used before and there is no point to rewrite
    it.

    Dan explained a situation where there were several values to pass, and then
    went on to say:

    <quote>
    With GoSub,
    all you really have to do is wrap the call and GoSub to execute it.
    Gone are the opportunities to screw up the parameter list for 15 or 20
    instances of it. Also gone is the need to modify 15 or 20 instances
    of the call when you change the parameter list.
    </quote>

    (Neither of you provided example code)

    Such tightly coupled code can be placed in a module where only the
    one call is public, and the working variables are either passed in (to
    be passed on) or initialized by the routine. The ones that are passed
    in from the calling code, can be passed on to any helper routines.
    The module level variables that are initialized by the function, should
    not be passed as parameters. There would be no change in the parameter
    list unless the parameters change for the public function. In that case,
    however rare it may be, Dan has a point. But more than likely, such
    changes can be made via the Find/Replace dialog.

    It is possible to code it up that way, but it was not done that way at
    the start, so now you guys want to leave it as is. That is about the
    only valid reason you have for using Gosub, and IMHO it is not a
    very strong one....

    Iceboxes used to keep food cold by using a block of ice, do you
    see any such iceboxes today? Like the old west, eventually old
    code will be replaced by new. It is just a matter of how much kicking
    and screaming we have to hear about during the process....

    I've heard enough already. I don't plan to reply to another message on
    this topic. I am not the one making the decisions, and it is apparent there
    are two camps in the debate. You need to make your case to MS, because
    like classic VB, it does not bother me if Gosub is included in VB.Net,
    or not.


    LFS







  15. #330
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 19:41:46 -0600, Larry Serflaten wrote:

    > "Jonathan West" <jwest@mvps.org> wrote

    [Snip]

    Just as a matter of interest, and after reading that the GoSub function is
    such a favourite of VB developers, and wondering if I was missing out on a
    popular programming construct, I did a Google search on the term
    "Sample code" VB gosub
    I got back 37 matches (after Google removed duplicates from the 58 found)
    Of those, only a handful were code containing the command 'GoSub', and most
    were explaining what it was, or pointing out that it has been discontinued.

    Thinking this was a rather interesting set of data, I did it for a few
    other commands too (but didn't request the de-dupe on the biggies) :

    Command, Approx matches
    -
    GoSub, 58
    Call, 10200
    Function, 10900
    "End Sub", 3730
    "End Function", 1800
    printf, 180 ??
    format, 8990
    Variant, 2540

    Obviously, this is a very rough measurement of usage, and many matches are
    in conversational text instead of code, but the figures are at least
    indicative of the *popularity* of the more unique terms such as "GoSub" and
    "End Sub".
    So does this indicate that GoSub is a heavily used function and will be
    missed by a significant proportion of those 6 million VB developers that
    Dan mentioned?

    Cheers,
    Jason

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