Microsoft's C++ bigotry - Page 12


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 12 of 43 FirstFirst ... 2101112131422 ... LastLast
Results 166 to 180 of 633

Thread: Microsoft's C++ bigotry

  1. #166
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    David,

    > Because in a language strictly tied to a platform,


    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?
    Not a good idea.

    > Integer should be the optimal integer size on the platform


    Why?

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


    Excuse me, but that is abusrd. No one is talking about making them work
    behind the scene as something else. What we are talking about is avoiding
    confusion. For example using Int16, Int32, Int64 is easy to understand and
    creates no confusion. But if I have a routine in VB6 that does binary file
    access and reads integers to and from the file and then convert that program
    to Vb.Net, I've got to make sure that every time I access the binary file in
    the Vb.Net program that I am no longer reading and writing integers but
    shorts. That can be very dangerous, because if just one gets by it'll blow
    my database.

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


    As if there are no errors waiting to happen in VB.Net.

    And, by the way, I am not a Notter. I have VB.Net installed and it has a lot
    of things I would have liked to have seen in VB6. In fact I've created
    several classes in VB6 that emulate things in VB.Net, which, of course will
    make the transition easier when I get there. But it is sure a shame that MS
    didn't make the transition easier. Integer is just another one of those
    unnecessary changes.

    Gary



  2. #167
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Patrick Troughton" <vb.@127.0.0.1> wrote in message
    news:3e2e0762$1@tnews.web.devx.com...
    >
    > I said this two years ago....MS should've created a VB7 with Managed

    Extensions
    > and that way they could have given us a no-holds barred version of VB.NET
    > and removed even more legacy features. Unfortunately, a small but vocal

    minority
    > of idiotic .NOTters like DB, KP, MM, GN and others had their heads so far
    > up their collective a** that they couldn't see the forest for the trees.


    I don't think anybody would have complained if a compatible language had
    been provided in addition to VB.NET. The problem is that option was not on
    offer from Microsoft.

    > As a response, MS gave us the disasterous beta 2 rollbacks which failed to
    > please anyone...just as I predicted.


    You weren't the only one. There was never going to be a "middle way" between
    the requirements of the two sides of the argument. Compatibility had to be
    done properly or it wasn't worth doing at all. If they don't do it properly,
    then they can kiss goodbye to bringing most of the existing VB6 codebase
    with them, no matter how many new languages they provide for the platform.

    > Oh well, there's nothing we can do about
    > it now.


    But there are plenty of things that Microsoft could do about it. Even now,
    they could provide something like the "VB7 with Managed Extensions" that you
    mentioned (in addition to keeping VB.NET), and at a stroke they would
    resolve almost all the arguments about this.

    --
    Regards
    Jonathan West


  3. #168
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Jonathan,

    > That remains to be seen. IMO, the main thing holding back many VB coders

    is
    > not the platform but the lack of a migration path. Because of that,

    interest
    > in the platform is limited to those early adopters who are willing to take
    > the plunge mainly with new projects, in the hope that history doesn't

    repeat
    > itself (again) or in blissful ignorance of the risks that it might.


    Absolutely. I find VB.Net very interesting. A little sluggish, but very
    interesting nonetheless. If I didn't have 140,000 lines of VB6 code and
    several thousand clients to maintain I would spend all my time there.

    > Until the migration path is sorted, there's kno way ultimately of knowing
    > how many people (and their applications) will move over. I guess quite a
    > large proportion, if they haven't gone to Delphi or Java first.


    Quite true. I would imagine that there are many in my position: Wait and
    see.

    Gary



  4. #169
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Paul,

    > Except I wasn't trivializing the upgrade which involves much more than the
    > core language. I think that was pretty clear in my first post.


    That's funny, because my main problems are with changes in the core
    language. Because I've been programming for a very long time (since
    gwbasic), and have had plenty of problems with third party tools, I
    generally do most of my programming in the core language.

    Problem one: Gosub

    I've got a truckload of Gosubs, about a thousand in just one program.
    Whether you like it or not, until VB.Net Gosub was part of the core
    language.

    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 extreemely important to me. If Binary file I/O is not part
    of the core language, what is?

    Problem three: Mid$

    Four hundred times slower in VB.Net. I make extensive use of Mid$. All
    routines that use Mid$ must be rewritten. Is not Mid$ part of the core
    language?

    Just these three problems are enough to stop my show, and all three are part
    of the core language.

    Gary





  5. #170
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Mike,

    > Okay, then. Sell it to me! What can I save? What will it cost? What do
    > I need it for? What do I do now?


    The little I have used VB.Net I've been very impressed. The 20MB library is
    not in vain, it's full of all kinds of neat stuff. When I've worked with it
    I've often said: Wow! I wish VB6 could do that!

    But all I can do is play, because I've got too much code to maintain and
    there is no way I can port it now. But if there were a way I could get my
    code across and get it working there would be no looking back.

    Gary



  6. #171
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 00:44:35 -0000, "Jonathan West" <jwest@mvps.org>
    wrote:

    >> >"Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message


    >> Windows API calls are not hacks. They are "using the Windows API". Dan
    >> Appleman wrote several books on using the API with VB, but they
    >> weren't books on hacks.

    >
    >Some of them are hacks. I'd call Matt Curland's book a hack from one cover
    >to the other, and I don't think that he would disagree with that assessment.
    >Its making VB do things is was never designed or intended to.


    Poking bytes into memory to change the program is a hack. Changing the
    address of a string pointer is a hack. Using the Windows API is not a
    hack.

    >> >Based on what you are saying, there's nothing of interest to you in

    >anything
    >> >about .Net, either in the platform or the languages which use it.

    >>
    >> Correct. Zilch.

    >
    >OK, glad we've got that straight. Would you mind taking a look at the name
    >of this newsgroup, and then ask why you choose to post here specifically?


    Because I can.

    MM

  7. #172
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 09:27:08 -0000, "Gary Nelson" <gn@contanet.es>
    wrote:

    >But all I can do is play, because I've got too much code to maintain and
    >there is no way I can port it now. But if there were a way I could get my
    >code across and get it working there would be no looking back.


    I just did a file scan on this (home) PC for *.vbp and it found 554
    files. This doesn't include sample progs in the VB folder or in the
    Crescent Software folder. Even if not all of those progs would require
    extensive rework to move them into VB.Net, *all* of them would need to
    be looked at individually, even the trivial ones. Contrary to that
    necessity, in VB3 to VB4/5 we just loaded the VB3 project, the IDE
    prompted for a few things, I seem to remember, then we compiled it and
    could release the 32-bit version almost immediately. In point of fact,
    we did do extensive testing first, and there were one or two funnies
    in the migration to be got over, but when I contemplate the vast
    number of VB apps that just three of my employers over the past 12
    years had, the potential for total rewriting over a few hundred
    thousand companies in the same boat must be enormous and
    insurmountable. Especially in view of the fact that many of the
    original authors will have left, and even the original design briefs
    may have been lost in the waters of time.

    MM

  8. #173
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On 21 Jan 2003 18:52:18 -0800, "Patrick Troughton" <vb.@127.0.0.1>
    wrote:

    >I said this two years ago....MS should've created a VB7 with Managed Extensions
    >and that way they could have given us a no-holds barred version of VB.NET
    >and removed even more legacy features. Unfortunately, a small but vocal minority
    >of idiotic .NOTters like DB, KP, MM, GN and others had their heads so far
    >up their collective a** that they couldn't see the forest for the trees.


    Might I assure people that at no time did I place my head up anyone's
    arse, for it would be rather a stupid and smelly thing to do. Just
    wanted to make that point clear.

    MM

  9. #174
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 08:46:07 -0000, "Jonathan West" <jwest@mvps.org>
    wrote:

    >But there are plenty of things that Microsoft could do about it. Even now,
    >they could provide something like the "VB7 with Managed Extensions" that you
    >mentioned (in addition to keeping VB.NET), and at a stroke they would
    >resolve almost all the arguments about this.


    I'm a bit dubious about these "managed extensions". What would they
    entail?

    MM

  10. #175
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:931t2vk6i8n4aaufdpfnmq66m3sdganfpn@4ax.com...
    > On Wed, 22 Jan 2003 08:46:07 -0000, "Jonathan West" <jwest@mvps.org>
    > wrote:
    >
    > >But there are plenty of things that Microsoft could do about it. Even

    now,
    > >they could provide something like the "VB7 with Managed Extensions" that

    you
    > >mentioned (in addition to keeping VB.NET), and at a stroke they would
    > >resolve almost all the arguments about this.

    >
    > I'm a bit dubious about these "managed extensions". What would they
    > entail?


    Simply stated in terms of the way they are presented in the language, that
    would be the object model that accesses the .Net framework.

    --
    Regards
    Jonathan West


  11. #176
    Patrick Troughton Guest

    Re: Microsoft's C++ bigotry


    "Jonathan West" <jwest@mvps.org> wrote:
    >
    >
    >I don't think anybody would have complained if a compatible language had
    >been provided in addition to VB.NET. The problem is that option was not

    on
    >offer from Microsoft.


    No, but did the .NOTters ever ask for a VB7 with Managed Extensions? No,
    they focused their attention on two strategies...

    1 - Compromising the VB.NET language (such as adding GoSub and getting rid
    of BitAnd, BitOr, etc.)
    2 - Rejecting the whole concept of .NET itself.

    The first strategy only succeeded in pissing off the pro-.NET folks which
    split the VB community in two.

    The second strategy was even more stupid than the first. It succeeded in
    pissing almost everyone off, pro-VB.NETters and MS. In fact, it alienated
    MS - the very people they wanted to help them. Even the ".NOT" phrase they
    thought they so cleverly coined worked against them.

    Both were self-defeating, and doomed to failure. The .NOTters should have
    pursued a third strategy...

    3 - VB7 with Managed Extensions.

    ...Almost no VB.NET programmer would have objected to this option. The .NOTters
    would have got the compatible language they wanted, and the VB.NETters would
    have got the no-holds barred language they wanted. The VB community would
    never have been split in two. Plus, rather than a condemnation of .NET, a
    VB7 with Managed Extensions would actually be considered an endorsement of
    .NET while still retaining "language stability". The .NOTters were their
    own worst enemy.

    Would MS have listened? Maybe they would have, maybe no. I don't know. But
    since it was never tried, we never found out.

    There's more I wish I could say, but I'm under NDA....

    /Pat
    ---------------------------
    It's the platform, stupid.
    ---------------------------

  12. #177
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 09:15:16 -0000, "Gary Nelson" <gn@contanet.es> wrote:


    That's funny, because my main problems are with changes in the core
    language. Because I've been programming for a very long time (since
    gwbasic), and have had plenty of problems with third party tools, I
    generally do most of my programming in the core language.

    Problem one: Gosub

    I've got a truckload of Gosubs, about a thousand in just one program.
    Whether you like it or not, until VB.Net Gosub was part of the core
    language.

    It was one of the few language elements to go. Microsoft has been more or less de emphasizing this
    construct for years and never optimized it for Visual Basic:

    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.


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


    Problem three: Mid$

    Four hundred times slower in VB.Net. I make extensive use of Mid$. All
    routines that use Mid$ must be rewritten. Is not Mid$ part of the core
    language?

    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. And, it's possible the VB.NET
    variation may be relatively easy to implement with a performance improvement.


    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.


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

  13. #178
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:hvvs2vc6foumq3gg2vp8a2f4p3lve8pdt9@4ax.com...
    > >> >Based on what you are saying, there's nothing of interest to you in

    > >anything
    > >> >about .Net, either in the platform or the languages which use it.
    > >>
    > >> Correct. Zilch.

    > >
    > >OK, glad we've got that straight. Would you mind taking a look at the

    name
    > >of this newsgroup, and then ask why you choose to post here specifically?

    >
    > Because I can.


    In that case, I can ignore you in future. You *are* the weakest link.
    Goodbye.

    --
    Regards
    Jonathan West


  14. #179
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 09:15:16 -0000, Gary Nelson wrote:

    > Paul,
    >
    >> Except I wasn't trivializing the upgrade which involves much more than the
    >> core language. I think that was pretty clear in my first post.

    >
    > That's funny, because my main problems are with changes in the core
    > language. Because I've been programming for a very long time (since
    > gwbasic), and have had plenty of problems with third party tools, I
    > generally do most of my programming in the core language.
    >
    > Problem one: Gosub
    >
    > I've got a truckload of Gosubs, about a thousand in just one program.
    > Whether you like it or not, until VB.Net Gosub was part of the core
    > language.


    Yep, it's been around since the original BASIC, but I don't think I have
    used it more than once in 10 years of VB
    I've used GoTo a few more times, but almost never GoSub.
    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
    I suppose it depends on the type of application you are writing. What were
    you using it for in your application?

    > 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 extreemely important to me. If Binary file I/O is not part
    > of the core language, what is?


    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.
    Moving it externally makes it more machine and filesystem independent, and
    making it into a stream type of file handling makes it much more flexible
    overall but may indeed introduce overhead with some functions.

    > Problem three: Mid$
    >
    > Four hundred times slower in VB.Net. I make extensive use of Mid$. All
    > routines that use Mid$ must be rewritten. Is not Mid$ part of the core
    > language?


    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.

    > Just these three problems are enough to stop my show, and all three are part
    > of the core language.


    They certainly highlight the compatibility issues, and shows how some
    applications can be even more difficult to convert than others.

    I guess we have to accept that with VB.NET some
    applications/modules/functions require rethinking instead of conversion.

    Cheers,
    Jason

  15. #180
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 07:50:32 -0600, Paul Clement wrote:
    > On Wed, 22 Jan 2003 09:15:16 -0000, "Gary Nelson" <gn@contanet.es> wrote:
    > 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.


    Wow, and I assumed GoSub would be more efficient. I have never seen this
    article before and I had no idea this issue existed.
    Lucky I never used it

    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