- why not use naked delete ? - 6 Updates
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 31 12:24AM On Tue, 30 Dec 2014 04:10:52 +0100 > > constrained in the Win32 environment. > std::unique_ptr has been designed so that it can take the same size > as a pointer by default, isn't this the case for Win32? Has it? Every object of class type must have a size of at least one. §20.7.1.2.4/7 of the C++11 standard suggests that an object of the deleter's type is stored as a class member rather than constructed on the fly when it is called (get_deleter() returns "a reference to the stored deleter"). This means that a std::unique_ptr object has a size comprising the size of a pointer + 1, assuming the deleter is a functor class without data members, as would usually be the case (it is also permitted by the standard be a function pointer, or more correctly an lvalue reference to function, which would normally have a larger size). Of course, returning a reference to the deleter means that the standard might as well have made it a public member, but that is a separate issue. Chris |
| legalize+jeeves@mail.xmission.com (Richard): Dec 31 12:28AM [Please do not mail me a copy of your followup] Lynn McGuire <lmc@winsim.com> spake the secret code >We run out of Win32 space if we are not careful. Probably heap space >since some of our datasets go over one GB. Things are better >not though since we started compressing strings in memory. Very large datasets are almost certainly going to be allocated on the heap and yeah, 32-bit Windows programs have the weird 2 GB/4 GB process space limitations that have haunted games for some time. >> Why naked new and not std::unique_ptr<> or some sort of container? >This code was written over a decade ago and works well. Never rewrite >code that is working well just to use new coding features. OK, but presumably for new code you are using std::unique_ptr? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 31 12:35AM On Wed, 31 Dec 2014 00:24:35 +0000 > Of course, returning a reference to the deleter means that the > standard might as well have made it a public member, but that is a > separate issue. Having said that, on testing I see that std::unique_ptr on my implementation has the size of a pointer. On looking at the implementation, instead of having separate pointer and deleter data members, it has a tuple member comprising the pointer and the deleter, so eliminating the need to give the deleter a size of 1 because tuples are implemented by recursive inheritance. Quite clever. Chris |
| "Öö Tiib" <ootiib@hot.ee>: Dec 30 07:04PM -0800 On Wednesday, December 31, 2014 1:10:18 AM UTC+2, Lynn McGuire wrote: > > intriguing because writing naked 'new' and 'delete' in modern C++ > > adds complexities (and so defects) but does not save resources. > So how would you implement this class without using new? Here is the class and constructor using a reference value: I do not know the purpose of it. So I can't tell for sure what I would do. Feels it has a lot of members so possibly I would consider splitting it up or reducing members somehow. I will comment below: > vector <int> * intArrayValue; > vector <double> * doubleArrayValue; > vector <string> * stringArrayValue; Above part of it seems to be a variant. If it is so then instead I would use some existing implementation of variant. For example boost::variant: typedef boost::variant< nullptr_t, int, double, std::string, std::vector<int>, std::vector<double>, std::vector<std::string> > ValueVariant; ValueVariant variantValue; Its copy-construction is default. The 'datatype' can be changed to function '{return variantValue.which();}'. The 'vectorFlag' can be changed to function '{return datatype() > 3;}''. > unsigned char * compressedData; > unsigned long compressedDataLength; Why not vector instead of above? Like: std::vector<unsigned char> compressedData; Its copy-construction is default. > vector <unsigned long> uncompressedStringLengths; > std::string * uncompressedString; Why above is pointer? I would replace it with just 'std::string': std::string uncompressedString; That would also copy by default. As are rest of the members. > // constructor > DesValue (); > DesValue (const DesValue & rhs); Above copy constructor could be just defaulted if to do like I suggested above since compiler-generated is as good: DesValue (const DesValue & rhs) = default; > DesValue & operator = (const DesValue & rhs); > // destructor > virtual ~DesValue (); Likely copy assignment and destructor and move constructor and move assignment as well. > virtual DesValue * clone () { return new DesValue ( * this); } Yes, that has to remain if you need virtual clone with covariance because there are no covariance between 'std::unique_ptr<base>' and 'std::unique_ptr<derived>'. > ... > } Looks quite big snip: |
| woodbrian77@gmail.com: Dec 30 11:01PM -0800 On Tuesday, December 30, 2014 6:28:57 PM UTC-6, Richard wrote: > >This code was written over a decade ago and works well. Never rewrite > >code that is working well just to use new coding features. > OK, but presumably for new code you are using std::unique_ptr? Sometimes I use unique_ptr but other times new and delete in new code. I think it's good to keep your options open. Brian Ebenezer Enterprises - http://webEbenezer.net Brian Ebenezer Enterprises |
| "Öö Tiib" <ootiib@hot.ee>: Dec 30 11:40PM -0800 On Wednesday, December 31, 2014 2:35:58 AM UTC+2, Chris Vine wrote: > members, it has a tuple member comprising the pointer and the deleter, > so eliminating the need to give the deleter a size of 1 because tuples > are implemented by recursive inheritance. Quite clever. Yes, the deleter is like static member of class of 'unique_ptr'. The 'shared_ptr'/'weak_ptr' family is kind of heavyweight but since shared ownership is sort of rare optimization itself (lets share instead of making copies) it does not matter much in practice. |
| 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