| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 15 02:07AM +0100 Hi! TV advertisement for my upcoming C++ GUI/game library "neoGFX": https://www.youtube.com/watch?v=IXvKOwQ4mvY&feature=youtu.be That concludes this announcement. /Flibble |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 15 04:16AM +0200 On 10/15/2017 3:07 AM, Mr Flibble wrote: > https://www.youtube.com/watch?v=IXvKOwQ4mvY&feature=youtu.be > That concludes this announcement. > /Flibble Nice presenter. Short & 2 the point, just name recognition. Your wife? Cheers!, - Alf |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 15 03:22AM +0100 On 15/10/2017 03:16, Alf P. Steinbach wrote: >> That concludes this announcement. >> /Flibble > Nice presenter. Short & 2 the point, just name recognition. Your wife? My wife? What a bizarre question. O_o /Flibble |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Oct 14 10:52PM -0700 On 10/14/2017 6:07 PM, Mr Flibble wrote: > TV advertisement for my upcoming C++ GUI/game library "neoGFX": > https://www.youtube.com/watch?v=IXvKOwQ4mvY&feature=youtu.be > That concludes this announcement. Imvho, you are a very nice coder. Very good that neoGFX is rising. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 15 10:38PM +0100 On 15/10/2017 06:52, Chris M. Thomasson wrote: >> https://www.youtube.com/watch?v=IXvKOwQ4mvY&feature=youtu.be >> That concludes this announcement. > Imvho, you are a very nice coder. Very good that neoGFX is rising. Thanks! :D /Flibble |
| fl <rxjwg98@gmail.com>: Oct 15 02:04PM -0700 Hi, I read the below code snippet on-line: '''''''''''''''''''' #include <gr_sync_block.h> class my_block_cc; typedef boost::shared_ptr<6829_my_block_cc> 6829_my_block_cc_sptr; 6829_my_block_cc_sptr 6829_make_my_block_cc(); class my_block_cc : public gr_sync_block { private: unsigned int d_count; friend 6829_my_block_cc_sptr 6829_make_my_block_cc(); 6829_my_block_cc(); public: int work(int noutput_items, gr_vector_const_void_star &input_items, gr_vector_void_star &output_items); //////////////// It is found line 3 has below in the container(Is this correctly called?): "6829_my_block_cc" But I see this private function is declared in the last line of the private section. This puzzles me a lot, as I think it should like the second line to declare "my_block_cc" first, then it is defined. Could you help me on it? Regards, |
| "Öö Tiib" <ootiib@hot.ee>: Oct 14 05:44PM -0700 On Saturday, 14 October 2017 23:24:08 UTC+3, Vir Campestris wrote: > Yes. If the constructor is private to force use of a factory function > make_shared won't compile. (I tried and failed to work out the correct > friend statement, then gave up) What? Enforcing additional allocation and additional deallocation just to force use of factory function? In general such schemes feel like "I am schizophrenicly fighting with myself". If you insist then it is possible to turn public constructor into not callable by it having a pass-key parameter. That forces to use factory function (that can produce such parameter). One extra parameter of constructor is certainly cheaper than one extra alloction and deallocation. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 15 10:45AM +0300 On 15.10.2017 3:44, Öö Tiib wrote: > What? Enforcing additional allocation and additional deallocation > just to force use of factory function? In general such schemes feel > like "I am schizophrenicly fighting with myself". This thread is about smartpointers. If the object is not dynamically allocated, then there is no need for the smartpointer in the first place. And yes, there are programs where all objects of some class need to be dynamically allocated anyway. Allowing some casual automatic objects in the mix would just complicate things like shared_from_this(). Cheers Paavo |
| "Öö Tiib" <ootiib@hot.ee>: Oct 15 02:22AM -0700 On Sunday, 15 October 2017 10:45:21 UTC+3, Paavo Helde wrote: > > like "I am schizophrenicly fighting with myself". > This thread is about smartpointers. If the object is not dynamically > allocated, then there is no need for the smartpointer in the first place. Here is either something I was expressing badly or reading comprehension issue. I have whole current thread discussed objects managed by smart pointer, specifically by shared_ptr. > And yes, there are programs where all objects of some class need to be > dynamically allocated anyway. Allowing some casual automatic objects in > the mix would just complicate things like shared_from_this(). That is mostly so but I had impression that we did not discuss it yet. Seems that I expressed myself not clearly enough. I was not talking about dynamic/automatic allocation of object with "additional allocation". I was talking about class that was deliberately made in a way where make_shared does not work (all the constructors were made private). The excuse making class in that way was forcing usage of factory function that was likely made for forcing usage of shared_ptr. Therefore separate dynamic allocation for shared state (that I meant by "additional allocation") was made for each object within that factory function by constructor of shared_ptr. How else? The make_shared does not compile. That is insane example for me but YMMV. Now coming back to what we haven't discussed yet. I agree with you that typically we want objects of class to be managed in single fashion to simplify things. There can also be a case where that "single fashion" is shared_ptr. It makes perfect sense to have factory function for it. The whole enable_shared_from_this however is complicated performance optimization for that case. Apparently author wants to pass around references to object instead of shared_ptr as performance optimization. Apparently author needs at the other end of such reference-passing-chain still have the shared_ptr as complication. Therefore complicated performance optimization. Usage of that means like author is not entirely happy about performance. Where programmer is unhappy about performance there flexibility may help and there may be desire to relax that "single fashion". Note that I am not saying that I know what helps just that it may. More efficient smart pointer or some casual automatic object may help in tightest spot. So it is only good if calling shared_from_this() of such objects is not undefined behavior anymore in C++17. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Oct 15 02:12PM +0200 On 13.10.17 22.37, Vir Campestris wrote: > If the STL is smart enough to detect the first case why doesn't it give > an error in the second? > I know a codebase where it would have saved lots of problems :( If you have a code base that has problems with memory management, search the code for /all/ occurrences of raw pointers, preferably the ones w/o const, and remove them. Most code bases where I have done so never had problems with undefined behavior again. Only NULL references remain, but they are usually easy to fix. If you do not want to go this far, switch to intrusive pointers. When the ref count is part of the object, you can safely convert to a raw pointer and back to an intrusive_ptr. I usually add a base class to all objects that should be reference countable. This class provides the ref count and it is the common interface to the intrusive_ptr methods. If you missed one, the compiler will tell you. This method is also faster than shared_ptr. I cannot understand why shared_ptr is recommended everywhere. In fact I never wrote any production application that used shared_ptr. Instead I usually avoid raw pointers (except for const char*) and additionally use intrusive reference counts. Marcel |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 15 04:54PM +0300 On 15.10.2017 12:22, Öö Tiib wrote: > were made private). The excuse making class in that way was forcing > usage of factory function that was likely made for forcing usage of > shared_ptr. I see. I indeed misread your post. > by "additional allocation") was made for each object within that > factory function by constructor of shared_ptr. How else? The > make_shared does not compile. By making the constructor public of course so that make_shared starts to compile. This is what I did in the same situation, so I assumed Vir did the same (but maybe I'm mistaken). Cheers Paavo |
| "Öö Tiib" <ootiib@hot.ee>: Oct 15 07:31AM -0700 On Sunday, 15 October 2017 16:55:20 UTC+3, Paavo Helde wrote: > By making the constructor public of course so that make_shared starts to > compile. This is what I did in the same situation, so I assumed Vir did > the same (but maybe I'm mistaken). Vir brought that as "sane counter example" where make_shared can't be used (and so constructing from raw pointer has to be used) if I understood him correctly. For me making the make_shared impossible to be called for forcing usage of shared_ptr is no way sane and so my answer might be was too emotional. I suggested to make it public and mentioned that there are ways (if he really needs) to make public constructor tricky to call, but that part you snipped. |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 15 05:38PM +0300 On 15.10.2017 15:12, Marcel Mueller wrote: > If you do not want to go this far, switch to intrusive pointers. When > the ref count is part of the object, you can safely convert to a raw > pointer and back to an intrusive_ptr. Only as long as you don't need weak pointers, and as long as you carefully avoid doing this during construction and destruction. > interface to the intrusive_ptr methods. If you missed one, the compiler > will tell you. > This method is also faster than shared_ptr. Only if you don't use std::make_shared() or std::allocate_shared (like you should). > never wrote any production application that used shared_ptr. Instead I > usually avoid raw pointers (except for const char*) and additionally use > intrusive reference counts. Because the people needing such recommendations are newbies, and newbies tend to mess up their raw pointers and cannot be trusted to write their own smartpointer classes either (especially if thread safety or weak pointers are involved). I agree there could be a lightweight performance-oriented smartpointer class in the standard (intrusive refcount, no thread safety, no weak pointers, etc), but regarding the recommendations this would not help much because the newbies would not know if their code can use it or not. Cheers Paavo |
| Vir Campestris <vir.campestris@invalid.invalid>: Oct 15 09:17PM +0100 On 15/10/2017 13:12, Marcel Mueller wrote: > const, and remove them. Most code bases where I have done so never had > problems with undefined behavior again. Only NULL references remain, but > they are usually easy to fix. I'm 6 weeks into a new job, and there are 782 occurrences of the string "_ptr(this)". I've fixed the one class where I could prove it was causing problems. (now all are weak_ptr, shared_ptr, or reference) The rest will have to wait. Andy |
| woodbrian77@gmail.com: Oct 14 08:41PM -0700 On Monday, October 9, 2017 at 10:57:18 AM UTC-5, Richard wrote: > he'd rather add one thing that results in user libraries that can be > tested, developed and shipped without further modification to the > standard. 'interface' is the big one that wins. Other than C++ 2011, there's not a lot to cheer about. Too many cooks spoil the soup. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| 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