Output integers formatted like +0012345

[Öö Tiib]

Le 30/11/10 17:47, James Kanze a écrit :




Look at this C++ solution:
ostream& operator<<(ostream &os, tstClass &t1)
{
   char sign = (t1.i<0)?'-':'+';
   int ii = (t1.i<0)?-(t1.i)t1.i);
   os << "Integer in " << tstClass::width << " width and Sign is: {" <<
sign << setw(tstClass::width) << setfill('0') << ii << "}" << endl;
   return(os);

}

You see the bug in it?

It is "pot and kettle" thing. Both iostream and printf are not overly
handy tools, one is complicated other is unsafe. Fortunately there are
several type- and buffer-safe printf-like things available but none of
them is in the language.

 

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <[email protected]> spake the secret code

Can you name a desktop or server OS that isn't written in C?

Most microcomputers had their original "DOS" written in assembly, if
they had DOS. If they didn't have DOS, the primitive command shell
was written in assembly. For instance, the Apple ][ monitor was
written in assembly and the ROM containing integer BASIC was written
in assembly.

IIRC, BeOS was written in C++, but its not clear from the wikipedia page.
The API was definately C++ and not C, so its reasonable to assume that
the implementation is C++ and not C. The open source successor to
BeOS, Haiku, is written in C++.
<http://en.wikipedia.org/wiki/Haiku_(operating_system)>

I think parts of the original MacOS (i.e. "System", "Finder", etc.)
may have been written in Pascal as MPW provided a Pascal compiler. I
think it provided a Pascal compiler before it provided a C compiler.
ISTR that if you wanted to program for the first Mac, it was basically
Pascal using MPW or use some other non-Apple sanctioned tool chain.

FORTH turnkey systems generally replace the OS entirely with code written
in FORTH.

Oberon is written in Oberon.
<http://en.wikipedia.org/wiki/Oberon_(operating_system)>

The Lilith workstation's operating system was written entirely in
Modula-2. <http://en.wikipedia.org/wiki/Lilith_(computer)>

Burroughs mainframes were programmed either in assembly or Algol.
<http://en.wikipedia.org/wiki/Burroughs_large_systems>

Granted, most of these examples are somewhat historical, although FORTH
is still used for many turnkey/embedded systems.

However, its important to remember that "OS" is not a synonym for LMW*
platforms. (*Linux, MacOS, Windows) Still, it should be mentioned
that many components that ship as part of Windows are written in C++
and expose themselves as COM objects. One can debate whether or not
these are part of the "OS", however.

 

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <[email protected]> spake the secret code

Can you name a desktop or server OS that isn't written in C?

Also: VMS/OpenVMS: "The first version of VMS was written in Maco and
the rest in Bliss."
<http://h71000.www7.hp.com/openvms/20th/vmsbook.pdf>

 

[Ian Collins]

It is "pot and kettle" thing. Both iostream and printf are not overly
handy tools, one is complicated other is unsafe. Fortunately there are
several type- and buffer-safe printf-like things available but none of
them is in the language.

iostreams, partly due to their complexity are extremely flexible. The
separation of formatting layer (the stream) from the transport
(streambuf) provides us with a very flexible tool. We don't have to
create different function for writing to strings or files and we can
specialise streambufs for any transport we care to use.

For simple, fixed width formatting, sprintf is hard to beat.

 

[Richard]

[Please do not mail me a copy of your followup]

Ian Collins <[email protected]> spake the secret code

For simple, fixed width formatting, sprintf is hard to beat.

Boost.Format beats it. It has the type safety of iostreams and the
format string friendliness of printf.

 

[James Kanze]

Ian Collins <[email protected]> spake the secret code
<[email protected]> thusly:

Boost.Format beats it. It has the type safety of iostreams and the
format string friendliness of printf.

It also supports manipulators and positional parameters, which
makes it almost usable in production code. (In practice, no
solution I've seen can handle the grammatical variation you find
in real languages, so if you want to do multilingual output
correctly, you end up having to write a dll for each language,
programmed by a native speaker with the grammatical
idiosyncrecies of that language. And finding native speakers
with adequate C++ knowledge isn't always simple.)