Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / March 2005

Tip: Looking for answers? Try searching our database.

Class Data Alignment Problem in v 7.1

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
sgraber@neo.rr.com - 22 Mar 2005 23:12 GMT
I have encountered a class data alignment issue in Microsoft Visual
Studio .Net 2003 (C++, 7.1). The issue only appears in certain
configurations.

My class is a simple class with no inheritance. The class includes 2
CStringArrays, 3 CStrings, 6 doubles, 2 unsigned chars, a couple of
longs. If I create a copy of the class using 'new CTestClass2', I can
then use the class pointer to call pTestCase2->m_strArray1.SetSize
(10); This works fine. However, if I declare another instance of the
class in another thread => CTestCase2 testCase2; Now the original class
returned by the new CTestClass2 appears to have a data alignment
problem. The vfptr in the m_strArray1 is off by 2 bytes. The first line
in SetSize ASSERT_VALID fails. If I adjust the this pointer by hand,
the SetSize will complete correctly.

Another strange anomaly with this issue is that if I remove all of the
doubles from the class, the SetSize works fine.

The app is a COM app.

Has anyone seen any behavior like this?
Carl Daniel [VC++ MVP] - 23 Mar 2005 00:23 GMT
>I have encountered a class data alignment issue in Microsoft Visual
> Studio .Net 2003 (C++, 7.1). The issue only appears in certain
[quoted text clipped - 17 lines]
>
> Has anyone seen any behavior like this?

Yes.  It's ALWAYS caused by one or both of two things:

1. Inconsistent compiler options between different modules that were linked
together, particuarly the /Zp command line option.
2. Unmatched #pragma pack() calls - these could be coming from an #include
file so they can be hard to track down.

-cd

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.