<dmitriy.kourtchikov@tms.tm3.com> wrote:
>>Nathan Myers wrote:
>> <dmitriy.kourtchikov@tms.tm3.com> wrote:
>> >It appears, that string type from the Standard C++ library doesn't work as
>> >an ordinary class. For example, the following code will cause a compilation
>> >error:
>> >
>> >   class string; // forward declaration
>> >   ...
>> >Is it a deficiency (trade-off) of C++ language or C++ library
>> >implementation?
>>
>> It is also specifically forbidden to forward-declare the basic_string<>
>> template, though you might not get a compile error.  The reason for that
>> is that implementers are allowed to add extra (defaulted) template
>> parameters, and your forward-declaration would then be wrong.
>
>Few more cents. There were so many discussions about standard C++ labrary
>classes. Efficiency, flexibility, etc... If current standard for the typedef
>does not allow a forward declaration for the string class, then Standard C++
>library implementation should address this issue. For example, define class
>string as follows:
>
>  class string : public basic_string<char>
>  {
>   //...
>  };

This was considered, of course.  Unfortunately, it doesn't work.  It
means that you cannot pass or return a basic_string<char> to a function
expecting a string.  (A programmed conversion wouldn't help templates.)
We went back and forth over this, but there's really no substitute for
#include <string>.  A <stringfwd> header might have been a good idea,
but it would add visible complexity only to improve compile times; and
vendors have ways to improve compile times without it.

>BTW, I have rejected an idea of the basic_string forward declaration
>from the beginnig since basic_string<char> is just one of implementations
>for the string class. You are right that extra parameters may be added by
>implementers. ObjectSpace library implementation of Standard C++
>library I currently use has the following definition:
>
>  typedef
>  os_basic_string<char, os_char_traits_char, os_allocator<char>> os_string;

The ObjectSpace implementation is non-conforming.  If you stay away
from their allocators, and a variety of other small differences from
the Standard, your code might be reasonably portable.

>I also use Rational Rose/C++. An inclusion of appropriate standard C++
>headers instead of forward declarations (recall that I use ONLY references
>or pointers for Stadard C++ classes in my headers) increases reverse
>engineering of my C++ headers in 20-50 times.

I'm sorry, I don't understand "increases reverse engineering of my
C++ headers in 20-50 times".  In any case, Rational could speed up
handling of standard headers, without help from forward-declarations,
if they cared to do it.

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

Thanks Nathan,

Few more cents. There were so many discussions about standard C++ labrary
classes. Efficiency, flexibility, etc... If current standard for the typedef
does not allow a forward declaration for the string class, then Standard C++
library implementation should address this issue. For example, define class
string as follows:

  class string : public basic_string<char>
  {
   //...
  };

BTW, I have regected an idea of the basic_string forward declaration
from the beginnig since basic_string<char> is just one of implementations
for the string class. You are right that extra parameters may be added by
implementers. ObjectSpace library implementation of Standard C++
library I currently use has the following definition:

  typedef
  os_basic_string<char, os_char_traits_char, os_allocator<char>> os_string;

I also use Rational Rose/C++. An inclusion of appropriate standard C++
headers instead of forward declarations (recall that I use ONLY references
or pointers for Stadard C++ classes in my headers) increases reverse
engineering of my C++ headers in 20-50 times.

Dmitriy
-----------------
In article <6e4a08$dii$1@shell7.ba.best.com>,
  ncm@nospam.cantrip.org (Nathan Myers) wrote:
>
> <dmitriy.kourtchikov@tms.tm3.com> wrote:
> >It appears, that string type from the Standard C++ library doesn't work as
> >an ordinary class. For example, the following code will cause a compilation
> >error:
> >
> >   class string; // forward declaration
> >   ...
> >
> >... forward declaration can not be used for string since it is a
> >typedef, and the header file string should be included instead of the
> >forward declaration. Result - compilation time increase. The same problem
> >exists for other Standard C++ library typed defined using typedef. At
> >the same time, string can be used as a base class and behave almost as
> >an ordinary class.
> >
> >Is it a deficiency (trade-off) of C++ language or C++ library
> >implementation?
>
> Of course the committee would have liked to permit this.  However,
> nobody knew any good way to implement it.
>
> It is also specifically forbidden to forward-declare the basic_string<>
> template, though you might not get a compile error.  The reason for that
> is that implementers are allowed to add extra (defaulted) template
> parameters, and your forward-declaration would then be wrong.
>
> Probably there should have been more "<...fwd>" headers in the
> standard.  With precompiled headers it will not make much difference.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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              ]