public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "erik.thiele@thiele-hydraulik.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/56760] namespaces, templates and forwarding declarations.
Date: Thu, 28 Mar 2013 07:58:00 -0000	[thread overview]
Message-ID: <bug-56760-4-QU7FV19shz@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-56760-4@http.gcc.gnu.org/bugzilla/>


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56760

--- Comment #4 from erik.thiele@thiele-hydraulik.de 2013-03-28 07:58:00 UTC ---
The example is reduced very much. Actually I have a module for "holder" and one
for "contain" (separate compilation units). They do not know about each other.
I have this global mechanism called "func" which everybody can make
specializations for to enable his class to take part in this "func" stuff. What
func does is serialize a class into the "binbuffer" binary buffer. If you
create a custom class, you can let it take part in the "func" system and thus
make it serializable.

Everything works fine until I have a holder<contain<foo> > or a
contain<holder<foo> >. The problem is that I cannot have a forward declaration
because "contain" and "holder" don't know each other. This is like adding
forward declarations in system libraries like "vector<>" for user classes which
the STL developers of course cannot know.

v2.cpp does not have the "nam" namespace that "v1.cpp" has. But the "nam"
namespace is only for the "binbuffer" class. See that it has nothing to do with
the "seco" namespace or the global namespace that "func" is inside. For that
reason I do not understand why leaving out the "nam" namespace fixes the
problem.

I cannot find a workaround. The problem is that template implementations are
inside headers. So either "holder" or "contain" is defined and implemented
first. I cannot define "holder" and "contain" and then afterwards implement
"holder" and "contain". This would fix my problem but then the template
implementation cannot be inside the header anymore, at least I do not know how.
I would need a precompiler that splits header interfaces from header
implementations and first puts all interfaces and then all implementations.

Is there another workaround?

Sorry I do not understand your comment. Probably I miss some important point
somehow. Anyway I do not find a solution...


  parent reply	other threads:[~2013-03-28  7:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-28  7:00 [Bug c++/56760] New: " erik.thiele@thiele-hydraulik.de
2013-03-28  7:01 ` [Bug c++/56760] " erik.thiele@thiele-hydraulik.de
2013-03-28  7:05 ` erik.thiele@thiele-hydraulik.de
2013-03-28  7:14 ` pinskia at gcc dot gnu.org
2013-03-28  7:58 ` erik.thiele@thiele-hydraulik.de [this message]
2013-03-28  8:22 ` erik.thiele@thiele-hydraulik.de
2013-03-28  8:27 ` erik.thiele@thiele-hydraulik.de
2013-03-28  9:16 ` redi at gcc dot gnu.org
2013-03-28  9:55 ` erik.thiele@thiele-hydraulik.de
2013-03-28 11:05 ` redi at gcc dot gnu.org
2013-03-28 16:50 ` erik.thiele@thiele-hydraulik.de
2013-03-28 17:19 ` redi at gcc dot gnu.org

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=bug-56760-4-QU7FV19shz@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).