Q: address of operator new/delete

**Ron Natalie** · Jul 19 '05, 05:04 PM

Re: address of operator new/delete

"Jakob Bieling" <netsurf@gmy.ne t> wrote in message news:bj7lvb$31s $03$1@news.t-online.com...[color=blue]
> Hi,
>
> is it possible to get the address of operator new/delete and operator
> new[]/delete[] portably? Otherwise I would have to go for a non-portable and
> rather unclean solution.
>[/color]

#include <new>

using namespace std;

int main() {
void* (*ona)(size_t) = &operator new[];
}

**tom_usenet** · Jul 19 '05, 05:05 PM

Re: Q: address of operator new/delete

On Thu, 4 Sep 2003 17:33:18 +0200, "Jakob Bieling" <netsurf@gmy.ne t>
wrote:
[color=blue]
>Hi,
>
> is it possible to get the address of operator new/delete and operator
>new[]/delete[] portably? Otherwise I would have to go for a non-portable and
>rather unclean solution.[/color]

AFAIK, this is fine and portable:

#include <cstddef>
#include <new>

struct A
{
void* operator new(size_t)
{
throw std::bad_alloc( );
}
};

int main()
{
void* (*ptr1)(std::si ze_t) = ::operator new;
void* (*ptr2)(std::si ze_t) = &A::operator new;
}

Tom

**Jakob Bieling** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

"Ron Natalie" <ron@sensor.com > wrote in message
news:3f575ca6$0 $23242$9a6e19ea @news.newshosti ng.com...[color=blue]
>
> "Jakob Bieling" <netsurf@gmy.ne t> wrote in message[/color]
news:bj7lvb$31s $03$1@news.t-online.com...[color=blue][color=green]
> > Hi,
> >
> > is it possible to get the address of operator new/delete and[/color][/color]
operator[color=blue][color=green]
> > new[]/delete[] portably? Otherwise I would have to go for a non-portable[/color][/color]
and[color=blue][color=green]
> > rather unclean solution.
> >[/color]
>
> #include <new>
>
> using namespace std;
>
> int main() {
> void* (*ona)(size_t) = &operator new[];
> }[/color]

Oh I see. I tried to convert it to a void* directly and I prolly did not
know which overloaded operator's address I wanted. With a static_cast it
works now.

Thanks!
--
jb

(replace y with x if you want to reply by e-mail)

**Ron Natalie** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

"Jakob Bieling" <netsurf@gmy.ne t> wrote in message news:bj7n2s$m24 $02$1@news.t-online.com...
[color=blue]
> Oh I see. I tried to convert it to a void* directly and I prolly did not
> know which overloaded operator's address I wanted. With a static_cast it
> works now.[/color]

You can't convert it to void* portably at all. void* is only guaranteed to be
able to hold pointers to (data) objects. You need to use some sort of function
pointer (even if you must cast it) to hold a function pointer.

**Jakob Bieling** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

"Ron Natalie" <ron@sensor.com > wrote in message
news:3f5761e7$0 $23254$9a6e19ea @news.newshosti ng.com...[color=blue]
>
> "Jakob Bieling" <netsurf@gmy.ne t> wrote in message[/color]
news:bj7n2s$m24 $02$1@news.t-online.com...[color=blue]
>[color=green]
> > Oh I see. I tried to convert it to a void* directly and I prolly did[/color][/color]
not[color=blue][color=green]
> > know which overloaded operator's address I wanted. With a static_cast it
> > works now.[/color]
>
> You can't convert it to void* portably at all. void* is only guaranteed[/color]
to be[color=blue]
> able to hold pointers to (data) objects. You need to use some sort of[/color]
function[color=blue]
> pointer (even if you must cast it) to hold a function pointer.[/color]

Well, I was not going to cast it back for use. I just wanted to store
the address to be able to print it out and void* seemed somewhat
appropriate. What else would you suggest?

regards
--
jb

(replace y with x if you want to reply by e-mail)

**Jakob Bieling** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

"Jakob Bieling" <netsurf@gmy.ne t> wrote in message
news:bj7n2s$m24 $02$1@news.t-online.com...
[color=blue]
> I tried to convert it to a void* directly and I prolly did not
> know which overloaded operator's address I wanted.[/color]

Little typo there btw. I meant to say "[..] and it prolly did not know
which overloaded operator's address I wanted".
--
jb

(replace y with x if you want to reply by e-mail)

**tom_usenet** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

On Thu, 4 Sep 2003 18:27:32 +0200, "Jakob Bieling" <netsurf@gmy.ne t>
wrote:
[color=blue]
>"Ron Natalie" <ron@sensor.com > wrote in message
>news:3f5761e7$ 0$23254$9a6e19e a@news.newshost ing.com...[color=green]
>>
>> "Jakob Bieling" <netsurf@gmy.ne t> wrote in message[/color]
>news:bj7n2s$m2 4$02$1@news.t-online.com...[color=green]
>>[color=darkred]
>> > Oh I see. I tried to convert it to a void* directly and I prolly did[/color][/color]
>not[color=green][color=darkred]
>> > know which overloaded operator's address I wanted. With a static_cast it
>> > works now.[/color]
>>
>> You can't convert it to void* portably at all. void* is only guaranteed[/color]
>to be[color=green]
>> able to hold pointers to (data) objects. You need to use some sort of[/color]
>function[color=green]
>> pointer (even if you must cast it) to hold a function pointer.[/color]
>
>
> Well, I was not going to cast it back for use. I just wanted to store
>the address to be able to print it out and void* seemed somewhat
>appropriate. What else would you suggest?[/color]

It is legal to reinterpret_cas t to a sufficiently large integer type -
I'd recommend unsigned long.

Compilers are required to issue a diagnostic if you cast a function
pointer to an object pointer, although there is a defect report
exploring this issue:

http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#195

Tom

**Gianni Mariani** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

tom_usenet wrote:
[color=blue]
>
> It is legal to reinterpret_cas t to a sufficiently large integer type -
> I'd recommend unsigned long.[/color]

Do you think that ptr_diff_t is more appropriate than unsigned long ?

**Andrey Tarasevich** · Jul 19 '05, 05:05 PM

Re: Q: address of operator new/delete

Jakob Bieling wrote:[color=blue]
> ...
> is it possible to get the address of operator new/delete and operator
> new[]/delete[] portably? Otherwise I would have to go for a non-portable and
> rather unclean solution.
> ...[/color]

It is possible, as others already stated. But keep in mind that the
functionality of functions 'operator new/delete' contains only a portion
of functionality of a new/delete expression (for class types with
non-trivial construction and destruction at least). If you want to
create a pointer to something that would reproduce the complete
functionality of new/delete expression, you'll have to write a dedicated
wrapper function (or use a library that provides one).

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

**Ron Natalie** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

"Jakob Bieling" <netsurf@gmy.ne t> wrote in message news:bj7p50$2sb $07$1@news.t-online.com...
[color=blue]
>
> Well, I was not going to cast it back for use. I just wanted to store
> the address to be able to print it out and void* seemed somewhat
> appropriate. What else would you suggest?[/color]

There's no guarantee it will fit. I'd just use the void * (*)() type I
suggested before and cast it to a large integer and hope that's good
enough.

**Ron Natalie** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

"Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message news:bj7sfc$o6i @dispatch.conce ntric.net...[color=blue]
> tom_usenet wrote:
>[color=green]
> >
> > It is legal to reinterpret_cas t to a sufficiently large integer type -
> > I'd recommend unsigned long.[/color]
>
> Do you think that ptr_diff_t is more appropriate than unsigned long ?
>[/color]
ptr_diff_t isn't necessarily the right answer. All that has to be is big
enough to hold the difference in offsets in the largest allocatable
array and still that's object sizes not code sizes. size_t is almost
certainly as big or bigger than ptr_diff_t, but it's still no guarantee.

**Jakob Bieling** · Jul 19 '05, 05:05 PM

Re: Q: address of operator new/delete

"Andrey Tarasevich" <andreytarasevi ch@hotmail.com> wrote in message
news:vleuts9qv6 ug5e@news.super news.com...[color=blue]
> Jakob Bieling wrote:[color=green]
> > ...
> > is it possible to get the address of operator new/delete and[/color][/color]
operator[color=blue][color=green]
> > new[]/delete[] portably? Otherwise I would have to go for a non-portable[/color][/color]
and[color=blue][color=green]
> > rather unclean solution.
> > ...[/color]
>
> It is possible, as others already stated. But keep in mind that the
> functionality of functions 'operator new/delete' contains only a portion
> of functionality of a new/delete expression (for class types with
> non-trivial construction and destruction at least). If you want to
> create a pointer to something that would reproduce the complete
> functionality of new/delete expression, you'll have to write a dedicated
> wrapper function (or use a library that provides one).[/color]

I already replied to Tom's message, that the pointers will not be used
to call the functions. What I meant is, I solely want to be able to uniquely
identify functions, and their addresses are the perfect id. Instead of
having them stored in pointers, I just want the numerical value. Looks like
I will store them in a size_t or unsigned long by using a cast.

Thanks
--
jb

(replace y with x if you want to reply by e-mail)

**Gianni Mariani** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

Ron Natalie wrote:[color=blue]
> "Gianni Mariani" <gi2nospam@mari ani.ws> wrote in message news:bj7sfc$o6i @dispatch.conce ntric.net...
>[color=green]
>>tom_usenet wrote:
>>
>>[color=darkred]
>>>It is legal to reinterpret_cas t to a sufficiently large integer type -
>>>I'd recommend unsigned long.[/color]
>>
>>Do you think that ptr_diff_t is more appropriate than unsigned long ?
>>[/color]
>
> ptr_diff_t isn't necessarily the right answer. All that has to be is big
> enough to hold the difference in offsets in the largest allocatable
> array and still that's object sizes not code sizes. size_t is almost
> certainly as big or bigger than ptr_diff_t, but it's still no guarantee.[/color]

Where is the definition ?

So this code is undefined ? (a little contrived ...)

int main()
{

char foo[ 1 ];

ptr_diff_t x = foo - ( char * ) 0;

char * foo_ptr = x + ( char * ) 0;

return foo == foo_ptr;
}

**llewelly** · Jul 19 '05, 05:05 PM

Re: address of operator new/delete

tom_usenet@hotm ail.com (tom_usenet) writes:
[color=blue]
> On Thu, 4 Sep 2003 18:27:32 +0200, "Jakob Bieling" <netsurf@gmy.ne t>
> wrote:
>[color=green]
>>"Ron Natalie" <ron@sensor.com > wrote in message
>>news:3f5761e7 $0$23254$9a6e19 ea@news.newshos ting.com...[color=darkred]
>>>
>>> "Jakob Bieling" <netsurf@gmy.ne t> wrote in message[/color]
>>news:bj7n2s$m 24$02$1@news.t-online.com...[color=darkred]
>>>
>>> > Oh I see. I tried to convert it to a void* directly and I prolly did[/color]
>>not[color=darkred]
>>> > know which overloaded operator's address I wanted. With a static_cast it
>>> > works now.
>>>
>>> You can't convert it to void* portably at all. void* is only guaranteed[/color]
>>to be[color=darkred]
>>> able to hold pointers to (data) objects. You need to use some sort of[/color]
>>function[color=darkred]
>>> pointer (even if you must cast it) to hold a function pointer.[/color]
>>
>>
>> Well, I was not going to cast it back for use. I just wanted to store
>>the address to be able to print it out and void* seemed somewhat
>>appropriate . What else would you suggest?[/color]
>
> It is legal to reinterpret_cas t to a sufficiently large integer type -
> I'd recommend unsigned long.[/color]
[snip]

But why, when storing it in a void(*)() is guaranteed safe? There are
platforms (rather, compiler flag sets on 64bit platforms) on which
code pointers are 64 bit, but unsigned long is only 32.

Q: address of operator new/delete

Q: address of operator new/delete

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment