|
Boost : |
From: Daryle Walker (darylew_at_[hidden])
Date: 2001-02-14 01:27:04
on 2/11/01 9:02 PM, Jens Maurer at Jens.Maurer_at_[hidden] wrote:
> Daryle Walker wrote:
>>
>> on 2/8/01 11:02 PM, Jens Maurer at Jens.Maurer_at_[hidden] wrote:
[SNIP iterator v. buffer/length and max stuff]
>> If I make the bit size a run-time parameter, what type is the interim CRC
>> supposed to be?
>
> std::bitset ?
Nope. Bit-sets are compile-time parameterized on the bit size. Like I
mentioned before, something like a arbitrary-precision type would be needed.
I don't think it's worth these steps to shift bit-size to run-time, users
can live with compile-time for now. (If they need performance, they would
use the all-compile-time fast version anyway.)
[SNIP minor GCC parsing problems]
>>> Also, gcc doesn't have <ostream>. Since you're already including
>>> <iostream>, you should forget about <ostream> until gcc gets fixed.
>>
>> GCC doesn't have <ostream>?! Where does it put its stream definitions?
>
> Into "ostream.h". Don't ask, grab STLport 4.0 :-)
I have one of the few platforms without GCC, so I can't check. With
problems like no <ostream> or <limits>, I could insist on users getting
STLport. :-)
>> Or stuff like "endl"? Is there a guarantee that <ostream>, for proper
>> compilers, is always #included in <iostream>?
>
> I've never seen a program fail that includes <iostream> and uses
> std::cout for output afterwards. And it's in all books I know.
I glanced a little bit at the standard. A type must be fully defined before
declaring an object of that type, so I guess that <iostream> must #include
the definition of std::ostream (and std::basic_ostream<>). This would
usually mean that it #includes <ostream>, so <iostream> would get std::endl.
I guess that, technically, an implementation could be pathological and
define std::ostream and std::basic_ostream<> in a mini-header that doesn't
include std::endl but will get #included in <iostream> (and <ostream>).
Your trick wouldn't work in that case.
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk