next ISO/ANSI standard for C++

Discussion in 'C++' started by skoco, Feb 11, 2004.

  1. skoco

    skoco Guest

    Hello!
    Do you know when will be the new standard for c++ approved? And WHAT
    will be inside? Hope there will be some thread and synchro classes,
    text and XML parsing, new containers and other new things. God save me
    from coding in boring & slow & no pointers java!!
    p.s.: how much time usually needs the compiler vendors to implement
    new standards?
    p.s.2: anybody knows which compiler supports export keyword?

    Thanks to you all.
     
    skoco, Feb 11, 2004
    #1
    1. Advertising

  2. skoco

    Sharad Kala Guest

    "skoco" <> wrote in message
    news:...
    > Hello!
    > Do you know when will be the new standard for c++ approved? And WHAT
    > will be inside? Hope there will be some thread and synchro classes,
    > text and XML parsing, new containers and other new things. God save me
    > from coding in boring & slow & no pointers java!!
    > p.s.: how much time usually needs the compiler vendors to implement
    > new standards?
    > p.s.2: anybody knows which compiler supports export keyword?


    I don't know when C++ standard is going to be revised again. But I really wish
    that things you mentioned like threads, XML parsing etc are included this time.
    Now that jdk1.5 is out and it has generics support (on template lines), C++
    should also get rich enough with other things in a standard way.
    No idea how much time our compiler vendors will take to adopt the new additions.
    May be people like Greg Comeau can comment on this :)
    Right now only Comeau has proper support for export keyword AFAIK.

    -Sharad
     
    Sharad Kala, Feb 11, 2004
    #2
    1. Advertising

  3. * Thus spoke skoco <>:

    Hallo,

    > Do you know when will be the new standard for c++ approved?


    No. My guess is that we won't be seeing it any time soon. (2006-2009)

    > And WHAT will be inside?


    <http://std.dkuug.dk/jtc1/sc22/wg21/>

    > p.s.: how much time usually needs the compiler vendors to implement
    > new standards?


    Too long. ;-)


    Wolfgang.
    --
    "I can remember the exact instant when I realized that a large part of my life
    from then on was going to be spent in finding mistakes in my own programs."
    -- Maurice Wilkes, 1947
     
    Wolfgang Kaufmann, Feb 11, 2004
    #3
  4. "Sharad Kala" <> wrote
    >
    > "skoco" <> wrote
    > > Hello!
    > > Do you know when will be the new standard for c++ approved? And WHAT
    > > will be inside? Hope there will be some thread and synchro classes,
    > > text and XML parsing, new containers and other new things. God save me
    > > from coding in boring & slow & no pointers java!!
    > > p.s.: how much time usually needs the compiler vendors to implement
    > > new standards?
    > > p.s.2: anybody knows which compiler supports export keyword?

    >
    > I don't know when C++ standard is going to be revised again. But I really wish
    > that things you mentioned like threads, XML parsing etc are included this

    time.
    > Now that jdk1.5 is out and it has generics support (on template lines), C++
    > should also get rich enough with other things in a standard way.
    > No idea how much time our compiler vendors will take to adopt the new

    additions.
    > May be people like Greg Comeau can comment on this :)
    > Right now only Comeau has proper support for export keyword AFAIK.


    I don't mean this deprecatingly, but the you both seem to be new to C++ and
    unaware of the underlying philosophy of the language. C++, like C, takes a
    minimalist approach to language features and standard libraries, which is what
    has allowed C and C++ to be so easily ported to a large number of vastly
    different platforms. Let's look at your wish list point by point:

    1) Threads - threads are a concept that doesn't exist on every platform. Many
    embedded systems don't have threads. Some older, but still supported systems,
    also don't have threads. For this reason alone, adding threads to the language
    is dangerous. But to make things worse, threads don't work the same way on all
    operating systems. Some allow different scheduling strategies, some don't. Some
    allow time slice quantization, some don't. Some allow scheduling priorities,
    some don't. Some allow signals to go to any thread, some force signals to go to
    specific threads, some have no signals at all. The Standards committee isn't
    about to jump in that tar pit when they can just waggle their finger in the
    direction of pthreads.

    2) Synchronization mechanisms - even if we ignore point 1, which would make this
    point moot, and look at the simplest of synchronization mechanisms: the mutex.
    Even lowly mutexes are different across platforms. On some platforms, mutexes
    are recursive, on others, recursive calls deadlock you. On some platforms,
    mutexes can be shared across processes, on others, you have different promitives
    to do that. And then, the poor Standards critters would have to choose what
    primitives to include. Semaphores? Condition variables? Events? Mailboxes? FIFO
    queues? Atomic integer operations? And do you emulate them on platforms that
    don't support them natively? With all respect due to the immensely competent
    people on the committee, I wouldn't trust even them to make that choice for me.

    3) XML - now this one's easy. XML is an application-specific data
    representation. That has no business being shoehorned into a language
    specification. Again, the Standards committee would correctly point you to one
    of the many existing libraries.

    This keeps coming back, but the C++ community just doesn't want a Java-like,
    bloated, jack-of-all-trades-but-master-of-none standard library.

    Claudio Puviani
     
    Claudio Puviani, Feb 11, 2004
    #4
  5. skoco

    Sharad Kala Guest


    > I don't mean this deprecatingly, but the you both seem to be new to C++ and
    > unaware of the underlying philosophy of the language. C++, like C, takes a
    > minimalist approach to language features and standard libraries, which is what
    > has allowed C and C++ to be so easily ported to a large number of vastly
    > different platforms. Let's look at your wish list point by point:


    Don't want to sound cheeky, cocky or start a flame war but seems like you think
    you are expert enough to judge other people. I personally think one should
    refrain from it unless you like to argue much.

    Most of the projects I have worked on have required XML somewhere or the other.
    You need to resort to 3rd party libraries like Xerces/MSXML etc and their
    intricacies each time you switch to a new library.
    Wouldn't be good if there was a standard way to write the code and it would have
    been portable too.

    I know writing programs involving threads in a standard way is tricky, owing to
    OS differences.
    But now that most of the major projects require threads somewhere or the other
    and then you include #ifdefs for your platform in your code because your product
    runs on various platforms. Wouldn't it be good to just provide a standard way of
    making the calls and let the compiler decide what to do under the hood?

    Though I agree with you that the minimalist approach has made C and C++ to be
    easily portable across platforms and extending the library would require more
    work to be done by our compiler vendors. I have been reading about the
    possibilities of library getting extended for quite some time and just voiced
    what I felt would make life of a developer to concentrate more on standard ways
    rather than deal with 3rd party or OS intricacies.

    -Sharad
     
    Sharad Kala, Feb 11, 2004
    #5
  6. "Sharad Kala" <> wrote...
    >
    > > I don't mean this deprecatingly, but the you both seem to be new to C++

    and
    > > unaware of the underlying philosophy of the language. C++, like C, takes

    a
    > > minimalist approach to language features and standard libraries, which

    is what
    > > has allowed C and C++ to be so easily ported to a large number of vastly
    > > different platforms. Let's look at your wish list point by point:

    >
    > Don't want to sound cheeky, cocky or start a flame war but seems like you

    think
    > you are expert enough to judge other people. I personally think one should
    > refrain from it unless you like to argue much.


    Everybody is allowed to judge other people, and one doesn't have to be
    an expert to do that (at least according to my experience). This is
    a public forum and I personally think one should refrain from telling
    others what they should refrain from (although I don't always follow
    my own advice either).

    > Most of the projects I have worked on have required XML somewhere or the

    other.

    So what? Out of twenty-plus years I've been programming, only about
    two years total I did some work involving XML. Doesn't at all speak
    to XML widespread-ness, but mostly to the length of one's career, no?

    > You need to resort to 3rd party libraries like Xerces/MSXML etc and their
    > intricacies each time you switch to a new library.
    > Wouldn't be good if there was a standard way to write the code and it

    would have
    > been portable too.


    No, it wouldn't. Just like it wouldn't to have some kind of networking
    or GUI capability.

    > I know writing programs involving threads in a standard way is tricky,

    owing to
    > OS differences.
    > But now that most of the major projects require threads somewhere


    Got any statistics about that?

    > or the other
    > and then you include #ifdefs for your platform in your code because your

    product
    > runs on various platforms. Wouldn't it be good to just provide a standard

    way of
    > making the calls and let the compiler decide what to do under the hood?


    No. The more the compiler has to decide, the less probable it is to
    have a decent compiler or a compiler that satisfies enough people for
    it to be a viable product. By the time such compiler comes out, the
    language will have died.

    >
    > Though I agree with you that the minimalist approach has made C and C++ to

    be
    > easily portable across platforms and extending the library would require

    more
    > work to be done by our compiler vendors. I have been reading about the
    > possibilities of library getting extended for quite some time and just

    voiced
    > what I felt would make life of a developer to concentrate more on standard

    ways
    > rather than deal with 3rd party or OS intricacies.


    Please voice it in comp.std.c++ and see what kind of reaction you get.

    "OS intricacies" are not going away any time soon, and are becoming more
    and more numerous every year. How do you really expect language creators
    to follow those and integrate them into the language? And (for the sake
    of argument) if the Committee does catch up with OS changes and other new
    technologies (like XML) popping up here and there, you would also need
    compiler developers to catch up, and they cannot do it without the language
    being fully defined.

    The only way to standardise C++ way of treating things like network, GUI,
    XML, threads, OS-specific stuff, etc., is to make them standard as well.
    How long will that take and how rigid will they become?

    V
     
    Victor Bazarov, Feb 11, 2004
    #6
  7. skoco

    Jason Guest

    "Sharad Kala" <> wrote in message news:c0dhv0>
    Most of the projects I have worked on have required XML somewhere or the
    other.
    > You need to resort to 3rd party libraries like Xerces/MSXML etc and their
    > intricacies each time you switch to a new library.
    > Wouldn't be good if there was a standard way to write the code and it

    would have
    > been portable too.


    There are many 3rd party libraries, or you can even write your own XML
    parser (gasp!). C++ is used because it, as a "core entity", is portable. If
    you add too many features too quickly it is hard to find conforming
    compilers. With Java this isn't the case, because Sun make Java and it's
    class libraries, and that is the end of things; there is no need for vendor
    agreement. What I am trying to say is C++ is borne out of a different
    community ethic.

    Anyway, what about ASN.1. I want ASN.1 support in C++ not pesky XML. :)

    .... these are my thoughts anyway, and of course they are not correct in any
    formal sense.
     
    Jason, Feb 11, 2004
    #7
  8. "Sharad Kala" <> wrote in message
    news:c0dhv0$15p7am$-berlin.de...
    >
    > > I don't mean this deprecatingly, but the you both seem to be new to C++

    and
    > > unaware of the underlying philosophy of the language. C++, like C,

    takes a
    > > minimalist approach to language features and standard libraries, which

    is what
    > > has allowed C and C++ to be so easily ported to a large number of

    vastly
    > > different platforms. Let's look at your wish list point by point:

    >
    > Don't want to sound cheeky, cocky or start a flame war but seems like you

    think
    > you are expert enough to judge other people. I personally think one

    should
    > refrain from it unless you like to argue much.
    >
    > Most of the projects I have worked on have required XML somewhere or the

    other.

    Your experience is not necessarilly representative for the rest of the
    world. The majority of projects I have done many projects that didn't
    involve XML. What people use most is highly dependant on the kind of
    projects they do and what kind of business they are in.

    > You need to resort to 3rd party libraries like Xerces/MSXML etc and their
    > intricacies each time you switch to a new library.


    I would not like to see standard C++ become as bloated as Java. I would
    like to see (interface) standardization for libraries in some areas, but
    not as part of the C++ standard.

    > Wouldn't be good if there was a standard way to write the code and it

    would have
    > been portable too.


    The way I see it is best to keep the core of C++ lean and mean. The more
    features that are added to core definition the less portable the language
    becomes, simply because some features are not available on every
    conceivable platform. For areas that tend to be domain specific I prefer to
    see separate standards, rather than a single standard that covers
    everything-but-the-kitchen-sink.

    > I know writing programs involving threads in a standard way is tricky,

    owing to
    > OS differences.
    > But now that most of the major projects require threads somewhere or the

    other
    > and then you include #ifdefs for your platform in your code because your

    product
    > runs on various platforms. Wouldn't it be good to just provide a standard

    way of
    > making the calls and let the compiler decide what to do under the hood?


    Yes, but what if the compiler cannot make that decision? How to overcome
    conceptual differences? Often the differences are more than just different
    names for functions that do the same thing. Just letting the compiler deal
    with it (emulating things in case of semantic differences) would lead to
    suboptimal results, less programmer control and more likely to lead to
    unexpected behaviour.

    Don't get me wrong, I would like to see standardization in this area. I
    write software that has to run on multiple platforms, and I know that it is
    a real pain to get software to do compile and do the right thing on all
    platforms. But the problems described above are based on experiences with
    libraries that hide platform differences (with varing success).

    > Though I agree with you that the minimalist approach has made C and C++

    to be
    > easily portable across platforms and extending the library would require

    more
    > work to be done by our compiler vendors. I have been reading about the
    > possibilities of library getting extended for quite some time and just

    voiced
    > what I felt would make life of a developer to concentrate more on

    standard ways
    > rather than deal with 3rd party or OS intricacies.


    Maybe you feel more comfortable with Java (not flame, just a suggestion).

    --
    Peter van Merkerk
    peter.van.merkerk(at)dse.nl
     
    Peter van Merkerk, Feb 11, 2004
    #8
  9. skoco

    Sharad Kala Guest

    "Victor Bazarov" <> wrote in message
    news:xtsWb.7733$uV3.18367@attbi_s51...
    > "Sharad Kala" <> wrote...
    > >
    > > > I don't mean this deprecatingly, but the you both seem to be new to C++

    > and
    > > > unaware of the underlying philosophy of the language. C++, like C, takes

    > a
    > > > minimalist approach to language features and standard libraries, which

    > is what
    > > > has allowed C and C++ to be so easily ported to a large number of vastly
    > > > different platforms. Let's look at your wish list point by point:

    > >
    > > Don't want to sound cheeky, cocky or start a flame war but seems like you

    > think
    > > you are expert enough to judge other people. I personally think one should
    > > refrain from it unless you like to argue much.

    >
    > Everybody is allowed to judge other people, and one doesn't have to be
    > an expert to do that (at least according to my experience). This is
    > a public forum and I personally think one should refrain from telling
    > others what they should refrain from (although I don't always follow
    > my own advice either).


    I never asked anyone not to refrain. I cannot stop anyone as you correctly
    pointed out it's a public forum.
    I just said that "I personally think...". I just told that one should be careful
    enough while making statements
    if one wants to have healthy discussions rather than ego-clashes.


    > > Most of the projects I have worked on have required XML somewhere or the

    > other.
    >
    > So what? Out of twenty-plus years I've been programming, only about
    > two years total I did some work involving XML. Doesn't at all speak
    > to XML widespread-ness, but mostly to the length of one's career, no?


    XML has become popular only in recent years.
    I may be near about your half age and cannot claim to say that this has been in
    use for 20 yrs. But in the recent times XML has become an important form of data
    exchange. There are even industry-wide protocols that are entirely XML based.
    Atleast it has so happened that I have had to deal with XML in all my projects.

    > > You need to resort to 3rd party libraries like Xerces/MSXML etc and their
    > > intricacies each time you switch to a new library.
    > > Wouldn't be good if there was a standard way to write the code and it

    > would have
    > > been portable too.

    >
    > No, it wouldn't. Just like it wouldn't to have some kind of networking
    > or GUI capability.


    Getting offtopic..Just the other day I helped someone with Xerces because it has
    peculiarity with treating whitespaces as text nodes.
    There is a transcode API that allocates memory and expects user to free it.
    Point is there are so many intracacies in handling with these
    3rd party libraries.

    > > I know writing programs involving threads in a standard way is tricky,

    > owing to
    > > OS differences.
    > > But now that most of the major projects require threads somewhere

    >
    > Got any statistics about that?

    Nope.

    > > or the other
    > > and then you include #ifdefs for your platform in your code because your

    > product
    > > runs on various platforms. Wouldn't it be good to just provide a standard

    > way of
    > > making the calls and let the compiler decide what to do under the hood?

    >
    > No. The more the compiler has to decide, the less probable it is to
    > have a decent compiler or a compiler that satisfies enough people for
    > it to be a viable product. By the time such compiler comes out, the
    > language will have died.


    Agreed. As I said earlier too that writing thread code in a standard way would
    be tricky. Thread started with what *would* be good to have in a standard
    library.
    But I do agree that it's a lot of work for compiler vendors.Don't think though
    it's the case with XML though.

    > > Though I agree with you that the minimalist approach has made C and C++ to

    > be
    > > easily portable across platforms and extending the library would require

    > more
    > > work to be done by our compiler vendors. I have been reading about the
    > > possibilities of library getting extended for quite some time and just

    > voiced
    > > what I felt would make life of a developer to concentrate more on standard

    > ways
    > > rather than deal with 3rd party or OS intricacies.

    >
    > Please voice it in comp.std.c++ and see what kind of reaction you get.
    >
    > "OS intricacies" are not going away any time soon, and are becoming more
    > and more numerous every year. How do you really expect language creators
    > to follow those and integrate them into the language? And (for the sake
    > of argument) if the Committee does catch up with OS changes and other new
    > technologies (like XML) popping up here and there, you would also need
    > compiler developers to catch up, and they cannot do it without the language
    > being fully defined.
    >
    > The only way to standardise C++ way of treating things like network, GUI,
    > XML, threads, OS-specific stuff, etc., is to make them standard as well.
    > How long will that take and how rigid will they become?


    I see your point and do agree to many extents with even what Claudio has to say.
    Let me clearify here. I just meant it would have been good had there been
    standard ways
    to do things. Never meaning that it *should* be the case or that there are no
    issues with extending the library.
     
    Sharad Kala, Feb 11, 2004
    #9
  10. skoco

    Sharad Kala Guest

    "Peter van Merkerk" <> wrote in message
    news:c0dll9$15pv8g$-berlin.de...
    > "Sharad Kala" <> wrote in message
    > news:c0dhv0$15p7am$-berlin.de...
    > >
    > > > I don't mean this deprecatingly, but the you both seem to be new to C++

    > and
    > > > unaware of the underlying philosophy of the language. C++, like C,

    > takes a
    > > > minimalist approach to language features and standard libraries, which

    > is what
    > > > has allowed C and C++ to be so easily ported to a large number of

    > vastly
    > > > different platforms. Let's look at your wish list point by point:

    > >
    > > Don't want to sound cheeky, cocky or start a flame war but seems like you

    > think
    > > you are expert enough to judge other people. I personally think one

    > should
    > > refrain from it unless you like to argue much.
    > >
    > > Most of the projects I have worked on have required XML somewhere or the

    > other.
    >
    > Your experience is not necessarilly representative for the rest of the
    > world. The majority of projects I have done many projects that didn't
    > involve XML. What people use most is highly dependant on the kind of
    > projects they do and what kind of business they are in.


    True..I can only voice my opinions.

    > > You need to resort to 3rd party libraries like Xerces/MSXML etc and their
    > > intricacies each time you switch to a new library.

    >
    > I would not like to see standard C++ become as bloated as Java. I would
    > like to see (interface) standardization for libraries in some areas, but
    > not as part of the C++ standard.


    Yes, there needs to be some kind of standardization if not in standard then with
    3rd library interfaces.

    > > Wouldn't be good if there was a standard way to write the code and it

    > would have
    > > been portable too.

    >
    > The way I see it is best to keep the core of C++ lean and mean. The more
    > features that are added to core definition the less portable the language
    > becomes, simply because some features are not available on every
    > conceivable platform. For areas that tend to be domain specific I prefer to
    > see separate standards, rather than a single standard that covers
    > everything-but-the-kitchen-sink.


    > > I know writing programs involving threads in a standard way is tricky,

    > owing to
    > > OS differences.
    > > But now that most of the major projects require threads somewhere or the

    > other
    > > and then you include #ifdefs for your platform in your code because your

    > product
    > > runs on various platforms. Wouldn't it be good to just provide a standard

    > way of
    > > making the calls and let the compiler decide what to do under the hood?

    >
    > Yes, but what if the compiler cannot make that decision? How to overcome
    > conceptual differences? Often the differences are more than just different
    > names for functions that do the same thing. Just letting the compiler deal
    > with it (emulating things in case of semantic differences) would lead to
    > suboptimal results, less programmer control and more likely to lead to
    > unexpected behaviour.
    >
    > Don't get me wrong, I would like to see standardization in this area. I
    > write software that has to run on multiple platforms, and I know that it is
    > a real pain to get software to do compile and do the right thing on all
    > platforms. But the problems described above are based on experiences with
    > libraries that hide platform differences (with varing success).



    >
    > Maybe you feel more comfortable with Java (not flame, just a suggestion).


    Not actually. C++ has been my 1st love as far as PLs go :)

    I am aware with the issues in having a standard with everything.
    When I replied to the OP I just supported the *wish* to point out the numerous
    differences one has
    to deal with different OS/libraries. I know that it isn't actually actually
    feasible to have a standard for everything
    unless one is ready to compromise with efficiency and performance.
     
    Sharad Kala, Feb 11, 2004
    #10
  11. skoco

    tom_usenet Guest

    On Wed, 11 Feb 2004 21:07:44 +0530, "Sharad Kala"
    <> wrote:

    >
    >> I don't mean this deprecatingly, but the you both seem to be new to C++ and
    >> unaware of the underlying philosophy of the language. C++, like C, takes a
    >> minimalist approach to language features and standard libraries, which is what
    >> has allowed C and C++ to be so easily ported to a large number of vastly
    >> different platforms. Let's look at your wish list point by point:

    >
    >Don't want to sound cheeky, cocky or start a flame war but seems like you think
    >you are expert enough to judge other people. I personally think one should
    >refrain from it unless you like to argue much.
    >
    >Most of the projects I have worked on have required XML somewhere or the other.
    >You need to resort to 3rd party libraries like Xerces/MSXML etc and their
    >intricacies each time you switch to a new library.
    >Wouldn't be good if there was a standard way to write the code and it would have
    >been portable too.


    Indeed, but the place for such standardization isn't the C++ standard,
    which is already getting too big and complex.

    >I know writing programs involving threads in a standard way is tricky, owing to
    >OS differences.
    >But now that most of the major projects require threads somewhere or the other
    >and then you include #ifdefs for your platform in your code because your product
    >runs on various platforms. Wouldn't it be good to just provide a standard way of
    >making the calls and let the compiler decide what to do under the hood?


    Indeed - pthreads already exists, and a C++ interface would be a good
    thing for standardization. I'm not at all convinced that the C++
    standard is the place for that though.

    >Though I agree with you that the minimalist approach has made C and C++ to be
    >easily portable across platforms and extending the library would require more
    >work to be done by our compiler vendors. I have been reading about the
    >possibilities of library getting extended for quite some time and just voiced
    >what I felt would make life of a developer to concentrate more on standard ways
    >rather than deal with 3rd party or OS intricacies.


    Standardization good; enormous, monolithic, hard-to-reach-consensus-on
    C++ standard bad.

    Tom

    C++ FAQ: http://www.parashift.com/c -faq-lite/
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
     
    tom_usenet, Feb 11, 2004
    #11
  12. skoco

    Mike Smith Guest

    Sharad Kala wrote:
    >
    > Most of the projects I have worked on have required XML somewhere or the other.


    That's nice. I've been doing C and C++ development for 13 years and
    I've never used XML on any professional project I've worked on. (I've
    been playing with it on my own time recently.)

    > You need to resort to 3rd party libraries like Xerces/MSXML etc and their
    > intricacies each time you switch to a new library.


    If you want a standard - pick one library and stick to it.

    > I know writing programs involving threads in a standard way is tricky, owing to
    > OS differences.
    > But now that most of the major projects require threads somewhere or the other


    There are many platforms that do not support threads at all. They're in
    your car, your coffee maker, the thermostat in your house, etc.
    "Desktop" type applications are only piece of the picture. There's a
    whole embedded world out there that doesn't know from threads.

    --
    Mike Smith
     
    Mike Smith, Feb 11, 2004
    #12
  13. skoco

    Mike Smith Guest

    Sharad Kala wrote:

    > I never asked anyone not to refrain. I cannot stop anyone as you correctly
    > pointed out it's a public forum.
    > I just said that "I personally think...". I just told that one should be careful
    > enough while making statements
    > if one wants to have healthy discussions rather than ego-clashes.


    Or maybe you could just grow a thicket skin, and not let yourself be led
    around by your ego. <shrug>

    > XML has become popular only in recent years.
    > I may be near about your half age and cannot claim to say that this has been in
    > use for 20 yrs. But in the recent times XML has become an important form of data
    > exchange. There are even industry-wide protocols that are entirely XML based.
    > Atleast it has so happened that I have had to deal with XML in all my projects.


    Fine. That's you. It's not true for everyone. Not everyone is even in
    agreement that XML is such a great thing. There are some valid
    arguments that XML is fundamentally broken, and that it doesn't live up
    to its promises. If I had a nickel for every time I've heard someone
    say they've come up with a brilliant idea for a data representation that
    will solve all the problems of past representations... well, I'm sure
    I'd have at least a buck or two.

    --
    Mike Smith
     
    Mike Smith, Feb 11, 2004
    #13
  14. skoco

    Attila Feher Guest

    Sharad Kala wrote:
    >> I don't mean this deprecatingly, but the you both seem to be new to
    >> C++ and unaware of the underlying philosophy of the language. C++,
    >> like C, takes a minimalist approach to language features and
    >> standard libraries, which is what has allowed C and C++ to be so
    >> easily ported to a large number of vastly different platforms. Let's
    >> look at your wish list point by point:

    >
    > Don't want to sound cheeky, cocky or start a flame war but seems like
    > you think you are expert enough to judge other people. I personally
    > think one should refrain from it unless you like to argue much.


    It is not a question of being an expert or not. I happen to sit at the
    committee meetings (I say at and not in/on because I am an observer only) so
    I can tell you: It seems so that it is not going to happen that you get XML
    support into ISO C++ itself. However, since XML *is* a standard and C++ has
    a standard there is no problem in creating a sort of binding. But - I am
    afraid - that first such library has to be made, I do not think that an XML
    library entirely designed by a committee would make you any happier than the
    existing ones. :)

    > Most of the projects I have worked on have required XML somewhere or
    > the other. You need to resort to 3rd party libraries like
    > Xerces/MSXML etc and their intricacies each time you switch to a new
    > library.
    > Wouldn't be good if there was a standard way to write the code and it
    > would have been portable too.


    Then again, if you so much want XML support into C++ and work out one! The
    point is, what some people cannot always get, that C++ is standardized in
    these committee meetings. It is not a visionary shop as such. While with
    C++ it has some of the latter, it is still a place where users of the
    language and vendors of the language related tools gather together to
    standardize existing practice. So if you want an XML library, you will need
    to propose one.

    > I know writing programs involving threads in a standard way is
    > tricky, owing to OS differences.


    Yeah. You know where is it the most trickier? On those OSes/platforms,
    where there is no threading and it does not make sense either.

    > But now that most of the major projects require threads somewhere or
    > the other and then you include #ifdefs for your platform in your code
    > because your product runs on various platforms.


    We make a quite large threaded application. Handling video calls and other
    kind of magic. You cannot find *one* ifdef in the code due to threading.

    > Wouldn't it be good
    > to just provide a standard way of making the calls and let the
    > compiler decide what to do under the hood?


    It is called POSIX threads.

    > Though I agree with you that the minimalist approach has made C and
    > C++ to be easily portable across platforms and extending the library
    > would require more work to be done by our compiler vendors. I have
    > been reading about the possibilities of library getting extended for
    > quite some time and just voiced what I felt would make life of a
    > developer to concentrate more on standard ways rather than deal with
    > 3rd party or OS intricacies.


    While these might be all well true and frustrating for you, none of the
    above matters in my work. This is no attack. :) Simply you have to
    understand that the standardization process is not a restaurant, where you
    order, and the waiter brings you a standard XML library, or C++ threading.
    So if you need these, you need to either make proposals yourself (preferably
    with a working, existing practice behind) or start kicking your
    compiler/library vendors to come up with one and standardize it.

    And I have to agree with Claudio, that you have a rather naive view of this
    process. Which I had as well, before people put me to my place. :) You
    seem to think that there is the committee, all mighty, and what he says
    shall happen, and him and only him governs the future of C++ and what the
    vendors will actually implement. It is quite the other way around. The
    committee is mainly made from those guyss writing compilers. So they decide
    what will be made. And they decide based on both technical data and
    customer demand. So you need to demand XML and threading from the guys
    providing you with the C++ compiler and library. Or come up with a
    solution. I guess the former is easier. :)

    --
    Attila aka WW
     
    Attila Feher, Feb 12, 2004
    #14
  15. skoco

    Attila Feher Guest

    tom_usenet wrote:
    [SNIP]
    > Standardization good; enormous, monolithic, hard-to-reach-consensus-on
    > C++ standard bad.


    And The Committee said, "Let there be thread support!"; and there was thread
    support. And The Committee saw that the thread support was good; by 5 voting
    strongly in favour, 4 weakly in favour, 2 weakly against and one strongly
    against. ;-)

    --
    Attila aka WW
     
    Attila Feher, Feb 12, 2004
    #15
  16. skoco

    Chris Theis Guest

    "Sharad Kala" <> wrote in message
    news:c0dn1j$15vdhm$-berlin.de...
    >

    [SNIP]
    > I am aware with the issues in having a standard with everything.
    > When I replied to the OP I just supported the *wish* to point out the

    numerous
    > differences one has
    > to deal with different OS/libraries. I know that it isn't actually

    actually
    > feasible to have a standard for everything
    > unless one is ready to compromise with efficiency and performance.
    >


    IMHO one has to keep in mind that the C++ standard deals with language
    specific issues, whereas 3rd party libraries are solution oriented. Thus,
    standardization of the language should not be intermixed with incorporating
    APIs or libraries that are meant to facilitate the developer's life (be it
    XML, or any kind of GUI, or any file format). This of course doesn't mean
    that standardization is not of concern for these "helpers", but it must be
    done seperately. Otherwise, one day we will end up with a standard (probably
    requiring a whole library) which covers everything and can be used for
    nothing.

    Cheers
    Chris
     
    Chris Theis, Feb 12, 2004
    #16
  17. skoco

    Attila Feher Guest

    Chris Theis wrote:
    > "Sharad Kala" <> wrote in message
    > news:c0dn1j$15vdhm$-berlin.de...
    >>

    > [SNIP]
    >> I am aware with the issues in having a standard with everything.
    >> When I replied to the OP I just supported the *wish* to point out
    >> the numerous differences one has
    >> to deal with different OS/libraries. I know that it isn't actually
    >> actually feasible to have a standard for everything
    >> unless one is ready to compromise with efficiency and performance.
    >>

    >
    > IMHO one has to keep in mind that the C++ standard deals with language
    > specific issues, whereas 3rd party libraries are solution oriented.
    > Thus, standardization of the language should not be intermixed with
    > incorporating APIs or libraries that are meant to facilitate the
    > developer's life (be it XML, or any kind of GUI, or any file format).
    > This of course doesn't mean that standardization is not of concern
    > for these "helpers", but it must be done seperately. Otherwise, one
    > day we will end up with a standard (probably requiring a whole
    > library) which covers everything and can be used for nothing.


    Actually I was thinking a bit (did not get far with it) if it would make
    *some* sense at least (enough to think more about) to make a study, helping
    library implementors to make good libraries. Something along the lines of
    the C++ Performance TR. Of course, this could only cover some guidelines
    and such...

    Another possible thing is to create official ways of creating bindings (for
    sort of optional things). I mean the official kind of part of it. To
    ensure that bindings will not just go against the original language, I mean
    that WG21/J16 will have ways to contribute/audit/comment...

    Along the same lines a technical report could be done on acceptable binding
    techniques...

    If those has been done already, we would have less hassle now with the
    C++/CLI binding. I guess.

    --
    Attila aka WW
     
    Attila Feher, Feb 13, 2004
    #17
  18. skoco

    Sharad Kala Guest

    > And I have to agree with Claudio, that you have a rather naive view of this
    > process. Which I had as well, before people put me to my place. :) You
    > seem to think that there is the committee, all mighty, and what he says
    > shall happen, and him and only him governs the future of C++ and what the
    > vendors will actually implement. It is quite the other way around. The
    > committee is mainly made from those guyss writing compilers. So they decide
    > what will be made. And they decide based on both technical data and
    > customer demand. So you need to demand XML and threading from the guys
    > providing you with the C++ compiler and library. Or come up with a
    > solution. I guess the former is easier. :)


    Thanks Attila for giving that insight into how the C++ committee works.
    Yes, I do agree with you that given the facts you presented it's not right
    to think about standradizations for these *helper* classes in the standard.

    Personally I do not credit/value myself at all for knowing things like MFC,
    Xerces,
    MSXML, Winsocks etc (I don't mention pthreads here ;-)) Because I know these
    would have
    little value if my project demanded me to use some other 3rd party/OS and I
    would need
    to re-learn everything again. But I guess it is the case with most of us. What
    is _always_ going
    to help me is some of the good literature by Meyers, Sutter, Alexandrescu,
    Josuttis, GoF etc.
    People agree that C++ standard is getting large and complex. So can't there be
    a way to keep things
    simple somewhere ( i mean these helper classes)? I don't mean that it's very
    tough to handle them but
    let there be some convergence somewhere. Let people focus more on the *core*
    language rather than
    some unique peculiarity/intricacy which doesn't actually value much in the long
    run.
    Ofcourse this is my personal opinion ;-)
    Even if there were some implementation standardization across these helper
    classes, who is going to mandate them?

    I agree with you that may be I don't understand the issues with standardization
    quite well
    I can relate to your points and really like the way you have put them across.
    But sorry to say but I think that may be some of us don't actually phrase
    ourself quite good here.

    Best regards,
    Sharad
     
    Sharad Kala, Feb 13, 2004
    #18
  19. Although I generally support the attitude of a minimalistic but unbound
    language (which can doom a language to die with the techniques integrated)
    There should be extensions to the standard library (_not_ the language
    itself!) for these purposes (threads, XML). The argument that some
    plattforms doesn't have threads and thread support is not so a strong point
    since C++ supports floating points despite of the fact that there are still
    machines without floating-point support out there. The impact of such
    extensions is still "experiable" when you use Trolltech's Qt library
    (www.trolltech.com). Some people state that they couldn't imagine C++
    without Qt no longer. And Qt promises to provide the support you need for
    real cross-plattform programming with C++ power. If you look at the thread
    classes in Qt you see that it wouldn't provide full support for all
    features you have on different plattforms - but finally you can write
    threaded programs cross-plattform with a unified interface thus starting to
    use threads! IMHO that's the point - nothing else.
     
    Ruediger Knoerig, Feb 13, 2004
    #19
  20. Did you have had a look at Trolltech's Qt?
    www.trolltech.com
    It may became a nearly-by-standard since it's very intuitive.
     
    Ruediger Knoerig, Feb 13, 2004
    #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. Chris Mantoulidis

    ISO/ANSI C++ Standard copy

    Chris Mantoulidis, Dec 11, 2003, in forum: C++
    Replies:
    3
    Views:
    2,813
    Andrew Koenig
    Dec 13, 2003
  2. Stephen Tyndall
    Replies:
    5
    Views:
    491
  3. Replies:
    2
    Views:
    609
    Ioannis Vranos
    Dec 18, 2004
  4. Nitin Bhardwaj

    Why didn't ANSI/ISO make alloca() standard?

    Nitin Bhardwaj, Jul 15, 2004, in forum: C Programming
    Replies:
    6
    Views:
    515
    Keith Thompson
    Jul 17, 2004
  5. Deniz Bahar
    Replies:
    2
    Views:
    512
    Andrey Tarasevich
    Mar 9, 2005
Loading...

Share This Page