Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c++ > #99 > unrolled thread

To standardize Boost.Pool

Back to article view | Back to comp.std.c++

Contents

  To standardize Boost.Pool  Phil Bouchard <phil@fornux.com> - 2011-04-12 13:10 -0600
    Re: To standardize Boost.Pool Phil Bouchard<phil@fornux.com> - 2011-04-14 13:10 -0600
      Re: To standardize Boost.Pool  Phil Bouchard <phil@fornux.com> - 2011-04-14 17:18 -0600
        Re: To standardize Boost.Pool  "Bo Persson" <bop@gmb.dk> - 2011-04-17 01:33 -0600

#99 — To standardize Boost.Pool

Boost.Pool provides an is_from() member function that does a simple range
checks of the heap memory pages and returns whether a pointer is part of the
pool or not.  This is a very useful function which I think should be part of
the standards because it could be used for the global pool as well; i.e. the
one used by operator ::new and ::delete.  The benefits for memory management
of knowing whether an object resides on the heap or stack outweigh the costs
of having to pollute the global namespace.


Thanks,
-Phil


-- 
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[toc] | [next] | [standalone]

#103

On 4/12/2011 12:10 PM, Phil Bouchard wrote:
>
>  Boost.Pool provides an is_from() member function that does a simple range
>  checks of the heap memory pages and returns whether a pointer is part of
>  the
>  pool or not. This is a very useful function which I think should be part of
>  the standards because it could be used for the global pool as well; i.e.
>  the
>  one used by operator ::new and ::delete. The benefits for memory management
>  of knowing whether an object resides on the heap or stack outweigh the
>  costs
>  of having to pollute the global namespace.

is_from() actually invokes undefined behavior if its parameter is a
pointer referring to an element outside of the pool according to 5.7.6.
  If the pointer was to be casted to the largest integer type available
on the system then a range check would be valid for that system.  For
example:

bool is_from(const char* p)
{
   return reinterpret_cast<long>(buffer)<= reinterpret_cast<long>(p)&&
reinterpret_cast<long>(p)<  reinterpret_cast<long>(buffer + sizeof(buffer));
}

It's "implementation defined" but perhaps a reinterpret_cast of a
pointer to a long integer could be guaranteed to be valid by the
standards, long being the greatest integer available on a system.

Because otherwise the current implementation of is_from would then be
useless if a false statement invokes undefined behavior.  The current
implementation of is_from can be found here:
http://www.boost.org/doc/libs/1_46_1/boost/pool/pool.hpp

is_from and a heap pool are frequent utilities used by memory managers
such a garbage collectors and Shifted Pointer.  An overview of Shifted
Pointer can be found at:
http://www.fornux.com/personal/philippe/devel/shifted_ptr/libs/smart_ptr/doc/overview.html


Regards,
-Phil


-- 
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[toc] | [prev] | [next] | [standalone]

#105

On 4/14/2011 12:10 PM, Phil Bouchard wrote:

>
> is_from() actually invokes undefined behavior if its parameter is a
> pointer referring to an element outside of the pool according to 5.7.6.
> If the pointer was to be casted to the largest integer type available
> on the system then a range check would be valid for that system. For
> example:
>
> bool is_from(const char* p)
> {
> return reinterpret_cast<long>(buffer)<= reinterpret_cast<long>(p)&&
> reinterpret_cast<long>(p)< reinterpret_cast<long>(buffer + sizeof(buffer));
> }
>
> It's "implementation defined" but perhaps a reinterpret_cast of a
> pointer to a long integer could be guaranteed to be valid by the
> standards, long being the greatest integer available on a system.
>

It turns out the C standard defines intptr_t to be the same size as a
pointer (7.18.1.4).  The following would consequently be perfectly portable:

bool is_from(const char* p)
{
   return reinterpret_cast<intptr_t>(buffer)<=
reinterpret_cast<intptr_t>(p)&&
reinterpret_cast<intptr_t>(p)< reinterpret_cast<intptr_t>(buffer +
sizeof(buffer));
}


Regards,
-Phil


-- 
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[toc] | [prev] | [next] | [standalone]

#108

Phil Bouchard wrote:
> On 4/14/2011 12:10 PM, Phil Bouchard wrote:
>
>>
>> is_from() actually invokes undefined behavior if its parameter is a
>> pointer referring to an element outside of the pool according to
>> 5.7.6. If the pointer was to be casted to the largest integer type
>> available on the system then a range check would be valid for that
>> system.
>> For example:
>>
>> bool is_from(const char* p)
>> {
>> return reinterpret_cast<long>(buffer)<= reinterpret_cast<long>(p)&&
>> reinterpret_cast<long>(p)< reinterpret_cast<long>(buffer +
>> sizeof(buffer)); }
>>
>> It's "implementation defined" but perhaps a reinterpret_cast of a
>> pointer to a long integer could be guaranteed to be valid by the
>> standards, long being the greatest integer available on a system.
>>
>
> It turns out the C standard defines intptr_t to be the same size as
> a pointer (7.18.1.4).  The following would consequently be
> perfectly portable:
> bool is_from(const char* p)
> {
>   return reinterpret_cast<intptr_t>(buffer)<=
> reinterpret_cast<intptr_t>(p)&&
> reinterpret_cast<intptr_t>(p)< reinterpret_cast<intptr_t>(buffer +
> sizeof(buffer));
> }
>
>

For some definition of "perfectly", yes.

The typedef is optional, because there is no requirement for an
implementation to actually have an integer type wide enough to hold a
pointer.


Bo Persson



--
[ comp.std.c++ is moderated.  To submit articles, try posting with your ]
[ newsreader.  If that fails, use mailto:std-cpp-submit@vandevoorde.com ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c++

csiph-web