Correction: you meant "pure virtual" functions. (I'm adding a note to the README file about these rules by the way.)
-Darin On Fri, Dec 3, 2010 at 8:55 AM, Darin Fisher <da...@chromium.org> wrote: > Yes, indeed. Thanks Jeremy! > > > On Fri, Dec 3, 2010 at 3:13 AM, Jeremy Orlow <jor...@chromium.org> wrote: > >> You forgot to mention virtual functions, which is another case where you >> do _not_ use WEBKIT_API. >> >> J >> >> On Thu, Dec 2, 2010 at 9:27 PM, Darin Fisher <da...@chromium.org> wrote: >> >>> If you do not work on the Chromium port of WebKit, you can stop reading >>> now. >>> >>> I've noticed that there is some confusion about how to use WEBKIT_API >>> properly. >>> WEBKIT_API causes a function to be exported from WebKit when it is built >>> as a DLL, >>> allowing Chromium to call the function. >>> >>> The rule is actually quite simple: >>> >>> WEBKIT_API should be affixed to any public, non-inline function that >>> is intended >>> for the embedder (Chromium) to call. >>> >>> Put another way: >>> -- Do not apply WEBKIT_API to inline functions. >>> -- Do not apply WEBKIT_API to private functions. >>> -- Do not apply WEBKIT_API to public functions within a #if >>> WEBKIT_IMPLEMENTATION block. >>> >>> (Of related note, we never put WEBKIT_API on public constructors and >>> destructors. >>> Instead, we have constructors call an initialize method and destructors >>> call a reset >>> method. Those then end up having the WEBKIT_API prefix applied.) >>> >>> Thanks! >>> -Darin >>> >>> >>> _______________________________________________ >>> 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