>>>>> Pascual Juan <pascual@gonzo.tid.es> writes:

> I just wanna know which are THE libraries the committee are working on!!!!

Apart from iostreams:

string
wstring (string of wchar_t)
bits<T> (fixed sequence of bits)
bitstring
dynarray<T>
ptrdynarray<T>
float_complex
double_complex
long_double_complex

Jason

In article <belanger-160294163225@131.195.96.61>, belanger@sgi_dev04.cdst.hydro.qc.ca (Jean-Pierre Belanger) writes:
|> In article <1994Feb14.082706.11293@tid.es>, pascual@gonzo.tid.es (Pascual
|> Juan) wrote:
|>
|> > I agree with you, but: Where can I "look to _standard_ libraries" proposed
|> > or acepted by the commitee? ...
|>
|> It will wait until a commercial product become a "de facto" standard.
|>
|> So, I think that what we are looking for now is a good library of classes
|> that work on multiple platforms.

Why not try the Common Objects Library from ATT?

It is available on most (?all) platforms that support cfront,
and I think it is usually distributed is *source* form, so it should
be fairly easily prted to other platforms.

It is a (comparatively) simple library that still provides all of the
basic container classes.  It may not be as 'sophisticated' as some
class libraries, but I find it easier to understand and use than the
more complex libraries.

It's implementation emphasized efficiency, but has sill managed to
provide ample flexibility.

--
swf@elsegundoca.ncr.com  sarima@netcom.com

The peace of God be with you.

A few days ago I started this discussion:

|> In article <1994Feb14.082706.11293@tid.es>, pascual@gonzo.tid.es (Pascual
|> Juan) wrote:
|>
|> > I agree with you, but: Where can I "look to _standard_ libraries" proposed
|> > or acepted by the commitee? ...
|>

And a lot of people wrote me to use USL library, NIH library, etc... until
a commercial product become a "de facto" standard. As old Tannenbaun said:
 "Standards are a good thing... you got hundreds to choose!!"
I just wanna know which are THE libraries the committee are working on!!!!
Since I knew there was going to be ANSI strings, I stopped adding new
features to mines and started to wait THE standard ones.

Please help me, I don't want to reinvent the wheel.
--
-------------------------------------------------------------------------------
 ||||  ##     ####                    |         Pascual Juan         |    _V_
 ||||  ## _|_ ## ##   Telefonica I+D  | E-mail: pascual@gonzo.tid.es |  _(,|,)`
 @@@@  ##  |  ## ##  (Telefonica R&D) |    Phone: +34-1-314-47-04    | | ___ ')
 @@@@  ##     ####                    |    fax:   +34-1-337-42-22    | |_|`__/
-------------------------------------------------------------------------------

In article <27705@alice.att.com>, bs@alice.att.com (Bjarne Stroustrup) writes:
|>
|> In general, I encourage people to look to libraries rather than language
|> extensions. More often than not there seem to be a choice.
|>
|>  - Bjarne

I agree with you, but: Where can I "look to _standard_ libraries" proposed
or acepted by the commitee? I don't want the implementation neither the
exact headers. I just want a list of the libraries with a little description
of one line, a sort of "man -k". I do really trust in the comitee (I'm a
liar) and if they are working in a standard string or a math library, I will
wait until the fall to hang on it, but I just want to know what I am waiting.
--
                              _V_
                            _(,|,)`   _
                           | ___ ')  _))
                           |_|`__/___//
                              /    --'  _,
                             /------) q(_)
----------------------------( /--( /----^--------------------------------------
    __     _            |    / ) / )          Pascual Juan
   /  )/| ( ) /, | /    |   (_/ (_/   E-mail: pascual@gonzo.tid.es
  /__//_|  \ /<  |/     |
 /   /  |(_//  ) /      |                Phone: +34-1-337-47-04
                        |                fax:   +34-1-337-42-22
-------------------------------------------------------------------------------

In article <27705@alice.att.com>, bs@alice.att.com (Bjarne Stroustrup) writes:
PJ>|>
PJ>|> In general, I encourage people to look to libraries rather than language
PJ>|> extensions. More often than not there seem to be a choice.
PJ>|>
PJ>|>      - Bjarne

Exactly!  Could we (we're not worthy, we're not worthy:-) poor
programmers, who just want to use the C++ language as it is
described in the ARM, count on you to use your influence with the
committee to persuade them to quit persuing every little language
extension proposal that comes up, long enough so that we may see
a standard in our lifetime?

I have found nothing in the ARM that, in any way hampers my ability
to use this language to produce good working programs. If the
committee wants to extend the language, they can re-convene _after_
a standard is produced.  This seemed to work well for the COBOL
committees.  Cobol programmers got the extensions that they wanted
about every four years.
regards,
chris
C++ isn't broken, and doesn't need to be fixed.
---
. OLX 2.2 . recursive (r.-k.r-s.v) adj.  See "recursive."

----
/-------------------------------------------------------------\
| Faster-Than-Light (FTL) Atlanta GA   Public access numbers: |
|  404-292-8761 / 404-296-3120 / 404-299-3930 / 404-292-0236  |
\-------------------------------------------------------------/

> In general, I encourage people to look to libraries rather than language
> extensions. More often than not there seem to be a choice.
>
>  - Bjarne
>

I join to opinion that better way is *standart* library extention.
But as for me I know only iostream.h , complex.h, task.h. Where are other
ones? Basic data structure, interface with operating system( As for me I
have to do my own libraries on very pure standart provision).

I think that future of C++ is in library support and development enviroment.
Smalltalk guys already have this one. I don't like Smalltalk, but right now,
IMHO, it is more creatfull enviroment. It should be as soon as it is possible
for us too!

Andrew Smirnoff,
JINR,
Russia.

In article <1994Feb14.082706.11293@tid.es>, pascual@gonzo.tid.es (Pascual
Juan) wrote:

> I agree with you, but: Where can I "look to _standard_ libraries" proposed
> or acepted by the commitee? I don't want the implementation neither the
> exact headers. I just want a list of the libraries with a little description
> of one line, a sort of "man -k". I do really trust in the comitee (I'm a
> liar) and if they are working in a standard string or a math library, I will
> wait until the fall to hang on it, but I just want to know what I am waiting.
> --

I fully agree with you, the "reusability" of code won't be fully possible
if the commitee doesn't define a standard.

As far as I know, the commitee only want to define the basic parts of C++.
It
will wait until a commercial product become a "de facto" standard.

(I hope I will see that someday...)

So, I think that what we are looking for now is a good library of classes
that work on multiple platforms.

JPI,

--
Jean-Pierre Belanger
Hydro-Quebec
5100 Sherbrooke east, 7th floor
Montreal, PQ, Canada H1V 3R9
tel : 514-251-3086 fax: 514-251-3110

chris.smith@ftl.atl.ga.us (Chris Smith @ Faster-Than-Light (FTL), Atlanta Georgia USA) writes

 > In article <27705@alice.att.com>, bs@alice.att.com (Bjarne Stroustrup) writes:
 > PJ>|>
 > PJ>|> In general, I encourage people to look to libraries rather than language
 > PJ>|> extensions. More often than not there seem to be a choice.
 > PJ>|>
 > PJ>|>      - Bjarne
 >
 > Exactly!  Could we (we're not worthy, we're not worthy:-) poor
 > programmers, who just want to use the C++ language as it is
 > described in the ARM, count on you to use your influence with the
 > committee to persuade them to quit persuing every little language
 > extension proposal that comes up, long enough so that we may see
 > a standard in our lifetime?

The committee never ``persued every little language extension proposal.''
We had to react to proposals made, but few were accepted. I don't have
a rigorous measure of complexity, but I'm sure that the complexity of the
sum of all extensions beyond templates and exceptions is only about the
same as the complexity of either templates or exceptions.

I expect to see a draft standard this fall. I expect the standard with
its Ts crossed and Is dotted by ANSI and ISO to look very much like
that draft.

 ...

 > C++ isn't broken, and doesn't need to be fixed.

Thanks

 - Bjarne