hattons@globalsymmetry.com ("Steven T. Hatton") writes:
[snip]
> namespace std
>   {
>   template<class _Tp>
>   class valarray;
> }

This is undefined behavior.

>
> Unfortunately it has proven less than 100% successful.  It is often
> difficult to determine exactly what the forward declaration should be.
>
> I am aware of the <iosfwd> header.  IIRC, in ancient days there was talk of
> a complete collection of such forward declaration headers.  Is such a thing
> reasonable to incorporate in the Standard?  That is, for each header, there
> would be a corresponding 'stub' header containing only the forward
> declarations of names contained in the complete header.
[snip]

The advantage is reducing compilation times and dependencies. The
    disadvantage is that there needs to be a formal proposal and some
    experimentation and discussion needs to be done.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

llewelly wrote:

> hattons@globalsymmetry.com ("Steven T. Hatton") writes:
> [snip]
>> namespace std
>>   {
>>   template<class _Tp>
>>   class valarray;
>> }
>
> This is undefined behavior.

And, as I've learned, a good way to get in trouble.

>>
>> Unfortunately it has proven less than 100% successful.  It is often
>> difficult to determine exactly what the forward declaration should be.
>>
>> I am aware of the <iosfwd> header.  IIRC, in ancient days there was talk
>> of
>> a complete collection of such forward declaration headers.  Is such a
>> thing
>> reasonable to incorporate in the Standard?  That is, for each header,
>> there would be a corresponding 'stub' header containing only the forward
>> declarations of names contained in the complete header.
> [snip]
>
> The advantage is reducing compilation times and dependencies. The
>     disadvantage is that there needs to be a formal proposal and some
>     experimentation and discussion needs to be done.

I believe another advantage would be to reduce confusion on the part of
(new) programmers.  There have been a few instances in which an omitted
header prevented code from compiling with GCC 3.4.0, whereas it compiled
under the previous GCC version. If I reproduce an example, I will share it.
The experience highlighted the confusion I've encountered regarding
#including standard headers in my header files.  The advice I've received
regarding headers is that I should only use them where an object id
defined, not where it is declared.  Currently, that seems not to apply to
the standard headers.

There is a related idea I believe is worth suggesting.  That has to do with
the ability to extract signature information from the implemented standard
headers.
--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Steven T. Hatton wrote:

>>>I am aware of the <iosfwd> header.  IIRC, in ancient days there was talk
>>>of
>>>a complete collection of such forward declaration headers.  Is such a
>>>thing
>>>reasonable to incorporate in the Standard?  That is, for each header,
>>>there would be a corresponding 'stub' header containing only the forward
>>>declarations of names contained in the complete header.
>>
>>[snip]
>>
>>The advantage is reducing compilation times and dependencies. The
>>    disadvantage is that there needs to be a formal proposal and some
>>    experimentation and discussion needs to be done.
>
>
> I believe another advantage would be to reduce confusion on the part of
> (new) programmers.  There have been a few instances in which an omitted
> header prevented code from compiling with GCC 3.4.0, whereas it compiled
> under the previous GCC version.

Not to mention changing among different C++ implementations. Unlike C,
C++ standard headers are allowed but not requried to include one
another. (The C++ Committee did not have the time to analyze what
strong statement could or should be made, given the complexity of the
headers.)

The C++ standard, and some reference books on the C++ library, tell
you what entities are declared in which headers.

A single header providing forward declarations (and as little else asl
possible) for the whole library would ease the problem of knowing what
to include. But it wouldn't help when you needed the full definition.

The C++ Committee has discussed informally the possibility of an <all>
header that would include the entire set of standard headers. You
could experiment with such a header yourself, particularly if your
compiler supports precompiled headers.

--
Steve Clamage, stephen.clamage@sun.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

hattons@globalsymmetry.com ("Steven T. Hatton") writes:

> llewelly wrote:
>
>> hattons@globalsymmetry.com ("Steven T. Hatton") writes:
>> [snip]
>>> namespace std
>>>   {
>>>   template<class _Tp>
>>>   class valarray;
>>> }
>>
>> This is undefined behavior.
>
> And, as I've learned, a good way to get in trouble.
>
>>>
>>> Unfortunately it has proven less than 100% successful.  It is often
>>> difficult to determine exactly what the forward declaration should be.
>>>
>>> I am aware of the <iosfwd> header.  IIRC, in ancient days there was talk
>>> of
>>> a complete collection of such forward declaration headers.  Is such a
>>> thing
>>> reasonable to incorporate in the Standard?  That is, for each header,
>>> there would be a corresponding 'stub' header containing only the forward
>>> declarations of names contained in the complete header.
>> [snip]
>>
>> The advantage is reducing compilation times and dependencies. The
>>     disadvantage is that there needs to be a formal proposal and some
>>     experimentation and discussion needs to be done.
>
> I believe another advantage would be to reduce confusion on the part of
> (new) programmers.

I think such confusion stems in part from allowing standard headers
    to provide standard names they aren't required to provide.

> There have been a few instances in which an omitted
> header prevented code from compiling with GCC 3.4.0, whereas it compiled
> under the previous GCC version. If I reproduce an example, I will
> share it.

#include<iostream>
#include<ostream>

int main()
  {
    std::cout << std::sqrt(2.0) << std::endl;
  }

compiles with no errors using g++ 3.3.3, but emits:

    hatton.cc: In function `int main()':
    hatton.cc:6: error: `sqrt' is not a member of `std'

when compiled with g++ 3.4 . g++ 3.3.3 #included <math.h> in
    <iostream> (more or less). g++ 3.4 does not.

I forget the reason for the change, but a significant fraction of the
    g++ and libstdc++ developers would like to minimize the amount of
    non-portable code that g++ will compile. Also, there were user
    complaints about examples like the above compiling when users felt
    they shouldn't. Finally, it seems to me that short snippets of
    example code in which most of the TU is #included standard
    headers (like the above) compile much faster with 3.4 than 3.3.3
    . There may have been a push to minimize the compile-time impact
    of #including standard headers.

[snip]
> There is a related idea I believe is worth suggesting.  That has to do with
> the ability to extract signature information from the implemented standard
> headers.

This makes me think of the decltype proposal (which I should read
    again someday), but I can't see how that could be used to avoid
    #including standard headers.

The other notion it brings to mind is a command-line tool, let's call
    it 'c++decl' which prints the declaration of its first
    argument. That would be quite useful, but it seems to me that
    even the notion of external tools is alien to the existing C++
    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://www.jamesd.demon.co.uk/csc/faq.html                       ]

The recent release of GCC 3.4.0 has revealed a problem with several programs
I've compiled in the past weeks. This excerpt from a discussion on the GCC
mailing list explains the situation:

/****************************************************************/
http://gcc.gnu.org/ml/gcc/2004-04/msg01269.html
to make things short: GCC 3.4.0 is right, the code is wrong.
(GCC 3.4.0 is just more standard conformant than 3.3.2.)

In order to make the code compile you have to add something like

  template<class> class Slice_iter;
  template<class> class Cslice_iter;

  template<class T> bool operator==(const Slice_iter<T>& p, const
Slice_iter<T>& q);
  template<class T> bool operator!=(const Slice_iter<T>& p, const
Slice_iter<T>& q);
  template<class T> bool operator< (const Slice_iter<T>& p, const
Slice_iter<T>& q);

  template<class T> bool operator==(const Cslice_iter<T>& p, const
Cslice_iter<T>& q);
  template<class T> bool operator!=(const Cslice_iter<T>& p, const
Cslice_iter<T>& q);
  template<class T> bool operator< (const Cslice_iter<T>& p, const
Cslice_iter<T>& q);

before the definition of "Slice_iter". That's because of [14.5.3]/2 in
the standard. The friend declarations in Slice_iter require that a
declaration of the template function for "operator==" etc. is already there.

  template<class T> class Slice_iter {
  // ...
          friend bool operator==<>(const Slice_iter& p, const Slice_iter& q);
          friend bool operator!=<>(const Slice_iter& p, const Slice_iter& q);
          friend bool operator< <>(const Slice_iter& p, const Slice_iter& q);
  };
/****************************************************************/

I've also been trying to follow the advice from the authorities in the field
which says to avoid #including headers in other header files.  The
proscribed approach is to use forward declarations wherever possible. My
approach to forward declaring names from std:: has been to open the
namespace and declare the name in my header file.  For example:

#ifndef _SLICETEST_H_
#define _SLICETEST_H_

#include <iosfwd>
#include <vector>
#include <utility>

namespace std
  {
  template<class _Tp>
  class valarray;
}

Unfortunately it has proven less than 100% successful.  It is often
difficult to determine exactly what the forward declaration should be.

I am aware of the <iosfwd> header.  IIRC, in ancient days there was talk of
a complete collection of such forward declaration headers.  Is such a thing
reasonable to incorporate in the Standard?  That is, for each header, there
would be a corresponding 'stub' header containing only the forward
declarations of names contained in the complete header.

--
STH
http://www.kdevelop.org
http://www.suse.com
http://www.mozilla.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://www.jamesd.demon.co.uk/csc/faq.html                       ]