Hi,
I just wonder how you can pass arguments to your new operator when they are
mandatory (no default constructor), in the following case:
class Foobar{
public:
Foobar(int a,char* b);
};
class Barfoo{
public:
Barfoo(char* a);
}
Foobar* myFoobar=newObject<Foobar>( ?????? );
Barfoo* myBarfoo=newObject<Barfoo>( ?????? );
Reading your patch, I don't think this testcase will work... will it?
Fred
Le Tuesday 16 September 2008 à 20:28, Paul Pedriana a écrit :
> >> I'm curious to see the patch (just to give an idea how
> >> big the changes would be). Do you have it somewhere?
>
> The patch is at: https://bugs.webkit.org/show_bug.cgi?id=20422.
> I don't think this is a terribly difficult thing to implement (though
> I don't mean to imply that it's trivial either). It might take a couple
> iterations to make sure all instances are handled, though. I searched
> the code and found a couple thousand instances of the keyword 'new',
> though most of those would fall under the case of the base class operator.
>
> >> Ah I see now. So you want to isolate the malloc from
> >> WebKit module. Furthermore, you want to be able to
> >> "kill" WebKit *only* when something weird happens,
> >> am I correct?
>
> I want to be able to shut down WebKit at any time, and possibly restart it.
> If WebKit is used as a library within an application instead of being the
> application itself, then you want to initialize it when needed, but when
> it's
> no longer needed then you want to shut it down. Think of computer games
> like Grand Theft Auto whereby you are a character walking around the
> world investigating something; and your character walks up to a computer
> in the game and uses it to connect to the real web (using an embedded
> WebKit)
> to search for live-generated info for a while. When the character shuts off
> the virtual computer, the game needs the resources of that computer to
> go away, as the game needs to recover the RAM for the next thing the user
> does. It significantly improves heap fragmentation of that WebKit instance
> ran in a single contiguous block of memory such that when it went away
> there is a nice big clean space left over.
>
> That being said, your original case of killing WebKit when something weird
> happens is also a practical use case. Such a thing might in fact be memory
> exhaustion due to fragmentation.
>
> Paul
>
> >> The primary benefit of being able to override operator new is to be able
> >> to redirect all allocations for a library to a user-specified heap. With
> >> global operator new, allocated WebKit memory is mixed in with the rest
> >> of the application memory and there is no practical way to tell them
> >> apart or sequester them. This makes it impossible to correctly shut down
> >> WebKit at runtime, since you don't know where its memory is. A side
> >> benefit related to this is that this allows for better memory metrics
> >> gathering.
> >
> > Ah I see now. So you want to isolate the malloc from WebKit module.
> > Furthermore, you want to be able to "kill" WebKit *only* when something
> > weird happens, am I correct?
> >
> >> The proposal provides for a base class that overrides global operator
> >> new. So any allocated classes use the same syntax as usual. Most of the
> >> source code would fall under this.
> >
> > Yes, that is true.
> >
> >> For the case of non-class-based memory allocations (e.g. raw char
> >> array), the proposal provides a newObject and newArray template
> >> function. So instead of 'new int' you would way 'newObject<int>' and
> >> instead of 'new char[32]' you would say 'newArray<char>(32)'. However,
> >> there is an alternative approach which is to provide a custom operator
> >> new type, like so:
> >> struct WTF{};
> >> void* operator new(size_t size, WTF);
> >>
> >> and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the
> >> conventional solution to namespacing operator new, where the C++
> >> standard doesn't allow for operator new being in a C++ namespace.
> >> Perhaps this syntax is preferable. This can be #defined to simply newWTF
> >> if desired, then it is practically identical to existing global new
> >> syntax.
> >>
> >> FWIW, I have been testing the proposed patch in my copy and so far it
> >> has been fine, but that of course includes only my uses.
> >
> > I'm curious to see the patch (just to give an idea how big the changes
> > would be). Do you have it somewhere?
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
