Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #3606
| Date | 2011-04-13 14:49 -0700 |
|---|---|
| From | Phil Bouchard <phil@fornux.com> |
| Newsgroups | comp.lang.c++ |
| Subject | Re: To standardize Boost.Pool |
| References | (1 earlier) <slrniq9ik7.gtj.grahn+nntp@frailea.sa.invalid> <4da4eede@news.x-privat.org> <4da54bdd$1@news.x-privat.org> <5497ee99-8d91-4412-8995-6e1ea58ded81@32g2000vbe.googlegroups.com> <4da5d23b@news.x-privat.org> |
| Message-ID | <4da61a7b$1@news.x-privat.org> (permalink) |
| Organization | X-Privat.Org NNTP Server - http://www.x-privat.org |
On 4/13/2011 9:41 AM, Phil Bouchard wrote:
> On 4/13/2011 8:28 AM, Öö Tiib wrote:
>>
>> Please elaborate what is process::stack? On most platforms a process
>> may have several threads, number of these threads often changes
>> dynamically during processes lifetime and each of these threads does
>> have its own stack.
>
> process::stack represents the memory pages reserved for the stack of the
> current thread quite simply. The details of the implementation would
> have to be hidden from the programmer so that all that he is exposed to
> are member functions such as malloc(size_t), free(void *), if_from(void
> *), etc. Note that the malloc(size_t) call would be available only for
> the heap memory pool and so on.
There was a discussion on the validity of a 'false' statement returned
by is_from() because out-of-bounds pointer comparison would invoke
undefined behavior according to 5.7.6. This was bringing the idea of
having adjacent pools stack & data to the heap pool.
But it looks like heap.is_from() could work without adjacent stack and
data pools in all cases, even if the pointers are arbitrary. This is
because they can be casted to an integral type before they are compared
together as stated by 5.2.10/4. The following example is thus valid for
arbitrary pointers:
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));
}
Thanks,
-Phil
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
To standardize Boost.Pool Phil Bouchard <phil@fornux.com> - 2011-04-12 07:44 -0600
Re: To standardize Boost.Pool Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-04-12 21:56 +0000
Re: To standardize Boost.Pool Phil Bouchard <phil@fornux.com> - 2011-04-12 17:31 -0700
Re: To standardize Boost.Pool Phil Bouchard <phil@fornux.com> - 2011-04-13 00:08 -0700
Re: To standardize Boost.Pool Öö Tiib <ootiib@hot.ee> - 2011-04-13 08:28 -0700
Re: To standardize Boost.Pool Phil Bouchard <phil@fornux.com> - 2011-04-13 09:41 -0700
Re: To standardize Boost.Pool Phil Bouchard <phil@fornux.com> - 2011-04-13 14:49 -0700
Re: To standardize Boost.Pool Phil Bouchard <phil@fornux.com> - 2011-04-13 15:57 -0700
Re: To standardize Boost.Pool Paavo Helde <myfirstname@osa.pri.ee> - 2011-04-13 23:39 -0500
Re: To standardize Boost.Pool Phil Bouchard <phil@fornux.com> - 2011-04-13 22:43 -0700
Re: To standardize Boost.Pool Phil Bouchard <phil@fornux.com> - 2011-04-13 22:53 -0700
Re: To standardize Boost.Pool Miles Bader <miles@gnu.org> - 2011-04-14 15:55 +0900
Re: To standardize Boost.Pool Phil Bouchard <phil@fornux.com> - 2011-04-14 00:15 -0700
csiph-web