public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nathan Myers <ncm@cygnus.com>
To: egcs@cygnus.com
Subject: Re: interface/implementation: export keyword?
Date: Fri, 30 Oct 1998 03:25:00 -0000	[thread overview]
Message-ID: <3639068E.87C69293@cygnus.com> (raw)
In-Reply-To: <71B30885B657D111809D080009EEBBF339EABC.cygnus.egcs@MAILSERV.molienergy.bc.ca>

Jan Reimers wrote:

> > > > I'm trying to sensibly separate template definitions/declarations
> > > > for a project I'm writing in C++, as I believe (?) it's good 
> > > > practice to separate the interface from the implementation.
> > >
> > > The short answer is to put your template declarations in an .h file,
> > > and your template definitions in a .cxx (or .cc) file, and until
> > > egcs supports export, #include the .cxx file as well as the .h file
> > > when you use the templates.
> >
> > Thanks for the advice, but there's two reasons I didn't do this in the
> > first place: ...

It's better to conditionally include the template definitions in the 
headers directly, as:

  // foo.h
  #ifndef INCLUDED_FOO
  # define INCLUDED_FOO
  template <class T> void mangle(T*);
  # ifdef EXPORT_NOT_IMPLEMENTED
  #  define export
  #  include "bar.h" /* needed for mangle() definition */
  #  include "foo.tcc"
  # endif
  #endif

  // foo.tcc
  export template <class T>
    void mangle(T*) {}

This is the solution used in the libstdc++-v3 project.
When export is supported then you read the ".tcc" files
into your template repository.  In the meantime compilation
is slower because each compilation unit sees the whole 
definition.

> > Surely there must be an elegant way of doing this already, or does
> > nobody else use templates and require them to be space-efficient?
>
> I would guess that very few people don't use templates these days.  The
> standard is full of them, even istream and ostream are implemented with
> templates.

It's not a space-efficiency issue; it's a matter of convenience,
size of intermediate files, and compilation time.  The solution
to these is to implement export.

Nathan Myers
ncm@cantrip.org

       reply	other threads:[~1998-10-30  3:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <71B30885B657D111809D080009EEBBF339EABC.cygnus.egcs@MAILSERV.molienergy.bc.ca>
1998-10-30  3:25 ` Nathan Myers [this message]
1998-10-29  0:50 Jan Reimers
  -- strict thread matches above, loose matches on Subject: below --
1998-10-27  3:15 Terence J. Wells
1998-10-27 16:33 ` Joe Buck
1998-10-28  3:53   ` Terence J. Wells
1998-10-28 18:51     ` Joe Buck
1998-10-31 16:39     ` Martin von Loewis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3639068E.87C69293@cygnus.com \
    --to=ncm@cygnus.com \
    --cc=egcs@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).