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

Groups > comp.lang.c++ > #4796 > unrolled thread

Customize operator new / delete

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

Contents

  Customize operator new / delete Nephi Immortal <immortalnephi@gmail.com> - 2011-05-07 19:11 -0700
    Re: Customize operator new / delete Ian Collins <ian-news@hotmail.com> - 2011-05-08 15:05 +1200
    Re: Customize operator new / delete James Kanze <james.kanze@gmail.com> - 2011-05-08 07:38 -0700
      Re: Customize operator new / delete "io_x" <a@b.c.invalid> - 2011-05-08 19:05 +0200
        Re: Customize operator new / delete Nephi Immortal <immortalnephi@gmail.com> - 2011-05-08 15:35 -0700
          Re: Customize operator new / delete Ian Collins <ian-news@hotmail.com> - 2011-05-09 10:45 +1200
        Re: Customize operator new / delete James Kanze <james.kanze@gmail.com> - 2011-05-10 13:25 -0700
          Re: Customize operator new / delete "io_x" <a@b.c.invalid> - 2011-05-11 09:31 +0200
            Re: Customize operator new / delete "io_x" <a@b.c.invalid> - 2011-05-11 09:56 +0200
              Re: Customize operator new / delete James Kanze <james.kanze@gmail.com> - 2011-05-15 06:14 -0700
                Re: Customize operator new / delete Joshua Maurice <joshuamaurice@gmail.com> - 2011-05-15 23:54 -0700
                  Re: Customize operator new / delete Ian Collins <ian-news@hotmail.com> - 2011-05-16 19:43 +1200
                  Re: Customize operator new / delete Nobody <nobody@nowhere.com> - 2011-05-16 12:53 +0100
                Re: Customize operator new / delete "io_x" <a@b.c.invalid> - 2011-05-18 17:32 +0200
                  Re: Customize operator new / delete Pete Becker <pete@versatilecoding.com> - 2011-05-18 12:38 -0400
            Re: Customize operator new / delete James Kanze <james.kanze@gmail.com> - 2011-05-15 06:12 -0700
    Re: Customize operator new / delete "io_x" <a@b.c.invalid> - 2011-05-08 18:44 +0200
      Re: Customize operator new / delete Nephi Immortal <immortalnephi@gmail.com> - 2011-05-08 15:43 -0700
        Re: Customize operator new / delete "io_x" <a@b.c.invalid> - 2011-05-09 08:47 +0200
          Re: Customize operator new / delete Leigh Johnston <leigh@i42.co.uk> - 2011-05-09 12:58 +0100
            Re: Customize operator new / delete "io_x" <a@b.c.invalid> - 2011-05-10 08:15 +0200
              Re: Customize operator new / delete Leigh Johnston <leigh@i42.co.uk> - 2011-05-10 12:39 +0100
          Re: Customize operator new / delete James Kanze <james.kanze@gmail.com> - 2011-05-10 13:29 -0700

Page 1 of 2  [1] 2  Next page →

#4796 — Customize operator new / delete

	I decide to customize my own operator new and operator delete in the
global scope.  They are independent outside class as long as they are
not function members of any class.
	Please confirm if my code is valid as C++ standard states.  I had
examined across website via google search.  I only find user-defined
classes, but not for global scope.

#include <stdio.h>
#include <malloc.h>

inline
void *operator new( size_t size ) { return malloc( size ); }

inline
void *operator new[]( size_t size ) { return malloc( size ); }

inline
void operator delete( void *pUserData ) { free( pUserData ); }

inline
void operator delete[]( void *pUserData ) { free( pUserData ); }

int main()
{
	char *p = new char[ 100 ];
	delete [] p;

	return 0;
}

[toc] | [next] | [standalone]

#4797

On 05/ 8/11 02:11 PM, Nephi Immortal wrote:
> 	I decide to customize my own operator new and operator delete in the
> global scope.  They are independent outside class as long as they are
> not function members of any class.
> 	Please confirm if my code is valid as C++ standard states.  I had
> examined across website via google search.  I only find user-defined
> classes, but not for global scope.
>
> #include<stdio.h>
> #include<malloc.h>
>
> inline
> void *operator new( size_t size ) { return malloc( size ); }
>
> inline
> void *operator new[]( size_t size ) { return malloc( size ); }
>
> inline
> void operator delete( void *pUserData ) { free( pUserData ); }
>
> inline
> void operator delete[]( void *pUserData ) { free( pUserData ); }
>
> int main()
> {
> 	char *p = new char[ 100 ];
> 	delete [] p;
>
> 	return 0;
> }

The code is fine, but I'd drop the "inline".  The draft C++0x standard 
prohibits it.

-- 
Ian Collins

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

#4809

On May 8, 3:11 am, Nephi Immortal <immortalne...@gmail.com> wrote:
> I decide to customize my own operator new and operator delete
> in the global scope.  They are independent outside class as
> long as they are not function members of any class.

> Please confirm if my code is valid as C++ standard states.  I
> had examined across website via google search.  I only find
> user-defined classes, but not for global scope.

> #include <stdio.h>
> #include <malloc.h>

> inline
> void *operator new( size_t size ) { return malloc( size ); }

> inline
> void *operator new[]( size_t size ) { return malloc( size ); }

> inline
> void operator delete( void *pUserData ) { free( pUserData ); }

> inline
> void operator delete[]( void *pUserData ) { free( pUserData ); }

> int main()
> {
>         char *p = new char[ 100 ];
>         delete [] p;

>         return 0;
> }

The operator new do not meet the requirements set down in the
standard, particularly the post-condition that the returned
pointer is never null.  You have to do something like:

    void operator new( size_t size )
    {
        void* result = malloc( size );
        if ( result == NULL ) {
            throw std::bad_alloc();
        }
        return result;
    }

Also, the implementations are not allowed to be inlined
(doubtlessly because the standard library is required to use
them if they are present, and the code in the standard library
has already been compiled expecting them not to be inlined).

--
James Kanze

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

#4811

"James Kanze" <james.kanze@gmail.com> ha scritto nel messaggio
news:78a4d447-9756-4dbc-ac6d-3513dbcd5031@l6g2000vbn.googlegroups.com...
> The operator new do not meet the requirements set down in the
> standard, particularly the post-condition that the returned
> pointer is never null.  You have to do something like:
>
>    void operator new( size_t size )
>    {
>        void* result = malloc( size );
>        if ( result == NULL ) {
>            throw std::bad_alloc();

for me better what does malloc(); it return 0, so each function know
the path they have to follow: the error path; each function for its
responsability.

>        }
>        return result;
>    }

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

#4818

On May 8, 12:05 pm, "io_x" <a...@b.c.invalid> wrote:
> "James Kanze" <james.ka...@gmail.com> ha scritto nel messaggionews:78a4d447-9756-4dbc-ac6d-3513dbcd5031@l6g2000vbn.googlegroups.com...
>
> > The operator new do not meet the requirements set down in the
> > standard, particularly the post-condition that the returned
> > pointer is never null.  You have to do something like:
>
> >    void operator new( size_t size )
> >    {
> >        void* result = malloc( size );
> >        if ( result == NULL ) {
> >            throw std::bad_alloc();
>
> for me better what does malloc(); it return 0, so each function know
> the path they have to follow: the error path; each function for its
> responsability.

	You are correct to say this way.  I don’t need to use neither throw()
nor exception.  The allocation failure will be reported to the error
handler and malloc sets errno to ENOMEM if a memory allocation fails.
	The allocation failure is tested at startup before the program begins
to run until it ends prior deallocation memory.  If error is reported,
then the program will be terminated immediately.

>
>
>
> >        }
> >        return result;
> >    }- Hide quoted text -
>
> - Show quoted text -

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

#4821

On 05/ 9/11 10:35 AM, Nephi Immortal wrote:
> On May 8, 12:05 pm, "io_x"<a...@b.c.invalid>  wrote:
>> "James Kanze"<james.ka...@gmail.com>  ha scritto nel messaggionews:78a4d447-9756-4dbc-ac6d-3513dbcd5031@l6g2000vbn.googlegroups.com...
>>
>>> The operator new do not meet the requirements set down in the
>>> standard, particularly the post-condition that the returned
>>> pointer is never null.  You have to do something like:
>>
>>>     void operator new( size_t size )
>>>     {
>>>         void* result = malloc( size );
>>>         if ( result == NULL ) {
>>>             throw std::bad_alloc();
>>
>> for me better what does malloc(); it return 0, so each function know
>> the path they have to follow: the error path; each function for its
>> responsability.
>
> 	You are correct to say this way.  I don’t need to use neither throw()
> nor exception.  The allocation failure will be reported to the error
> handler and malloc sets errno to ENOMEM if a memory allocation fails.
> 	The allocation failure is tested at startup before the program begins
> to run until it ends prior deallocation memory.  If error is reported,
> then the program will be terminated immediately.

If you want a no-throw allocation, use the alternative standard form:

  operator new(std::size_t, const std::nothrow_t&);

-- 
Ian Collins

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

#4874

On May 8, 6:05 pm, "io_x" <a...@b.c.invalid> wrote:
> "James Kanze" <james.ka...@gmail.com> ha scritto nel messaggionews:78a4d447-9756-4dbc-ac6d-3513dbcd5031@l6g2000vbn.googlegroups.com...

> > The operator new do not meet the requirements set down in the
> > standard, particularly the post-condition that the returned
> > pointer is never null.  You have to do something like:

> >    void operator new( size_t size )
> >    {
> >        void* result = malloc( size );
> >        if ( result == NULL ) {
> >            throw std::bad_alloc();

> for me better what does malloc(); it return 0, so each function know
> the path they have to follow: the error path; each function for its
> responsability.

I'd argue about that (although most of the applications I've
worked on have set the new handler to abort).  Still, if you're
providing replacement for the standard operator new, you don't
have a choice.  One of the post-conditions that must be met is
that you return a valid non-null pointer.  And a lot of code
(e.g. in the standard library) counts on it, and will fail
otherwise.

--
James Kanze

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

#4883

"James Kanze" <james.kanze@gmail.com> ha scritto nel messaggio
news:bb132999-0899-4e03-b5b8-942ef18d079d@a10g2000vbz.googlegroups.com...
> On May 8, 6:05 pm, "io_x" <a...@b.c.invalid> wrote:
>> "James Kanze" <james.ka...@gmail.com> ha scritto nel
>> messaggionews:78a4d447-9756-4dbc-ac6d-3513dbcd5031@l6g2000vbn.googlegroups.com...
>
>> > The operator new do not meet the requirements set down in the
>> > standard, particularly the post-condition that the returned
>> > pointer is never null.  You have to do something like:
>
>> >    void operator new( size_t size )
>> >    {
>> >        void* result = malloc( size );
>> >        if ( result == NULL ) {
>> >            throw std::bad_alloc();
>
>> for me better what does malloc(); it return 0, so each function know
>> the path they have to follow: the error path; each function for its
>> responsability.
>
> I'd argue about that (although most of the applications I've
> worked on have set the new handler to abort).  Still, if you're
> providing replacement for the standard operator new, you don't
> have a choice.  One of the post-conditions that must be met is
> that you return a valid non-null pointer.  And a lot of code
> (e.g. in the standard library) counts on it, and will fail
> otherwise.

Buon Giorno

but the C++ libraries are linked with the new, delete of C++, right?

there is a conflict for some other new, delete, defined in some
other place?

The .asm result seems to indicate there is a name conflict
because the name of new[] operator is always "@$bnwa$qui" for both
[std new[] and defined new[] ];
but the .exe result show there is no conflict because the real name of the
new, delete of the standard C++ in this compiler is different; something
as __org_.. show in the debugger different from "operator new"
show in the debugger

so locally here it seems, there is no problem and the two function
new[] are recognise different; ok from the sys and for what i think
should be right

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

#4884

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4dca3b03$0$38643$4fafbaef@reader1.news.tin.it...
>
> "James Kanze" <james.kanze@gmail.com> ha scritto nel messaggio
> news:bb132999-0899-4e03-b5b8-942ef18d079d@a10g2000vbz.googlegroups.com...
>> On May 8, 6:05 pm, "io_x" <a...@b.c.invalid> wrote:
>>> "James Kanze" <james.ka...@gmail.com> ha scritto nel
>>> messaggionews:78a4d447-9756-4dbc-ac6d-3513dbcd5031@l6g2000vbn.googlegroups.com...
>>
>>> > The operator new do not meet the requirements set down in the
>>> > standard, particularly the post-condition that the returned
>>> > pointer is never null.  You have to do something like:
>>
>>> >    void operator new( size_t size )
>>> >    {
>>> >        void* result = malloc( size );
>>> >        if ( result == NULL ) {
>>> >            throw std::bad_alloc();
>>
>>> for me better what does malloc(); it return 0, so each function know
>>> the path they have to follow: the error path; each function for its
>>> responsability.
>>
>> I'd argue about that (although most of the applications I've
>> worked on have set the new handler to abort).  Still, if you're
>> providing replacement for the standard operator new, you don't
>> have a choice.  One of the post-conditions that must be met is
>> that you return a valid non-null pointer.  And a lot of code
>> (e.g. in the standard library) counts on it, and will fail
>> otherwise.
>
> Buon Giorno
>
> but the C++ libraries are linked with the new, delete of C++, right?
>
> there is a conflict for some other new, delete, defined in some
> other place?
>
> The .asm result seems to indicate there is a name conflict
> because the name of new[] operator is always "@$bnwa$qui" for both
> [std new[] and defined new[] ];
> but the .exe result show there is no conflict because the real name of the
> new, delete of the standard C++ in this compiler is different; something
> as __org_.. show in the debugger different from "operator new"
> show in the debugger
>
> so locally here it seems, there is no problem and the two function
> new[] are recognise different; ok from the sys and for what i think
> should be right

here the 2 class of function
[std::new[], std::delete etc] and [new[], delete[] etc] are different

i mean libraries == file libraries .dll
i mean      code == file main.exe

yes the problem could be if the STL or C++ libraries build obj with std::new[]
and the code free it with delete[]; or viceversa
code create space memory for one obj with new[] and the library
use std::delete[]. Is this the problem? It is allow to a library function
to build objects that some other has to free, and not the same class?

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

#4983

On May 11, 8:56 am, "io_x" <a...@b.c.invalid> wrote:
> "io_x" <a...@b.c.invalid> ha scritto nel
> messaggionews:4dca3b03$0$38643$4fafbaef@reader1.news.tin.it...

    [...]
> i mean libraries == file libraries .dll

Technically speaking, DLLs are not libraries, although the name
seems to have stuck.  Except in very rare cases, you should not
link the C++ standard library as a DLL, but statically.

--
James Kanze

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

#5008

On May 15, 6:14 am, James Kanze <james.ka...@gmail.com> wrote:
> Except in very rare cases, you should not
> link the C++ standard library as a DLL, but statically.

Wait what? IIRC, msvc in newer versions has even removed the option of
statically linking to the C++ standard library (the C runtime library
or whatever Microsoft calls it).

Also, I know I've heard about fun results that can happen in Windows
if you have two different DLLs that both statically link to the C
runtime, and try to allocate memory in one DLL and free that object in
the other DLL.

I just want to point out that your advice is clearly wrong for
Windows. As a programmer, one should educate oneself a bit about your
platform or platforms, and then make an informed decision. And that
informed decision will not /not/ be "almost always statically link
against the C++ standard library".

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

#5009

On 05/16/11 06:54 PM, Joshua Maurice wrote:
> On May 15, 6:14 am, James Kanze<james.ka...@gmail.com>  wrote:
>> Except in very rare cases, you should not
>> link the C++ standard library as a DLL, but statically.
>
> Wait what? IIRC, msvc in newer versions has even removed the option of
> statically linking to the C++ standard library (the C runtime library
> or whatever Microsoft calls it).
>
> Also, I know I've heard about fun results that can happen in Windows
> if you have two different DLLs that both statically link to the C
> runtime, and try to allocate memory in one DLL and free that object in
> the other DLL.
>
> I just want to point out that your advice is clearly wrong for
> Windows. As a programmer, one should educate oneself a bit about your
> platform or platforms, and then make an informed decision. And that
> informed decision will not /not/ be "almost always statically link
> against the C++ standard library".

That can be extrapolated to other platforms as well.  There isn't a 
static C++ standard library provided for (Open)Solaris.  Indeed if there 
were, it would make interposing user provided new and delete operator a 
lot harder.

-- 
Ian Collins

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

#5011

On Sun, 15 May 2011 23:54:10 -0700, Joshua Maurice wrote:

> Also, I know I've heard about fun results that can happen in Windows
> if you have two different DLLs that both statically link to the C
> runtime, and try to allocate memory in one DLL and free that object in
> the other DLL.

This issue exists regardless of whether you link statically or dynamically.

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

#5132

"James Kanze" <james.kanze@gmail.com> ha scritto nel messaggio 
news:053f6f0f-2caa-4fa3-b90d-2db959c12a28@d15g2000yqn.googlegroups.com...
> On May 11, 8:56 am, "io_x" <a...@b.c.invalid> wrote:
>> "io_x" <a...@b.c.invalid> ha scritto nel
>> messaggionews:4dca3b03$0$38643$4fafbaef@reader1.news.tin.it...
>
>    [...]
>> i mean libraries == file libraries .dll
>
> Technically speaking, DLLs are not libraries, although the name
> seems to have stuck.  Except in very rare cases, you should not
> link the C++ standard library as a DLL, but statically.

if you have 10000 C++ programs tha use the same routines
could be good to have put all these routine in a .dll
so one not have to load always the same code
but it is load only one time, and so the space of memory
where these routine are written- it is only one place

only static .data of the set of to these routines
should  be in each process out of the .dll
at last at what i belive to have understood

> --
> James Kanze 

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

#5135

On 2011-05-18 11:32:43 -0400, io_x said:

> 
> if you have 10000 C++ programs tha use the same routines
> could be good to have put all these routine in a .dll
> so one not have to load always the same code
> but it is load only one time, and so the space of memory
> where these routine are written- it is only one place
> 
> only static .data of the set of to these routines
> should  be in each process out of the .dll
> at last at what i belive to have understood

Yes, that's the theory. In practice, even Microsoft refers to this as 
"DLL hell". A typical system ends up with multiple, perhaps 
inconsistent, versions of various DLLs and often there's no good way of 
knowing which version will be selected for a particular application. 
The result is that your application may or may not work right, 
depending on which version of each of its DLLs gets loaded. Unless, of 
course, your application supplies its own version of every DLL that it 
uses.

-- 
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The 
Standard C++ Library Extensions: a Tutorial and Reference 
(www.petebecker.com/tr1book)

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

#4982

On May 11, 8:31 am, "io_x" <a...@b.c.invalid> wrote:
> "James Kanze" <james.ka...@gmail.com> ha scritto nel messaggionews:bb132999-0899-4e03-b5b8-942ef18d079d@a10g2000vbz.googlegroups.com...
> > On May 8, 6:05 pm, "io_x" <a...@b.c.invalid> wrote:
> >> "James Kanze" <james.ka...@gmail.com> ha scritto nel
> >> messaggionews:78a4d447-9756-4dbc-ac6d-3513dbcd5031@l6g2000vbn.googlegroups.com...

> >> > The operator new do not meet the requirements set down in the
> >> > standard, particularly the post-condition that the returned
> >> > pointer is never null.  You have to do something like:

> >> >    void operator new( size_t size )
> >> >    {
> >> >        void* result = malloc( size );
> >> >        if ( result == NULL ) {
> >> >            throw std::bad_alloc();

> >> for me better what does malloc(); it return 0, so each function know
> >> the path they have to follow: the error path; each function for its
> >> responsability.

> > I'd argue about that (although most of the applications I've
> > worked on have set the new handler to abort).  Still, if you're
> > providing replacement for the standard operator new, you don't
> > have a choice.  One of the post-conditions that must be met is
> > that you return a valid non-null pointer.  And a lot of code
> > (e.g. in the standard library) counts on it, and will fail
> > otherwise.

> but the C++ libraries are linked with the new, delete of C++,
> right?

It depends.  The standard requires that the implementation
provide some means of replacing the standard operators new and
delete.  How the implementation does it (and what additional
commands it might require) is up to it.  If the C++ libraries
are really libraries (and not fully linked DLL's), then this
will typically be trivial; separate object files in a library
are not yet linked, and the object file containing the standard
operators new and delete will only be linked into the program if
they resolve an otherwise unresolved external.

> there is a conflict for some other new, delete, defined in some
> other place?

> The .asm result seems to indicate there is a name conflict
> because the name of new[] operator is always "@$bnwa$qui" for both
> [std new[] and defined new[] ];
> but the .exe result show there is no conflict because the real name of the
> new, delete of the standard C++ in this compiler is different; something
> as __org_.. show in the debugger different from "operator new"
> show in the debugger

> so locally here it seems, there is no problem and the two function
> new[] are recognise different; ok from the sys and for what i think
> should be right

operator new() and operator new[]() are two different functions,
with two different names.  (What the standard does require is
that the standard operator new[] call operator new() to obtain
its memory.)

--
James Kanze

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

#4810

"Nephi Immortal" <immortalnephi@gmail.com> ha scritto nel messaggio
news:e557f572-1a34-4a96-aad9-ffd1241a71be@c41g2000yqm.googlegroups.com...
> I decide to customize my own operator new and operator delete in the
> global scope.  They are independent outside class as long as they are
> not function members of any class.
> Please confirm if my code is valid as C++ standard states.  I had
> examined across website via google search.  I only find user-defined
> classes, but not for global scope.
>
> #include <stdio.h>
> #include <malloc.h>

for the C language the header of malloc() function is not malloc.h
but stdlib.h; possiblily you not call the malloc() of the C language...

> inline
> void *operator new( size_t size ) { return malloc( size ); }
>
> inline
> void *operator new[]( size_t size ) { return malloc( size ); }

this should be wrong because the right malloc size here is
malloc(size*sizeof(*pointerType))
but who know how to get the number sizeof(*pointerType)?

> inline
> void operator delete( void *pUserData ) { free( pUserData ); }
>
> inline
> void operator delete[]( void *pUserData ) { free( pUserData ); }
>
> int main()
> {
> char *p = new char[ 100 ];

here you are lucky for delete but what about
 int *p = new int[ 100 ];
if is call the new above it reserve space for one
array of 100 chars not one array of 100 ints

> delete [] p;

i never understand that; excuse if i speak too much

> return 0;
> }

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

#4819

On May 8, 11:44 am, "io_x" <a...@b.c.invalid> wrote:
> "Nephi Immortal" <immortalne...@gmail.com> ha scritto nel messaggionews:e557f572-1a34-4a96-aad9-ffd1241a71be@c41g2000yqm.googlegroups.com...
>
> > I decide to customize my own operator new and operator delete in the
> > global scope.  They are independent outside class as long as they are
> > not function members of any class.
> > Please confirm if my code is valid as C++ standard states.  I had
> > examined across website via google search.  I only find user-defined
> > classes, but not for global scope.
>
> > #include <stdio.h>
> > #include <malloc.h>
>
> for the C language the header of malloc() function is not malloc.h
> but stdlib.h; possiblily you not call the malloc() of the C language...
>
> > inline
> > void *operator new( size_t size ) { return malloc( size ); }
>
> > inline
> > void *operator new[]( size_t size ) { return malloc( size ); }
>
> this should be wrong because the right malloc size here is
> malloc(size*sizeof(*pointerType))
> but who know how to get the number sizeof(*pointerType)?

	No, you are wrong unless you don’t need to put sizeof() on malloc()
function inside operator new function because size_t size parameter of
operator new function is already provided the sizeof( type ) times
elements by C++ Compiler.
	Test it yourself until you find out.  You will always need to use
sizeof() if you place malloc() function somewhere.


>
> > inline
> > void operator delete( void *pUserData ) { free( pUserData ); }
>
> > inline
> > void operator delete[]( void *pUserData ) { free( pUserData ); }
>
> > int main()
> > {
> > char *p = new char[ 100 ];
>
> here you are lucky for delete but what about
>  int *p = new int[ 100 ];
> if is call the new above it reserve space for one
> array of 100 chars not one array of 100 ints

	The buffer overruns NEVER happens because C++ Compiler knows the
size.  It will recognize int type and add four bytes each element in
the int array.

> > delete [] p;
>
> i never understand that; excuse if i speak too much
>
>
>
> > return 0;
> > }- Hide quoted text -
>
> - Show quoted text -

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

#4826

"Nephi Immortal" <immortalnephi@gmail.com> ha scritto nel messaggio
news:7dbad185-521d-449c-b491-b60af6964602@n10g2000yqf.googlegroups.com...
> > inline
> > void *operator new( size_t size ) { return malloc( size ); }
>
> > inline
> > void *operator new[]( size_t size ) { return malloc( size ); }
>
> this should be wrong because the right malloc size here is
> malloc(size*sizeof(*pointerType))
> but who know how to get the number sizeof(*pointerType)?

>No, you are wrong unless you don’t need to put sizeof() on malloc()
>function inside operator new function because size_t size parameter of
>operator new function is already provided the sizeof( type ) times
>elements by C++ Compiler.
>Test it yourself until you find out.  You will always need to use
>sizeof() if you place malloc() function somewhere.

ok right what you say; thank you; i have to say i never had understood that;

but i don't understand well too why use 2 delete function
if they do the same:

for example in:
#include <stdio.h>
#include <stdlib.h>

void* operator new( size_t size )   { return malloc( size ); }
void* operator new[]( size_t sizePerSizeT ) { return malloc( sizePerSizeT ); }
void  operator delete( void *pUserData) { free( pUserData ); }
void  operator delete[]( void *pUserData ) { free( pUserData ); }

int main(void)
{int *p = new int[ 100 ];
 char *pc= new char;
 char *pcc=new(char);

 delete    p;
 delete [] p;
 return 0;
}


 ;
 ; void  operator delete( void *pUserData) { free( pUserData ); }
 ;
@@$bdele$qpv:
 push      ebp
 mov       ebp,esp
@7:
 push      dword ptr [ebp+8]
 call      @_free
 pop       ecx
@8:
 pop       ebp
 ret

 ;
 ; void  operator delete[]( void *pUserData ) { free( pUserData ); }
 ;
@@$bdla$qpv:
 push      ebp
 mov       ebp,esp
@9:
 push      dword ptr [ebp+8]
 call      @_free
 pop       ecx
@10:
 pop       ebp
 ret
 ....
....
main:
etc
....
 ;
 ;  delete    p;
 ;
 push      ebx
 call      @@$bdele$qpv
 pop       ecx
 ;
 ;  delete [] p;
 ;
 push      ebx
 call      @@$bdla$qpv
 pop       ecx

are the same

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

#4831

On 09/05/2011 07:47, io_x wrote:
> "Nephi Immortal"<immortalnephi@gmail.com>  ha scritto nel messaggio
> news:7dbad185-521d-449c-b491-b60af6964602@n10g2000yqf.googlegroups.com...
>>> inline
>>> void *operator new( size_t size ) { return malloc( size ); }
>>
>>> inline
>>> void *operator new[]( size_t size ) { return malloc( size ); }
>>
>> this should be wrong because the right malloc size here is
>> malloc(size*sizeof(*pointerType))
>> but who know how to get the number sizeof(*pointerType)?
>
>> No, you are wrong unless you don’t need to put sizeof() on malloc()
>> function inside operator new function because size_t size parameter of
>> operator new function is already provided the sizeof( type ) times
>> elements by C++ Compiler.
>> Test it yourself until you find out.  You will always need to use
>> sizeof() if you place malloc() function somewhere.
>
> ok right what you say; thank you; i have to say i never had understood that;
>
> but i don't understand well too why use 2 delete function
> if they do the same:
>
> for example in:
> #include<stdio.h>
> #include<stdlib.h>
>
> void* operator new( size_t size )   { return malloc( size ); }
> void* operator new[]( size_t sizePerSizeT ) { return malloc( sizePerSizeT ); }
> void  operator delete( void *pUserData) { free( pUserData ); }
> void  operator delete[]( void *pUserData ) { free( pUserData ); }
>
> int main(void)
> {int *p = new int[ 100 ];
>   char *pc= new char;
>   char *pcc=new(char);
>
>   delete    p;
>   delete [] p;
>   return 0;
> }
>
>
>   ;
>   ; void  operator delete( void *pUserData) { free( pUserData ); }
>   ;
> @@$bdele$qpv:
>   push      ebp
>   mov       ebp,esp
> @7:
>   push      dword ptr [ebp+8]
>   call      @_free
>   pop       ecx
> @8:
>   pop       ebp
>   ret
>
>   ;
>   ; void  operator delete[]( void *pUserData ) { free( pUserData ); }
>   ;
> @@$bdla$qpv:
>   push      ebp
>   mov       ebp,esp
> @9:
>   push      dword ptr [ebp+8]
>   call      @_free
>   pop       ecx
> @10:
>   pop       ebp
>   ret
>   ....
> ....
> main:
> etc
> ....
>   ;
>   ;  delete    p;
>   ;
>   push      ebx
>   call      @@$bdele$qpv
>   pop       ecx
>   ;
>   ;  delete [] p;
>   ;
>   push      ebx
>   call      @@$bdla$qpv
>   pop       ecx
>
> are the same
>

Typically there will be different code at the call site rather than in 
the delete functions themselves for example the extra new[] bookkeeping 
information added after the new[] allocation will be used to call the 
correct number of destructors before deallocation.

/Leigh

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web