Nathan Myers wrote:
> The rule is very, very simple: if you want formatting or parsing, use
> operator << or >> (corresponding to printf and scanf in the C
> library).
> If you want fast, simple character operations, use streambuf members
> sputc and sgetc (corresponding to getc and putc in the C library).
> Is that so hard?
>
> It is a real disgrace that so many texts fail to teach the appropriate
> use of streambuf operations.  When even professionals cannot remember
> this very simple distinction outlined above (or remain so terrified of
> streambufs as to ignore it) it inclines me toward despair.

Well, yes, on the one hand, I am a software engineering
professional.  But on the other hand, I'm new to iostreams (I've
gotten along just fine for the last few years using only <stdio.h>).
Given their complexity, it will take me a while to get used to
them and their own peculiar "look and feel".  It will also take
me a while to get a working grasp of the STL, which is far larger
and more complex.

And I know I'm not alone in this regard; most of us, I suspect,
will be learning a lot in the next two years, while the compiler
vendors catch up to the new std.

-- David R. Tribble, dtribble@technologist.com --


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote in article
<35D37F5A.53D1@noSPAM.central.beasys.com>...
>     cout << 'a';    // iostream
>
>     putchar('a');   // stdio
>
> And:
>     cin >> ch;      // iostream
>
>     ch = getchar(); // stdio
>
> Theoretically (and hopefully), these should all run at about the
> same speed.  More complicated I/O operation tests can then proceed
> from these "minimal" starting points.

there is a real danger in creating de facto standard ways of mesauring
speed---implementors will optimise their implementations to run them fast,
at the expense of more normal programming patterns.

stuart



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,

David R Tribble <david.tribble@noSPAM.central.beasys.com> wrote in article
<35D37F5A.53D1@noSPAM.central.beasys.com>...
>     cout << 'a';    // iostream
>
>     putchar('a');   // stdio
>
> And:
>     cin >> ch;      // iostream
>
>     ch = getchar(); // stdio
>
> Theoretically (and hopefully), these should all run at about the
> same speed.  More complicated I/O operation tests can then proceed
> from these "minimal" starting points.

Note, that it is more important in C++ that the following is efficient:

  ostreambuf_iterator<charT, traits> oit(sbuf);
  *oit = ch;
  ++oit

  istreambuf_iterator<charT, traits> iit(sbuf);
  ch = *iit;
  ++iit;

These operations are used in the heart of the extractors and inserters (ie. in
the 'do_put()' and 'do_get()' members of the 'num_put' and 'num_get' facets).
Using 'out << ch' is much slower than the above because it create a
'ostream::sentry' object which in turn may do some locking and additional
processing. Correspondingly for 'in >> ch'.

If you need to process lots of characters, you should almost certainly use the
corresponding streambuf iterator.
--
<mailto:dietmar.kuehl@claas-solutions.de>
homepage: <http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:
>> Immature implementations of iostreams are uniformly slower than
>> mature implementations of stdio.  (This is no surprise.)  However,
>> there is no inherent reason for iostreams to be slower; a good
>> implementation should be at least as fast, and maybe faster.

Alwyn Thomas wrote:
> I have no problem with this in theory. But, given the fact that
> compiler- and library implementors are having such a hard time
> catching up with the standard, I suspect we will have to wait some
> while before we have really fast iostreams.

I wonder if the iostream inserter/extracter functions inherently
require more function calls than the equivalent stdio functions?
This might lead to slower iostream operations than the equivalent
stdio calls.

OTOH, printf() must interpret the formatting specifiers in the
controlling format string, which might lead to slower stdio
operations than the equivalent inserter functions, assuming that
the inserters don't do much "interpreting".

Perhaps a simple "minimal" test could be done by comparing the
execution times of these sets of statements:

    cout << 'a';    // iostream

    putchar('a');   // stdio

And:
    cin >> ch;      // iostream

    ch = getchar(); // stdio

Theoretically (and hopefully), these should all run at about the
same speed.  More complicated I/O operation tests can then proceed
from these "minimal" starting points.

-- David R. Tribble, dtribble@technologist.com --


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <dtribble@technologist.com> wrote:
>Perhaps a simple "minimal" test could be done by comparing the
>execution times of these sets of statements:
>    cout << 'a';    // iostream
>    putchar('a');   // stdio
>And:
>    cin >> ch;      // iostream
>    ch = getchar(); // stdio
>Theoretically (and hopefully), these should all run at about the
>same speed.  More complicated I/O operation tests can then proceed
>from these "minimal" starting points.

Foul!  This is comparing apples and alveoli.

I would be very surprised if the relative speed of the suggested
operations _ever_ approached within an order of magnitude on any
implementation.  The following may be considered comparable to the
suggestion above, but biased the opposite way:

  scanf("%c", &ch);            // slow
  ch = cin.rdbuf()->sgetc();   // fast

If you were interested in reading a character efficiently, you
wouldn't use scanf or op>>.  (Let me repeat that: if you were
interested in reading a character efficiently, you wouldn't use
op>>.)  Any comparison of "formatted" operations on one system
(e.g. scanf) will always suffer grievously compared to raw character
operations (e.g.  streambuf::sgetc) on the other system.

Perhaps

  fscanf(stdin, "%d", &i) == 1;
  cin >> i;

(where i is an int) is a fairer comparison, since both operations
are "formatted".  For manipulating individual characters efficiently,
the corresponding operations are:

  ch = getc(stdin);
  ch = cin.rdbuf()->sgetc();

Of course these can only be meaninfully measured in a loop, and
the use of rdbuf() belongs outside the loop.

The rule is very, very simple: if you want formatting or parsing, use
operator << or >> (corresponding to printf and scanf in the C library).
If you want fast, simple character operations, use streambuf members
sputc and sgetc (corresponding to getc and putc in the C library).
Is that so hard?

It is a real disgrace that so many texts fail to teach the appropriate
use of streambuf operations.  When even professionals cannot remember
this very simple distinction outlined above (or remain so terrified of
streambufs as to ignore it) it inclines me toward despair.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:

>     cout << 'a';    // iostream
>
>     putchar('a');   // stdio
>
> And:
>     cin >> ch;      // iostream
>
>     ch = getchar(); // stdio

But those aren't equivalent.  The statements
  cout << 'a';
and
  cin >> 'c';
are formatted I/O.  They skip whitespace, pad output to the requested
width, and so on.  They are really quite complicated!

The C++ equivalent of putchar() is streambuf::sputc().


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alwyn Thomas <alwyn@dircon.co.uk> wrote:
>Nathan Myers wrote:
>
>> Immature implementations of iostreams are uniformly slower than mature
>> implementations of stdio.  (This is no surprise.)  However, there is no
>> inherent reason for iostreams to be slower; a good implementation should
>> be at least as fast, and maybe faster.
>
>I have no problem with this in theory. But, given the fact that
>compiler- and library implementors are having such a hard time catching
>up with the standard, I suspect we will have to wait some while before
>we have really fast iostreams.

I don't understand the expression "catching up with the standard".
The standard isn't moving.  Yes, the standard is new, and it takes
time to implement it, and more time to implement it well.  If you
want it sooner, implement it.  There are free implementation efforts
going on that would welcome help.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35C791B2.6D1E@noSPAM.central.beasys.com>,
  dtribble@technologist.com wrote:

> I am curious how fast the iostream functions are compared to the
> stdio functions.  I haven't seen any comparisons.

I've seen a number, with differing results.  Very implementation
dependant.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:

> I don't understand the expression "catching up with the standard".
> The standard isn't moving.

Well, did I say it was moving? Perhaps this discussion should move to
alt.usage.english.

The well known truth is, of course, that the draft standard was moving for
years, forwards, backwards and sideways (think of the notorious auto_ptr, for
example), while publically available compilers lagged a long way behind. Even
now that the standard has ground to a halt, the poor vendors have a long
distance to make up.

>  Yes, the standard is new, and it takes
> time to implement it, and more time to implement it well.  If you
> want it sooner, implement it.  There are free implementation efforts
> going on that would welcome help.

Indeed. If I were a gentleman of leisure, I would be the first to volunteer.


Alwyn




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
In article <35C8C576.A9719AC0@dircon.co.uk>,
  alwyn@dircon.co.uk wrote:
> Now here's a theme for this newsgroup: standard functions and
> classes are by necessity stronger on generality than on processor-efficiency
> or compactness.

C++ templates can help a lot to maintain both generality and efficiency.
Using specializations, functions can be tuned to particular needs. Other
techniques to supply efficient versions of functions use some scheme to
select functions at link time, depending on what functionality is actually
used by a program (for example, the IOStream inserters and extractors can be
more efficient if locales are not used).

Library implementation always has to trade generality for efficiency. On the
other hand, implementing a library implies that someone focusses on a very
special part of a program which is normally of minor concern to others. Thus,
it can mean more efficient implementations in the general case. If there are
special needs (eg. parsing millions of numbers all formatted the same), this
issue can be a major concern and a specialized function is probably
appropriate.

The intent of a standard library is not to supply the most efficient
implementation for all situations but rather an efficient implementation for
the normal case. The standard library should provide a ready to use
implementation of typical services needed by many programs. This
implementation is often more efficient than ad hoc approaches (but there is
actually no requirement for this). --
<mailto:dietmar.kuehl@claas-solutions.de> homepage:
<http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35C8C576.A9719AC0@dircon.co.uk>,
  alwyn@dircon.co.uk wrote:
> David R Tribble wrote:
>
> > Alwyn Thomas wrote:
> > > Well, I certainly don't have it on my Sun, and I wouldn't expect it
> > > either on any SVR4 system.  Why should anyone need itoa() if they
> > > already have the standard C function sprintf()?
> >
> > Speed, perhaps?  While I agree that sprintf() gives you all the
> > functionality that itoa() does, it is slower (since it must
> > interpret the "%d" formatting string before it reads any input
> > characters).  This might make a difference if you're reading
> > millions of numbers.  (But that's an argument for rolling your own
> > itoa(), not for adding it to the ISO standard.)
>
> Yes indeed! Now here's a theme for this newsgroup: standard functions and
> classes are by necessity stronger on generality than on processor-efficiency
> or compactness.

I couldn't disagree more.

It may be true that the *specification* for "standard functions and
classes are by necessity more focused on generality than on
processor-efficiency or compactness." However, as a general rule
(with I'm sure many exceptions), the *implementation* for these
functions and classes is free to take advantage of local
optimization techniques which would be impractical to write in
portable code.

For example, it's easy to write strcpy() in a totally portable
manner, but on most systems the library version is much more efficient
(meaning that it's faster, or smaller, or both). Despite this, it must
have exactly the semantics spelled out in the standard. This makes
usage of that function both efficient and portable, an otherwise rare
combination.

> > > C++ users are, of course, spoilt for choice, since they have the
> > > ostrstream (and in the future also maybe the easier-to-use
> > > ostringstream) class as well for formatting.
> >
> > I am curious how fast the iostream functions are compared to the
> > stdio functions.  I haven't seen any comparisons.
>
> It depends inevitably on the implementation. I once did a test of my own
> using Metrowerks CodeWarrior on the Apple Power Macintosh and found that a
> program using iostream operators took about three times as long to print
> numbers on the console as one with the equivalent functions from stdio; the
> stdio program was also much smaller.

I wouldn't assume that this is true on every platform. I also wouldn't
assume that it's true for every version of the compiler you use. By
definition, this is a Quality of Implementation issue. In general, on
most platforms, quality is ever-increasing.

You may want to consider re-running that test if it wasn't recent.

> However, that does not stop me from using iostreams wherever possible.

Then although "about three times as long" was a source of concern, you
didn't consider it unacceptable. This is a tradeoff: do you go with
the platform-specific techniques, to improve the program's run-time
efficiency at the cost of development cycle? Or do you go with the
general techniques, to keep development costs down? This is an especially
important tradeoff when developing portable code, since the first version
may mean rewriting sections of code for every system (and probably means
code littered with #ifdef's).

Neither alternative is always better for every program.

> Alwyn

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Alwyn Thomas <alwyn@dircon.co.uk> wrote:
>> I am curious how fast the iostream functions are compared to the
>> stdio functions.  I haven't seen any comparisons.
>
>It depends inevitably on the implementation. I once did a test of my own
>using Metrowerks CodeWarrior on the Apple Power Macintosh and found that a
>program using iostream operators took about three times as long to print
>numbers on the console as one with the equivalent functions from stdio; the
>stdio program was also much smaller.

Immature implementations of iostreams are uniformly slower than mature
implementations of stdio.  (This is no surprise.)  However, there is no
inherent reason for iostreams to be slower; a good implementation should
be at least as fast, and maybe faster.

Reports of slow iostreams aren't news.  Reports of fast iostreams,
though, will be very interesting reading, and I look forward to
such reports.  Eventually fast iostreams will be the norm, and then
slow ones will be worth reporting.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:

> Immature implementations of iostreams are uniformly slower than mature
> implementations of stdio.  (This is no surprise.)  However, there is no
> inherent reason for iostreams to be slower; a good implementation should
> be at least as fast, and maybe faster.

I have no problem with this in theory. But, given the fact that compiler- and
library implementors are having such a hard time catching up with the standard,
I suspect we will have to wait some while before we have really fast iostreams.


Alwyn



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
...
> My question was about the wording in the C++ standard which urged
> C++ compiler vendors to "consider" adopting changes to referenced
> standards. It looks as if you're both saying that despite this
> wording, any new features should *not* automatically be made part of
> the C++ language.
>
> Which is exactly what I hoped everyone would say. The stationary
> target is already tough enough to hit!

My personal take on the matter is that any new features borrowed from
developements in C have the same status as language extensions. That
wording merely serves to encourage implementors to choose their
extensions based upon compatibility with developments in C. Any stronger
wording would have required closer coordination with the C9X standard
than has actually been possible. They're still working on their
standard.


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35C6E86E.44131ECE@pia.bt.co.uk>,
  Alwyn Thomas <alwyn@pia.bt.co.uk> wrote:
> AllanW@my-dejanews.com wrote:
>
> > > BTW, itoa is *not* part of Standard C.
> >
> > You're right, of course, but it should be. Further, I treat it *as if*
> > it was part of the standard library; I'm prepared to write it manually,
> > if I ever port it to an environment where that isn't available, but so
> > far I've been lucky, I guess.
>
> Well, I certainly don;'t have it on my Sun, and I wouldn't expect it
> either on any SVR4 system.

You may use this. (It also demonstrates how I use local optimizations
without requiring them on every platform I port to.)

    // impl.h
    #ifdef _MSC_VER
      #include <stdlib.h> // _itoa()
      #ifdef __STDC__
        // itoa() isn't included with /Za, but _itoa() is
        inline char*itoa(int num,char*buff,int base)
          { return _itoa(num,buff,base); }
      #endif
    #elif __BORLAND__ // I don't remember their real preprocessor symbol
      // ... similar concepts
    #else // Unknown compiler, use no local optimizations
      #define IMPL_NEED_ITOA
      char*itoa(int number,char*buff,int base); // Defined in impl.cpp
    #endif

    // impl.cpp
    #include "impl.h"
    #ifdef IMPL_NEED_ITOA
    char*itoa(int number, char*buffer, int base) {
        if (base<2 || base>36) {
            assert(false);
            return 0;
        }
        char *retval = buffer;
        if (number<0) {
            *(buffer++) = '-';
            number = -number;
        }
        unsigned int num = unsigned int(number);
        char temp[65];    // Assumes 64 bits or less per int
        temp[0] = num%base;
        int size = 1;
        while (num /= base) temp[size++] = num%base;
        char digit[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";
        while (size--) *(buffer++) = digit[temp[size]];
        *buffer = '\0';
        return retval;
    }
    #endif // IMPL_NEED_ITOA

> Why should anyone need itoa() if they
> already have the standard C function sprintf()?

itoa() may be a lot more lean than sprintf(), including all the
library functions it could pull in with it on certain platforms.
Further, in some libraries, itoa() may be able to take advantage of
local (non-portable) techniques. For instance, a CPU with a
machine instruction to convert binary to BCD might be able to
translate binary to base-10 printable much more quickly than the
routine listed above, which is written to be maximally portable.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>> BTW, itoa is *not* part of Standard C.

AllanW@my-dejanews.com wrote:
>> You're right, of course, but it should be. Further, I treat it *as
>> if* it was part of the standard library; I'm prepared to write it
>> manually, if I ever port it to an environment where that isn't
>> available, but so far I've been lucky, I guess.

Alwyn Thomas wrote:
> Well, I certainly don't have it on my Sun, and I wouldn't expect it
> either on any SVR4 system.  Why should anyone need itoa() if they
> already have the standard C function sprintf()?

Speed, perhaps?  While I agree that sprintf() gives you all the
functionality that itoa() does, it is slower (since it must
interpret the "%d" formatting string before it reads any input
characters).  This might make a difference if you're reading
millions of numbers.  (But that's an argument for rolling your own
itoa(), not for adding it to the ISO standard.)

> C++ users are, of course, spoilt for choice, since they have the
> ostrstream (and in the future also maybe the easier-to-use
> ostringstream) class as well for formatting.

I am curious how fast the iostream functions are compared to the
stdio functions.  I haven't seen any comparisons.

-- David R. Tribble, dtribble@technologist.com --


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:

> Alwyn Thomas wrote:
> > Well, I certainly don't have it on my Sun, and I wouldn't expect it
> > either on any SVR4 system.  Why should anyone need itoa() if they
> > already have the standard C function sprintf()?
>
> Speed, perhaps?  While I agree that sprintf() gives you all the
> functionality that itoa() does, it is slower (since it must
> interpret the "%d" formatting string before it reads any input
> characters).  This might make a difference if you're reading
> millions of numbers.  (But that's an argument for rolling your own
> itoa(), not for adding it to the ISO standard.)

Yes indeed! Now here's a theme for this newsgroup: standard functions and
classes are by necessity stronger on generality than on processor-efficiency
or compactness.

> > C++ users are, of course, spoilt for choice, since they have the
> > ostrstream (and in the future also maybe the easier-to-use
> > ostringstream) class as well for formatting.
>
> I am curious how fast the iostream functions are compared to the
> stdio functions.  I haven't seen any comparisons.

It depends inevitably on the implementation. I once did a test of my own
using Metrowerks CodeWarrior on the Apple Power Macintosh and found that a
program using iostream operators took about three times as long to print
numbers on the console as one with the equivalent functions from stdio; the
stdio program was also much smaller.

However, that does not stop me from using iostreams wherever possible.


Alwyn



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:

> > BTW, itoa is *not* part of Standard C.
>
> You're right, of course, but it should be. Further, I treat it *as if*
> it was part of the standard library; I'm prepared to write it manually,
> if I ever port it to an environment where that isn't available, but so
> far I've been lucky, I guess.

Well, I certainly don;'t have it on my Sun, and I wouldn't expect it
either on any SVR4 system.  Why should anyone need itoa() if they
already have the standard C function sprintf()?

C++ users are, of course, spoilt for choice, since they have the
ostrstream (and in the future also maybe the easier-to-use
ostringstream) class as well for formatting.


Alwyn
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <35C572D8.49048148@physik.tu-muenchen.de>,
  Christopher Eltschka <celtschk@physik.tu-muenchen.de> wrote:
> Jerry Coffin wrote:
[snip]
> > > Suppose that the next C standard requires a new function:
> > >     int exception(const char*);
[snip]
> > They have a couple of possibilities: first, they could include the
> > function, but not declare it in any of the standard C++ headers.
[snip]
> I'd prefer a namespace like std::extensions or std::C9x or the like.
> >  Still another possibility would be
[snip]
> A similar problem holds for new C keywords like restrict: A C++
> compiler that doesn't compile
> int main() {
>   int restrict=0;
>   return restrict;
> }
> would not be conforming.

[snip]

I realize that a C++ vendor can provide any feature from C, or for
that matter any feature from assembly language, COBOL, or even from
a drug-induced dream, etc., so long as they either don't affect any
conforming C++ programs or there is a way to turn it off (and thus
compile those affected conforming C++ programs anyway).

My question was about the wording in the C++ standard which urged
C++ compiler vendors to "consider" adopting changes to referenced
standards. It looks as if you're both saying that despite this
wording, any new features should *not* automatically be made part of
the C++ language.

Which is exactly what I hoped everyone would say. The stationary
target is already tough enough to hit!

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6polpe$eoe$1@nnrp1.dejanews.com>, AllanW@my-dejanews.com
says...

[ ... ]

>   At
>   the time of publication, the editions indicated were valid.  All stan-
>   dards are subject to revision, and parties to agreements based on this
>   International  Standard  are encouraged to investigate the possibility
>   of applying the most recent editions of the standards indicated below.

[ ... ]

> My interpretation of "encouraged to investigate the possibility of
> apploying" is that such changes do NOT automatically propogate to C++,

That's correct.

> although the vendors are urged to add them as local extensions. Does
> that sound right to you?

Yes.  Of course, most C++ compilers ship along with C compilers, and
with or without urging from the C++ committee, this would probably
happen in most cases anyway.

> Suppose that the next C standard requires a new function:
>     int exception(const char*);
> If a C++ implementation included this in :: or in std::, it could
> cause ambiguity errors. But if a C++ implementation didn't include
> it, then it would not achieve maximum portability of C programs. I
> suppose there are ways to achieve both goals, with compier switches
> for instance. But which one is *required* by the C++ standard --
> should they adopt the new function, as "urged," or leave it alone,
> as implied by the words "investigate the possibility?"

They have a couple of possibilities: first, they could include the
function, but not declare it in any of the standard C++ headers.  If
it was required to be declared in a header defined in both C and C++,
they could skip over the declaration of __cplusplus was defined.
Another possibility would be to define the function in some other name
space in C++, though of course the name of the namespace would have to
be one they could legally define, such as __stdc.  Still another
possibility would be to start with a function named something like
"__exception" and after the declaration add something like:

#if defined(_Extensions) || !defined(__cplusplus)
#define exception __exception
#endif

so if you were compiling C, or had vendor extensions turned on, you'd
get the C name for the function, but if you were doing strict C++
without extensions, you'd only get a name in the implementor's name
space, which won't collide with a name you should be using.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Jerry Coffin wrote:

[...]

> > Suppose that the next C standard requires a new function:
> >     int exception(const char*);
> > If a C++ implementation included this in :: or in std::, it could
> > cause ambiguity errors. But if a C++ implementation didn't include
> > it, then it would not achieve maximum portability of C programs. I
> > suppose there are ways to achieve both goals, with compier switches
> > for instance. But which one is *required* by the C++ standard --
> > should they adopt the new function, as "urged," or leave it alone,
> > as implied by the words "investigate the possibility?"
>
> They have a couple of possibilities: first, they could include the
> function, but not declare it in any of the standard C++ headers.  If
> it was required to be declared in a header defined in both C and C++,
> they could skip over the declaration of __cplusplus was defined.
> Another possibility would be to define the function in some other name
> space in C++, though of course the name of the namespace would have to
> be one they could legally define, such as __stdc.

I'd prefer a namespace like std::extensions or std::C9x or the like.

>  Still another
> possibility would be to start with a function named something like
> "__exception" and after the declaration add something like:
>
> #if defined(_Extensions) || !defined(__cplusplus)
> #define exception __exception
> #endif
>
> so if you were compiling C, or had vendor extensions turned on, you'd
> get the C name for the function, but if you were doing strict C++
> without extensions, you'd only get a name in the implementor's name
> space, which won't collide with a name you should be using.

A more complicated case would be if a new C standard demanded a
function named delete (say, a new char* handling function, which
allows to delete arbitrary characters). Since delete is a reserved
keyword in C++, using namespaces would not help. However, __delete
would still be allowed (as would be _delete, sine in global scope
- and of course in namespace std - all names with one underscore
are reserved as well).

A similar problem holds for new C keywords like restrict: A C++
compiler that doesn't compile

int main()
{
  int restrict=0;
  return restrict;
}

would not be conforming. Therefore, just taking the C keyword
restrict into C++ would not result in a conforming implementation.
In this case, introducing __restrict or similar would be the only
possible option (_restrict would not be possible, since it's not
reserved in every scope).
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <01bdba30$635d5720$8a1ec2d0@porky>,
  "P.J. Plauger" <pjp@dinkumware.com> wrote:
> If you want a complete *reference* (as opposed to a tutorial) on the Standard
> C++ library, see http://www.dinkumware.com/htm_cpl/index.html. You can
> now order a copy that matches the FDIS. It includes full descriptions of the
> Standard C library, including the required Amendment 1 additions and those
> mandated by the C++ Standard.

Yes, I've had this bookmarked for some time.  Thanks to you and to
DinkumWare for making it publicly available.

> BTW, itoa is *not* part of Standard C.

You're right, of course, but it should be. Further, I treat it *as if*
it was part of the standard library; I'm prepared to write it manually,
if I ever port it to an environment where that isn't available, but so
far I've been lucky, I guess.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6photo$1ej$1@nnrp1.dejanews.com>,
  Dietmar_Kuehl@my-dejanews.com wrote:
> > > The problem is: There is no book describing the whole standard C++
library!
> > >
> > > The good news is this: There is at least one book covering the whole
> > > standard
> > > C++ library (including previously undocumented classes like 'valarray' and
> > > 'locale') relatively close to completion. It will probably called "The C++
> > > Standard Library" by Nicolai Josuttis and be published by Addison-Wesley.

In article <6pir6i$ho4$1@nnrp1.dejanews.com>, I wrote:
> > Will this include things that are part of Standard C++ by reference,
> > without details? Such as details about scanf() and itoa()?

Dietmar_Kuehl:
> No. The functions, data types and macros inherited from C are not covered. The
> standard C library, actually the whole standard C, is covered in the book
> "Standard C", P.J.Plauger and J.Brodie, Prentice Hall.
>
> BTW, I haven't found a reference to 'itoa()' in the working paper I have
> available here and it is also quite unlikely that this function is referenced
> from the standard: It is not a standard C function and only standard C
> functions are referenced from the ISO C++ document.

Oopsie.

That's a function that I treat *as if* it was standard, because it's
implemented on so many compilers (and because if I come across one
where it isn't implemented, it's easy for me to craft it manually).
Whatever header file it's declared in is only #included by my
system-dependant header file.

BTW, I came across this in CD2:

  1.2  Normative references                                 [intro.refs]
1 The following standards contain provisions which, through reference in
  this text, constitute provisions of this International  Standard.   At
  the time of publication, the editions indicated were valid.  All stan-
  dards are subject to revision, and parties to agreements based on this
  International  Standard  are encouraged to investigate the possibility
  of applying the most recent editions of the standards indicated below.
  Members  of IEC and ISO maintain registers of currently valid Interna-
  tional Standards.
  --ISO/IEC 2382 Dictionary for Information Processing Systems.
  --ISO/IEC 9899:1990 Programming Languages - C
  --ISO/IEC:1990 Programming Languages - C AMENDMENT 1: C Integrity

My interpretation of "encouraged to investigate the possibility of
apploying" is that such changes do NOT automatically propogate to C++,
although the vendors are urged to add them as local extensions. Does
that sound right to you?

Suppose that the next C standard requires a new function:
    int exception(const char*);
If a C++ implementation included this in :: or in std::, it could
cause ambiguity errors. But if a C++ implementation didn't include
it, then it would not achieve maximum portability of C programs. I
suppose there are ways to achieve both goals, with compier switches
for instance. But which one is *required* by the C++ standard --
should they adopt the new function, as "urged," or leave it alone,
as implied by the words "investigate the possibility?"

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hey--

Sorry to bother the newsgroup with this question but which C++ book best
covers the standard library (including the Standard Template Library)?
We were only just introduced to the standard library (by a teacher who
doesn't know much) in school and by accident I discovered that on the
#include's, one drops the '.h' from things like iostream and string.
So I am looking for resources to assist me in learning the standard
library.

Thanks in advance for your assistance!
Earl Commander
http://www.pcisys.net/~astronerdboy/comics/comics.html



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
In article <35BB5AB3.8B2BAEBC@NO-SPAM-PLEASE.pcisys.net>,
  AstroNerdBoy <astronerdboy@NO-SPAM-PLEASE.pcisys.net> wrote:
> Sorry to bother the newsgroup with this question but which C++ book best
> covers the standard library (including the Standard Template Library)?

The problem is: There is no book describing the whole standard C++ library!
At least, I haven't heard from one. There are books covering STL (there are
*LOTS* of them), there are books covering the IOStream library (but these are
often not up to date). That's the bad news.

The good news is this: There is at least one book covering the whole standard
C++ library (including previously undocumented classes like 'valarray' and
'locale') relatively close to completion. It will probably called "The C++
Standard Library" by Nicolai Josuttis and be published by Addison-Wesley. The
plan is to publish this book in this year (I don't know of the exact
publishing date). If you can read German, you may get the German version
called "Die C++ Standardbibliothek" (same author, same publisher). However,
the German version is not as complete as the English one... --
<mailto:dietmar.kuehl@claas-solutions.de> homepage:
<http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi,
In article <6pir6i$ho4$1@nnrp1.dejanews.com>,
  AllanW@my-dejanews.com wrote:
> In article <6photo$1ej$1@nnrp1.dejanews.com>,
>   Dietmar_Kuehl@my-dejanews.com wrote:
> > The problem is: There is no book describing the whole standard C++ library!
> >
> > The good news is this: There is at least one book covering the whole
> > standard
> > C++ library (including previously undocumented classes like 'valarray' and
> > 'locale') relatively close to completion. It will probably called "The C++
> > Standard Library" by Nicolai Josuttis and be published by Addison-Wesley.

> Will this include things that are part of Standard C++ by reference,
> without details? Such as details about scanf() and itoa()?

No. The functions, data types and macros inherited from C are not covered. The
standard C library, actually the whole standard C, is covered in the book
"Standard C", P.J.Plauger and J.Brodie, Prentice Hall.

BTW, I haven't found a reference to 'itoa()' in the working paper I have
available here and it is also quite unlikely that this function is referenced
from the standard: It is not a standard C function and only standard C
functions are referenced from the ISO C++ document. --
<mailto:dietmar.kuehl@claas-solutions.de> homepage:
<http://www.informatik.uni-konstanz.de/~kuehl>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote in article <6pir6i$ho4$1@nnrp1.dejanews.com>...
> In article <6photo$1ej$1@nnrp1.dejanews.com>,
>   Dietmar_Kuehl@my-dejanews.com wrote:
> > The problem is: There is no book describing the whole standard C++ library!
> >
> > The good news is this: There is at least one book covering the whole standard
> > C++ library (including previously undocumented classes like 'valarray' and
> > 'locale') relatively close to completion. It will probably called "The C++
> > Standard Library" by Nicolai Josuttis and be published by Addison-Wesley. The
>
> Will this include things that are part of Standard C++ by reference,
> without details? Such as details about scanf() and itoa()?

If you want a complete *reference* (as opposed to a tutorial) on the Standard
C++ library, see http://www.dinkumware.com/htm_cpl/index.html. You can
now order a copy that matches the FDIS. It includes full descriptions of the
Standard C library, including the required Amendment 1 additions and those
mandated by the C++ Standard.

BTW, itoa is *not* part of Standard C.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> Sorry to bother the newsgroup with this question but which C++ book best
> covers the standard library (including the Standard Template Library)?
> We were only just introduced to the standard library (by a teacher who
> doesn't know much) in school and by accident I discovered that on the
> #include's, one drops the '.h' from things like iostream and string.
> So I am looking for resources to assist me in learning the standard
> library.

Try http://www.dinkumware.com/htm_cpl/index.html

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <6photo$1ej$1@nnrp1.dejanews.com>,
  Dietmar_Kuehl@my-dejanews.com wrote:
> The problem is: There is no book describing the whole standard C++ library!
>
> The good news is this: There is at least one book covering the whole standard
> C++ library (including previously undocumented classes like 'valarray' and
> 'locale') relatively close to completion. It will probably called "The C++
> Standard Library" by Nicolai Josuttis and be published by Addison-Wesley. The

Will this include things that are part of Standard C++ by reference,
without details? Such as details about scanf() and itoa()?

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]