- "In defense of printf" - 2 Updates
- why not use naked delete ? - 5 Updates
- std::thread...too little, too late? - 1 Update
| Lynn McGuire <lmc@winsim.com>: Dec 26 03:42PM -0600 On 12/20/2014 6:03 AM, Jouko Koski wrote: >> return buffer; >> } > Well, MSVC might not be 100 % conforming to the standard... Visual C++ 2005 (my version) uses _snprintf. Lynn |
| Paavo Helde <myfirstname@osa.pri.ee>: Dec 26 05:02PM -0600 >>> } >> Well, MSVC might not be 100 % conforming to the standard... > Visual C++ 2005 (my version) uses _snprintf. More troublesome is the fact that the return values of MSVC _snprintf and standard snprintf differ in the case of too small buffer (one returning a negative number and the other a positive one). |
| arnuld <sunrise@invalid.address>: Dec 26 10:58AM After 5 years of working purely in C, finally I becawe jobless and have some time on my hands to start C++. Well, I kept on peeking into stroustrup from time to time but now I see with C++14 everything has changed. Even in C++, I will allocate memory using /new/ and then free it using /delete/ but now I see Stroustrup does not seem to agree to that: http://isocpp.org/blog/2014/12/myths-2 He is calling it naked delete. I know there lot of other examples he has given but those are using generic/oo programming(half of that code is incomprehensible to me because IU just started C++ today). I am more concerned with simple procedural subset of C++: X* p = new X; X* q = p; delete p; // ... q->do_something(); // the memory that held *p may have been re-used STROUSTRUP: Don't do that. Naked deletes are dangerous ARNULD: then what I should do ? Can someone point me to some direction in understanding this ? -- arnuld http://lispmachine.wordpress.com/ |
| Dombo <dombo@disposable.invalid>: Dec 26 12:29PM +0100 Op 26-Dec-14 11:58, arnuld schreef: > STROUSTRUP: Don't do that. Naked deletes are dangerous > ARNULD: then what I should do ? > Can someone point me to some direction in understanding this ? Look for the RAII (Resource Acquisition Is Initialization) idiom which every C++ programmer should be very familiar with. Examples of RAII are the smart pointer classes std::unique_ptr and std::shared_ptr which automatically take care of delete at the right time so you don't have to. The problem with "naked" delete is that it is very easy to leak memory, especially when you use exceptions. The RAII idiom and smart pointers makes it much easier to write clean and robust code that doesn't leak resources. Also when you use container classes like std::vector smart pointers make life a lot easier. |
| Bo Persson <bop@gmb.dk>: Dec 26 01:11PM +0100 On 2014-12-26 11:58, arnuld wrote: > STROUSTRUP: Don't do that. Naked deletes are dangerous > ARNULD: then what I should do ? > Can someone point me to some direction in understanding this ? Another part of the advice is not to use naked pointers either. :-) Stroustrup shows how to use a unique_ptr when you need a single pointer to an object. There is also a shared_ptr for when you want to share ownership of the object. In both cases, the object is automagically deleted when the last pointer goes away. You could do: auto p = std::make_shared<X>(); auto q = p; // do something that invalidates p q->do_something(); // q is still valid here Bo Persson |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 26 09:00PM On Fri, 2014-12-26, arnuld wrote: > given but those are using generic/oo programming(half of that code is > incomprehensible to me because IU just started C++ today). I am more > concerned with simple procedural subset of C++: If you ignore classes in C++, then you'll have problems. Try instead to ignore your C knowledge and follow the book (I get the impression you own "The C++ Programming Language"). > q->do_something(); // the memory that held *p may have been re-used > STROUSTRUP: Don???t do that. Naked deletes are dangerous > ARNULD: then what I should do ? But /in the very next sentence/ he explains it! You just have to read for five seconds more: Don't do that. Naked deletes are dangerous - and unnecessary in general/user code. Leave deletes inside resource management classes, such as string, ostream, thread, unique_ptr, and shared_ptr. There, deletes are carefully matched with news and harmless. Personally I find that 99% of my resource management is done without any pointers or smart pointers. If I have some object 'foo' it's either: - allocated "on the stack" (or whatever the proper term is) - a member of some bigger object - an element of some container e.g. a std::vector No doubt people need new/delete and smart pointers from time to time, and some people need it frequently -- but you can do /a lot/ of programming without having to care about such things. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Mr Flibble <flibble@i42.co.uk>: Dec 26 09:44PM On 26/12/2014 21:00, Jorgen Grahn wrote: > - allocated "on the stack" (or whatever the proper term is) I believe the phrase "on the stack" appears in the ISO C++ standard so I wouldn't worry about using it; if it didn't appear in the ISO C++ standard I still wouldn't worry about using it. /Flibble |
| "Öö Tiib" <ootiib@hot.ee>: Dec 25 09:39PM -0800 On Thursday, December 25, 2014 11:34:54 PM UTC+2, Melzzzzz wrote: > > lament about. > Main reason for using threads is startup time. Other reason is > that not all systems overcommit memory. I am not against using threads. I was arguing against generic claim of Leigh that multithreading is superior solution than multiprocessing. Neither is generally superior. Each has usages. Existence of systems without feature (for example floating point hardware) can not be good excuse to avoid the feature (for example floating point arithmetic) on general. > > 2) Multithreading does waste lot of time to synchronize access > > to shared data, processes do not share data. > Second main reason to use threads is simpler IPC. However when there are no IPC needed? For example your program tries to open a file but discovers that it is for some older version. It can spawn a process that converts it since all that it needs is file of current version. No IPC is needed. Does it scale better if it instead keeps all the code for converting old files in memory just for such rare case? > If there are no memory leaks I can't see why is this problem > with threads? In C++, just throwing exception is usually enough > to exit from thread... What memory leaks? The program reached a point where the work is done. However by our typical good design nothing will leak. Everything is managed by RAII. So thread has nothing like 'std::quick_exit' that frees all the resources it acquired for doing the work at once. Instead it will run all the destructors recursively and deallocate every tiny 'std::string' it has separately. It may be considerably less efficient. > Only thing that is bad for threads and goes in favor of processes > is memory fragmentation and therefore steady growth of memory usage. All > long running threaded programs have that problem. No, not all at all. :D My point was that there are no generic silver bullets "that are always best and period". |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment