Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-05-24 16:16:28


on 5/23/01 10:31 PM, Hubert HOLIN at Hubert.Holin_at_[hidden] wrote:

> Paris (U.E.), le 24/05/2001
>
> --- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
>
> [SNIP]
>
>> The reason is given in the error messages, I'm trying to use a class that
>> only has its name identified, and I need the full definition. The <iosfwd>
>> header _only_ gives names, it never gives full definitions. So the real
>> question isn't why my compiler choking, but why yours is letting you get
>> away with it. My main guess is: between CWP 5.3 and 6.1, a class (template)
>> in one of the standard headers you #include changed its I/O implementation
>> to use string-based streams internally. This change necessitated #including
>> <sstream>, which also #includes <istream> and <ostream>. So you are
>> "benefiting" from indirect #includes.
>>
>> Don't depend on indirect #includes, always #include the header for the full
>> definition (if needed). The reason is that indirect #includes are not
>> portable. They can be different across compilers (I told someone else here
>> writing a garbage collector about an indirect <cassert>.) or even versions
>> of the same compiler (like us here). I think someone here thought that
>> indirect #includes shouldn't be visible at all! In the future, Metrowerks
>> could change the implementation again to remove <sstream>, or block indirect
>> #includes, so why take the risk?

> I agree with the need not to rely on indirect includes. I just fail to see how
> the problem you describe can actually come about. The interest of only
> including iosfwd is the fact that it is the minimal include possible for
> things to work. Your clain is that it is actually to little, and that more is
> needed. I just can't decide if the problem is caused by my platform or yours.
> At any rate this has to be resolved, and I will abide by the final
> recomandations (IOW, I need some enlightement here!).

I have a copy of the C++ standard. The I/O part is described in chapter 27.
The <iosfwd> header is the first one after the chapter introduction. That
section only has the header's synopsis, which are forward declarations of
all the I/O templates and types, and descriptions of the (inheritance)
relations between the various types. There are no class definitions given,
unlike the other headers described in later sections of the chapter. I'm
assuming that this means that <iosfwd> doesn't give any information about
its templates and types except their names. (Why call it a forward
declaration header if the full declarations are there?) Section 3.1 says
such names describe incomplete types, and incomplete types can't be used for
object definitions, like the ones in the beginning of your I/O operators.

The headers I mentioned add the full class declarations, making the types
complete, so they can be used for objects.

-- 
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