From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17556 invoked by alias); 11 Apr 2003 11:46:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 17507 invoked by uid 71); 11 Apr 2003 11:46:01 -0000 Date: Fri, 11 Apr 2003 11:46:00 -0000 Message-ID: <20030411114601.17506.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "Igor A. Goussarov" Subject: Re: c++/10332: Template classes are not instantiated correctly in presense of #pragma pack() Reply-To: "Igor A. Goussarov" X-SW-Source: 2003-04/txt/msg00494.txt.bz2 List-Id: The following reply was made to PR c++/10332; it has been noted by GNATS. From: "Igor A. Goussarov" 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