btw: I mean to say that my new problem is now I cannot see the actual value of the string in the debug window it still acts like the pragma wasn't set. BUT fortuntely the code does work now. bill
"Bill Andreozzi" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > After some futher testing and stepping through the code, we've noticed that > when the string::t0 is copied from another string::t0 that the full > string::t2 structure was not copied, therfore missing the final element of > string::t2.data_ (null term character) So whatever information that was > there prior to the copy, it stayed there (in some cases a luck null char, > other times a random byte). > > After surround the two structures with a pragma pack 1 (since the short_size > is a bit field), it seems to have fixed the problem. Now my problem is > (basically UI in the debugger or some existing type library that is being > used by the debugger) that when viewing this data in the debug watch window, > the short_size structure still appears as two bytes. therefore making it > appear as if I have truncated the start of my data_, but when you look in > memory, all is well. (hence if I set a lpcstr to the string.c_str() of this > object, the value is correct.). > > Is there anything I can do to correct the debugger problem? > Any help would be Greatly! appreciated.. > > The snippet of code in the string file is below. > > problem could be solved by modifying the string file (~line 993) to pack the > short_size and short_t structs. > > #pragma pack (1) > struct short_size > { > unsigned char f_ : 1; > unsigned char size_ : __char<>::bits - 1; > }; > > struct short_t > { > union > { > short_size s; > value_type pad; > }; > value_type data_[min_cap]; > }; > #pragma pack () > > thanks - bill > > "Ben Combee" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > > At 12:40 2003-3-19 -0800, you wrote: > > >Has metrowerks updated the STL that is included with the product? > > >Is this their own? > > > > This is our own STL, part of the Metrowerks Standard Library, and > > maintained by C++ library experts like Howard Hinnant. > > > > >I've having some really strange problems with the string class, and need > to > > >know if there's been an update to the template? (or if you use > Dinkumwares > > >etc, if there's an update.) > > > > There have been updates to MSL internally, but we have not issued a V9 > > patch that has these updates yet. They will be part of the V9.2 release, > > but I'm not sure if the bug you're reporting is fixed yet. > > > > >Here is what I'm doing and what I'm seeing: > > > > > >DatabaseInfo dbi; > > > > > > dbi.uicardno = volRefNum; > > >dbi.dbID = 0; > > >dbi.strfilename = pszNameSrc; > > >dbi.strpath = pszVol; > > > > > >pszNameSrc is a char[], as well as strpath, this dbi structure is added > to a > > >vector of these DatabaseInfo structures. > > >strfilename and strpath are string > > > > > >If I verify the value of pszNameSrc, and the value of dbi.strfilename > after > > >this code, they are the same and appear correctly. > > > > > >After I loop through all the databases and build this vector of these > > >DatabaseInfo objects, (for testing) I then loop through this vector and > > >verify the information in the dbi structure. > > > > > >for some reason (once in awhile, but on the very same filenames), I get > > >garbage at the end of strfilename. (e.g. database1.pdb becomes > > >database1.pdb*&*$ ) > > > > This seems similar to a bug that just got reported on Mac OS with that > > version of MSL, but the code in that MSL is actually older than this > > version, and the fix didn't apply. > > > > >(but I know for a fact that the char[] is clean and has been zero'ed out > > >prior to puting the name into it.) - I've actually stepped through the > code, > > >added this structure, then looked at the structure in the vector AND > looked > > >at the original structure and the original structure would be clean and > the > > >one in the vector would have the garbage. > > > > The problem is the internal buffer allocated in the string object that > > holds a copy of your data. > > > > I suggest that you turn off inlining and step into the code that does the > > string assignment to see what's happening. I just did a cursory look at > > the code, and I don't see anything obviously wrong. If you can't figure > it > > out, I'd send an example in to CW tech support who can forward it to the > > right engineer. > > > > -- > > Ben Combee <[EMAIL PROTECTED]> > > CodeWarrior for Palm OS technical lead > > Palm OS programming help @ www.palmoswerks.com > > > > > > > > > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
