What is the future of C++?

Discussion in 'C++' started by GTO, Jan 7, 2005.

  1. GTO

    GTO Guest

    I do not believe that C# is the future of C++. I also do not believe that
    adding two thousand new library functions to the standard library is the
    future of C++. But what is the future of C++? Is it as good as a programming
    language can get?

    Like so many of you, I programmed speech recognizers, image recognition
    systems, a portion of a chess program, lots of numeric code using STL, and
    tons of other applications in C++, (even firmware for time critical
    applications). Since 1997, I never missed even one feature in the language.
    The poor implementation of C++ in various compilers however was certainly
    outermost painful.

    Anyway, is there a way to improve C++? - I think it's the perfect
    programming language for our current computer architectures. I am even
    tempted to believe that future "enhancements" can only negatively impact the
    beauty of this language. No?

    Gregor
     
    GTO, Jan 7, 2005
    #1
    1. Advertising

  2. GTO wrote:
    > I do not believe that C# is the future of C++.


    I don't think anyone does. Some people think that C++ is on its last legs, with
    languages like C# as the languages of the future, or that C++/CLI is the future
    of C++.

    > I also do not believe
    > that adding two thousand new library functions to the standard
    > library is the future of C++.


    There will be lots of new library functions in the next version of the standard,
    largely from C99. You don't have to use them if you don't want to.

    New C++ libraries are mostly centered around new class templates.

    > But what is the future of C++? Is it as
    > good as a programming language can get?
    >
    > Like so many of you, I programmed speech recognizers, image
    > recognition systems, a portion of a chess program, lots of numeric
    > code using STL, and tons of other applications in C++, (even firmware
    > for time critical applications). Since 1997, I never missed even one
    > feature in the language. The poor implementation of C++ in various
    > compilers however was certainly outermost painful.
    >
    > Anyway, is there a way to improve C++? - I think it's the perfect
    > programming language for our current computer architectures. I am even
    > tempted to believe that future "enhancements" can only negatively
    > impact the beauty of this language. No?


    It's certainly refreshing to hear this point of view in a message with the
    current subject line. I was expecting someone compaining that C++ had fallen
    behind the times and was doomed to extinction.

    You shouldn't fear that C++ will be made worse, since the standards committee is
    very sensitive to backward compatibility. If you don't like new feartures, you
    can ignore them for the most part.

    However, in addition to lots of additions to the standard library, there are
    many exciting possibility for the next version of C++, including move semantics,
    a module system and threading.

    > Gregor


    Jonathan
     
    Jonathan Turkanis, Jan 7, 2005
    #2
    1. Advertising

  3. GTO wrote:
    > Anyway, is there a way to improve C++? - I think it's the perfect
    > programming language for our current computer architectures. I am

    even
    > tempted to believe that future "enhancements" can only negatively

    impact the
    > beauty of this language. No?


    You might want to discuss this in comp.std.c++ where many of the C++
    committee members hang out: this is the crowd which moves C++ forward
    (and it is open, i.e. everybody can participate essentially by joining
    a national standardization body).

    I don't think that C++ is perfect, although I think it is the best
    choice currently available. You said you were using templates but
    apparently you weren't implementing them: in the context of templates
    the most dire needs I have found arise but there are others not related
    to templates, too. From my perspective there is a set of important
    areas
    which need fixing (and which aren't library issues at all):

    - Concurrency needs to be integrated into the language. Much of this
    will
    be in form of a library but some essential stuff like an overhaul of
    the C++ memory model has to be done in the core language.
    - Templates and meta programming need fixing. There are various issues
    like template typedefs, something like "typeof" (I the current
    direction goes under the name of "decl_type"), possibly concept
    support,
    more structured type capability detection, and a whole bunch of other
    stuff.
    - Type Information, both at compile time (again for the use in
    templates)
    and at run time (i.e. something akin to reflection).
    - Move semantics allowing non-POD objects to be moved efficiently
    between
    locations (e.g. when returning an object or when resizing a
    'std::vector').

    This is just which immediately pops to my head when thinking about
    necessary changes to C++. Other may think of other stuff and consider
    it
    more important (e.g. optional garbage collection rates high for many
    people). There is a host of proposals being made (have a look at the
    "papers" section at <http://www.open-std.org/jtc1/sc22/wg21/> to get an
    overview) and more halfbaked ideas being circulated amoung committee
    members. The proposals and ideas range from more or less minor fixes to
    rather major changes.

    In any case, the C++ committee is well aware that some change is needed
    to keep C++ attractive. For example, with multi-processors or
    hyperthreaded
    CPUs becoming common in the mainstream market (I'd guess that the
    average
    desktop computer in a decade will have more than just one CPU) support
    for
    multi-threading is essential. The next revision of the standard is
    scheduled
    to become available sometime in this decade - and it is more likely
    that it
    is 2009 than anything earlier...
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Jan 7, 2005
    #3
  4. GTO

    GTO Guest

    Regarding "move semantics", I thought that C++ already supports some sort of
    moving of "expensive" objects (see copy constructor etc.). But to further
    optimize C++, it might come handy. Or should we not just leave it up to
    optimizing compilers to do this kind of work?

    Regarding "threading", do you mean support for multithreading (a la JAVA)?
    If yes, I would rather not see this added to C++ since support for
    multithreaded concepts are details of the system's architecture and not the
    language. But maybe you were referring to something else.

    Gregor


    "Jonathan Turkanis" <> wrote in message
    news:...
    > GTO wrote:
    >> I do not believe that C# is the future of C++.

    >
    > I don't think anyone does. Some people think that C++ is on its last legs,
    > with
    > languages like C# as the languages of the future, or that C++/CLI is the
    > future
    > of C++.
    >
    >> I also do not believe
    >> that adding two thousand new library functions to the standard
    >> library is the future of C++.

    >
    > There will be lots of new library functions in the next version of the
    > standard,
    > largely from C99. You don't have to use them if you don't want to.
    >
    > New C++ libraries are mostly centered around new class templates.
    >
    >> But what is the future of C++? Is it as
    >> good as a programming language can get?
    >>
    >> Like so many of you, I programmed speech recognizers, image
    >> recognition systems, a portion of a chess program, lots of numeric
    >> code using STL, and tons of other applications in C++, (even firmware
    >> for time critical applications). Since 1997, I never missed even one
    >> feature in the language. The poor implementation of C++ in various
    >> compilers however was certainly outermost painful.
    >>
    >> Anyway, is there a way to improve C++? - I think it's the perfect
    >> programming language for our current computer architectures. I am even
    >> tempted to believe that future "enhancements" can only negatively
    >> impact the beauty of this language. No?

    >
    > It's certainly refreshing to hear this point of view in a message with the
    > current subject line. I was expecting someone compaining that C++ had
    > fallen
    > behind the times and was doomed to extinction.
    >
    > You shouldn't fear that C++ will be made worse, since the standards
    > committee is
    > very sensitive to backward compatibility. If you don't like new feartures,
    > you
    > can ignore them for the most part.
    >
    > However, in addition to lots of additions to the standard library, there
    > are
    > many exciting possibility for the next version of C++, including move
    > semantics,
    > a module system and threading.
    >
    >> Gregor

    >
    > Jonathan
    >
    >
     
    GTO, Jan 7, 2005
    #4
  5. GTO

    GTO Guest

    > members. The proposals and ideas range from more or less minor fixes to
    > rather major changes.
    >


    I have read some of the "proposed" additions to C++, but I would like to see
    minor fixes rather than major changes. For me JAVA has become a rather bad
    example of how to move a language into the future. But you are right, the
    standard committee might try everything possible to keep C++ "attractive".
    Hyperthreaded CPUs or at least multiple CPUs are certainly in every box
    until 2009. But what about FPGA's instead of CPU's? Would it not be easier
    to have on-the-fly C++ compiler generate FPGA code rather than always run
    everything on general purpose switches? In this case, the improvements would
    be more in the compiler architecture rather than in the language.

    Gregor
     
    GTO, Jan 7, 2005
    #5
  6. GTO wrote:

    > I do not believe that C# is the future of C++.



    What has C# to do with C++?


    > I also do not believe that
    > adding two thousand new library functions to the standard library is the
    > future of C++. But what is the future of C++? Is it as good as a programming
    > language can get?



    The future of C++ is to be one of the best practical programming
    languages out there.


    > Anyway, is there a way to improve C++? - I think it's the perfect
    > programming language for our current computer architectures. I am even
    > tempted to believe that future "enhancements" can only negatively impact the
    > beauty of this language. No?



    C++ will hopefully keep expanding by adopting new mainstream paradigms
    and improving the existing supported ones.


    Some library extensions will surely take place. For example check the
    upcoming TR1:

    http://www.open-std.org/jtc1/sc22/wg21/docs/library_technical_report.html




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Jan 7, 2005
    #6
  7. GTO wrote:
    > Regarding "move semantics", I thought that C++ already supports some

    sort of
    > moving of "expensive" objects (see copy constructor etc.). But to

    further
    > optimize C++, it might come handy. Or should we not just leave it up

    to
    > optimizing compilers to do this kind of work?


    Moving objects is not just a matter of optimization: some objects
    cannot
    be copied at all (e.g. streams) but it would be desirable to move them,
    e.g. when returning them from a function. Also, it is desirable to have
    guarantees about certain things rather than hoping all compilers your
    system runs on implement a certain non-trivial optimization.

    > Regarding "threading", do you mean support for multithreading (a la

    JAVA)?
    > If yes, I would rather not see this added to C++ since support for
    > multithreaded concepts are details of the system's architecture and

    not the
    > language. But maybe you were referring to something else.


    Some portions of multi-threading go beyond a system's architecture and
    it is, again, necessary to have certain guarantees. Notably, it is
    necessary to have guarantees about ordering read and write operations
    relative to access of potentially shared resources, independent of the
    underlying multi-threading architecture. For example, the compiler
    shall
    be prohibited to move read access before the statement acquiring a lock
    (you might want to have a look at
    <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1738.pdf> for
    a more thorough coverage; I'd hope for a more detailed discussion but
    I'm not aware of any).
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Jan 7, 2005
    #7
  8. GTO wrote:
    > > members. The proposals and ideas range from more or less minor

    fixes to
    > > rather major changes.
    > >

    >
    > I have read some of the "proposed" additions to C++, but I would like

    to see
    > minor fixes rather than major changes. For me JAVA has become a

    rather bad
    > example of how to move a language into the future. But you are right,

    the
    > standard committee might try everything possible to keep C++

    "attractive".
    > Hyperthreaded CPUs or at least multiple CPUs are certainly in every

    box
    > until 2009. But what about FPGA's instead of CPU's? Would it not be

    easier
    > to have on-the-fly C++ compiler generate FPGA code rather than always

    run
    > everything on general purpose switches? In this case, the

    improvements would
    > be more in the compiler architecture rather than in the language.


    I'm not sufficiently familiar with FPGAs but if these support some form
    of multi-threading, some form of multi-threading aware memory model
    would
    still be necessary (and if they don't, I don't think they can solve the
    whole problem) - in addition to improvements to the compiler back-end.
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Jan 7, 2005
    #8
  9. Microsoft has proposed C++/CLI. Among other things, it supports
    a built-in garbage collector. It even supports STL as STL.NET.

    Deepa
    --
    http://www.EventHelix.com/EventStudio
    EventStudio 2.5 - Automate sequence diagram generation
     
    EventHelix.com, Jan 7, 2005
    #9
  10. EventHelix.com wrote:
    > Microsoft has proposed C++/CLI. Among other things, it supports
    > a built-in garbage collector. It even supports STL as STL.NET.


    Nope, Microsoft has not proposed this as approach to C++. Nor
    would C++/CLI stand any reasonable chance of becoming the
    C++ standard!

    C++/CLI is Microsoft's attempt to make something roughly
    resembling C++ operational on a system which tries hard to
    avoid integration of C++. Sure, you can run C++ on that
    system but it doesn't integrate into the "managed" part of
    it.
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Jan 7, 2005
    #10
  11. GTO

    Randy Yates Guest

    "Ufit" <> writes:

    > "Ioannis Vranos" <> wrote in message news:1105081564.329048@athnrd02...
    > > GTO wrote:
    > >
    > > > I do not believe that C# is the future of C++.

    > >
    > >
    > > What has C# to do with C++?
    > >

    > /\
    > Exactly what I was thinking.
    > IMHO C# = VB with small changes.
    > Let me brighten the case up this way - I was developing custom fast databases
    > and tried VB.NET then C# and the code was SO big and slow. Still needed more speed.
    > So I looked in C++ applications and rewrote one program from VB to VC++.
    > I was amazed - code was smaller maybe 4times, program faster 10times and customer
    > happy as hell.) Just my app wasn't so fat in graphics as was C# one.
    > I totaly left VB\C# practicing and chose C++ - the best language out there.


    I can't really speak to the issue since I've not used C#, but it sure SEEMS like
    C# is a bad solution in search of a self-imposed problem. I've heard it said C#
    is C++ with built-in overflow checking - is that true?

    I agree with the general sentiment, though - we don't need another language that
    essentially adds little value to C++ - let's stick with what we've got and improve
    it and/or the libraries available for it.
    --
    Randy Yates
    Sony Ericsson Mobile Communications
    Research Triangle Park, NC, USA
    , 919-472-1124
     
    Randy Yates, Jan 7, 2005
    #11
  12. Randy Yates wrote:
    > I agree with the general sentiment, though - we don't need another

    language that
    > essentially adds little value to C++ - let's stick with what we've

    got and improve
    > it and/or the libraries available for it.


    The key reason I see for an entirely new language (probably created
    with C++'s
    mindset) is that C++ has acquired that much legacy that it is hard to
    create
    a C++ processor. As a result, there are few good C++ tools which help
    in various
    development settings (reverse engineering of code for documentation,
    code analysis
    for correctness, IDE navigation, code completion, etc.) and those which
    exist are
    often quite imperfect (e.g. they fail utterly if heavy template stuff
    is used).
    This lack of tools, including correct and fast compilers, is the major
    problem of
    C++. I don't think that it can be rectified while retaining the usual
    amount of
    backward compatibility.

    I think that there will be a workable C++0x which is compatible with
    the current
    C++ in that current C++ is valid C++0x. However, evolution beyond this
    step will
    need to get rid of many aspects of C++ and loads of C++'s complexities.
    I don't
    think that we can simplify the language sufficiently without breaking
    compatiblity.
    However, simplification in various aspects is already necessary.

    Some trends are also hard to ignore: newer languages typically run on
    some form
    of virtual machine. They typically support garbage collection which can
    even be
    a speed advantage e.g. in multi-threaded environments. ... and, of
    course,
    multi-threading support will be essentially with multi-processor or
    hyper-threading machines becoming mainstream. C++ will have to change
    to
    accomodate future technology.
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Jan 7, 2005
    #12
  13. GTO

    Randy Yates Guest

    "Dietmar Kuehl" <> writes:

    > Randy Yates wrote:
    > > I agree with the general sentiment, though - we don't need another
    > > > language that essentially adds little value to C++ - let's stick

    > > with what we've > got and improve it and/or the libraries
    > > available for it.

    >
    > The key reason I see for an entirely new language (probably created
    > with C++'s mindset) is that C++ has acquired that much legacy that
    > it is hard to create a C++ processor. As a result, there are few
    > good C++ tools which help in various development settings (reverse
    > engineering of code for documentation, code analysis for
    > correctness, IDE navigation, code completion, etc.)


    xemacs foots two of those bills. Going to another language does not
    implicitly guarantee either of the other two.

    > and those which
    > exist are often quite imperfect (e.g. they fail utterly if heavy
    > template stuff is used). This lack of tools, including correct and
    > fast compilers,


    Huh? What's wrong with g++? It's certainly fast enough for me. If
    I cranked out a few dozen lines of code per minute I might start
    to think that compile time would be a signficant overhead, but
    I don't.

    > is the major problem of C++. I don't think that it
    > can be rectified while retaining the usual amount of backward
    > compatibility.


    I don't really even see the problem, so I don't see what needs to
    be rectified.

    > I think that there will be a workable C++0x which is compatible with
    > the current C++ in that current C++ is valid C++0x.


    What's "C++0x"?

    > However, evolution beyond this step will need to get rid of many
    > aspects of C++ and loads of C++'s complexities.


    Why? Which ones?

    > I don't think that we can simplify the language sufficiently without
    > breaking compatiblity. However, simplification in various aspects
    > is already necessary.


    Why do we need to simplify the language?

    > Some trends are also hard to ignore: newer languages typically run
    > on some form of virtual machine. They typically support garbage
    > collection which can even be a speed advantage e.g. in
    > multi-threaded environments. ... and, of course, multi-threading
    > support will be essentially with multi-processor or hyper-threading
    > machines becoming mainstream. C++ will have to change to accomodate
    > future technology. -- <mailto:>
    > <http://www.dietmar-kuehl.de/> <http://www.contendix.com> - Software
    > Development & Consulting


    I'll see you in the marketplace.
    --
    Randy Yates
    Sony Ericsson Mobile Communications
    Research Triangle Park, NC, USA
    , 919-472-1124
     
    Randy Yates, Jan 7, 2005
    #13
  14. Randy Yates wrote:
    > "Dietmar Kuehl" <> writes:
    > > The key reason I see for an entirely new language (probably created
    > > with C++'s mindset) is that C++ has acquired that much legacy that
    > > it is hard to create a C++ processor. As a result, there are few
    > > good C++ tools which help in various development settings (reverse
    > > engineering of code for documentation, code analysis for
    > > correctness, IDE navigation, code completion, etc.)

    >
    > xemacs foots two of those bills.


    These must be IDE navigation and code completion. Actually, I doubt
    that (x)emacs can do a perfect job on those two things and an
    imperfect one does not really help: if you rely on code completion
    and it does not provide you with appropriate template instantiations
    or suppresses them in other contexts, it is somewhat unhelpful at
    best. Likewise I doubt that (x) emacs is capable of navigating to
    the appropriate [partial] specialization of a template. It surely
    provides some help but it does not go all the way.

    > Going to another language does not implicitly guarantee either of
    > the other two.


    We are in perfect agreement on this. However, a new language gives
    the opportunity to add considerations like potential tool support
    to the language design guidelines.

    > > and those which
    > > exist are often quite imperfect (e.g. they fail utterly if heavy
    > > template stuff is used). This lack of tools, including correct and
    > > fast compilers,

    >
    > Huh? What's wrong with g++? It's certainly fast enough for me.


    First of all, g++ is wrong in some cases and it does not support
    standard C++. If you disagree, try to use the 'export' keyword.
    Considering g++ speed, I think it is reasonable but I would prefer
    it to be faster: I tend to run testsuites often and most of my
    projects have bigger testsuites which take considerable amounts of
    time. Compilation speed of g++ compared to e.g. VC++ is not really
    favourable although this shows that C++ can be compiled faster than
    what g++ does (but then, with other flows). Essentially, there is
    still only one standard conforming C++ implementation: EDG's
    front-end and just one compiler (AFAIK) which actually ships it
    with the whole feature set (Comeau). However, this compiler is not
    exactly fast either. Of course, other compilers (C, Java, C#, etc.)
    don't have that much to do (e.g. no templates) but they are much
    faster for comparable amounts of code.

    > If
    > I cranked out a few dozen lines of code per minute I might start
    > to think that compile time would be a signficant overhead, but
    > I don't.


    You might think differently if most of your code were in testsuits
    which get recompiled with each run.

    > > is the major problem of C++. I don't think that it
    > > can be rectified while retaining the usual amount of backward
    > > compatibility.

    >
    > I don't really even see the problem, so I don't see what needs to
    > be rectified.


    The template mechanism is one of C++'s most powerful features but
    it inherently broken: just have a look at all those funny ADL
    discussions on comp.lang.c++.moderated or comp.std.c++. Correct
    template support is pretty hard to get it right and except for
    EDG's front-end nobody has made it (and even EDG's front-end seems
    to be imperfect in some corner-cases).

    > > I think that there will be a workable C++0x which is compatible

    with
    > > the current C++ in that current C++ is valid C++0x.

    >
    > What's "C++0x"?


    The working title for the next C++ standard: the committee is
    working on the next C++ revision and plans to finish it in this
    decade. Most likely, the "x" will eventually be replaced by "9".

    > > However, evolution beyond this step will need to get rid of many
    > > aspects of C++ and loads of C++'s complexities.

    >
    > Why? Which ones?


    Why? Because it is hard to get remember all issues even for C++
    experts. Which ones? Well, the core language specification (i.e.
    C++ without its standard library) takes roughly 250 pages. I'd
    consider this to be more than most people can remember and I
    actually doubt that there is anybody who does know all the details
    without refering back to this document in all situations. This is
    clearly too complex.

    But don't get me wrong: I surely want to retain C++'s power. I
    just want to get rid of all those special rules you need to
    remember. It actually starts with the declaration syntax: it is
    not really obvious that

    | std::vector<int> vec(std::istream_iterator(in),
    | std::isteram_iterator());

    declares a function rather than defining an object, is it?

    > Why do we need to simplify the language?


    Because it is too complex for both humans and machines!

    > I'll see you in the marketplace.


    I have no trouble with that: I think I'm quite good at writing
    C++ and C++ is clearly my preferred language. However, I also
    see C++'s limitations and disadvantages, many of which are not
    really necessary - once we accept certain changes.
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Jan 7, 2005
    #14
  15. Randy Yates wrote:

    > I can't really speak to the issue since I've not used C#, but it sure SEEMS like
    > C# is a bad solution in search of a self-imposed problem. I've heard it said C#
    > is C++ with built-in overflow checking - is that true?
    >
    > I agree with the general sentiment, though - we don't need another language that
    > essentially adds little value to C++ - let's stick with what we've got and improve
    > it and/or the libraries available for it.



    C#/CLI which is its exact name, is just syntax (as C++/CLI) with few
    binding descriptions with CLI (which is a standard of its own).


    It doesn't provide anything more. However C# programmers (as well as VB
    ..NET programmers), think that all CLI (and .NET) is C#. That is, they
    think the whole CLI/.NET library is C# (and VB respectively)!


    They say for example, "System::String of C#, or System::StringBuilder
    are far better than C++'s string", missing the fact that myself also use
    System::String and System::StringBuilder in my own applications.


    Also with C++/CLI, C++ becomes the systems programming language of .NET
    with far more abilities than C#.


    To name a few, templates together with generics, deterministic
    destruction (stack semantics/delete), etc.


    For example in the upcoming revision of CLI (.NET 2.0), in C#/CLI,
    C++/CLI, and the rest languages it is not directly supported to pin ref
    objects in the managed heap directly.


    However in C++ you can cast a ref handle to some other value handle,
    then use that handle to pin the object and then with another
    reinterpret_cast casting to an unsigned char * and print out its
    contents. :)




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Jan 7, 2005
    #15
  16. Dietmar Kuehl wrote:

    > Some trends are also hard to ignore: newer languages typically run on
    > some form
    > of virtual machine. They typically support garbage collection which can
    > even be
    > a speed advantage e.g. in multi-threaded environments.



    Check C++/CLI.


    > ... and, of
    > course,
    > multi-threading support will be essentially with multi-processor or
    > hyper-threading machines becoming mainstream. C++ will have to change
    > to
    > accomodate future technology.



    Check OpenMP (supported in VC++ 2005 along with others).




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Jan 7, 2005
    #16
  17. Dietmar Kuehl wrote:

    > Nope, Microsoft has not proposed this as approach to C++. Nor
    > would C++/CLI stand any reasonable chance of becoming the
    > C++ standard!



    C++/CLI is a standard of C++ extensions that helps programmers to take
    *full advantage* of a CLI environment (actually it is the *systems
    programming language* of CLI (and .NET).




    > C++/CLI is Microsoft's attempt to make something roughly
    > resembling C++ operational on a system which tries hard to
    > avoid integration of C++. Sure, you can run C++ on that
    > system but it doesn't integrate into the "managed" part of
    > it.




    You are completely wrong. With C++/CLI you can write fully verifiable
    ..NET programs with more facilities and possibilities available than C#.




    --
    Ioannis Vranos

    http://www23.brinkster.com/noicys
     
    Ioannis Vranos, Jan 7, 2005
    #17
  18. GTO

    Ufit Guest

    "Ioannis Vranos" <> wrote in message news:1105081564.329048@athnrd02...
    > GTO wrote:
    >
    > > I do not believe that C# is the future of C++.

    >
    >
    > What has C# to do with C++?
    >

    /\
    Exactly what I was thinking.
    IMHO C# = VB with small changes.
    Let me brighten the case up this way - I was developing custom fast databases
    and tried VB.NET then C# and the code was SO big and slow. Still needed more speed.
    So I looked in C++ applications and rewrote one program from VB to VC++.
    I was amazed - code was smaller maybe 4times, program faster 10times and customer
    happy as hell.) Just my app wasn't so fat in graphics as was C# one.
    I totaly left VB\C# practicing and chose C++ - the best language out there.
    Greets

    Uf
     
    Ufit, Jan 7, 2005
    #18
  19. GTO

    seguso Guest

    GTO wrote:

    > I do not believe that C# is the future of C++. I also do not believe that
    > adding two thousand new library functions to the standard library is the
    > future of C++. But what is the future of C++? Is it as good as a
    > programming language can get?


    Maybe adding higher-order functions, lambdas and type inference would make
    C++ at least a bit more readable and bearable. If you really want to shine,
    you could also add transparent backtracking a-la Prolog. Also, adding the
    possibility to program in a pure functional style would make it faster (due
    to static garbage collection) and less error prone.

    > Anyway, is there a way to improve C++? - I think it's the perfect
    > programming language for our current computer architectures.


    I suppose you don't know Mercury, Clean, Haskell, OCaml, Prolog. How many
    languages do you know?

    --
    Best Regards,
    Maurizio Colucci --- http://onefinger.sf.net
    Please remove the uppercase letters "S,P,A,M":
     
    seguso, Jan 7, 2005
    #19
  20. GTO

    Walter Guest

    "GTO" <> wrote in message
    news:tPpDd.8918$...
    > I do not believe that C# is the future of C++. I also do not believe that
    > adding two thousand new library functions to the standard library is the
    > future of C++.


    I agree.

    > But what is the future of C++? Is it as good as a programming
    > language can get?


    Not at all. C++ has evolved over decades, with new features evolving to fit
    new ideas in how to write programs. Each feature was carefully grafted over
    existing features to maintain backwards compatibility. As such, it resembles
    a farm house that started out as a cabin, but as each successive family
    owned it they added new rooms and repurposed existing ones, resulting in a
    lot of odd compromises and weirdities.

    Many of us have programmed in C++ for so many years that we no longer even
    see what those compromises and weirdities are, we can drive around them in
    our sleep. But they're still there, they still make the language hard to
    learn, and make programming in C++ unnecessarilly tedious and error-prone.
    (One small example is when tag names are sometimes in a separate name space,
    and sometimes not. There's no reason for that nonsense other than backwards
    compatibility, no sane language designer would design a new language that
    way.)

    C++ stands to gain a lot from being refactored, a process by which one looks
    at what works and what doesn't, and engineers a new language to make what
    works work in a straightforward, seemless manner.

    > Like so many of you, I programmed speech recognizers, image recognition
    > systems, a portion of a chess program, lots of numeric code using STL, and
    > tons of other applications in C++, (even firmware for time critical
    > applications). Since 1997, I never missed even one feature in the

    language.
    > The poor implementation of C++ in various compilers however was certainly
    > outermost painful.


    The "poor implementation" is usually a consequence of the complexity,
    inconsistencies and weirdities of the language. It's unlikely that C++ has
    just had the bad luck of having crummy compiler writers attracted to it <g>.

    > Anyway, is there a way to improve C++? - I think it's the perfect
    > programming language for our current computer architectures. I am even
    > tempted to believe that future "enhancements" can only negatively impact

    the
    > beauty of this language. No?


    Check out the D programming language for an example of how one can have the
    efficiency and power of C++ without the endless complexity.

    -Walter
    www.digitalmars.com/d/ the D Programming Language
    "code of the nerds"
     
    Walter, Jan 7, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Midnight Java Junkie

    future of high-speed cable modems?

    Midnight Java Junkie, Jun 20, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    455
    Midnight Java Junkie
    Jun 20, 2004
  2. Elias Politakis

    Is ASP.NET the future of web applications

    Elias Politakis, Dec 1, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    1,329
    Cowboy \(Gregory A. Beamer\)
    Dec 1, 2003
  3. Elias Politakis

    Is ASP.NET the future of web applications

    Elias Politakis, Dec 1, 2003, in forum: ASP .Net
    Replies:
    2
    Views:
    458
  4. =?Utf-8?B?QW5kcmV3?=

    Future of ASP

    =?Utf-8?B?QW5kcmV3?=, Apr 29, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    406
  5. James P.
    Replies:
    7
    Views:
    12,523
    phamtasmic
    Jul 13, 2004
Loading...

Share This Page