A doubt in Boost Format
Hi, We are using Boost format in our project. We want to replace the normal allocator with a special allocator and we don't want any allocation be made with normal new. I was looking at the Boost fusion reference. format_class.hpp The class accepts a allocator and indeed uses it to instantiate the std::string inside. But there are two vectors inside - std::vector<format_item_t> items_; // each '%..' directive leads to a format_item std::vector<bool> bound_; // stores which arguments were bound. size() == 0 || num_args I am seeing that the vectors are not using the allocators. Is this the intended behavior? Is it right, to try to make an application not to use the normal new/delete completely? Thanks, Gokul.
Can someone please help me on this? We have a memory pool based approach and we want all the allocations to be redirected to the pool. But there are some std::vectors inside boost::format object. Can someone suggest me a way to deal with this? Thanks, Gokul. On Sat, Jun 11, 2011 at 1:55 PM, Gokulakannan Somasundaram < gokul007@gmail.com> wrote:
Hi, We are using Boost format in our project. We want to replace the normal allocator with a special allocator and we don't want any allocation be made with normal new. I was looking at the Boost fusion reference. format_class.hpp
The class accepts a allocator and indeed uses it to instantiate the std::string inside. But there are two vectors inside -
std::vector<format_item_t> items_; // each '%..' directive leads to a format_item
std::vector<bool> bound_; // stores which arguments were bound. size() == 0 || num_args
I am seeing that the vectors are not using the allocators. Is this the intended behavior? Is it right, to try to make an application not to use the normal new/delete completely?
Thanks, Gokul.
On Jun 14, 2011, at 10:57 AM, Gokulakannan Somasundaram wrote:
Can someone please help me on this? We have a memory pool based approach and we want all the allocations to be redirected to the pool. But there are some std::vectors inside boost::format object. Can someone suggest me a way to deal with this?
Why don't you override the global operator new? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Or if you know the element type of the vectors, override operator new of the element. Jiryih Tsaur ----- Original Message ----- From: Marshall Clow [mailto:mclow.lists@gmail.com] Sent: Tuesday, June 14, 2011 02:07 PM To: boost-users@lists.boost.org <boost-users@lists.boost.org> Subject: Re: [Boost-users] A doubt in Boost Format On Jun 14, 2011, at 10:57 AM, Gokulakannan Somasundaram wrote:
Can someone please help me on this? We have a memory pool based approach and we want all the allocations to be redirected to the pool. But there are some std::vectors inside boost::format object. Can someone suggest me a way to deal with this?
Why don't you override the global operator new? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users PLEASE READ: This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please delete it and all copies from your system, destroy any hard copies and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Nomura Holding America Inc., Nomura Securities International, Inc, and their respective subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state the views of such entity. Unless otherwise stated, any pricing information in this message is indicative only, is subject to change and does not constitute an offer to deal at any price quoted. Any reference to the terms of executed transactions should be treated as preliminary only and subject to our formal written confirmation.
Or if you know the element type of the vectors, override operator new of the
element.
Hmm.. i am really not getting you. The element types are format_item_t and bool, which are both under library. Even if i have the access to the elements, we are talking about the allocation done by the vector to store its contents, which is controlled by the vector's allocator. Thanks. Gokul.
Why don't you override the global operator new?
-- overriding the global operator new is generally a discouraged practice.
We have overridden new in the specific classes and passed it around as a policy class to be inherited. With Windows DLLs, i would need to do only static linking with global operator new override. Because of all these reasons, we are staying away from it. Thanks.
On Sat, Jun 11, 2011 at 1:55 AM, Gokulakannan Somasundaram <gokul007@gmail.com> wrote:
We are using Boost format in our project. We want to replace the normal allocator with a special allocator and we don't want any allocation be made with normal new. I was looking at the Boost fusion reference. format_class.hpp
The class accepts a allocator and indeed uses it to instantiate the std::string inside. But there are two vectors inside -
std::vector<format_item_t> items_; // each '%..' directive leads to a format_item std::vector<bool> bound_; // stores which arguments were bound. size() == 0 || num_args
I am seeing that the vectors are not using the allocators. Is this the intended behavior? Is it right, to try to make an application not to use the normal new/delete completely?
So you just want to pass the format instance's allocator through to the two std::vector instances? I don't claim any relevant expertise here, but it sounds reasonable to me. Have you tried it?
So you just want to pass the format instance's allocator through to the two std::vector instances? I don't claim any relevant expertise here, but it sounds reasonable to me. Have you tried it? _______________________________________________
I have tried it in similar classes. There shouldn't be any issue. Any class that will maintain private heap( like string, vector etc.. ) can pass on the control of memory allocation to the end user through the allocator arguments. The library might be even more flexible, if you take two allocators as template arguments - one for the string and one for the vector,(with default arguments, so it won't affect the current users ). But you can take a call on that. Please let me know, if you need any more inputs on the same. Thanks, Gokul.
participants (4)
-
Gokulakannan Somasundaram -
jiryih.tsaur＠nomura.com -
Marshall Clow -
Nat Linden