C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Passing Pointers Goto page Previous  1, 2, 3 ... 17, 18, 19          C++Talk.NET Forum Index -> C++ language (comp.lang.c++) View previous topic :: View next topic   Author Message Dombo Guest Posted: Mon Jun 11, 2012 5:02 pm    Post subject: Re: Access Violation Problem Op 11-Jun-12 11:23, Juha Nieminen schreef: Quote: Paavo Helde<myfirstname (AT) osa (DOT) pri.ee> wrote: This is about the worst advice one could give, exactly because of the implicit conversion to const char*. This means that if some function f() outputs a string, the following code compiles without any warning or error: const char* s = f(); Now imagine that f() returned a char* pointer originally (e.g. to a static buffer, or to a string literal), and was later upgraded to return a CString. I think this is exactly what OP wants to do. I'm not absolutely sure of this, but I have the impression that if he's using C++.NET (which isn't a far-fetched assumption given that he is developing a Visual C++ project), the string in question would be gargabe-collected and hence the above would be safe. CString is probably allocating the string using gcnew. I doubt that (can't check it because I don't have the Professional Edition of VC2010). Am sure this isn't true for the version of MFC and ATL that came with VC2005, and I seriously doubt Microsoft would change this as it would imply you couldn't use MFC or ATL with unmanaged applications, which would kinda defeat the purpose of including these libraries in the first place. Note that VC2010 still can produce native executables which do not require the .NET framework. As far as the .NET garbage collection thingy is concerned; that doesn't do anything for raw C++ pointers, the onus is still on the programmer to take care of the lifetime. I have recently looked in to this for a project that required C# code to communicate with unmanaged C++ code. C++/CLI is a schizophrenic language. There is C++ part with C++ semantics and the CLI part with the semantics typical for .NET languages, including garbage collection. Those two parts are quite separated and don't mix easily. If you want .NET garbage collection, you can only use a 'ref class', which defines a .NET class. A 'ref class' cannot derive from C++ classes, or have C++ class instances as members, must be instantiated with gcnew and instances must referred by handle (e.g. my_type^). C++ classes cannot derive from .NET classes or directly have references to instances of .NET classes (at least not directly at the language level). Compiling standard C++ code doesn't get you any of the .NET features. Because of this and the reasons stated above I don't expect that the CString implementation would be safe to use in the example posted above. Given that the OP stated that he is using the Express Edition of VC2010, using CString isn't an option, using basic_string is the only choice that is supported out-of-the-box (unless he gets a copy of a suitable version of the MFC/ATL library and manages to use it with the Express Edition). Back to top Balog Pal Guest Posted: Thu Jun 28, 2012 4:26 pm    Post subject: Re: Access Violation Problem "Paavo Helde" <myfirstname (AT) osa (DOT) pri.ee> Quote: basic_string? Forget it. CString is your friend in that case -- it has interface suitable for about all tasks you have in the envirionment, and has implicit conversion toward const char *, so you can start replacing the c-style stuff without uglifying the user code. This is about the worst advice one could give, exactly because of the implicit conversion to const char*. This means that if some function f() outputs a string, the following code compiles without any warning or error: const char* s = f(); And we arrived to gremlin-land. Yeah, that means that. So then what? In C++ we have too many opportunities for dongling objects and references. So any actually working system deals with that on reviews. Generally you're not supposed to use raw pointers. And if any pointer or ref is stored, there must be a proof for correct lifetime issues. Conversions, implicit or explicit, adds quite nothing to that case. Quote: Now imagine that f() returned a char* pointer originally (e.g. to a static buffer, or to a string literal), and was later upgraded to return a CString. I think this is exactly what OP wants to do. You can hardly sell that conversion as sensible on a review. If a static lifetime char* was returned, then you must return CString with a similar lifetime, so the client code will just work fine. If you change lifetime issues, like returning a temporary in stead of a stable thing, you must revisit all usege places and adjust them. Capturing the temporary correctly. Quote: I am sure you and me could foresee the dangers and avoid the problems, but I am not so sure at all about OP. Whoever can't design the flow of data in a system is doomed to failure regardless of tools used. Didn't the 'new age' languages like java, promising Canaan with garbage collection enough proof? Making all the same problems actually escalated? Quote: (As a bonus you also dodge a ton of problems if decide to put some code into DLL). std::basic_string works as fine in dll-s as do std::vector and std::map, not sure what problems you have in mind. WOW, did you read MSDN recently or ever? Or tried to use them? You get violent warning right ahead about the templates not being exported by nature. Then will have an uphill battle. I didn't even mention what you get for mixing ITERATOR_DEBUG_LEVEL, where you may get a linker warning at least, but may just silently have ODR violation and the wildest crashes imaginable... Back to top Balog Pal Guest Posted: Thu Jun 28, 2012 4:26 pm    Post subject: Re: Access Violation Problem "Jorgen Grahn" <grahn+nntp (AT) snipabacken (DOT) se> Quote: basic_string? Forget it. "Forget it?" Why? It's the standard string type in C++. "standard" is not a synonym for "good". I believe there's a wide consensus that std::string is an abomination with the interface it has. And in thoese 100+ members it still can't deal with the most basic use cases. From the interface you can hardly tell what it was designed for, mostly resembles a half-done vector. tuned for iterator usage, that is hardly done ever. Actual string-like operations NOT really in mind. Not to mention accidents like it was supposedly designed to use COW strategy, but due to broken accessor interface that had to be forbidden implementation for thread-unsafety reasons. Annonuced like a year after the standard published. It's quite a shame, by '98 we had a ton of actually useful, used, GOOD string classes, possibly with a decade+ of practical use. The standardisation would suppose to not invent speculative stuff, rather pick what is good from actual use, and put it in formal terms. I did not happen for std::string (and many other parts of the standard lib.) Back to top Paavo Helde Guest Posted: Thu Jun 28, 2012 5:18 pm    Post subject: Re: Access Violation Problem "Balog Pal" <pasa (AT) lib (DOT) hu> wrote in news:jsi7ko$1asu$1 (AT) news (DOT) ett.com.ua: Quote: std::basic_string works as fine in dll-s as do std::vector and std::map, not sure what problems you have in mind. WOW, did you read MSDN recently or ever? Or tried to use them? You get violent warning right ahead about the templates not being exported by nature. Then will have an uphill battle. I didn't even mention what you get for mixing ITERATOR_DEBUG_LEVEL, where you may get a linker warning at least, but may just silently have ODR violation and the wildest crashes imaginable... I am using std::string, std::vector etc. all the time across DLL borders. One must just ensure that all DLL-s are compiled with the same compiler version, same compiler options, same iterator debugging control macros etc. This is a general requirement of C++, nothing so special to STL. Just compile everything with the same settings and be done. IMO this is far simpler than CString lifetime issues, by the way. Don't know what violent warnings you are talking about. Maybe you have tuned the MSVC warning level too high, this is futile. Fortunately MSVC lets you silence silly warnings easily. Cheers Paavo Back to top Jorgen Grahn Guest Posted: Fri Jun 29, 2012 4:57 pm    Post subject: Re: Access Violation Problem On Thu, 2012-06-28, Balog Pal wrote: Quote: "Jorgen Grahn" <grahn+nntp (AT) snipabacken (DOT) se basic_string? Forget it. "Forget it?" Why? It's the standard string type in C++. "standard" is not a synonym for "good". I believe there's a wide consensus that std::string is an abomination with the interface it has. That was what I thought you meant. There is *not* such a consensus -- although I'm aware that some (a lot of?) people are unhappy with it. [snip] /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . Back to top Jamie Guest Posted: Sun Jul 15, 2012 5:11 am    Post subject: Re: Access Violation Problem You are, of course, wondering about the validity of your "law". "Mike Copeland" <mrc2323 (AT) cox (DOT) net> wrote in message news:MPG.2a34292fa1a939d398970e (AT) news (DOT) eternal-september.org... Quote: I have the following code that compiles but produces a "Access violation reading location..." runtime error when executed. I tried casting the first statement to (char*), but that produced the same fault. I suppose the problem lies with the use of the "const char" in the parameter declaration, but I've been trying to follow the examples I see here that always seem to declare incoming parameters as "const"). 8<{{ Other than that, I don't know how to deal with this problem. (I'm using VC 2010 Express here.) Please advise. TIA char* TTB(const char *str) // Truncate Trailing Blanks { string wStr = str; // faults at this statement wStr = trim_right(wStr); return (char*)wStr.c_str(); } // TTB Back to top ajim Guest Posted: Tue Feb 12, 2013 9:45 am    Post subject: Re: Assignment help please!!! Assignment making and homework in academic life has gotten out of hand. So it is not easy for us to prepare the assignment without the help of the experts. Acropolismentors provide us that help to the students of every stream, at the higher level. Back to top red floyd Guest Posted: Tue Feb 12, 2013 6:22 pm    Post subject: Re: Assignment help please!!! On 2/12/2013 1:45 AM, ajim wrote: Quote: Assignment making and homework in academic life has gotten out of hand. So it is not easy for us to prepare the assignment without the help of the experts. Acropolismentors provide us that help to the students of every stream, at the higher level. FAQ 5.2 http://www.parashift.com/c++-faq-lite/dont-ask-hw-probs.html Back to top ephlodur Guest Posted: Sun Mar 03, 2013 4:10 pm    Post subject: Re: memory leak On Fri, 01 Mar 2013 12:34:19 +0000, Jorgen Grahn wrote: I'm not sure I understand your comment below Quote: (They will also tell you you shouldn't uselessly call operator new, and rely on constructors instead of manual initialization some time after the object was created.) Back to top Jorgen Grahn Guest Posted: Sun Mar 03, 2013 7:48 pm    Post subject: Re: memory leak On Sun, 2013-03-03, ephlodur wrote: Quote: On Fri, 01 Mar 2013 12:34:19 +0000, Jorgen Grahn wrote: I'm not sure I understand your comment below Your code upthread (in comp.unix.programmer; I hope you noticed the followup-to) was Quote: struct MyData { std::string msg; int level; }; int main( void ) { MyData * _m = new MyData; _m->msg = "hello"; _m->level = 0; delete _m; } (They will also tell you you shouldn't uselessly call operator new, The 'new' above wasn't needed. You could have just said MyData m; m.msg = "hello"; m.level = 0; Perhaps it was needed because of your question about memory leaks, but it's a common mistake for Java programmers to abuse C++ new exactly like this, so it was worth mentioning. Quote: and rely on constructors instead of manual initialization some time after the object was created.) Perhaps it's better if you explain /what/ you don't understand first. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . Back to top Guest Posted: Sun Mar 03, 2013 9:38 pm    Post subject: Re: memory leak On Thursday, February 28, 2013 5:59:35 PM UTC-7, ephlodur wrote: Quote: hello all, I'm wondering is there memory leak is the below situation struct MyData { std::string msg; int level; }; int main( void ) { MyData * _m = new MyData; _m->msg = "hello"; _m->level = 0; delete _m; } If std::string's assignment operator throws above you will leak memory as you will never reach delete _m. In this case, if std::string::operator= throws your program will terminate and the operating system will clean up your mess (note that it probably won't here due to short string optimizations – but that's implementation specific). Follow Jorgen's suggestion if possible or use std::unique pointer if you really wanted to dynamically allocate the object: MyData _m {“hello”, 0}; MyData _m = {“hello”, 0}; std::unique_ptr <MyData> _m {new MyData {“hello”, 0}}; Back to top ajim Guest Posted: Thu Mar 21, 2013 11:34 am    Post subject: Re: Assignment help please!!! Hey friends we don't know what you want in your assignment, and its not easy to describe i know. so you should contact with the person who can teach you by face. One more option is there to choose go with online service, acropolismentors can help you. Back to top        C++Talk.NET Forum Index -> C++ language (comp.lang.c++) All times are GMT Goto page Previous  1, 2, 3 ... 17, 18, 19 Page 19 of 19 Powered by phpBB © 2001, 2006 phpBB Group