Microsoft's C++ bigotry - Page 19


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 19 of 43 FirstFirst ... 9171819202129 ... LastLast
Results 271 to 285 of 633

Thread: Microsoft's C++ bigotry

  1. #271
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 12:13:21 -0600, "Larry Serflaten"
    <serflaten@usinternet.com> wrote:

    >Designs change, everything that man makes undergoes a process of improvement.
    >If you fail to improve your software, you stand to fall behind....


    Improvement, yes. Scrapping the bridge and putting in a ferry instead
    is just irritating.

    MM

  2. #272
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On 23 Jan 2003 11:55:26 -0800, "Bob" <vb.@127.0.0.1> wrote:

    >So if Mike isn't lying or crazy according to his own statement, he isnt'
    >developing in VB anymore--any version. Which is it Mike? Are you crazy or
    >just spreading FUD?


    I'm neither crazy, nor spreading FUD. All I asked was, did anyone test
    out the claims that GoSub is slower than achieving the same
    functionality through calling a Sub multiple times and passing maybe a
    dozen arguments?

    But, Bob, Bob! I have to say, please calm down! Blood pressure is
    supposed to be 120/80. Try keeping it that way!

    MM

  3. #273
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 11:40:28 -0600, "Larry Serflaten"
    <serflaten@usinternet.com> wrote:

    >You did not report your findings for the EXE, knowlegable people want
    >to know, what values did you see reported?


    That's because I have no wish to prolong your agony any longer. You
    don't like GoSub? Fair enough. End of story. I'm certainly not going
    to argue all night about it.

    MM

  4. #274
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 12:02:40 -0800, "Phil Weber"
    <pweber@nospam.fawcette.com> wrote:

    > > But I'm curious, perhaps you have a machine that computes
    > > differently than most...[run] the code below, and report your
    > > findings, just to check if it matches what the rest of us see...

    >
    >Larry:
    >
    > Gosub took: 1282
    > Subroutine took: 4436


    Thank God! Now, for f***'s sake, let's fuggedabout GoSub for five
    ruddy minutes!

    MM

  5. #275
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 13:11:53 -0500, "Mark Jerde"
    <mark.jerde@verizon.no.spam.net> wrote:

    >Round-trip UML tools are superior to paper specs since the design & code can
    >be kept in sync. Delphi 7 Architect ships with Bold, which is as I
    >understand it an even higher level abstraction than UML.


    Bold is a washing powder over here. Still, I suppose if you end up
    with a nice, clean design...! I'll have to take a look-see at this
    Bold.

    MM

  6. #276
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Mark Jerde" <mark.jerde@verizon.no.spam.net> wrote
    > > Could each be replaced by a call to a separate subroutine that includes the Append
    > > code:
    > >
    > > IncludeField dta, hTrx, "hTrx:"
    > > IncludeField dta, TrxTimeMs, "TrxTimeMS:"
    > > ... etc ...

    >
    > IncludeField has to have knowledge of whether or not to append Separator.
    > This could be done as a class (as I replied to myself ;-) but as a separate
    > subroutine two more arguments are needed:


    No, not really. I gave it a cursory glance and could easily see that would be
    a more tidy approach. I did not study it enough to duplicate the result, only
    to suggest what I thought would be a better design.

    To include the separator, you simply return the data and append it inline:

    > > DataOrHeader = DataOrHeader & IIF(dta, hTrx, "hTrx:") & Separator
    > > DataOrHeader = DataOrHeader & IIF(dta, TrxTimeMs, "TrxTimeMS:") & Separator


    And the last one in the list just doesn't use the Separator.


    > A few thoughts.
    > 1. Your solution doesn't appear to be a drop-in replacement w/o adding a
    > couple more parameters.


    No, it was made even simpler by using the intrinsic IIf function. (IIf may not
    have been present when you wrote it, but that was the function of IncludeField)

    > 2. Having started writing BASIC when an 8 MHz 8086 was a real screamer, I
    > admit having an inertia to GoSubs for string concationation of this form. I
    > am learning to think "classes" instead.


    Its a little late to be getting started now, is it not? Classes came in with version 4.
    But, better late than never!

    > 3. The "best" design can be the enemy of good. This solution works, runs
    > fast enough for the app, is easily "groked" IMO, fits on a page & is
    > encapsulated.


    Perhaps that is where the big dividing line is. You find it easy to read, because
    that is the way to like to write it. I find it more difficult to read because I like to
    keep a neat and ordered appearance, and for good reason:

    Take a look at the above statements and you'll see you can, if desired, move them
    all to a new function that takes one dta value, one Separator value and all the others
    as parameter pairs. Not that such would be needed, but because it is in an orderly
    fashion, you can see how it would be possible. That same thing holds true else-
    where, where it may matter. A list of common statements might be better run in
    a loop, for example. There are enough situations like that, where I've found it
    pays to strive to keep the code in a neat and orderly fashion to help with readability
    as well as optimizations, if that need arrises.

    All that code you might add to the end of a procedure (error handlers need some
    space too) I look at as so much clutter. You know, everytime you see a block of
    code down there, there has to be a coresponding jump to get there. It doesn't take
    too many such jumps to start making a simple routine look like spaghette code.

    That's why I think routines with extra code at the bottom is more difficult to
    follow than routines that have none. Its hard enough to try to follow the intentions
    of the code, without having to follow each and every jump.

    LFS



  7. #277
    Mark Jerde Guest

    Re: Microsoft's C++ bigotry

    > To include the separator, you simply return the data and append it inline:
    >
    >>> DataOrHeader = DataOrHeader & IIF(dta, hTrx, "hTrx:") & Separator
    >>> DataOrHeader = DataOrHeader & IIF(dta, TrxTimeMs, "TrxTimeMS:") &

    Separator

    IIF? Doesn't that start another religious war? <g>

    Yes this would also work & may be better than GoSubs.

    -- Mark



  8. #278
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Phil Weber" <pweber@nospam.fawcette.com> wrote in message
    news:3e305215$1@tnews.web.devx.com...
    > > Paul, it's either new or it's not...

    >
    > Jonathan: I'm Phil. Do you have me confused with Paul?


    In that particular case, yes. However, I'll stand by the statement regarding
    Paul in general terms, given that the following has appeared from him within
    this thread.

    We have these:

    "When you consider the number of actual changes to the core language (which
    many of the VB.NOT folks enjoy clamoring about) they amount to a very small
    and almost insignificant part of the language."

    "Well first the changes to the actual language were few as I indicated."

    "VB.NET isn't a new language."


    And we have these:

    ""Classic" VB is/was a dead end. Microsoft was unable to evolve it beyond
    what it was. It's a great tool for building Windows desktop apps or COM
    components but that's as far as they were able to go with it. It need to be
    re-architected."

    "You weren't around when VB 1.0 was released were you? It wasn't until
    version 3.0 that it actually started to become popular.
    I don't think it's realistic to expect everyone to jump on the .NET
    bandwagon right away. It simply isn't practical."


    --
    Regards
    Jonathan West



  9. #279
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Phil Weber" <pweber@nospam.fawcette.com> wrote
    > > MS says use COM Interoperability to access legacy code,
    > > and start using .NET for new projects. How much clearer
    > > do they have to make it?

    >
    > Larry: More accurately (to bring us back to the subject of this thread), MS
    > says, "If you use C++, just load your code into VS.NET and recompile. You
    > may optionally extend existing code with managed extensions, but your legacy
    > code will 'just work.'
    >
    > "If, however, you use VB, your choices are to maintain it in its existing
    > version, or rewrite it for .NET."
    >
    > "How much clearer do they have to make it?" VB is still a second-class
    > citizen relative to C++.


    How is that bigotry on their part? It works because basically, nothing has
    changed for their platform. They are still talking directly to the WIndows
    API, something VB never did.

    Now they have an option to include a second layer, the .Net classes, that
    can be called. But they still use the exact same language to do their work.
    Whether they use extentions, or not, they have the same code base. VB.Net
    is not the same syntax as its earlier version. VB.Net does not have a no
    ..Net option, it MUST use the .Net classes. Even if it did have that option,
    the syntax would still be different, requiring the rewrite you indicated as
    one of the choices.

    Can you imagine how bloated VS.Net would be if they included VB6
    just so that old code could still be compiled in the new package? What
    would be the point of that when VB6 still works to create applications?

    > "How much clearer do they have to make it?" VB is still a second-class
    > citizen relative to C++.


    You chose VB, if you want the advantages of C++ then you have to
    start using it. You can't expect VB to be made into something as robust
    as C++ and still be the RAD tool it was designed to be. By your standards,
    C# is a second class participate because it also does not have a no .Net
    option. There are several who would disagree there, no doubt....

    LFS








  10. #280
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Phil Weber" <pweber@nospam.fawcette.com> wrote
    > > Well... the "first make it work, then make it work well"
    > > principle is usually applied to code in early development,
    > > prior to official release...

    >
    > Dave: Not where I've worked! ;-) My employers have generally wanted to get
    > functional, if suboptimal, code into the hands of users (generating
    > revenue!) before we devote time and money to the luxury of optimization.


    If you haven't got time to do it right the first time, when are you going to
    find time to do it again?

    It is that 'hurry up' attitude that puts buggy code into the hands of the users.
    Of course if your users are a captive audience, like co-workiers in a firm,
    and its that firm's managers that want the work out rapidly, then, they get
    what they pay for. But that attitutde is wrong for the general populace!

    Where might you see that attitude working well, in any other industry?

    Should the firemen bulldoze the house down to stop a small kitchen fire?
    It will put the fire out quicker....

    Should the doctor stuff gauze in the knife wound and bandage the
    patient up? It will stop the bleeding sooner....

    Every industry benefits when the workers strive to do quality work.
    As another old cliche goes; Quality doesn't cost, it pays....

    LFS




  11. #281
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 16:21:08 +0000, Mike Mitchell wrote:

    > On Fri, 24 Jan 2003 01:32:07 +1100, Jason Sobell iGadget
    > <igadget_@hotmail.com> wrote:
    >
    >>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

    >
    > Oh, dear. Why are you so scathing about classic VB, when these kinds
    > of features are exactly what made it the world-beater it became?
    > Phrases like: "bodge", "colossal monolithic application" are
    > pejorative and unnecessary. GoSub is not a kludge! Neither was
    > edit-and-continue. One could perfectly well "help" a program during
    > the debugging stage over a hiccup or two by whacking in a GoSub, but
    > that shouldn't mean that the GoSub would necessarily stay there
    > forever. Once the program had terminated, one could study the code and
    > optimise a final solution, based perhaps on what had been established
    > through the temporary GoSub functionality.


    I've made my living from developing in it, and I've *always* considered it
    to be a language that allows anyone to bodge up a program in a short time.
    This is not being scathing, it is recognising VB6 for what it is!
    I have never recommended that a company use an alternative language for a
    VB based solution, but have frequently recommended that they employ a high
    level developer to review and rewrite the code that they have developed
    in-house.

    The difference between my attitude and yours is that I acknowledge the
    faults and limitations in VB6, and while I would have been quite happy to
    use a VB7.classic, I am also quite happy to use VB.NET along with all of
    the extra features and improvements (and its missing features).

    > Makes me laugh sometimes! There you are, the .Netizenry, hoping that
    > more and more users are going to come into the fold, yet the language
    > that *had* the millions of users you all are desperate to slag off!
    > Weird.


    A new phrase "the .Netizenry"? Defined as "All who do not despise VB.NET"?


    Cheers,
    Jason

  12. #282
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 11:49:51 -0800, Phil Weber wrote:

    > > Get 1, , TemStr

    >
    > Gary: Just a thought...
    >
    > What if you created a VB.NET method, e.g.:
    >
    > Public Sub GetEx(ByVal Handle As Integer, _
    > Optional ByVal Offset As Integer = 0, _
    > Optional ByRef Target As String = "")
    >
    > that uses the Stream classes internally? Then you could convert your
    > existing Get statements using a simple search-and-replace (using Regular
    > Expressions, replace "Get {:d}, {.*}, {.+}" with "GetEx(\1, \2, \3)"), and
    > still get nearly optimal performance.


    Any search and replace would probably run into the same problems regarding
    immutable strings, but I don't think it matters anyway; any performance
    increase would only be a *perceived* increase, so no optimisation is needed


  13. #283
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
    >
    > My wish is that we fill that space only with standalone executables,
    > where each exe contains ONLY the code needed to draw the app and drive
    > the functionality. Obviously, we need space to do that. But at the
    > moment, the extra space and its low cost are simply devices to justify
    > bloated code. The Beta 2 .Net DVD I have is already gigabytes big.
    > What about another two or three years down the road?


    Did you ever stop to think that most of that was documentation and
    debugging aids?

    How about this, try out their new WebMatrix:
    http://www.asp.net/Default.aspx?tabindex=4&tabid=46

    You can write ASP.NET forms, and try them out on your own
    system. You can create databases, and bind to those, create and
    edit HTML, and XML documents, and so on...

    And, (you'll like this) the entire download fits on a floppy!

    Of course, you have to be running Windows XP, or Win2000
    to use it, and if you want DB support you have to have either
    MSDE, Server 7 or Server 2000 (MSDE is free) installed on your
    system, and don't forget the NetFramework, has to be installed....

    But other than the components you as a developer of current apps
    should already have, you can get an entire application in a very short
    download under 1.4 Megs.

    <g>
    LFS







  14. #284
    Phil Weber Guest

    Re: Microsoft's C++ bigotry

    > If you haven't got time to do it right the first time,
    > when are you going to find time to do it again?


    Larry: You're preaching to the choir! That's why I said that my managers
    have to "frequently admonish" me to hurry it up. I believe in taking pride
    in my work, which means that I often miss deadlines in order to produce code
    of which I can be proud.

    But I acknowledge that there's a constant tug-of-war between writing solid
    code and shipping as soon as possible; it doesn't surprise me when version
    1.0 products are not fully optimized.
    --
    Phil Weber



  15. #285
    Kent Guest

    Re: Microsoft's C++ bigotry


    Now it's a third class citizen to C++ and C# I'm not sure which one they like
    more. VB has become the "red headed step-child" that no one wants.

    "Phil Weber" <pweber@nospam.fawcette.com> wrote:
    > > MS says use COM Interoperability to access legacy code,
    > > and start using .NET for new projects. How much clearer
    > > do they have to make it?

    >
    >Larry: More accurately (to bring us back to the subject of this thread),

    MS
    >says, "If you use C++, just load your code into VS.NET and recompile. You
    >may optionally extend existing code with managed extensions, but your legacy
    >code will 'just work.'
    >
    >"If, however, you use VB, your choices are to maintain it in its existing
    >version, or rewrite it for .NET."
    >
    >"How much clearer do they have to make it?" VB is still a second-class
    >citizen relative to C++.
    >--
    >Phil Weber
    >
    >


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