public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: "Igor A. Goussarov" <igusarov@akella.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
Subject: Re: c++/10332: Template classes are not instantiated correctly in presense of #pragma pack()
Date: Fri, 11 Apr 2003 11:46:00 -0000	[thread overview]
Message-ID: <20030411114601.17506.qmail@sources.redhat.com> (raw)

The following reply was made to PR c++/10332; it has been noted by GNATS.

From: "Igor A. Goussarov" <igusarov@akella.com>
To: ljrittle@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/10332: Template classes are not instantiated correctly in
 presense of #pragma pack()
Date: Fri, 11 Apr 2003 15:46:35 +0400

 Hello Loren and the team,
 
     Thank you for taking time to examine this another report!
     Unfortunately the fix you suggested isn't very good for two reasons:
 a) __atribute__ is much less portable (compared to #pragma pack which is 
 supported at least by gcc, MSVC, BCB and CodeWarrior)
 b) the fix doesn't address the problem.
 
     I _don't_ want to have packed template classes. I want to have 
 ordinary templates, which use default packing and alignment. But: if 
 this template occasiously got instantiated at the point where "#pragma 
 pack" was set to some obscure value, then the template instance somewhy 
 become packed! This is the behaviour I object to.
 
     Let me put it in other words:
 1. I wrote a template class which doesn't need any packing.
 2. I was using this template class in many translation units all over 
 the program.
 3. One day I wrote another not-template class (or POD struct), which 
 _has_ to be packed.
 4. If the template class in question is implicitly instantiated from 
 within the said packed struct, it miraculously becomes packed.
 5. More disasters follows when several TUs are linked together...
 
     So you see, I'm not trying to apply packing to template classes 
 intentionally. Well, in a sense, packing and templates are used 
 together, since a single translation unit contains them both. But it 
 doesn't look right to me that some class affects the instantiation of a 
 previously defined template. This is kind of... not right.
     For example, imagine that the layout of vtable for polymorphic 
 classes was dependent on the use of some feature in some other place in 
 the program. This would come as a surprise to the developer of the said 
 class, because he always firmly belived that since the class was fully 
 defined nothing more can change it.
     So did I, and so was I surprised. Actually, I've called this 
 behaviour "a bug" because I get used to think that once a class was 
 defined nothing more can change it (and inherently its layout).
 
     Being a programmer myself I can see where all this comes from: it is 
 likely that gcc uses some global variable for storing the current 
 packing size instead of associating the packing size with each 
 individual data structure. Thus, when there is a need to create an 
 instance of a template class, the compiler simply uses the current value 
 of that global variable.
     If this is the case, then changing such behaviour of the compiler is 
 not easy. I mean, it looks more like design issue rather then like 
 implementation bug. Also I can see that such situation is impossible to 
 detect and thus no diagnostic message is ever possible... Pity.
 
 Best Regards,
 Igor
 


             reply	other threads:[~2003-04-11 11:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-11 11:46 Igor A. Goussarov [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-04-15 13:46 Igor A. Goussarov
2003-04-14 23:46 Loren James Rittle
2003-04-14 10:06 Igor A. Goussarov
2003-04-14  9:06 Momchil Velikov
2003-04-14  8:56 Igor A. Goussarov
2003-04-11 13:56 Momchil Velikov
2003-04-11  1:16 ljrittle
2003-04-07 10:46 igusarov

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=20030411114601.17506.qmail@sources.redhat.com \
    --to=igusarov@akella.com \
    --cc=gcc-prs@gcc.gnu.org \
    --cc=nobody@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).