Pete Becker  <petebecker@acm.org> wrote:
+ Phil Edwards wrote:
+ >
[snip for space]
+ > This is a compiler-specific restriction, /not/ specified by the
+ > language itself.  However, it's a restriction that's common to every
+ > compiler I've tried; things usually get funky at the link stage.
+
+ April Fool's day must have come early. Sorry, but this makes no sense. I
+ have never seen this sort of problem with any compiler that I've used,
+ nor have I ever heard anyone complain of this problem before. Moving the
+ definition of s1 out into a separate header and then #include'ing that
+ header where the definition used to be does not affect the contents of
+ the translation unit.

The posted example /is/ a simplified one.

Sorry, friend, but that's the way it is.  I don't understand it either,
and there's certainly no language-mandated reason for it.  Here's a
note, cut from the release notes file from DEC's CXX compiler version
5.5 (the almost-latest compiler for dUnix 3.2x -- I understand the CXX
that comes for dUnix 4.0 is much better, and 5.5 is pretty good to
begin with):

    #
    # 1.9.5 Restrictions
    #
    #       This section describes problems of interest to Standard
    #       Library users that Digital has no current plans to fix.
    #       Where feasible, a way to work around the problem is
    #       suggested.
    #
    #[snip]
    #
    #       o  Auto-instantiation does not work correctly when
    #          declarations of types that are used to instantiate a
    #          particular template are defined in the source file.
    #
    #          To avoid this problem, use pragmas or explicit
    #          instantiation (see Section 1.6) to force manual
    #          instantiation (see Chapter 5 of Using DEC C++ for
    #          Digital UNIX Systems), or move the type declarations
    #          into a template declaration file.
    #

I ran into this exact problem, and the only change I made was the one
suggested in my previous article:  move the struct/class definition into a
different file, and #include that file.  Presto, it works.

Seems to be just growing pains of the compiler community as experience
is gained with templates (such as the STL's) and ways of managing
them.  I don't find it to be a particularly horrible annoyance; you can
force yourself to look at it from the bright side and say that
modularity is increased.  :-|

I ran the exact same code through the GNU compiler (g++ 2.7.something)
and it suffered from the same difficulty.  The same solution worked.
(The "explicit instantiation" solution was pretty buggy under g++ at
the time, so I went with the portable solution.)  I haven't tried it on
the 2.8 release.

It also died on some Wintel compilers, but I stopped caring at that point.


Luck++;
/dev/phil

=> If you post a followup, please don't email a copy to me.  I read news
    often enough that replying to things twice is annoying.  But thanks.
---
[ 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              ]

Phil Edwards wrote:
>
> Pete Becker  <petebecker@acm.org> wrote:
> + Phil Edwards wrote:
> + >
> [snip for space]
> + > This is a compiler-specific restriction, /not/ specified by the
> + > language itself.  However, it's a restriction that's common to every
> + > compiler I've tried; things usually get funky at the link stage.
> +
> + April Fool's day must have come early. Sorry, but this makes no sense. I
> + have never seen this sort of problem with any compiler that I've used,
> + nor have I ever heard anyone complain of this problem before. Moving the
> + definition of s1 out into a separate header and then #include'ing that
> + header where the definition used to be does not affect the contents of
> + the translation unit.
>
> The posted example /is/ a simplified one.
>
> Sorry, friend, but that's the way it is.  I don't understand it either,
> and there's certainly no language-mandated reason for it.  Here's a
> note, cut from the release notes file from DEC's CXX compiler version
> 5.5 (the almost-latest compiler for dUnix 3.2x -- I understand the CXX
> that comes for dUnix 4.0 is much better, and 5.5 is pretty good to
> begin with):

I stand by my original statement: I have never had to do this. I haven't
used DEC's compilers, and I'm perfectly happy to believe that they
require this. But as they say in the world of medical diagnosis, "when
you hear hoofbeats, don't think of zebras". And don't describe the
quirks of one line of compilers as "common to every compiler I've tried"
-- it's misleading.
 -- Pete
---
[ 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              ]

Phil Edwards wrote:
>
> Bryan Brandt <umbran17@cc.UManitoba.CA> wrote:
> + i'm having some problems with structs... basically, i get a really
> + vague error when i try to put a vector in a struct. it goes something
> + like this:
> +
> [legal-looking code snipped for space]
> +
> + is there something wrong with that code?  i'm getting all kinds of
> + compile-time errors under Visual C++, and link errors under DJGPP.
> + any clues?
>
> It's purely an "quality of implementation" problem.  The definition of
> the type being used as an element of the vector must be in a different
> header file than the declaration of the vector variable.  Try splitting
> your code into something like:
>
 > //////////  thing1.h  //////
 >
 > struct s1
 > {
 >     int i, j;
 > };
 >
 > //////////  thing2.h  //////  (or thing2.C, for this example)
 >
 > #include <vector>
 > #include "thing1.h"    // inclusion order is irrelevant here
 >
 > using std::vector;  // slightly cleaner than "using namespace std" -- you
 >                     // may as well just #include <vector.h> in that case
 >
 > struct ss2
 > {
 >     vector<s1>  thing;
 >     int         otherstuff;
 > };
>
> This is a compiler-specific restriction, /not/ specified by the
> language itself.  However, it's a restriction that's common to every
> compiler I've tried; things usually get funky at the link stage.

April Fool's day must have come early. Sorry, but this makes no sense. I
have never seen this sort of problem with any compiler that I've used,
nor have I ever heard anyone complain of this problem before. Moving the
definition of s1 out into a separate header and then #include'ing that
header where the definition used to be does not affect the contents of
the translation unit.
 -- Pete
---
[ 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              ]

This code compiles with g++ compiler without any problem.
/Prasad

On 1 Mar 1998, Pete Becker wrote:

||Bryan Brandt wrote:
||>
||> i'm having some problems with structs... basically, i get a really
||> vague error when i try to put a vector in a struct. it goes something
||> like this:
||>
||> #include <vector>
||>
||> using namespace std;
||>
||> struct s1 {
||>    int i,j;
||> };
||>
||> struct s2 {
||>    int i;
||>    vector<s1> ss1;
||> };
||>
||> is there something wrong with that code?  i'm getting all kinds of
||> compile-time errors under Visual C++, and link errors under DJGPP.
||> any clues?
||
||You left out the most critical clue: what the compile-time errors were,
||and what the link errors were. Compilers give you error messages for a
||reason: they describe what went wrong.
---
[ 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              ]

i'm having some problems with structs... basically, i get a really
vague error when i try to put a vector in a struct. it goes something
like this:

#include <vector>

using namespace std;

struct s1 {
   int i,j;
};

struct s2 {
   int i;
   vector<s1> ss1;
};

is there something wrong with that code?  i'm getting all kinds of
compile-time errors under Visual C++, and link errors under DJGPP.
any clues?

--
+-Bryan Brandt-------------+-------------------------------+
| umbran17@cc.umanitoba.ca | brandt@sirvys.com             |
| Computer Engineering,    | Special Projects Development, |
| University of Manitoba   | Sirvys Corporation            |
+--------------------------+-------------------------------+
| http://home.cc.umanitoba.ca/~umbran17                    |
+----------------------------------------------------------+
---
[ 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              ]

Bryan Brandt wrote:
>
> i'm having some problems with structs... basically, i get a really
> vague error when i try to put a vector in a struct. it goes something
> like this:
>
> #include <vector>
>
> using namespace std;
>
> struct s1 {
>    int i,j;
> };
>
> struct s2 {
>    int i;
>    vector<s1> ss1;
> };
>
> is there something wrong with that code?  i'm getting all kinds of
> compile-time errors under Visual C++, and link errors under DJGPP.
> any clues?

You left out the most critical clue: what the compile-time errors were,
and what the link errors were. Compilers give you error messages for a
reason: they describe what went wrong.
---
[ 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              ]

Bryan Brandt wrote in message
<6d7nk4$t3t$1@canopus.cc.umanitoba.ca>...
>#include <vector>
>
>using namespace std;
>
>struct s1 {
>   int i,j;
>};
>
>struct s2 {
>   int i;
>   vector<s1> ss1;
>};
>
>is there something wrong with that code?  i'm getting all kinds of
>compile-time errors under Visual C++, and link errors under DJGPP.
>any clues?

This code is perfectly valid, the problem lies in the compilers.  I'm
not sure what the problem is in DJGPP, but I've run into this problem
in VC++ (5.0 no SP).  Here's a regurgitation from one of my source
files that explains it:

STL container member functions sometimes use relational operators to
compare contained objects.  VC 5.0 instantiates all member functions
of a template class regardless of whether or not they are used (this
violates CD-2 subclause 14.7.1 paragraph 7).  Even if these member
functions are not used, any class object that is contained in an STL
container must define
these relational  operators.  At the very least, these operators
include < and ==, and may include other operators depending on the
container.

In English, the workaround is:
  struct s1 {
    int i,j;
    void operator<(const s1&) const;
    void operator==(const s1&) const;
  };

Leave the two member operators undefined to prevent them from actually
being used.

-Chris




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

Bryan Brandt <umbran17@cc.UManitoba.CA> wrote:
+ i'm having some problems with structs... basically, i get a really
+ vague error when i try to put a vector in a struct. it goes something
+ like this:
+
[legal-looking code snipped for space]
+
+ is there something wrong with that code?  i'm getting all kinds of
+ compile-time errors under Visual C++, and link errors under DJGPP.
+ any clues?

It's purely an "quality of implementation" problem.  The definition of
the type being used as an element of the vector must be in a different
header file than the declaration of the vector variable.  Try splitting
your code into something like:

//////////  thing1.h  //////

struct s1
{
    int i, j;
};

//////////  thing2.h  //////  (or thing2.C, for this example)

#include <vector>
#include "thing1.h"    // inclusion order is irrelevant here

using std::vector;  // slightly cleaner than "using namespace std" -- you
                    // may as well just #include <vector.h> in that case

struct ss2
{
    vector<s1>  thing;
    int         otherstuff;
};


This is a compiler-specific restriction, /not/ specified by the
language itself.  However, it's a restriction that's common to every
compiler I've tried; things usually get funky at the link stage.


Luck++;
/dev/phil

=> If you post a followup, please don't email a copy to me.  I read news
    often enough that replying to things twice is annoying.  But thanks.
---
[ 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              ]

On 2 Mar 1998 16:55:34 GMT, "Christopher M. Gurnee"
<gurnec@nospam.yahoo.com> wrote:

>STL container member functions sometimes use relational operators to
>compare contained objects.  VC 5.0 instantiates all member functions
>of a template class regardless of whether or not they are used (this
>violates CD-2 subclause 14.7.1 paragraph 7).  Even if these member
>functions are not used, any class object that is contained in an STL
>container must define
>these relational  operators.  At the very least, these operators
>include < and ==, and may include other operators depending on the
>container.
>
>In English, the workaround is:
>  struct s1 {
>    int i,j;
>    void operator<(const s1&) const;
>    void operator==(const s1&) const;
>  };
>
>Leave the two member operators undefined to prevent them from actually
>being used.

That worked fine for the original release of VC5. The definitive
workaround for VC5 is to apply one of the service packs (the current
service pack revision is 3), which addressed this problem and rendered
the unnecessary relational operator declarations unnecessary.

--
Doug Harrison
dHarrison@worldnet.att.net
---
[ 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              ]