BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  strange string behavior          BorlandTalk.com Forum Index -> C++ Builder (IDE) View previous topic :: View next topic   Author Message panders Guest Posted: Wed Sep 28, 2005 1:56 pm    Post subject: strange string behavior Borland 6 I am copying a string from an edit box to a string object. In the edit box the string is "test" - when it is copied to the string object it copies as "test~1`*" with additional invalid characters appended to the edit box string. I have checked the lengths of both the edit "test" and the copied "test~1`*" and both are length = 4. can anyone tell me why I might be seeing this bizarre behavior? When I write the copied string to a file I get the same garbage invalid characters as I see in my debug. thanks! Back to top Andrue Cope [TeamB] Guest Posted: Wed Sep 28, 2005 2:11 pm    Post subject: Re: strange string behavior panders wrote: Quote: can anyone tell me why I might be seeing this bizarre behavior? When I write the copied string to a file I get the same garbage invalid characters as I see in my debug. There are many ways to 'copy a string' and you haven't indicated which one you're using. Please post some sample code that is complete enough for us to compile. -- Andrue Cope [TeamB] [Bicester, Uk] http://info.borland.com/newsgroups/guide.html Back to top Liz Albin Guest Posted: Wed Sep 28, 2005 2:33 pm    Post subject: Re: strange string behavior On Wed, 28 Sep 2005 09:56:14 -0400, panders wrote: Quote: I am copying a string from an edit box to a string object How are you copying? What sort of string object? -- Good luck, liz Back to top Chris Uzdavinis (TeamB) Guest Posted: Wed Sep 28, 2005 2:46 pm    Post subject: Re: strange string behavior "panders" <paul.anderson (AT) jhuapl (DOT) edu> writes: Quote: Borland 6 I am copying a string from an edit box to a string object. In the edit box the string is "test" - when it is copied to the string object it copies as "test~1`*" with additional invalid characters appended to the edit box string. I have checked the lengths of both the edit "test" and the copied "test~1`*" and both are length = 4. For a specific answer, you'll have to show code. Some possibilities: * your copy is into invalid memory * you are not copying the null termination * your data may be ok but your means of determining it is invalid is flawed * something else. If it's a std::string, and you're looking at it in the debugger, then this is normal behavior. You can only expect a null terminated array of characters when you call c_str() on the object. Quote: can anyone tell me why I might be seeing this bizarre behavior? When I write the copied string to a file I get the same garbage invalid characters as I see in my debug. In the future, be sure to give source code (less than 50 lines!) I hate to guess, and giving the source saves everyone time and gives you a better answer. -- Chris (TeamB); Back to top panders Guest Posted: Wed Sep 28, 2005 2:53 pm    Post subject: Re: strange string behavior Here's the simplest code: string name = edit_Name->Text.c_str(); "Liz Albin" <lizalbinNotThis (AT) yahoo (DOT) com> wrote Quote: On Wed, 28 Sep 2005 09:56:14 -0400, panders wrote: I am copying a string from an edit box to a string object How are you copying? What sort of string object? -- Good luck, liz Back to top Andrue Cope [TeamB] Guest Posted: Wed Sep 28, 2005 3:07 pm    Post subject: Re: strange string behavior panders wrote: Quote: Here's the simplest code: string name = edit_Name->Text.c_str(); Ah ha, std::string then in all probability. In that case as Chris has posted this is normal debug behaviour. std::string stores the length separately and doesn't need to rely on null terminators. -- Andrue Cope [TeamB] [Bicester, Uk] http://info.borland.com/newsgroups/guide.html Back to top panders Guest Posted: Wed Sep 28, 2005 3:36 pm    Post subject: Re: strange string behavior but I am also getting this behavior when I print to a file...is this accurate even though the length is correct for the string name? How can I get around this behavior so I only get the correct string when I write it to the file? "Andrue Cope [TeamB]" <no.spam (AT) not (DOT) a.valid.address> wrote Quote: panders wrote: Here's the simplest code: string name = edit_Name->Text.c_str(); Ah ha, std::string then in all probability. In that case as Chris has posted this is normal debug behaviour. std::string stores the length separately and doesn't need to rely on null terminators. -- Andrue Cope [TeamB] [Bicester, Uk] http://info.borland.com/newsgroups/guide.html Back to top Andrue Cope [TeamB] Guest Posted: Wed Sep 28, 2005 3:49 pm    Post subject: Re: strange string behavior panders wrote: Quote: but I am also getting this behavior when I print to a file...is this accurate even though the length is correct for the string name? That depends how you are printing to the file although I confess that I can't think of any way other than gross abuse and the right way :) std::string is a class and it has its own record of the string length. This means it doesn't have to store the null terminator. Conceptually it is as if you had coded: char fred[ 4 ]; fred[ 0 ]='T'; fred[ 1 ]='e'; fred[ 2 ]='s'; fred[ 3 ]='t'; int fredLen=4; If you pass 'fred' to a function expecting a C-style string it's anyone's guess what will happen. As an example 'strlen( fred )' could return anything. It might even not return at all and instead trigger an AV or crash the computer. Now as Chris wrote std::string does have a member function called c_str(). This returns a pointer to a character array that /will/ be NULL terminated. -- Andrue Cope [TeamB] [Bicester, Uk] http://info.borland.com/newsgroups/guide.html Back to top panders Guest Posted: Wed Sep 28, 2005 4:10 pm    Post subject: Re: strange string behavior 2 things: 1) the debugger shows the string containing the extra garbage characters before it is even written to the file so I don't think it even matters how it is written to the file, but... 2) I am creating an xml node as: child->Attributes[WideString("name")]= (WideString)def.m_name.c_str(); yet I am still getting the garbage characters in the xml node even though I am using the c_str() call. ok...so anyway, I did the simplest test to see what happens in a separate app when copying from edit1 to a std::string and everything copies fine...I presume I must have some other issue that is causing the garbage to occur in my string. I guess I'll have to dig deeper...thanks for your time. "Andrue Cope [TeamB]" <no.spam (AT) not (DOT) a.valid.address> wrote Quote: panders wrote: but I am also getting this behavior when I print to a file...is this accurate even though the length is correct for the string name? That depends how you are printing to the file although I confess that I can't think of any way other than gross abuse and the right way :) std::string is a class and it has its own record of the string length. This means it doesn't have to store the null terminator. Conceptually it is as if you had coded: char fred[ 4 ]; fred[ 0 ]='T'; fred[ 1 ]='e'; fred[ 2 ]='s'; fred[ 3 ]='t'; int fredLen=4; If you pass 'fred' to a function expecting a C-style string it's anyone's guess what will happen. As an example 'strlen( fred )' could return anything. It might even not return at all and instead trigger an AV or crash the computer. Now as Chris wrote std::string does have a member function called c_str(). This returns a pointer to a character array that /will/ be NULL terminated. -- Andrue Cope [TeamB] [Bicester, Uk] http://info.borland.com/newsgroups/guide.html Back to top panders Guest Posted: Wed Sep 28, 2005 6:32 pm    Post subject: Re: strange string behavior I've done a bit of testing found that some of my libraries were compiled with "quad word" alignment instead of "byte" - I wish I knew what this meant but at least if I compile all of my libs with "byte" alignment my string copying works fine...if I set them all to quad word, I get the same problem as before...I'll just move forward with what's working for now... "Chris Uzdavinis (TeamB)" <chris (AT) uzdavinis (DOT) com> wrote Quote: "panders" <paul.anderson (AT) jhuapl (DOT) edu> writes: Borland 6 I am copying a string from an edit box to a string object. In the edit box the string is "test" - when it is copied to the string object it copies as "test~1`*" with additional invalid characters appended to the edit box string. I have checked the lengths of both the edit "test" and the copied "test~1`*" and both are length = 4. For a specific answer, you'll have to show code. Some possibilities: * your copy is into invalid memory * you are not copying the null termination * your data may be ok but your means of determining it is invalid is flawed * something else. If it's a std::string, and you're looking at it in the debugger, then this is normal behavior. You can only expect a null terminated array of characters when you call c_str() on the object. can anyone tell me why I might be seeing this bizarre behavior? When I write the copied string to a file I get the same garbage invalid characters as I see in my debug. In the future, be sure to give source code (less than 50 lines!) I hate to guess, and giving the source saves everyone time and gives you a better answer. -- Chris (TeamB); Back to top Chris Uzdavinis (TeamB) Guest Posted: Wed Sep 28, 2005 8:21 pm    Post subject: Re: strange string behavior "panders" <paul.anderson (AT) jhuapl (DOT) edu> writes: Quote: I've done a bit of testing found that some of my libraries were compiled with "quad word" alignment instead of "byte" - I wish I knew what this meant but at least if I compile all of my libs with "byte" alignment my string copying works fine...if I set them all to quad word, I get the same problem as before...I'll just move forward with what's working for now... Alignment has to do with where in memory is the compiler allowed to place the address of your variables. Small alignment, like bytes, has no padding between variables, which conserves some memory. However, at runtime, the CPU must shift data around to properly align it "just in time", which can have a considerable performance penalty. Usually, the performance hit is not worth the modest reduction in memory usage. Obviously, if your application is built with inconsistant options, it won't work because the shifting will be different depending on what part of your application is running, but the physical memory layout does not change. Thus, part of the application will always be wrong and have irratic behavior. Inconsistant build options can have severe consequences, so don't gloss this over too easily. If something seems strange like this, it's best to understand why it's happening, or else you can't be sure that the problem is really solved. Perhaps by using byte-alignment you have only covered up the symptoms of a lingering problem that really requires a different fix. Be sure your libraries and application have the same build options. Go over all of them, and whenever there is a difference, be suspicious. Some are necessary, such as causing a library to be built, but others can be catastrophic. (I ran into one project where the "empty member optimization" was enabled in a library but not in the exe, so the runtime addresses were wrong inside my object when passing it between the dll and the main application. It works in one place, and immediately fails in another, but nothing ever modified memory. This was another case similar of incompatible alignment. -- Chris (TeamB); Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> C++ Builder (IDE) All times are GMT Page 1 of 1   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.