On Jul 28, 2009, at 9:53 PM, Roland Steiner wrote:
I definitely like the general idea, but I don't think a NeverNull
template is worth it in the general case, for the following reasons:
First, I don't hink you can catch even a meaningful subset of all
cases of NULL assignment at compile
On Tue, Jul 28, 2009 at 9:53 PM, Roland Steiner wrote:
>
> I definitely like the general idea, but I don't think a NeverNull template
> is worth it in the general case, for the following reasons:
>
> First, I don't hink you can catch even a meaningful subset of all cases of
> NULL assignment at co
I definitely like the general idea, but I don't think a NeverNull template
is worth it in the general case, for the following reasons:
First, I don't hink you can catch even a meaningful subset of all cases of
NULL assignment at compile time. OTOH, writing a template class that wraps a
non-null po
On Tue, Jul 28, 2009 at 4:29 PM, Jozwiak, John wrote:
> Isn't the C++ "reference" annotation
>
> char & x;
>
> tantamount to declaration of a pointer
>
> char * x;
>
> to whom NULL assignment, as detectable at compile time, is a compile-time
> error?
I'm not sure what you mean by "as detectable
On Tue, Jul 28, 2009 at 4:29 PM, Jozwiak, John wrote:
> Isn't the C++ "reference" annotation
>
> char & x;
>
> tantamount to declaration of a pointer
>
> char * x;
>
> to whom NULL assignment, as detectable at compile time, is a compile-time
> error?
Remember that you can't "reassign" a refere
Isn't the C++ "reference" annotation
char & x;
tantamount to declaration of a pointer
char * x;
to whom NULL assignment, as detectable at compile time, is a compile-time error?
If so, is that adequately applicable?
From: webkit-dev-boun...@lists.we
28.07.2009, в 15:25, Eric Seidel написал(а):
It just occurred to me that we have a lot of places in WebKit were
we ASSERT(foo) (where foo is some passed in Foo* pointer which
should never be NULL).
I like to use references instead of pointers that can never be null.
This doesn't always
On Jul 28, 2009, at 3:59 PM, Peter Kasting wrote:
On Tue, Jul 28, 2009 at 3:55 PM, Oliver Hunt wrote:
Personally i like the idea of having type system/compiler enforced
null checking.
Note that eseidel's proposal is still a runtime check. One could
use template specialization to write a
On Jul 28, 2009, at 3:59 PM, Peter Kasting wrote:
On Tue, Jul 28, 2009 at 3:55 PM, Oliver Hunt wrote:
Personally i like the idea of having type system/compiler enforced
null checking.
Note that eseidel's proposal is still a runtime check. One could
use template specialization to write a
On Tue, Jul 28, 2009 at 3:55 PM, Oliver Hunt wrote:
> Personally i like the idea of having type system/compiler enforced null
> checking.
>
Note that eseidel's proposal is still a runtime check. One could use
template specialization to write a class that gives a compile-time error if
you try to
Eric Seidel wrote:
Could get nasty when interacting with other templates though. I don't
think we want a NeverNullOwnPtr, or maybe we do?
Does this seem useful to anyone else? Oh c++ experts, does this even
seem possible, seem like it would perform well, not bloat the code size,
etc?
Neve
On Jul 28, 2009, at 3:49 PM, Adam Barth wrote:
I think Oliver was talking about something similar on IRC the other
day.
And in fact i landed a similar class for pointers that _must_ be null
checked. It has since been rolled out because the copy constructors
weren't correct (and i haven't
I think Oliver was talking about something similar on IRC the other day.
Adam
On Tue, Jul 28, 2009 at 3:25 PM, Eric Seidel wrote:
> It just occurred to me that we have a lot of places in WebKit were we
> ASSERT(foo) (where foo is some passed in Foo* pointer which should never be
> NULL).
> Maybe
It just occurred to me that we have a lot of places in WebKit were we
ASSERT(foo) (where foo is some passed in Foo* pointer which should never be
NULL).
Maybe it would be cleaner/better/whatever if we instead used a template to
do this ASSERTing in a centralized place. The primary advantage would
Hi, all
I just built a program in QT webkit, and noticed that the memory usage of my
program grows 1 or 2 megabytes as I load each web page.
My program is quite simple. I defined a global variable:
QWebPage mypage;
Each time when a new URL request comes, I call the following to load the web
page:
Seems like --clean needs to know how to delete Debug/DerivedSources/*
On Tue, Jul 28, 2009 at 8:57 AM, Alexey Proskuryakov wrote:
>
> 28.07.2009, в 8:51, Thomas Brodt написал(а):
>
>> Should I cleanup more than --clean?
>
>
> I just wipe the WebKitBuild directory when I need to rebuild.
>
> - WBR,
Hi Alexey
that wiping did the trick, all projects were successfully built.
Thanks a lot for the instant help.
Thomas
Alexey Proskuryakov schrieb:
28.07.2009, в 8:51, Thomas Brodt написал(а):
Should I cleanup more than --clean?
I just wipe the WebKitBuild directory when I need to rebuil
28.07.2009, в 8:51, Thomas Brodt написал(а):
Should I cleanup more than --clean?
I just wipe the WebKitBuild directory when I need to rebuild.
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.
After the normal build didn't work, I already did a rebuild within
VisualStudio. That didn't help.
Now, I did a
build-webkit --clean
build-webkit --debug --cairo-win32
but the errors about SilenceAssertionsOnly are still there, see examples
below.
Should I cleanup more than --clean?
Tho
28.07.2009, в 4:05, Thomas Brodt написал(а):
I've seen that there is 46441/442 that deals with
SilenceAssertionsOnly, but prefixing JSC:: doesn't work.
Currently the winCairo doesn't build with 46462 because of these
"undeclared identifier SilenceAssertionsOnly" or
"SilenceAssertionsOnly
I've seen that there is 46441/442 that deals with SilenceAssertionsOnly,
but prefixing JSC:: doesn't work.
Currently the winCairo doesn't build with 46462 because of these
"undeclared identifier SilenceAssertionsOnly" or "SilenceAssertionsOnly
not a member of JSC" if prefixed with JSC::, both
21 matches
Mail list logo
