>>    The expansive monolithic approach to C++ library standardization
 >> resembles more the philosophies of Ada or Java.

This has been my observation, too. I'd like to see:

     .STL removed from the core C++ specification
     .core C++ language cleaned up and made simpler
     .only worry about C compatibility in terms of linking to precompiled C
libs

In addition, I'd like to see standard libraries for:

     .64-bit file management
     .virtual memory and memory mapping
     .sockets
     .heaps
     .threads

BUT: i don't want to see these libraries included in the C++ standard.
Instead, I'd prefer to see them in sperarate standards, example: POSIX.

I have a feeling my wishes are not going to come true, though!

--nate





      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3d36ef11$0$29462$4c41069e@reader1.ash.ops.us.uu.net>, Nate
Hayes <nhayes@cyberoptics.com> writes
>     .only worry about C compatibility in terms of linking to
>precompiled C libs

Which is primarily an ABI problem and C cannot even guarantee that a C
program can link to precompiled C libraries.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

    comp.std.c++: This thread is joined in progress from
comp.lang.c++.moderated.  See comp.lang.c++.moderated for prior postings
regarding this thread with this title.  This posting is self-contained
enough to not absolutely require any of those prior postings.

Nick Thurn wrote:

 > "Daniel T." <notdanielt3@gte.net> wrote in message
 > news:notdanielt3-7A9594.13580809072002@news.bellatlantic.net...
 >
 >>Adding new libraries to the language is easy, venders do it all the
 >>time. We don't need a standards committee for that. What the committee
 >>should be concentrating on IMO is cleaning up the language, removing as
 >>many of the special cases as possible.
 >>
 >>
 > Wholeheartedly agree!
 >
 > We have way too many halfbaked solutions included in the standard.
 > - templatized iostreams
 > - locales
 > - valarray etc
 > - export
 > - typeinfo
 > - and gasp stl <algorithm>!
 >
 > Like half baked legislation that has unforseen consequences (eg
 > home carers hit with fringe benefits tax bills), the tweaks to enable
 > the above had no practical experience. The solutions themselves
 > only reached concensus in the (albeit learned) circle of the committee.
 > We are now living with the on-the-fly design decisions and added
 > complexity in the language.
 >
 > The bottom line is that 10 years after we should have had a standard
 > we are only just seeing the first fully compliant parser and experience
 > is showing that things that appeared useful at the time are not widely
 > used (or by implication - actually useful!)
 >
 > The overhead of simply using C++ gets in the way of using it
 > to do real work. The removal of as much of this overhead as possible
 > should be the core task of the next standardisation effort.
 >
 > I see no reason for the std C++ library to become even bigger.


    I agree with this library-related statement if we are discussing
post-C++98 expansion of the monolithic one-size-fits-all library in
C++98's ISO/IEC 14882:1998.  I disagree if this implies no more
standardization of any libraries by any standards body on the planet.

 > It would be preferable to split out the library as a separate set
 > of standards with a tiny core collapsed into the language itself
 > (ie string, vector/array) ah but it's too late for sanity ;-(.


    Amen.  I wholeheartedly agree.  This one-size-fits-all approach leads
to the following downsides:

    . "lowest common denominator" (a.k.a., the mediocrity imposed by
strict set intersection) approaches to portability.  This ignores
portability within large subcommunities, such as a POSIX.C++ language
binding which would be a far more expressive library than one which must
also handle radically-nonPOSIX or intentionally-nonPOSIX operating systems.

    . libraries designed to be "for those means which give the greatest
good to the greatest number" (a.k.a., compromising consensus based on
popularity in general-purpose software) instead of libraries designed to
solve a particular topic in the best way.  This ignores standardizing
libraries tailored for real-time embedded systems instead of
general-purpose software.  This tends to make a monolithic
one-size-fits-all library the only standardized choice in the spectrum
from massively-parallel scientific computation through realtime embedded
systems through high-availability severs through commodity computers at
the appliance store through mainframes for business systems.

    . libraries which at best push toward standardizing some new cool
cutting edge academic research instead of endorsing multi-decade-honored
existing techniques or at worst are naive start-from-scratch greenfield
toy-subsets of what a mature treatment of the topic would have contained.

    . libraries which push a subcommunity's agenda of contorting one or
more language features to push deeply into drastically new territory for
which those language features (and thus the design of compilers) were
never intended.  I am professionally appalled at the trend of pushing
templates/parameterized-types too far, such as considering C++ templates
to be a pure functional language which permits considering the compiler
(at compile-time) to be a (quasi-)general-purpose compute-engine as a
clever way to pull off incredibly complex trickery/hacking.  (I am
personally intellectually curious at the what-if level about such
push-the-envelope metaprogramming & reflection topics, but there is a
big difference between a pure-researcher's cool new
intellectually-stimulating toy indicating what a state-of-the-art
computer language in the year 2015 might look like versus a technique
which should be brought & taught to the masses nowadays.)

    Instead of a one-size-fits-all monolithic approach to C++0x's
libraries, I concur with Nick Thurn that the libraries should be kicked
out of ISO/IEC 14882 itself and placed in other standards (promulgated
by ISO/IEC and/or IEEE and/or so forth) which can separately evolve with
different standards working-groups which are each comprised of advocates
for each topic.  It is quite likely that experts aggressively
researching functional-language template metaprogramming & reflection
would have far less expertise in realtime embedded systems, and vice
versa.  Since C++ is a multiparadigm language supporting POP, OOP, GP,
etc applied to different problem domains, I could imagine a standards
working-group for realtime libraries which gingerly uses OOP & GP versus
a completely different standards working-group for wild
push-the-envelope metaprogramming/reflection versus a standards
working-group which emphasized pure OO (with lots of virtual
member-functions).  Then like the langauge itself, C++ libraries would
permit multiple paradigms by not imposing a single monolithic ISO
14882-dictated library paradigm on to every problem domain.

    The standardized C++ language itself is intentionally multiparadigm.
   The standardized C++ libraries should likewise be capable of
expressing multiple paradigms instead of the single paradigm which we
see in C++98.  Personally I happen to like much of that single paradigm
which I currently see in C++98, but I am extremely concerned with
forward-looking trends of what that monolithism would probably look like
in a C++0x.

    POP = procedure-oriented programming
    GP = generic programming (with parameterized types)
    _ARM_ = _Annotated C++ Reference Manual_ by Ellis & Stroustrup, 1990


 > The philosophy of C++ was violated by the standard.


    The expansive monolithic approach to C++ library standardization
resembles more the philosophies of Ada or Java.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]