C++ danger to break due to its weight, fragmentation danger - C++0x

Discussion in 'C++' started by Ioannis Vranos, Apr 19, 2004.

  1. I would like to see your views on these.


    C++98 is already a large language since it supports 4 paradigms and each one
    is supported well, with optimal space and time efficiency. And this is
    excellent.

    From the few things that i have read about C++0x, in addition to some C99...
    features (actually some other term comes in my mind for this instinctively,
    but it is another subject for discussion), there is library expansion with
    new facilities, some of them *not supported directly by language constructs*
    (= exotic) like networking. Also not all of the new features will be
    required by the standard to be implemented everywhere, since not all of this
    functionality will be available in all computer systems (e.g. networking
    again).

    This is a departure from the initial language ideals, that is to provide a
    common well-defined functionality subset of all existing computer systems
    out there with an integral language. Today, all C++98 language constructs
    are available to all C++98 compliant compilers.


    The existence of facilities not required to be implemented in a compliant
    C++0x implementation, is by itself fragmentation. ISO C++0x code that
    compiles in a C++0x compliant compiler will not compile in another, although
    the computer system may have the functionality available (e.g. networking
    again). So one may have C++0x networking code that compiles in a compiler,
    and does not in another. Why would one write code using C++0x facilities
    which is not guaranteed to compile everywhere, not even in the same platform
    with a different compiler? The availability of such facilities should be
    left to third party system-specific and framework APIs (e.g. .NET, QT,
    etc). Will a programmer write "ISO C++0x" network code not guaranteed to
    compile in another ISO C++0x compliant compiler even in the same platform,
    or will he use the APIs of his platform?

    Due to this, it is very possible that most compiler implementors will stick
    with the required stuff. This means that no longer we will have a coherent
    language, and this by definition (the standard itself).


    The idea of library facilities not supported by language constructs
    (=exotic), does not fit in a systems programming language, which must be
    self-dependent. This means that either those facilities must not be part of
    the library, or they are deemed very necessary and thus the fundamental
    language constructs must be added to the core language. Since they are
    exotic, we can conclude that they are not very necessary. The unneeded
    language facilities add extra "weight" to the language.


    The idea of numerous extensions to the library (i am talking about
    non-exotic stuff here) is nice, but adds much extra weight to the language.
    The result is that each implementor may choose to implement only what he
    considers as important from all this stuff, even to stick only with C++98
    library. This means extra fragmentation, and this time to the
    *required-by-the-standard* core. In this case, there is great danger the
    language to break by its weight. The new core of the library may become
    non-portable de facto, and this will mean the abortion of the most new part
    of C++0x. If this happens, C++ may become extinct!


    I am talking about possible dangers, so please be gentle with your critique.






    Regards,

    Ioannis Vranos
     
    Ioannis Vranos, Apr 19, 2004
    #1
    1. Advertising

  2. Ioannis Vranos

    Jack Klein Guest

    On Mon, 19 Apr 2004 09:26:26 +0300, "Ioannis Vranos"
    <> wrote in comp.lang.c++:

    > I would like to see your views on these.
    >
    >
    > C++98 is already a large language since it supports 4 paradigms and each one
    > is supported well, with optimal space and time efficiency. And this is
    > excellent.
    >
    > From the few things that i have read about C++0x, in addition to some C99...
    > features (actually some other term comes in my mind for this instinctively,
    > but it is another subject for discussion), there is library expansion with
    > new facilities, some of them *not supported directly by language constructs*
    > (= exotic) like networking. Also not all of the new features will be
    > required by the standard to be implemented everywhere, since not all of this
    > functionality will be available in all computer systems (e.g. networking
    > again).


    [snip]

    This newsgroup is for discussing using the C++ language that exists
    today. The (moderated) newsgroup for discussing possible future
    additions or changes to the C++ language standard is comp.std.c++.
    This post belongs there, not here.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Apr 19, 2004
    #2
    1. Advertising

  3. "Jack Klein" <> wrote in message
    news:...
    > On Mon, 19 Apr 2004 09:26:26 +0300, "Ioannis Vranos"
    > <> wrote in comp.lang.c++:
    >
    > > I would like to see your views on these.
    > >
    > >
    > > C++98 is already a large language since it supports 4 paradigms and each

    one
    > > is supported well, with optimal space and time efficiency. And this is
    > > excellent.
    > >
    > > From the few things that i have read about C++0x, in addition to some

    C99...
    > > features (actually some other term comes in my mind for this

    instinctively,
    > > but it is another subject for discussion), there is library expansion

    with
    > > new facilities, some of them *not supported directly by language

    constructs*
    > > (= exotic) like networking. Also not all of the new features will be
    > > required by the standard to be implemented everywhere, since not all of

    this
    > > functionality will be available in all computer systems (e.g. networking
    > > again).

    >
    > [snip]
    >
    > This newsgroup is for discussing using the C++ language that exists
    > today. The (moderated) newsgroup for discussing possible future
    > additions or changes to the C++ language standard is comp.std.c++.
    > This post belongs there, not here.




    I checked the clc FAQ and did not see any restriction for current standard
    discussion.






    Ioannis Vranos
     
    Ioannis Vranos, Apr 19, 2004
    #3
  4. "Ioannis Vranos" <> wrote in message
    news:c5vsuq$1nr0$...
    >
    > I checked the clc FAQ and did not see any restriction for current standard
    > discussion.



    I meant: I checked the clc++ FAQ and did not see any restriction for
    future-standard-features discussions.






    Ioannis Vranos
     
    Ioannis Vranos, Apr 19, 2004
    #4
  5. "Ioannis Vranos" <> wrote in message
    news:c5vtaf$1opc$...
    >
    > I meant: I checked the clc++ FAQ and did not see any restriction for
    > future-standard-features discussions.



    And i had posted the same message to clc++m before i post it here. I posted
    here too, because here there are more people and the flow of discussion is
    faster.






    Regards,

    Ioannis Vranos
     
    Ioannis Vranos, Apr 19, 2004
    #5
  6. "Ioannis Vranos" <> wrote in message
    news:c5vu2b$1qum$...
    >
    > And i had posted the same message to clc++m before i post it here. I

    posted

    #^*%&(%$$. I meant to say comp.std.c++.






    Ioannis Vranos
     
    Ioannis Vranos, Apr 19, 2004
    #6
  7. "Ioannis Vranos" <> wrote in message news:<c5vtaf$1opc$>...
    > I checked the clc++ FAQ and did not see any restriction for
    > future-standard-features discussions.


    5.9 Only post to comp.lang.c++ if your question is about the C++ language _itself_.

    Networking is not in the C++ language. 5.9 also points to the correct
    group: comp.std.c++
    "Discussion directly related to the evolving ANSI/ISO C++ standard"
    i.e. what /may become/ the C++ language.


    English is sometimes sloppy when compared to other languages,
    especially when it comes to verbs and events in the future.

    "Ultimately this means your question must be answerable by looking
    into the C++ language definition as determined by the ISO/ANSI
    C++ Standard document, and by planned extensions and adjustments."
    (FAQ, 5.9)
    does not cover your case. Networking is not planned, but it might
    become planned depending on discussions in csc++ and WG21.


    Regards,
    Michiel Salters
     
    Michiel Salters, Apr 19, 2004
    #7
  8. "Ioannis Vranos" <> wrote:
    > From the few things that i have read about C++0x, in addition to some C99...
    > features (actually some other term comes in my mind for this instinctively,
    > but it is another subject for discussion), there is library expansion with
    > new facilities, some of them *not supported directly by language constructs*
    > (= exotic) like networking. Also not all of the new features will be
    > required by the standard to be implemented everywhere, since not all of this
    > functionality will be available in all computer systems (e.g. networking
    > again).


    Your information on this issue is wrong. Although we are discussing how to
    possibly deal with features not available everywhere, there are no [new]
    libraries for the standard on the way which are optional. In particular, no
    networking library is currently under discussion. There is, however, a
    technical report on on standard C++ library extensions (lib-tr for short)
    which provides some features which are unimplementable without non-standard
    extensions to the C++ compiler. These features need not be implemented by
    all compilers for the context of the lib-tr but this will probably change
    if the components are added to the standard: none of these is inherently
    unimplementable on some systems (it is always just accessing information
    which is available anyway to the compiler but it would require compilers to
    change).

    As of now, nothing like networking or GUI is under discussion and I doubt
    that any proposal for such a component would stand a reasonable chance.
    This is not because it is unimplementable on some platforms but because the
    variation between systems is too big to warrant standardization (yes, I
    know: "Java has done it" - actually, it has not).

    > This is a departure from the initial language ideals, that is to provide a
    > common well-defined functionality subset of all existing computer systems
    > out there with an integral language. Today, all C++98 language constructs
    > are available to all C++98 compliant compilers.


    This statement is also wrong: there are at least three different kinds of
    compliant C++ implementations. The C++ standard explicitly mentions two of
    them:

    - A free standing implementation is one which only has a very rudimentary
    standard library. Essentially, only the language support library (eg.
    the memory allocation operators and the exception classes mentioned in
    the core language) is guaranteed to be supported there.
    - A hosted implementation supports the whole library. However, there are
    two variations for a hosted implementation:
    - a good one where eg. the file operations indeed write some form of a
    file.
    - a "bad" one where eg. the file operations actually have no effect.

    > The existence of facilities not required to be implemented in a compliant
    > C++0x implementation, is by itself fragmentation.


    Other standard also allow optional portions and this approach works
    reasonable well for them. The issue for the customer becomes then to
    select an implementation with the proper support. If there is a market for
    the corresponding support, most vendors will implement it. Actually, this
    is already the case: The separation model for template compilation (the
    stuff associated witht the keyword "export") is only implemented by one
    compiler (well, actually potentially a group of compilers: those based on
    the EDG front-end). The other compiler vendors think that there is no
    market which warrants implementation of this featurs - although it not an
    optional one and any compiler not supporting it is not a C++ compiler: as
    far as I know, there is currently only one existing standard conforming C++
    compiler, namely the implementation of Comeau (see
    <http://www.comeaucomputing.com>). Of course, it can be assumed that no
    major software is entirely bug free but still no major C++ feature is
    missing from Comeau's C++ compiler when used with the Dinkumware standard
    library.

    > Due to this, it is very possible that most compiler implementors will stick
    > with the required stuff. This means that no longer we will have a coherent
    > language, and this by definition (the standard itself).


    This is already the case. Actually, implementers will stick to features
    requested by the market: if nobody or only few users want a compiler
    conforming to C++-0x, most C++ implementers will not implement it.

    > The idea of numerous extensions to the library (i am talking about
    > non-exotic stuff here) is nice, but adds much extra weight to the language.
    > The result is that each implementor may choose to implement only what he
    > considers as important from all this stuff, even to stick only with C++98
    > library. This means extra fragmentation, and this time to the
    > *required-by-the-standard* core. In this case, there is great danger the
    > language to break by its weight. The new core of the library may become
    > non-portable de facto, and this will mean the abortion of the most new part
    > of C++0x. If this happens, C++ may become extinct!


    This is funny: other claim that C++ will become extinct if we don't add
    major libraries (like eg. Java's) to the language. Taking both prognoses
    together, C++ will become extinct anyway. So why bother?

    My personal expectation is that we will effectively bring the core language
    in line with the C++/CLI binding currently standardized by ECMA and that
    C++ will grow and prosper as *the* programming language used for implementing
    applications on the dominant operating system or even operating systems (as
    the CLR is not restricted to a particular platform). I'm not saying that I
    like to follow the ECMA lead in this respect but I would guess that this is
    the most reasonable path to pursue.
    --
    <mailto:> <http://www.dietmar-kuehl.de/>
    <http://www.contendix.com> - Software Development & Consulting
     
    Dietmar Kuehl, Apr 19, 2004
    #8
  9. "Dietmar Kuehl" <> wrote in message
    news:...
    >


    At first I must tell that i have not enough information on what exactly is
    going on with the committee, i based my questions mainly on rumors. If there
    is a blog or something regarding C++0x please post some URL.


    > Your information on this issue is wrong. Although we are discussing how to
    > possibly deal with features not available everywhere,



    I had heared of that.


    > there are no [new]
    > libraries for the standard on the way which are optional.


    I did not know that.



    > In particular, no
    > networking library is currently under discussion.



    My info then was erroneus.


    > There is, however, a
    > technical report on on standard C++ library extensions (lib-tr for short)
    > which provides some features which are unimplementable without

    non-standard
    > extensions to the C++ compiler. These features need not be implemented by
    > all compilers for the context of the lib-tr but this will probably change
    > if the components are added to the standard: none of these is inherently
    > unimplementable on some systems (it is always just accessing information
    > which is available anyway to the compiler but it would require compilers

    to
    > change).



    So there is a proposal for exotic features.


    >
    > As of now, nothing like networking or GUI is under discussion and I doubt
    > that any proposal for such a component would stand a reasonable chance.
    > This is not because it is unimplementable on some platforms but because

    the
    > variation between systems is too big to warrant standardization (yes, I
    > know: "Java has done it" - actually, it has not).



    Who cares for Java anyway. :)


    > This is already the case. Actually, implementers will stick to features
    > requested by the market: if nobody or only few users want a compiler
    > conforming to C++-0x, most C++ implementers will not implement it.



    Well this is not already the case. All serious compiler vendors strive for
    C++98 conformance (even MS these days).



    > This is funny: other claim that C++ will become extinct if we don't add
    > major libraries (like eg. Java's) to the language. Taking both prognoses
    > together, C++ will become extinct anyway. So why bother?



    I think that the best approach is somewhere in the middle. More library
    facilities but not thousand of new facilities which not all will implement.
    And Java API is made by only one company SUN, as with all frameworks and
    APIs. Here we will expect many facilities from many. So it needs some
    caution.



    > My personal expectation is that we will effectively bring the core

    language
    > in line with the C++/CLI binding currently standardized by ECMA and that
    > C++ will grow and prosper as *the* programming language used for

    implementing
    > applications on the dominant operating system or even operating systems

    (as
    > the CLR is not restricted to a particular platform). I'm not saying that I
    > like to follow the ECMA lead in this respect but I would guess that this

    is
    > the most reasonable path to pursue.



    I agree with that entirely.






    Thanks for the clarifications!

    Ioannis Vranos
     
    Ioannis Vranos, Apr 19, 2004
    #9
  10. Ioannis Vranos

    Pete Becker Guest

    Ioannis Vranos wrote:
    >
    > From the few things that i have read about C++0x, in addition to some C99...
    > features (actually some other term comes in my mind for this instinctively,
    > but it is another subject for discussion), there is library expansion with
    > new facilities, some of them *not supported directly by language constructs*
    > (= exotic) like networking. Also not all of the new features will be
    > required by the standard to be implemented everywhere, since not all of this
    > functionality will be available in all computer systems (e.g. networking
    > again).


    That is, of course, a possibility, but no decisions have yet been made
    for C++0x. Your concerns are premature, to put it mildy. If you're so
    concerned that we're totally blind, though, join the standards
    committee, attend meetings, see what's actually happening, and if you
    have something to contribute, do so.

    --

    Pete Becker
    Dinkumware, Ltd. (http://www.dinkumware.com)
     
    Pete Becker, Apr 20, 2004
    #10
  11. "Ioannis Vranos" <> wrote in message news:<c61bh2$2ji2$>...
    > "Dietmar Kuehl" <> wrote in message
    > news:...


    >
    > > There is, however, a
    > > technical report on on standard C++ library extensions (lib-tr for short)
    > > which provides some features which are unimplementable without
    > > non-standard extensions to the C++ compiler. These features need
    > > not be implemented by all compilers for the context of the lib-tr
    > > but this will probably change if the components are added to the
    > > standard: none of these is inherently unimplementable on some
    > > systems (it is always just accessing information which is available
    > > anyway to the compiler but it would require compilers to change).

    >
    > So there is a proposal for exotic features.


    #define exotic new

    Seriously, we already have mechanisms to figure out in template code
    whether some type T is an int, or a pointer. Asking whether
    some type T is a union or an enum fits in with the list, but is in
    fact not possible or rather complex. This is being generalized,
    and a common interface is being proposed which can answer these kinds
    of questions with a uniform syntax. That's not exotic. Providing
    a single interface for a number of related functions is Good Software.

    Regards,
    Michiel Salters
     
    Michiel Salters, Apr 20, 2004
    #11
  12. "Michiel Salters" <> wrote in message
    news:...
    >
    > > So there is a proposal for exotic features.

    >
    > #define exotic new


    :)

    > Seriously, we already have mechanisms to figure out in template code
    > whether some type T is an int, or a pointer. Asking whether
    > some type T is a union or an enum fits in with the list, but is in
    > fact not possible or rather complex. This is being generalized,
    > and a common interface is being proposed which can answer these kinds
    > of questions with a uniform syntax. That's not exotic. Providing
    > a single interface for a number of related functions is Good Software.



    Yes that is nice and i agree with you. With the term "exotic" i meant
    facilities like network connections on the standard library, which wouldn't
    be possible to be defined using the core language since the core language
    would lack the basic constructs to support this kind of stuff. Since there
    is no network proposal, are there any proposals for other kinds of exotic
    facilities?






    Regards,

    Ioannis Vranos
     
    Ioannis Vranos, Apr 20, 2004
    #12
  13. Re: C++ danger to break due to its weight, fragmentation danger -C++0x

    On Tue, 20 Apr 2004, Ioannis Vranos wrote:

    >"Michiel Salters" <> wrote in message
    >news:...
    >>
    >> > So there is a proposal for exotic features.

    >>
    >> #define exotic new

    >
    >:)
    >
    >> Seriously, we already have mechanisms to figure out in template code
    >> whether some type T is an int, or a pointer. Asking whether
    >> some type T is a union or an enum fits in with the list, but is in
    >> fact not possible or rather complex. This is being generalized,
    >> and a common interface is being proposed which can answer these kinds
    >> of questions with a uniform syntax. That's not exotic. Providing
    >> a single interface for a number of related functions is Good Software.

    >
    >
    >Yes that is nice and i agree with you. With the term "exotic" i meant
    >facilities like network connections on the standard library, which wouldn't
    >be possible to be defined using the core language since the core language
    >would lack the basic constructs to support this kind of stuff. Since there


    Which "basic constructs"? For what "kind of stuff"? Many network
    protocols are written in C and could no doubt be rewritten in
    (idiomatic) Standard C++. This is also true, and even more so, of
    programming interfaces provided to network protocols, e.g. sockets for
    TCP connections. Your term "exotic" does not carry any meaning in this
    context, and you are making things worse by explaining it with another
    vague formulation. As far as I can judge, the problems relating to
    specifying an interface for networking functions that could be
    implemented on a wide range of platforms are due not to the allegedly
    restricted capabilities of the core language, but to the (lack or
    disparity of) networking support on those platforms.

    >is no network proposal, are there any proposals for other kinds of exotic
    >facilities?
    >
    >
    >
    >
    >
    >
    >Regards,
    >
    >Ioannis Vranos
    >
    >


    --
    Claudio Jolowicz

    Department of Computing
    180 Queen's Gate
    South Kensington campus
    Imperial College
    London SW7 2AZ

    31 Humbolt Road
    Fulham
    London W6 8QH

    mobile: +44(0)7963 892810
    http://www.doc.ic.ac.uk/~cj603
     
    Claudio Jolowicz, Apr 20, 2004
    #13
  14. "Claudio Jolowicz" <> wrote in message
    news:p...
    >
    > Which "basic constructs"? For what "kind of stuff"? Many network
    > protocols are written in C and could no doubt be rewritten in
    > (idiomatic) Standard C++. This is also true, and even more so, of
    > programming interfaces provided to network protocols, e.g. sockets for
    > TCP connections. Your term "exotic" does not carry any meaning in this
    > context, and you are making things worse by explaining it with another
    > vague formulation. As far as I can judge, the problems relating to
    > specifying an interface for networking functions that could be
    > implemented on a wide range of platforms are due not to the allegedly
    > restricted capabilities of the core language, but to the (lack or
    > disparity of) networking support on those platforms.



    Can you establish a TCP/IP connection using only ISO C++? No. You will have
    to use some system specific API. So if a library was provided having
    networking facilities it would not be able to be written in ISO C++ the way
    like std::basic_string can be written for example.






    Ioannis Vranos
     
    Ioannis Vranos, Apr 20, 2004
    #14
  15. Re: C++ danger to break due to its weight, fragmentation danger -C++0x

    On Wed, 21 Apr 2004, Ioannis Vranos wrote:

    >"Claudio Jolowicz" <> wrote in message
    >news:p...
    >>
    >> Which "basic constructs"? For what "kind of stuff"? Many network
    >> protocols are written in C and could no doubt be rewritten in
    >> (idiomatic) Standard C++. This is also true, and even more so, of
    >> programming interfaces provided to network protocols, e.g. sockets for
    >> TCP connections. Your term "exotic" does not carry any meaning in this
    >> context, and you are making things worse by explaining it with another
    >> vague formulation. As far as I can judge, the problems relating to
    >> specifying an interface for networking functions that could be
    >> implemented on a wide range of platforms are due not to the allegedly
    >> restricted capabilities of the core language, but to the (lack or
    >> disparity of) networking support on those platforms.

    >
    >
    >Can you establish a TCP/IP connection using only ISO C++? No. You will have
    >to use some system specific API. So if a library was provided having
    >networking facilities it would not be able to be written in ISO C++ the way
    >like std::basic_string can be written for example.


    How about std::cout? How would you implement that without using a
    "system specific API"?

    --
    Claudio Jolowicz
     
    Claudio Jolowicz, Apr 21, 2004
    #15
    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. Lloyd Sheen

    Danger Danger Will Robinson Vista SP1

    Lloyd Sheen, Mar 19, 2008, in forum: ASP .Net
    Replies:
    2
    Views:
    448
    Lloyd Sheen
    Mar 19, 2008
  2. Fresh
    Replies:
    2
    Views:
    654
    Bo Persson
    Apr 22, 2008
  3. thunk
    Replies:
    1
    Views:
    347
    thunk
    Mar 30, 2010
  4. thunk
    Replies:
    0
    Views:
    523
    thunk
    Apr 1, 2010
  5. thunk
    Replies:
    14
    Views:
    655
    thunk
    Apr 3, 2010
Loading...

Share This Page