Re: [webkit-dev] renaming ASSERT macro
Hi Darin,
Thanks for your detailed comments!
Adding windows.h to Assertions.h will not cause it to be included in
public headers. Assertions.h is not designed to be used in public
headers; it's for internal use inside the WebKit project.
I've just executed the following:
find . -name '*.h' -exec grep -Hn 'Assertions.h' '{}' \;
You're sure, that none of the 40+ files, the above call yields, is a
public header or used inside a public header?
But well, if Assertions.h is meant to be part of the private API,
that particular argument of mine is void. A public header including
Assertions.h, even an indirect include, should then be considered as bug?
For one thing, I don't like the other names you suggested.
Well, that was a proposal. I really don't have strong feelings about the
name. I just didn't want it to be ASSERT. ;-)
Regards,
Jörg
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] renaming ASSERT macro
Darin Adler wrote: Well, this is a small change but also a very bad idea. Not because of compilation time, but because of the crappy Windows headers which define *a* *lot* of global stuff. E.g. the XSLT parser of WebKit won't build because there's a #define ERROR somenumber which breaks an enum definition. Or think of the famous MIN / MAX definitions, which drive every crossplatform developer insane. OK. Lets #undef those things. This solution is easy to do, leads to the smallest source diff but is a very dirty hack, which will lead to problems on WinCE, because we will include windows.h in public headers. One survival rule of Windows developers is: only include windows.h when it is really needed. So what's your argument against the clean solution (renaming)? Regards, Jörg ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
