This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
#pragma interface && generating virtual tables (of templates?)
- To: egcs at cygnus dot com (egcs at cygnus dot com)
- Subject: #pragma interface && generating virtual tables (of templates?)
- From: Carlo Wood <carlo at runaway dot xs4all dot nl>
- Date: Sat, 20 Feb 1999 18:41:12 +0100 (CET)
Hi all,
I have good reasons to believe that #pragma interface, when
added to a header file which contains templates, results
sometimes (constistently, but too complex for me to understand
under what kind of conditions) in certain virtual tables
not to be generated.
Am I correct to think that this would be a bug, because
templates should not be influenced by '#pragma interface'
at all (since they don't generate code by themselfs to
begin with)?
One of the reasons that I think that this must be a bug
in egcs (I still use 1.1.1 release) is that when I *remove*
a fucntion call somewhere it started to link, see
example below - I can't provide a working example because
of the included header files :(.
If one NOT #defines FOOBAR then the code below compiles and
links fine, if you do #define FOOBAR, then I get
(among other undefines):
/home/carlo/c++/egcs.bugs/bug3/ircd.lag.cc:34: undefined reference to `server_sock_dct virtual table'
The problem is also solved by removing the "#pragma interface"
in one of the header files (libr/sock.h).
When excluding the code between #ifdef FOOBAR ... #endif, it compiles
and links fine, as I just said, and I get:
~/c++/egcs.bugs/bug3>nm -C ircd.lag.o | grep server_sock_dct
00000000 W server_sock_dct::~server_sock_dct(void)
00000000 W server_sock_dct::server_sock_dct(int)
00000000 W server_sock_dct type_info function
00000000 W virtual function thunk (delta:-44) for server_sock_dct::~server_sock_dct(void)
00000000 W virtual function thunk (delta:-64) for server_sock_dct::~server_sock_dct(void)
00000010 C server_sock_dct type_info node
00000000 W server_sock_dct virtual table
00000000 W server_sock_dct::ios virtual table
00000000 W server_sock_dct::fd_dct virtual table
00000000 W server_sock_dct::dbbuf_fd_dtct<write_ostream_ct> virtual table
00000000 W server_sock_dct::get_output_stream(void) const
So, by NOT including the call to timer(), it DOES generate code which
it does not generate when I do NOT call timer():
~/c++/egcs.bugs/bug3>nm -C ircd.lag.o | grep server_sock_dct
00000000 W server_sock_dct::server_sock_dct(int)
U server_sock_dct virtual table
U server_sock_dct::ios virtual table
U server_sock_dct::fd_dct virtual table
U server_sock_dct::dbbuf_fd_dtct<write_ostream_ct> virtual table
Now normally I'd expect that by calling extra code, extra templates
get instantiated (at most), and not that I get LESS generated code.
I understand this is all pretty vague :(, because I can't provide
a working example - but perhaps someone can give me a clue on
whether or not using #pragma interface is deprecated in this case
and/or if I can organize things differently so I won't get undefined
virtual tables all the time :)... Some general story thus.
At the bottom have added some brainstorming :/
Thanks,
--
Carlo Wood <carlo@runaway.xs4all.nl>
-----------------------------------------------------------------------------
#include <libr/sys.h>
#include <libr/sock.h>
#include <libr/timing.h>
class server_input_ct : public decode_input_ct {
protected:
void decode(char *msg, size_t len);
virtual ostream &get_output_stream(void) const = 0;
server_input_ct(dbstreambuf_ct *ibuf) : decode_input_ct(ibuf) { }
private:
void msg_expired(const timer_event_type_ct &expired_at);
};
void server_input_ct::decode(char *msg, size_t len)
{
#ifdef FOOBAR
struct timeval timeout = { 1, 0 };
timer(timeout, *this, &msg_expired);
#endif
}
void server_input_ct::msg_expired(const timer_event_type_ct &expired_at)
{
}
class server_sock_dct : public sock_dtct<server_input_ct, write_ostream_ct> {
protected:
virtual ostream &get_output_stream(void) const { return *((ostream *)NULL); }
};
int main(void)
{
new server_sock_dct();
}
==============================================================================
More about the header files:
The reason for class server_sock_dct not to be generated (its virtual table
that is) can probably found in the fact that:
/home/carlo/c++/egcs.bugs/bug3/ircd.lag.cc:34: undefined reference to `server_sock_dct::dbbuf_fd_dtct<write_ostream_ct> virtual table'
The hierarchy of the classes is:
class server_sock_dct :
public sock_dtct<server_input_ct, write_ostream_ct>
sock_dtct<server_input_ct, write_ostream_ct> :
public iodbbuf_fd_dtct<server_input_ct, write_ostream_ct>, private sockbuf_dbct, virtual public fd_dct
class sockbuf_dbct : virtual public fd_dct
class fd_dct : public node_tct<sbll_node_ct, fd_dct>
class node_tct<sbll_node_ct, fd_dct> : public sbll_node_ct
class sbll_node_ct: private sbll_base_ct
class sbll_base_ct
class iodbbuf_fd_dtct<server_input_ct, write_ostream_ct> :
public dbbuf_fd_dtct<server_input_ct>, public dbbuf_fd_dtct<write_ostream_ct>, virtual public fd_dct
class server_input_ct : public decode_input_ct
class decode_input_ct : public line_input_ct
class line_input_ct : public read_input_ct
class read_input_ct : public input_ct
class input_ct : virtual public fd_dct
class write_ostream_ct : public write_output_ct, public ostream
class write_output_ct : public output_ct
class output_ct : virtual public fd_dct
class dbbuf_fd_dtct<server_input_ct> : public server_input_ct, virtual public fd_dct
class dbbuf_fd_dtct<write_ostream_ct> : public write_ostream_ct, virtual public fd_dct
(This makes clear I hope why I can't seem to make a small working example).
In other words, when dbbuf_fd_dtct<write_ostream_ct> virtual table
is not generated, then iodbbuf_fd_dtct<server_input_ct, write_ostream_ct> virtual table
is not generated, then sock_dtct<server_input_ct, write_ostream_ct> virtual table
is not generated, then server_sock_dct virtual table is not generated.
There doesn't seem any reason however why dbbuf_fd_dtct<write_ostream_ct> virtual table
is not generated: This class is only derived from write_ostream_ct and
the virtual base class fd_dct - which both are stable classes that have worked
for at least a year now.