DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 3 123 LastLast
Results 1 to 15 of 35

Thread: Re: Is C# going to take over? Or is MS going to continue their VC++

  1. #1
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    Eric wrote:
    >
    > "Persuer" <dabsoft@valint.net> wrote:
    > >
    > >Is C# going to take over? Or is MS going to continue their VC++ line of

    > products?
    > >
    > >Also, is VC++ .NET essentially VC++ 7.0?

    >
    > There have been many articles written concerning your question, so I will
    > attempt to summarize from memory the most relevant conclusions.
    >
    > C#(C-Sharp), isn't going to necessarily replace C++ or Visual C++, however
    > C# does offer many improvements, and simplifications to the memory allocation/destruction
    > involved with C++, Visual C++. .Net is essentially a framework, and as such
    > you can use aspects of it that are beneficial to your environment, or disregard
    > it entirely. The most important development C# brings to the table, is Managed
    > C++ which uses the gc or Garbage Collection Class.

    Actually, Managed C++ is independent of C#. It's simply C++ with an
    vendor-specific extension called managed classes. Without starting a
    debate over the usefulness of GC in general, I think that the very idea
    of toggling GC support on a per class basis rather than per object, is
    dubious, at best. What if I want to create an instance of a class and
    manage its memory by myself?

    Danny

  2. #2
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    Persuer wrote:
    >
    > Is C# going to take over?


    Certainly. It's going to take over VB.

    > Or is MS going to continue their VC++ line of products?


    Actually, MS has just announced new hires of a well renowned C++ guru,
    Herb Sutter who's joining another guru recently hired by MS: Stan
    Lippman. More importantly, M$ has announced (at last!) its commitment to
    bring Visual C++ to 100% ANSI/ISO conformance. It doesn't sound like
    they're dumping Visual C++, does it?

    Danny

  3. #3
    Zoroastro Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    Right, in microsoft's accademic page there is a curious phrase avaliable in
    http://www.msdnaa.net/technologies/cplusplus.asp :
    "Visual C++ is still a powerful development tool since certain appliations
    such as system utilities need to work outside of the .NET framework. This
    compiler is generally compliant with current ANSI C/C++ standards and is
    as powerful as before..."

    So, until they are announcing their C++ .NET , they are trying to continue
    with VC++ 6.0 . There are no reasons to change if you wont run applications
    in .NET framework.

    About GC , what is wrong in writting a delete statement in the end of program!?




    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >
    >Persuer wrote:
    >>
    >> Is C# going to take over?

    >
    >Certainly. It's going to take over VB.
    >
    >> Or is MS going to continue their VC++ line of products?

    >
    >Actually, MS has just announced new hires of a well renowned C++ guru,
    >Herb Sutter who's joining another guru recently hired by MS: Stan
    >Lippman. More importantly, M$ has announced (at last!) its commitment to
    >bring Visual C++ to 100% ANSI/ISO conformance. It doesn't sound like
    >they're dumping Visual C++, does it?
    >
    >Danny



  4. #4
    ralph Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    "Zoroastro" <zoro@hotmail.com> wrote:
    >
    >Right, in microsoft's accademic page there is a curious phrase avaliable

    in
    >http://www.msdnaa.net/technologies/cplusplus.asp :
    >"Visual C++ is still a powerful development tool since certain appliations
    >such as system utilities need to work outside of the .NET framework. This
    >compiler is generally compliant with current ANSI C/C++ standards and is
    >as powerful as before..."
    >
    >So, until they are announcing their C++ .NET , they are trying to continue
    >with VC++ 6.0 . There are no reasons to change if you wont run applications
    >in .NET framework.
    >


    Just as an amplification. The VC++ 7.0 compiler which comes with VS.NET(unlike
    VB or C#) is not a redesigned or new creature - it is a plain old-fashion
    mainstream C++ 32-bit compiler. It has improved ANSI/ISO support, better
    optimization, and some extensions to supply support for and to utilize the
    .NET framework.

    These additional extensions are merely additional options. Similar to the
    /GX /Ge /EH switches available in VC++ 6.0 to enable stack-checking, SEH,
    EH, etc. When you type "cl /nologo /GX HelloWorld.cpp" on the command line
    you will not detect any difference between 6 and 7. With one major exception
    - if you are used to using the "idx" outside a for block as in ...
    for( idx = 0; ... )
    { //block }
    iCount = idx;
    You are going to be very disappointed. <g>

    >
    >About GC , what is wrong in writting a delete statement in the end of program!?
    >


    I understand your annoyance. You will be pleased to know - You don't have
    to use it if you don't want to. It is only for "managed applications". In
    fact for "normal" C++ it will non-trivial TO use it. These extensions are
    only provided for dealing with the .net framework which does use GC. Think
    of it as more a case of ownership - if stuff belongs to somebody else you
    will just have to be a little more careful with it, or if you are dealing
    with someone who may be a little careless with borrowed items, then you just
    have to keep tighter control over your loans.

    Within a tighly defined 'framework' some forms of GC make sense. Take a look
    at a string class for example. Part of the power and usefulness of using
    string comes from "never having to say delete".

    However, I can't see it as being of any real use in "universal" practice.
    People that support GC as a general practice always seem to me to be a bunch
    of whiners that lament they have to remember to type a '}' after they have
    typed a '{'. <g>

  5. #5
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    Zoroastro wrote:
    >
    > Right, in microsoft's accademic page there is a curious phrase avaliable in
    > http://www.msdnaa.net/technologies/cplusplus.asp :
    > "Visual C++ is still a powerful development tool since certain appliations
    > such as system utilities need to work outside of the .NET framework. This
    > compiler is generally compliant with current ANSI C/C++ standards and is
    > as powerful as before..."
    >
    > So, until they are announcing their C++ .NET , they are trying to continue
    > with VC++ 6.0 . There are no reasons to change if you wont run applications
    > in .NET framework.
    >
    > About GC , what is wrong in writting a delete statement in the end of program!?


    I've never really found any difference between the need to write 'delete
    p;' and 'obj=null;' as in Java. Besides, one has to remember that
    garbage collected languages use a GC because they limit the programmer's
    choice to one, i.e., heap allocation, whereas in C++ you can use static
    or automatic memory and avoid the hassles of memory leaks in the first
    place.

    Danny

  6. #6
    LPVOID Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    >About GC , what is wrong in writting a delete statement in the end of program!?


    Well, I think there are no differences !

    you'll have to free the allocated memory by delete or __gc anyway.

    I mean...

    in .NET
    class __gc MyClass { // eligible to garbage collector.
    }; ...

    C++ Standard
    class MyClass {
    }; ...

    // ...
    MyClass * mc = new MyClass()...
    delete mc; // free memory

    What does happens if do you forget to write __gc (.NET) and delete (C++ std)
    in examples above!?

    you'll holding the memory , doesn't it?







  7. #7
    ralph Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >
    >Eric wrote:
    >>
    >> "Persuer" <dabsoft@valint.net> wrote:
    >> >
    >> >Is C# going to take over? Or is MS going to continue their VC++ line

    of
    >> products?
    >> >
    >> >Also, is VC++ .NET essentially VC++ 7.0?

    >>
    >> There have been many articles written concerning your question, so I will
    >> attempt to summarize from memory the most relevant conclusions.
    >>
    >> C#(C-Sharp), isn't going to necessarily replace C++ or Visual C++, however
    >> C# does offer many improvements, and simplifications to the memory allocation/destruction
    >> involved with C++, Visual C++. .Net is essentially a framework, and as

    such
    >> you can use aspects of it that are beneficial to your environment, or

    disregard
    >> it entirely. The most important development C# brings to the table, is

    Managed
    >> C++ which uses the gc or Garbage Collection Class.

    >Actually, Managed C++ is independent of C#. It's simply C++ with an
    >vendor-specific extension called managed classes. Without starting a
    >debate over the usefulness of GC in general, I think that the very idea
    >of toggling GC support on a per class basis rather than per object, is
    >dubious, at best. What if I want to create an instance of a class and
    >manage its memory by myself?
    >
    >Danny


    You're out of luck! <g>

    By utilizing the preprocessor you can share code between platforms, of course.
    You can also provide simple wrappers, i.e. call GCWrappedMyObject in Managed
    situations and just MyObject for non-managed situations. Or you can use the
    wrappers the .net platform will provide for you.

    There are enough differences between the two platforms that except for porting
    existing code it is highly unlikely you will find many practical reasons
    to use an object this way.

  8. #8
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    cplus.@127.0.0.1 wrote:
    >
    > "Persuer" <dabsoft@valint.net> wrote:
    > >
    > >Is C# going to take over? Or is MS going to continue their VC++ line of

    > products?
    > >
    > >Also, is VC++ .NET essentially VC++ 7.0?

    >
    > For application development, yes. There are no significant advantages of
    > using C++ over C# (or VB.NET). But there are advantages of using C# (and
    > VB.NET) over C++.


    As well as disadvantages...

    > Managed C++ in the .NET framework is there for upgrading
    > legacy C++ code. It would be extremely difficult to justify using Managed
    > C++ over VB.NET for new software development; hence in this domain I believe
    > C++ will be used very little.


    How about perfromance? Isn't this the reason why VC++ has been used
    instead of VB for years?

    >
    > The C# language finally provides C++ developers with the opportunity for
    > rapid application development (10 years after VB) in a syntax they can understand.


    RAD, with all due respect, isn't the only game in town. Not every
    application is based on flashy GUI; critical, robust, server side
    applications require low level access to system and hardware services,
    utmost determinacy (which Managed C++ fails to provide). Cross-platform
    development is another reason for prefering C++ to proprietary
    languages.
    >
    > No doubt there are a lot of die-hard C programmers who still view “If ()
    > {}” as being superior to “If … Then Begin … End” or “If Then … End If”. But
    > this is not the view of a professional software developer.


    Trust me, any decent C++ programmer couldn't care less about the
    if-statement notation of his or her favorite programming language. It's
    issues like perfromance, portability, etc. that make the difference. And
    there ARE huge differences between C and VB in these respects.

    >
    > Naturally, it will take time. C++ programmers tend to be quite stubborn,
    > but those who don’t change are in danger of being left behind.


    They are stubborn, yet with good reason. We've seen what happened to
    Java and its "write once run anywhere" vision, not to mention the "wait
    a few more years until the language matures, and be ready to rewrite
    your apps with every new JDK release" or "don't bother about
    perfromance; Sun's expensive hardware will make it up for the sluggish
    and memory hungry JVM we've just released, which is 1000 faster than the
    previous one, yet 1000 slower than the next release".
    In short, your claims are applicable to VB. VB is certainly on the brink
    of vanishing. C# will probably take its place. C++ is here to stay not
    because of bigotry of stiffneckedness but because there's simply no
    alternative language that can compete with it.

    Danny

  9. #9
    Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >
    >cplus.@127.0.0.1 wrote:
    >>
    >> "Persuer" <dabsoft@valint.net> wrote:
    >> >
    >> >Is C# going to take over? Or is MS going to continue their VC++ line

    of
    >> products?
    >> >
    >> >Also, is VC++ .NET essentially VC++ 7.0?

    >>
    >> For application development, yes. There are no significant advantages

    of
    >> using C++ over C# (or VB.NET). But there are advantages of using C# (and
    >> VB.NET) over C++.

    >
    >As well as disadvantages...
    >
    >> Managed C++ in the .NET framework is there for upgrading
    >> legacy C++ code. It would be extremely difficult to justify using Managed
    >> C++ over VB.NET for new software development; hence in this domain I believe
    >> C++ will be used very little.

    >
    >How about perfromance? Isn't this the reason why VC++ has been used
    >instead of VB for years?
    >
    >>
    >> The C# language finally provides C++ developers with the opportunity for
    >> rapid application development (10 years after VB) in a syntax they can

    understand.
    >
    >RAD, with all due respect, isn't the only game in town. Not every
    >application is based on flashy GUI; critical, robust, server side
    >applications require low level access to system and hardware services,
    >utmost determinacy (which Managed C++ fails to provide). Cross-platform
    >development is another reason for prefering C++ to proprietary
    >languages.
    >>
    >> No doubt there are a lot of die-hard C programmers who still view “If

    ()
    >> {}” as being superior to “If … Then Begin … End” or “If Then … End If”.

    But
    >> this is not the view of a professional software developer.

    >
    >Trust me, any decent C++ programmer couldn't care less about the
    >if-statement notation of his or her favorite programming language. It's
    >issues like perfromance, portability, etc. that make the difference. And
    >there ARE huge differences between C and VB in these respects.
    >
    >>
    >> Naturally, it will take time. C++ programmers tend to be quite stubborn,
    >> but those who don’t change are in danger of being left behind.

    >
    >They are stubborn, yet with good reason. We've seen what happened to
    >Java and its "write once run anywhere" vision, not to mention the "wait
    >a few more years until the language matures, and be ready to rewrite
    >your apps with every new JDK release" or "don't bother about
    >perfromance; Sun's expensive hardware will make it up for the sluggish
    >and memory hungry JVM we've just released, which is 1000 faster than the
    >previous one, yet 1000 slower than the next release".
    >In short, your claims are applicable to VB. VB is certainly on the brink
    >of vanishing. C# will probably take its place. C++ is here to stay not
    >because of bigotry of stiffneckedness but because there's simply no
    >alternative language that can compete with it.
    >
    >Danny



    Hi Danny, regarding you points:

    PERFORMANCE

    Have a look at this site: http://www.devhood.com/Tutorials/tut...utorial_id=203

    It compares a number of performance tests of a number of languages. Note
    how VB.NET (and C#) compares against Visual C++. As can be seen VC++ offers
    no advantage.

    Also, remember I’m talking specifically about application development and
    not system development. For example, consider an application that records
    a sales order. It’s makes no difference if the C/C++ execute 10 times faster
    that it’s VB equivalent; it comes down to network speed, the execution of
    the stored procedures, performance of the data access components etc. So
    using C++ instead of VB as the ‘glue’ to bring these components together
    is irrelevant. The expected increase in speed will not materialise.


    PORTABILITY

    Generally, in application development, C/C++ isn’t portable. Firstly we are
    not really comparing like with like; which variant of C++ are we talking
    about MS Visual C++, Borland C Builder, IBM Visual Age for C++ etc.?

    Application development nowadays incorporates some degree of RAD which leads
    to component-based development. So if you use any third-party components
    and you do not have access to the source (or a version of the component for
    the platform you are wanting to port to) or if you use technologies like
    COM/DCOM etc. your application will not port.


    In short, C++ offers no significant advantage. But VB is here to stay. VB
    is Microsoft “own” language (C# is now an open language which they no longer
    control); VB is as powerful as any other .NET language VB is easy to Learn;
    There’s already a large VB developer community, source code; Managed C++
    in the .NET framework is there for upgrading legacy C++ code;

    May be I’ve just met some ‘bad’ C++ programmers. But do you really think
    that C# would be as popular to C++ programmers if it had been called Basic#
    ? I don’t believe it would.

    There certainly are languages that have competed with C++ e.g. Delphi. C++
    has been losing ground to the RAD languages for a long time and will continue
    to do so; .NET will only speed thing ups.


  10. #10
    ralph Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    Danny Kalev <dannykk@inter.net.il> wrote:
    >
    >
    >cplus.@127.0.0.1 wrote:
    >>
    >> "Persuer" <dabsoft@valint.net> wrote:
    >> >
    >> >Is C# going to take over? Or is MS going to continue their VC++ line

    of
    >> products?
    >> >
    >> >Also, is VC++ .NET essentially VC++ 7.0?

    >>
    >> For application development, yes. There are no significant advantages

    of
    >> using C++ over C# (or VB.NET). But there are advantages of using C# (and
    >> VB.NET) over C++.

    >
    >As well as disadvantages...
    >
    >> Managed C++ in the .NET framework is there for upgrading
    >> legacy C++ code. It would be extremely difficult to justify using Managed
    >> C++ over VB.NET for new software development; hence in this domain I believe
    >> C++ will be used very little.

    >
    >How about perfromance? Isn't this the reason why VC++ has been used
    >instead of VB for years?
    >
    >>
    >> The C# language finally provides C++ developers with the opportunity for
    >> rapid application development (10 years after VB) in a syntax they can

    understand.
    >
    >RAD, with all due respect, isn't the only game in town. Not every
    >application is based on flashy GUI; critical, robust, server side
    >applications require low level access to system and hardware services,
    >utmost determinacy (which Managed C++ fails to provide). Cross-platform
    >development is another reason for prefering C++ to proprietary
    >languages.
    >>
    >> No doubt there are a lot of die-hard C programmers who still view “If

    ()
    >> {}” as being superior to “If … Then Begin … End” or “If Then … End If”.

    But
    >> this is not the view of a professional software developer.

    >
    >Trust me, any decent C++ programmer couldn't care less about the
    >if-statement notation of his or her favorite programming language. It's
    >issues like perfromance, portability, etc. that make the difference. And
    >there ARE huge differences between C and VB in these respects.
    >
    >>
    >> Naturally, it will take time. C++ programmers tend to be quite stubborn,
    >> but those who don’t change are in danger of being left behind.

    >
    >They are stubborn, yet with good reason. We've seen what happened to
    >Java and its "write once run anywhere" vision, not to mention the "wait
    >a few more years until the language matures, and be ready to rewrite
    >your apps with every new JDK release" or "don't bother about
    >perfromance; Sun's expensive hardware will make it up for the sluggish
    >and memory hungry JVM we've just released, which is 1000 faster than the
    >previous one, yet 1000 slower than the next release".
    >In short, your claims are applicable to VB. VB is certainly on the brink
    >of vanishing. C# will probably take its place. C++ is here to stay not
    >because of bigotry of stiffneckedness but because there's simply no
    >alternative language that can compete with it.
    >
    >Danny


    There is no doubt that more C++/MFC/ATL programmers who would never fire
    up a VB IDE will now tend to utilize C#.net for ad hoc applications. There
    will be C++ programmers who occasionally used VB who will now turn to C#.
    VB will be the biggest loser during this sea change.

    For C++ programmers writing services and middle-ware there will be less a
    change in 'language' as there will be in learning how to best utilize the
    .net SDK and .net programming patterns to provide Managed solutions.

    The greatest impact will be on C++/MFC programmers. They will have to make
    some hard decisions over the next couple of months. Part of their problem
    is that Windows Forms isn't quite ready yet for "industrial-strength" (as
    in new and improved, all the bells and whistles) applications users have
    come to expect. These "gaps" will have to be supplied somehow - will it be
    with existing MFC controls backed-up with Managed Interfaces to .net, or
    will it be with Windows Forms front-ends backed up with C++ Managed Controls?

    In many ways I see the C++/MFC programmer facing some of the same problems
    the VB programmer faced a few years ago - Here is this great RAD tool that
    can do 80% of what needs to be done. So do I then struggle with the last
    20% or do I use another tool? Unfortunately for the VB programmer that "other"
    tools was often C++ which was foreign to most of them. As a result most VB
    programmers chose plan A and struggled and their apps show it. At least C#
    and C++ are less foreign. [Actually they put me mind of the quote - "England
    and America divided by a common language." Shaw?]

    So a main feature I see coming out of this is better program structure. The
    average VB programmer writes decent front-ends and great database back-ends
    but the middle tends to be a bloody mess of non-scalable, non-maintainable,
    write-only, one-offs piles of code. It is not entirely their fault as most
    of this tends to be that tough 20% we talked about. Contrary to what resumes
    may report there are very very few 'good' VB programmers that are 'good'
    C++ programmers and vice versa. So we all paid lip service to the often quoted
    - "use the language that is best suited" - but in fact we seldom did.

    I believe there will be more 'good' C# and C++ programmers. As a consequence
    I believe in some ways there will be MORE C++ programming in the average
    application.

    -ralph


  11. #11
    ralph Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    <cplus.@127.0.0.1> wrote:
    >
    >Danny Kalev <dannykk@inter.net.il> wrote:
    >>
    >>
    >>cplus.@127.0.0.1 wrote:
    >>>
    >>> "Persuer" <dabsoft@valint.net> wrote:
    >>> >
    >>> >Is C# going to take over? Or is MS going to continue their VC++ line

    >of
    >>> products?
    >>> >
    >>> >Also, is VC++ .NET essentially VC++ 7.0?
    >>>
    >>> For application development, yes. There are no significant advantages

    >of
    >>> using C++ over C# (or VB.NET). But there are advantages of using C# (and
    >>> VB.NET) over C++.

    >>
    >>As well as disadvantages...
    >>
    >>> Managed C++ in the .NET framework is there for upgrading
    >>> legacy C++ code. It would be extremely difficult to justify using Managed
    >>> C++ over VB.NET for new software development; hence in this domain I

    believe
    >>> C++ will be used very little.

    >>
    >>How about perfromance? Isn't this the reason why VC++ has been used
    >>instead of VB for years?
    >>
    >>>
    >>> The C# language finally provides C++ developers with the opportunity

    for
    >>> rapid application development (10 years after VB) in a syntax they can

    >understand.
    >>
    >>RAD, with all due respect, isn't the only game in town. Not every
    >>application is based on flashy GUI; critical, robust, server side
    >>applications require low level access to system and hardware services,
    >>utmost determinacy (which Managed C++ fails to provide). Cross-platform
    >>development is another reason for prefering C++ to proprietary
    >>languages.
    >>>
    >>> No doubt there are a lot of die-hard C programmers who still view “If

    >()
    >>> {}” as being superior to “If … Then Begin … End” or “If Then … End If”.

    >But
    >>> this is not the view of a professional software developer.

    >>
    >>Trust me, any decent C++ programmer couldn't care less about the
    >>if-statement notation of his or her favorite programming language. It's
    >>issues like perfromance, portability, etc. that make the difference. And
    >>there ARE huge differences between C and VB in these respects.
    >>
    >>>
    >>> Naturally, it will take time. C++ programmers tend to be quite stubborn,
    >>> but those who don’t change are in danger of being left behind.

    >>
    >>They are stubborn, yet with good reason. We've seen what happened to
    >>Java and its "write once run anywhere" vision, not to mention the "wait
    >>a few more years until the language matures, and be ready to rewrite
    >>your apps with every new JDK release" or "don't bother about
    >>perfromance; Sun's expensive hardware will make it up for the sluggish
    >>and memory hungry JVM we've just released, which is 1000 faster than the
    >>previous one, yet 1000 slower than the next release".
    >>In short, your claims are applicable to VB. VB is certainly on the brink
    >>of vanishing. C# will probably take its place. C++ is here to stay not
    >>because of bigotry of stiffneckedness but because there's simply no
    >>alternative language that can compete with it.
    >>
    >>Danny

    >
    >
    >Hi Danny, regarding you points:
    >
    >PERFORMANCE
    >
    >Have a look at this site: http://www.devhood.com/Tutorials/tut...utorial_id=203
    >
    >It compares a number of performance tests of a number of languages. Note
    >how VB.NET (and C#) compares against Visual C++. As can be seen VC++ offers
    >no advantage.
    >
    >Also, remember I’m talking specifically about application development and
    >not system development. For example, consider an application that records
    >a sales order. It’s makes no difference if the C/C++ execute 10 times faster
    >that it’s VB equivalent; it comes down to network speed, the execution of
    >the stored procedures, performance of the data access components etc. So
    >using C++ instead of VB as the ‘glue’ to bring these components together
    >is irrelevant. The expected increase in speed will not materialise.
    >


    I don't want to speak for Danny but I don't think he or anyone else ever
    suggested C++ makes network/database connections or user button clicking
    run any faster. Everyone accepts your premise that VB is "just as good" in
    this situation.


    >
    >PORTABILITY
    >
    >Generally, in application development, C/C++ isn’t portable. Firstly we

    are
    >not really comparing like with like; which variant of C++ are we talking
    >about MS Visual C++, Borland C Builder, IBM Visual Age for C++ etc.?
    >
    >Application development nowadays incorporates some degree of RAD which leads
    >to component-based development. So if you use any third-party components
    >and you do not have access to the source (or a version of the component

    for
    >the platform you are wanting to port to) or if you use technologies like
    >COM/DCOM etc. your application will not port.
    >


    Peculiar last line as VB is nothing at all if it is not COM.


    >
    >In short, C++ offers no significant advantage. But VB is here to stay. VB
    >is Microsoft “own” language (C# is now an open language which they no longer
    >control);
    > ...


    I am glad to see that M$'s hype and marketing dollars have borne some fruit.
    I will grant you that C# is just as "Open" as Java.

    As for "VB is here to stay" - you are obviously in the denial stage of a
    terminal illness. (Possibly drifting to 'anger'?) Get over it, VB is dead.

    >...
    >VB is as powerful as any other .NET language VB is easy to Learn;
    >There’s already a large VB developer community, source code; Managed C++
    >in the .NET framework is there for upgrading legacy C++ code;
    > ...


    As for "Managed C++ ... there for ugrading legacy C++ code." I think you
    missed some of the hype. Managed C++ is for access, integration, and support
    of the new .net framework.

    > ...
    >May be I’ve just met some ‘bad’ C++ programmers. But do you really think
    >that C# would be as popular to C++ programmers if it had been called Basic#
    >? I don’t believe it would.
    >
    >There certainly are languages that have competed with C++ e.g. Delphi. C++
    >has been losing ground to the RAD languages for a long time and will continue
    >to do so; .NET will only speed thing ups.
    >


    Most of these RAD were not created to compete with C++ they were created
    to provide a development enviroment for easier Windows development. They
    usually succeed in their choosen domain. However, most fail at some point
    because they are subsets of the over-all solution domain. C++ provides access
    to all possible solutions. C++ is harder to learn and definitely not RAD,
    but it is the whole enchilada. No RAD or language has ever replaced C/C++
    and there is little chance any will for the next ten years or so.

    Eventually with O/S kernel code becoming more modular, "APIs" more extensive,
    and hardware faster and smarter there will be less and less reason to use
    C++ in application programming. So I see C++ as not being replaced but less
    commonly needed.

    IMHO: C# and Hosting scripts will become the language of RAD but they will
    all be backed up with C++ components and devices. Not sure how this mix will
    play out over the next couple of years. However, the one thing I am sure
    of, is VB and Pascal will not be there.


  12. #12
    Danny Kalev Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++



    cplus.@127.0.0.1 wrote:
    >
    > Danny Kalev <dannykk@inter.net.il> wrote:
    > >
    > >
    > >cplus.@127.0.0.1 wrote:
    > >>
    > >> "Persuer" <dabsoft@valint.net> wrote:
    > >> >
    > >> >Is C# going to take over? Or is MS going to continue their VC++ line

    > of
    > >> products?
    > >> >
    > >> >Also, is VC++ .NET essentially VC++ 7.0?
    > >>
    > >> For application development, yes. There are no significant advantages

    > of
    > >> using C++ over C# (or VB.NET). But there are advantages of using C# (and
    > >> VB.NET) over C++.

    > >
    > >As well as disadvantages...
    > >
    > >> Managed C++ in the .NET framework is there for upgrading
    > >> legacy C++ code. It would be extremely difficult to justify using Managed
    > >> C++ over VB.NET for new software development; hence in this domain I believe
    > >> C++ will be used very little.

    > >
    > >How about perfromance? Isn't this the reason why VC++ has been used
    > >instead of VB for years?
    > >
    > >>
    > >> The C# language finally provides C++ developers with the opportunity for
    > >> rapid application development (10 years after VB) in a syntax they can

    > understand.
    > >
    > >RAD, with all due respect, isn't the only game in town. Not every
    > >application is based on flashy GUI; critical, robust, server side
    > >applications require low level access to system and hardware services,
    > >utmost determinacy (which Managed C++ fails to provide). Cross-platform
    > >development is another reason for prefering C++ to proprietary
    > >languages.
    > >>
    > >> No doubt there are a lot of die-hard C programmers who still view “If

    > ()
    > >> {}” as being superior to “If … Then Begin … End” or “If Then … End If”.

    > But
    > >> this is not the view of a professional software developer.

    > >
    > >Trust me, any decent C++ programmer couldn't care less about the
    > >if-statement notation of his or her favorite programming language. It's
    > >issues like perfromance, portability, etc. that make the difference. And
    > >there ARE huge differences between C and VB in these respects.
    > >
    > >>
    > >> Naturally, it will take time. C++ programmers tend to be quite stubborn,
    > >> but those who don’t change are in danger of being left behind.

    > >
    > >They are stubborn, yet with good reason. We've seen what happened to
    > >Java and its "write once run anywhere" vision, not to mention the "wait
    > >a few more years until the language matures, and be ready to rewrite
    > >your apps with every new JDK release" or "don't bother about
    > >perfromance; Sun's expensive hardware will make it up for the sluggish
    > >and memory hungry JVM we've just released, which is 1000 faster than the
    > >previous one, yet 1000 slower than the next release".
    > >In short, your claims are applicable to VB. VB is certainly on the brink
    > >of vanishing. C# will probably take its place. C++ is here to stay not
    > >because of bigotry of stiffneckedness but because there's simply no
    > >alternative language that can compete with it.
    > >
    > >Danny

    >
    > Hi Danny, regarding you points:
    >
    > PERFORMANCE
    >
    > Have a look at this site: http://www.devhood.com/Tutorials/tut...utorial_id=203
    >
    > It compares a number of performance tests of a number of languages. Note
    > how VB.NET (and C#) compares against Visual C++. As can be seen VC++ offers
    > no advantage.


    I wonder how all these "benchmarks" always prove that a very carefully
    crafted obfuscated code that runs under very specific settings appears
    to be faster than native assembly. Seriously, do you believe C#, which
    is built on top of C++ can be faster than C++? Let's be realistic. We've
    heard exactly the same claims from Java buffs for seven years, and still
    Java is s-l-o-w.

    >
    > Also, remember I’m talking specifically about application development and
    > not system development.


    I don't make such a distinction because C++ doesn't make it either.
    We're talking about programming languages in general, not what's best
    for developing a ComboBox on Windows 3000. If you're confining the
    domain of discussion to this realm, then I don't see how C# is going to
    replace C++ anyway.


    development
    For example, consider an application that records
    > a sales order. It’s makes no difference if the C/C++ execute 10 times faster
    > that it’s VB equivalent; it comes down to network speed, the execution of
    > the stored procedures, performance of the data access components etc.


    It does make a difference if you have 100 of salesperson using the same
    server at once.

    So
    > using C++ instead of VB as the ‘glue’ to bring these components together
    > is irrelevant. The expected increase in speed will not materialise.


    Actually, I'd think of VB as the GUI glue. The real core application
    should be written in C++ or a similar high performance language unless
    you really have 100,000 to spare for a mainframe.

    >
    > PORTABILITY
    >
    > Generally, in application development, C/C++ isn’t portable. Firstly we are
    > not really comparing like with like; which variant of C++ are we talking
    > about MS Visual C++, Borland C Builder, IBM Visual Age for C++ etc.?


    We're talking about ANSI C++. The products you listed are not distinct
    programming languages, mind you, but implementations of the same
    language, which only proves the point that C++ is ubiquitously
    available, as opposed to VB and C#. When was the last time you saw an
    IBM compiler running VB code?

    >
    > Application development nowadays incorporates some degree of RAD which leads
    > to component-based development.

    Again, it depends on which type of application development you're
    talking about. I haven't seen components used in database engines,
    compilers or OS kernels yet.

    So if you use any third party components
    > and you do not have access to the source (or a version of the component for
    > the platform you are wanting to port to) or if you use technologies like
    > COM/DCOM etc. your application will not port.


    Again, you're confining the discussion to a very narrow (and quite
    obsolete) type of applications. Who uses DCOM these days? People who
    need components could use CORBA, C# or even Java. Then again, they might
    use VC++ too. The point is that many applications don't and will never
    use components.

    >
    > In short, C++ offers no significant advantage. But VB is here to stay. VB
    > is Microsoft “own” language

    So what you're saying is that C++ is disappearing while VB is here to
    stay? Gee! Bill Gates and Linus Torvalds should seriously consider
    rewriting Linux and Windows in VB!

    (C# is now an open language which they no longer
    > control);


    That's what they want you to believe. Since they are the only vendor
    selling development tools for this language, rest assured that they will
    change it as they please, ECMA standard or not. And they will certainly
    do so because the language is still immature and will undergo the
    natural course of a language evolution, as every programming language
    does. Java only recently (2002) introduced assertions. Something we've
    had in C since the early 1970s (so much for "a new technology", btw). C#
    is no different. If you want a more compelling example, look at the
    evolution of VB in the past decade.


    VB is as powerful as any other .NET language VB is easy to Learn;
    > There’s already a large VB developer community, source code; Managed C++
    > in the .NET framework is there for upgrading legacy C++ code;


    It isn't an upgrade, it's just different, and not necessarily better.
    For starters, it uses a GC which is the anathema of determinacy. As
    opposed to what most people think, GC introduces many problems (the lack
    of destructors is only a minor example), outstanding memory (Java
    programmers can tell you about that) and so on and so forth. Managed C++
    isn't better than C++, it's just different.

    >
    > May be I’ve just met some ‘bad’ C++ programmers.


    No offense, but it's obvious that you haven't done any serious C++
    programming and your conclusions are based on your own experience with
    VB. That's why you're so easily convinced that C# is the best thing
    since sliced bread. Trust me, it isn't. I do agree with you about one
    thing though: C++ is certainly not for everybody. Quoting Bjarne
    Stroustrup, "it's for serious programmers".

    But do you really think
    > that C# would be as popular to C++ programmers if it had been called Basic#
    > ?

    If a programmer chooses a programming language by its name, he or she
    should seriously consider changing their job.

    > I don’t believe it would.
    >
    > There certainly are languages that have competed with C++ e.g. Delphi. C++
    > has been losing ground to the RAD languages for a long time and will continue
    > to do so; .NET will only speed thing ups.


    Delphi? you gotta be kidding me. It was buried at least twice, ages ago.
    Again, you have to understand that there's more to programming than
    splash screens and dialog boxes.

    Danny

  13. #13
    Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    >I wonder how all these "benchmarks" always prove that a very carefully
    >crafted obfuscated code that runs under very specific settings appears
    >to be faster than native assembly. Seriously, do you believe C#, which
    >is built on top of C++ can be faster than C++? Let's be realistic. We've
    >heard exactly the same claims from Java buffs for seven years, and still
    >Java is s-l-o-w.


    You must remember the C# is compiled to native code (Java compiles to byte
    code) using a JIT compiler. Why can’t C# be as fast as C++? Indeed, it could
    execute faster as the JIT compiler will optimised for the characteristics
    of an individual machine.

    >I don't make such a distinction because C++ doesn't make it either.
    >We're talking about programming languages in general, not what's best
    >for developing a ComboBox on Windows 3000. If you're confining the
    >domain of discussion to this realm, then I don't see how C# is going to
    >replace C++ anyway.


    The C++ language may not make a distinction but software analysis, design
    and development does !!!

    I would regard a ComboBox (or a TextBox, Button, Scrollbar etc.) as part
    of the primitive set of GUI components provided by an operating system and
    hence system development.

    >It does make a difference if you have 100 of salesperson using the same
    >server at once.


    Believe me it doesn’t (remember that the data access components (ADO) are
    written in C++). It comes down to performance tuning the server and database
    (for example, by adding indexes).

    >Actually, I'd think of VB as the GUI glue. The real core application
    >should be written in C++ or a similar high performance language unless
    >you really have 100,000 to spare for a mainframe.


    Yes, but not just the GUI glue. The glue for ALL components not just GUI
    ones like: ADO, MSMQ, MSXML etc. – all written in C++ and glued together
    in VB – rapid/component based development.

    >We're talking about ANSI C++. The products you listed are not distinct
    >programming languages, mind you, but implementations of the same
    >language, which only proves the point that C++ is ubiquitously
    >available, as opposed to VB and C#. When was the last time you saw an
    >IBM compiler running VB code?


    Vendor specific implementations of same language – that’s my point. You will
    find very few C++ applications that are truly ANSI C compliant and therefore
    not portable (by the way, I think IBM have released the own version of VB).

    >Again, it depends on which type of application development you're
    >talking about. I haven't seen components used in database engines,
    >compilers or OS kernels yet.

    This is system development, I am talking spcifically about using C++ for
    Application Development.

    >Again, you're confining the discussion to a very narrow (and quite
    >obsolete) type of applications. Who uses DCOM these days? People who
    >need components could use CORBA, C# or even Java. Then again, they might
    >use VC++ too. The point is that many applications don't and will never
    >use components.


    No, my discussion spcifically about using C++ for Application Development
    (COM/DCOM was just an example of a technology that was supported by one platform
    and not another).

    My general point is that application development nowadays incorporates some
    degree of RAD and this leads to component-based development. In which case
    any third-party components and techonologies must also be portable.

    >
    >>
    >> In short, C++ offers no significant advantage. But VB is here to stay.

    VB
    >> is Microsoft “own” language

    >So what you're saying is that C++ is disappearing while VB is here to
    >stay? Gee! Bill Gates and Linus Torvalds should seriously consider
    >rewriting Linux and Windows in VB!
    >
    >(C# is now an open language which they no longer
    >> control);

    >
    >That's what they want you to believe. Since they are the only vendor
    >selling development tools for this language, rest assured that they will
    >change it as they please, ECMA standard or not. And they will certainly
    >do so because the language is still immature and will undergo the
    >natural course of a language evolution, as every programming language
    >does. Java only recently (2002) introduced assertions. Something we've
    >had in C since the early 1970s (so much for "a new technology", btw). C#
    >is no different. If you want a more compelling example, look at the
    >evolution of VB in the past decade.
    >
    >
    >VB is as powerful as any other .NET language VB is easy to Learn;
    >> There’s already a large VB developer community, source code; Managed C++
    >> in the .NET framework is there for upgrading legacy C++ code;

    >
    >It isn't an upgrade, it's just different, and not necessarily better.
    >For starters, it uses a GC which is the anathema of determinacy. As
    >opposed to what most people think, GC introduces many problems (the lack
    >of destructors is only a minor example), outstanding memory (Java
    >programmers can tell you about that) and so on and so forth. Managed C++
    >isn't better than C++, it's just different.
    >
    >>
    >> May be I’ve just met some ‘bad’ C++ programmers.

    >
    >No offense, but it's obvious that you haven't done any serious C++
    >programming and your conclusions are based on your own experience with
    >VB. That's why you're so easily convinced that C# is the best thing
    >since sliced bread. Trust me, it isn't. I do agree with you about one
    >thing though: C++ is certainly not for everybody. Quoting Bjarne
    >Stroustrup, "it's for serious programmers".
    >
    >But do you really think
    >> that C# would be as popular to C++ programmers if it had been called Basic#
    >> ?

    >If a programmer chooses a programming language by its name, he or she
    >should seriously consider changing their job.
    >
    >> I don’t believe it would.
    >>
    >> There certainly are languages that have competed with C++ e.g. Delphi.

    C++
    >> has been losing ground to the RAD languages for a long time and will continue
    >> to do so; .NET will only speed thing ups.

    >
    >Delphi? you gotta be kidding me. It was buried at least twice, ages ago.
    >Again, you have to understand that there's more to programming than
    >splash screens and dialog boxes.
    >
    >Danny



  14. #14
    James Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    >I wonder how all these "benchmarks" always prove that a very carefully
    >crafted obfuscated code that runs under very specific settings appears
    >to be faster than native assembly. Seriously, do you believe C#, which
    >is built on top of C++ can be faster than C++? Let's be realistic. We've
    >heard exactly the same claims from Java buffs for seven years, and still
    >Java is s-l-o-w.


    You must remember the C# is compiled to native code (Java compiles to byte
    code) using a JIT compiler. Why can’t C# be as fast as C++? Indeed, it could
    execute faster as the JIT compiler will optimised for the characteristics
    of an individual machine.

    >I don't make such a distinction because C++ doesn't make it either.
    >We're talking about programming languages in general, not what's best
    >for developing a ComboBox on Windows 3000. If you're confining the
    >domain of discussion to this realm, then I don't see how C# is going to
    >replace C++ anyway.


    The C++ language may not make a distinction but software analysis, design
    and development does !!!

    I would regard a ComboBox (or a TextBox, Button, Scrollbar etc.) as part
    of the primitive set of GUI components provided by an operating system and
    hence system development.

    >It does make a difference if you have 100 of salesperson using the same
    >server at once.


    Believe me it doesn’t (remember that the data access components (ADO) are
    written in C++). It comes down to performance tuning the server and database
    (for example, by adding indexes).

    >Actually, I'd think of VB as the GUI glue. The real core application
    >should be written in C++ or a similar high performance language unless
    >you really have 100,000 to spare for a mainframe.


    Yes, but not just the GUI glue. The glue for ALL components not just GUI
    ones like: ADO, MSMQ, MSXML etc. – all written in C++ and glued together
    in VB – rapid/component based development.

    >We're talking about ANSI C++. The products you listed are not distinct
    >programming languages, mind you, but implementations of the same
    >language, which only proves the point that C++ is ubiquitously
    >available, as opposed to VB and C#. When was the last time you saw an
    >IBM compiler running VB code?


    Vendor specific implementations of same language – that’s my point. You will
    find very few C++ applications that are truly ANSI C compliant and therefore
    not portable (by the way, I think IBM have released the own version of VB).

    >Again, it depends on which type of application development you're
    >talking about. I haven't seen components used in database engines,
    >compilers or OS kernels yet.

    This is system development, I am talking spcifically about using C++ for
    Application Development.

    >Again, you're confining the discussion to a very narrow (and quite
    >obsolete) type of applications. Who uses DCOM these days? People who
    >need components could use CORBA, C# or even Java. Then again, they might
    >use VC++ too. The point is that many applications don't and will never
    >use components.


    No, my discussion spcifically about using C++ for Application Development
    (COM/DCOM was just an example of a technology that was supported by one platform
    and not another).

    My general point is that application development nowadays incorporates some
    degree of RAD and this leads to component-based development. In which case
    any third-party components and techonologies must also be portable.

    >So what you're saying is that C++ is disappearing while VB is here to
    >stay? Gee! Bill Gates and Linus Torvalds should seriously consider
    >rewriting Linux and Windows in VB!


    No, I'm saying C++ for application development will descline significantly,
    replaced by either VB.NET or C# (both equally powerful).

    >That's what they want you to believe. Since they are the only vendor
    >selling development tools for this language, rest assured that they will
    >change it as they please, ECMA standard or not. And they will certainly
    >do so because the language is still immature and will undergo the
    >natural course of a language evolution, as every programming language
    >does. Java only recently (2002) introduced assertions. Something we've
    >had in C since the early 1970s (so much for "a new technology", btw). C#
    >is no different. If you want a more compelling example, look at the
    >evolution of VB in the past decade.


    Not so, I believe they will no abide by the ECMA standards.

    >It isn't an upgrade, it's just different, and not necessarily better.
    >For starters, it uses a GC which is the anathema of determinacy. As
    >opposed to what most people think, GC introduces many problems (the lack
    >of destructors is only a minor example), outstanding memory (Java
    >programmers can tell you about that) and so on and so forth. Managed C++
    >isn't better than C++, it's just different.


    I wasn't suggesting managed C++ is better that C++. I personally think it's
    there solely for legacy C++ code.

    >No offense, but it's obvious that you haven't done any serious C++
    >programming and your conclusions are based on your own experience with
    >VB. That's why you're so easily convinced that C# is the best thing
    >since sliced bread. Trust me, it isn't. I do agree with you about one
    >thing though: C++ is certainly not for everybody. Quoting Bjarne
    >Stroustrup, "it's for serious programmers".


    My conclusions are based on 10 years experience in application development
    and IT consultancy. Again I repeat my claim: "For application development,
    yes. There are no significant advantages of using C++ over C# (or VB.NET)."



    >Delphi? you gotta be kidding me. It was buried at least twice, ages ago.
    >Again, you have to understand that there's more to programming than
    >splash screens and dialog boxes.

    You give a number of emotive statements like above, yet fail it provide any
    technical, economic justifications of why C++ is better.


  15. #15
    James Guest

    Re: Is C# going to take over? Or is MS going to continue their VC++


    "ralph" <nt_consulting32@hotmail.com> wrote:
    >
    ><cplus.@127.0.0.1> wrote:
    >>
    >>Danny Kalev <dannykk@inter.net.il> wrote:
    >>>
    >>>
    >>>cplus.@127.0.0.1 wrote:
    >>>>
    >>>> "Persuer" <dabsoft@valint.net> wrote:
    >>>> >
    >>>> >Is C# going to take over? Or is MS going to continue their VC++ line

    >>of
    >>>> products?
    >>>> >
    >>>> >Also, is VC++ .NET essentially VC++ 7.0?
    >>>>
    >>>> For application development, yes. There are no significant advantages

    >>of
    >>>> using C++ over C# (or VB.NET). But there are advantages of using C#

    (and
    >>>> VB.NET) over C++.
    >>>
    >>>As well as disadvantages...
    >>>
    >>>> Managed C++ in the .NET framework is there for upgrading
    >>>> legacy C++ code. It would be extremely difficult to justify using Managed
    >>>> C++ over VB.NET for new software development; hence in this domain I

    >believe
    >>>> C++ will be used very little.
    >>>
    >>>How about perfromance? Isn't this the reason why VC++ has been used
    >>>instead of VB for years?
    >>>
    >>>>
    >>>> The C# language finally provides C++ developers with the opportunity

    >for
    >>>> rapid application development (10 years after VB) in a syntax they can

    >>understand.
    >>>
    >>>RAD, with all due respect, isn't the only game in town. Not every
    >>>application is based on flashy GUI; critical, robust, server side
    >>>applications require low level access to system and hardware services,
    >>>utmost determinacy (which Managed C++ fails to provide). Cross-platform
    >>>development is another reason for prefering C++ to proprietary
    >>>languages.
    >>>>
    >>>> No doubt there are a lot of die-hard C programmers who still view “If

    >>()
    >>>> {}” as being superior to “If … Then Begin … End” or “If Then … End If”.

    >>But
    >>>> this is not the view of a professional software developer.
    >>>
    >>>Trust me, any decent C++ programmer couldn't care less about the
    >>>if-statement notation of his or her favorite programming language. It's
    >>>issues like perfromance, portability, etc. that make the difference. And
    >>>there ARE huge differences between C and VB in these respects.
    >>>
    >>>>
    >>>> Naturally, it will take time. C++ programmers tend to be quite stubborn,
    >>>> but those who don’t change are in danger of being left behind.
    >>>
    >>>They are stubborn, yet with good reason. We've seen what happened to
    >>>Java and its "write once run anywhere" vision, not to mention the "wait
    >>>a few more years until the language matures, and be ready to rewrite
    >>>your apps with every new JDK release" or "don't bother about
    >>>perfromance; Sun's expensive hardware will make it up for the sluggish
    >>>and memory hungry JVM we've just released, which is 1000 faster than the
    >>>previous one, yet 1000 slower than the next release".
    >>>In short, your claims are applicable to VB. VB is certainly on the brink
    >>>of vanishing. C# will probably take its place. C++ is here to stay not
    >>>because of bigotry of stiffneckedness but because there's simply no
    >>>alternative language that can compete with it.
    >>>
    >>>Danny

    >>
    >>
    >>Hi Danny, regarding you points:
    >>
    >>PERFORMANCE
    >>
    >>Have a look at this site: http://www.devhood.com/Tutorials/tut...utorial_id=203
    >>
    >>It compares a number of performance tests of a number of languages. Note
    >>how VB.NET (and C#) compares against Visual C++. As can be seen VC++ offers
    >>no advantage.
    >>
    >>Also, remember I’m talking specifically about application development and
    >>not system development. For example, consider an application that records
    >>a sales order. It’s makes no difference if the C/C++ execute 10 times faster
    >>that it’s VB equivalent; it comes down to network speed, the execution

    of
    >>the stored procedures, performance of the data access components etc. So
    >>using C++ instead of VB as the ‘glue’ to bring these components together
    >>is irrelevant. The expected increase in speed will not materialise.
    >>

    >
    >I don't want to speak for Danny but I don't think he or anyone else ever
    >suggested C++ makes network/database connections or user button clicking
    >run any faster. Everyone accepts your premise that VB is "just as good"

    in
    >this situation.


    Yes, and this situation is component based development. Remember I wrote
    “Application development nowadays incorporates some degree of RAD which leads
    to component-based development…..”.



    >>PORTABILITY
    >>
    >>Generally, in application development, C/C++ isn’t portable. Firstly we

    >are
    >>not really comparing like with like; which variant of C++ are we talking
    >>about MS Visual C++, Borland C Builder, IBM Visual Age for C++ etc.?
    >>
    >>Application development nowadays incorporates some degree of RAD which

    leads
    >>to component-based development. So if you use any third-party components
    >>and you do not have access to the source (or a version of the component

    >for
    >>the platform you are wanting to port to) or if you use technologies like
    >>COM/DCOM etc. your application will not port.
    >>

    >
    >Peculiar last line as VB is nothing at all if it is not COM.
    >
    >>
    >>In short, C++ offers no significant advantage. But VB is here to stay.

    VB
    >>is Microsoft “own” language (C# is now an open language which they no longer
    >>control);
    >> ...

    >
    >I am glad to see that M$'s hype and marketing dollars have borne some fruit.
    >I will grant you that C# is just as "Open" as Java.
    >
    >As for "VB is here to stay" - you are obviously in the denial stage of a
    >terminal illness. (Possibly drifting to 'anger'?) Get over it, VB is dead.


    Your arguements for such a statement are?

    >
    >>...
    >>VB is as powerful as any other .NET language VB is easy to Learn;
    >>There’s already a large VB developer community, source code; Managed C++
    >>in the .NET framework is there for upgrading legacy C++ code;
    >> ...

    >
    >As for "Managed C++ ... there for ugrading legacy C++ code." I think you
    >missed some of the hype. Managed C++ is for access, integration, and support
    >of the new .net framework.


    Not so, managed C++ extensions are poor and give the feel of being grafted
    onto the language rather than part of the core langauge design.

    >> ...
    >>May be I’ve just met some ‘bad’ C++ programmers. But do you really think
    >>that C# would be as popular to C++ programmers if it had been called Basic#
    >>? I don’t believe it would.
    >>
    >>There certainly are languages that have competed with C++ e.g. Delphi.

    C++
    >>has been losing ground to the RAD languages for a long time and will continue
    >>to do so; .NET will only speed thing ups.
    >>

    >
    >Most of these RAD were not created to compete with C++ they were created
    >to provide a development enviroment for easier Windows development. They
    >usually succeed in their choosen domain. However, most fail at some point
    >because they are subsets of the over-all solution domain. C++ provides access
    >to all possible solutions. C++ is harder to learn and definitely not RAD,
    >but it is the whole enchilada. No RAD or language has ever replaced C/C++
    >and there is little chance any will for the next ten years or so.


    No, anything that could be done at the application level could be done in
    Delphi, and VB could do most (with the help of the Win32 API).

    >Eventually with O/S kernel code becoming more modular, "APIs" more extensive,
    >and hardware faster and smarter there will be less and less reason to use
    >C++ in application programming. So I see C++ as not being replaced but less
    >commonly needed.


    Ahh!, At last! You agree, but you put it more diplomatically - "less commonly
    needed".

    >IMHO: C# and Hosting scripts will become the language of RAD but they will
    >all be backed up with C++ components and devices. Not sure how this mix

    will
    >play out over the next couple of years. However, the one thing I am sure
    >of, is VB and Pascal will not be there.
    >

    C# isn't superior to VB.NET, why do think VB.NET will also disappear?

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