Re: [Boost-users] nondynamic: A utility class that promotes safe programming
Ovanes wrote: [snip]
What do you think how this allocator will allocate the number of these element? Actually in any possible way. It can use new[] or new char[sizeof(T)*NumElems] or use an own mem-manager. And the worse thing you can't make allocator friend of your class, since users of containers can pass their own allocators. And despite all enumerated facts you will fail to compile, since the function address will fail to return the pointer to x, because it is prohibited in your case.
Yes, well boost::noncopyable also prohibits something :-) The whole intent of nondynamic is to prohibit (or make difficult) dynamic allocation/pointer usage. Do you think boost::noncopyable has a valid purpose, but nondynamic is less useful? -- Daniel
There are other classes that can't be used in containers such as scoped_ptr so there is precedent - stl containers aren't the be all and end all of software design.
Yes, well boost::noncopyable also prohibits something :-) The whole intent of nondynamic is to prohibit (or make difficult) dynamic allocation/pointer usage. Do you think boost::noncopyable has a valid purpose, but nondynamic is less useful?
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ****************************************************************************** "This message and any attachments are solely for the intended recipient and may contain confidential and privileged information. If you are not the intended recipient, any disclosure, copying, use, or distribution of the information included in this message and any attachments is prohibited. If you have received this communication in error, please notify us by reply e-mail and immediately and permanently delete this message and any attachments. Thank you." Interactive Transaction Solutions Ltd (2473364 England) Registered Office: Systems House, Station Approach Emsworth PO10 7PW ********************************************************************** Ce message �lectronique contient des informations confidentielles � l'usage unique des destinataires indiqu�s, personnes physiques ou morales. Si vous n'�tes pas le destinataire voulu, toute divulgation, copie, ou diffusion ou toute autre utilisation de ces informations, est interdite. Si vous avez re�u ce message �lectronique par erreur, nous vous remercions d'en avertir son exp�diteur imm�diatement par email et de d�truire ce message ainsi que les �l�ments attach�s. Interactive transaction Solutions SAS- France (RCS Pontoise : 489 397 877) Si�ge social : Parc Saint Christophe, 10, Avenue de l�Entreprise 95865 Cergy-Pontoise Cedex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On Fri, Mar 28, 2008 at 1:59 PM, Patrick Loney < Patrick.Loney@interactivets.com> wrote:
There are other classes that can't be used in containers such as scoped_ptr so there is precedent - stl containers aren't the be all and end all of software design.
Yes, well boost::noncopyable also prohibits something :-) The whole intent of nondynamic is to prohibit (or make difficult) dynamic allocation/pointer usage. Do you think boost::noncopyable has a valid purpose, but nondynamic is less useful?
All applications of noncopyable are clearly defined in my opinion. In case of nondynamic it is not so. If I declare a class as nondynamic I still probably can assume that it is locally copyable. Isn't is so? So this construct should be valid: { //local scope std::vector<some_nondynamic> local_collection; local_collection.push_back(some_nondynamic(params_here)); // BOOM! Compiler error! new[] is not accessible or address is not accessible. ... } Do you see the problem here? Any user who deals with nondynamic must be aware of the internal structure of some third-party class involved wheather it will try to allocate storage for this class to copy it more efficiently. So in other words, you would state: I allow you to copy, but it depends how you do that... Where in noncopyable you state: I disallow any copies. IMO nondynamic will involve a whole bunche of exceptional rules when it can be used or not, where from the point of view of an automatic variable this should be valid or possible. So you break somehow natural semantics. Best Regards, Ovanes
AMDG Daniel Lidström wrote:
Ovanes wrote:
Yes, well boost::noncopyable also prohibits something :-) The whole intent of nondynamic is to prohibit (or make difficult) dynamic allocation/pointer usage. Do you think boost::noncopyable has a valid purpose, but nondynamic is less useful?
Yes. Copying objects is part of the interface of T. There are some classes for which copying does not make sense. Where T's are created is the business of users. The only even conceivable use case I see is RAII wrappers. I still don't think that it's very useful to prohibit creation on the heap, because unlike copies, C++ doesn't automatically call new for you, on the drop of a hat. In addition, trying to allocate an RAII object on the heap will not generally cause a program to go down in flames the way copying a noncopyable object can. In Christ, Steven Watanabe
participants (2)
-
Daniel Lidström -
Ovanes Markarian -
Patrick Loney -
Steven Watanabe