41–50 of 74 posts
Without a doubt, WebKit is one of the most interesting parts of Apple. A community of open source developers that accept contributions (I'm assuming) with a developer-focused open blog with tips on writing C++ - a language not even particularly widely used elsewhere in Apple.
What is the future of WebKit now that Blink has been introduced? Will Apple spend considerable resources keeping an open-source project at the bleeding-edge considering it doesn't really make them any money? Should Safari just be scrapped? It only accounts for http://en.wikipedia.org/wiki/WebKit
Without a doubt, WebKit is one of the most interesting parts of Apple. A community of open source developers that accept contributions (I'm assuming) with a developer-focused open blog with tips on writing C++ - a language not even particularly widely used elsewhere in Apple.
If Apple could have developed their own proprietary rendering engine they would have. Jumping on KHTML meant they could get a working, OS X UI compliant browser when IE for OS X was no longer being maintained, even if the guts of that app had to be shared with others.
Interesting that this article doesn't mention profile guided optimization. In my experience, PGO is able to eliminate a lot of the performance problems associated with unnecessary inlines and rarely called functions eating up cache space. The major downsides are that you can only optimize what the profiler can see and running the thing to make a build takes forever.
And clang's PGO support is not very good so far, so there isn't much to talk about...
Without a doubt, WebKit is one of the most interesting parts of Apple. A community of open source developers that accept contributions (I'm assuming) with a developer-focused open blog with tips on writing C++ - a language not even particularly widely used elsewhere in Apple.
I concur. When I was there, they were pretty clear that everything I made belonged to Apple (which was total bullshit according to California law), that nothing we made would ever be open sourced due to patent issues, and that I was to never say anything about the company in public. I wonder how their team could swing that culture without tripping over legal at every turn.
This remains the case to a large extent. This makes working with Apple and Microsoft in standards groups a bit challenging at times, since they won't actually comment on whether they're even thinking about implementing a standard, or whether they would be willing to implement it as written, until they suddenly ship it.
And if they're _not_ shipping it you have no way to tell whether that's because they never will because of some fundamental issue they perceive or whether they're basically fine with the idea bu just haven't gotten around to finding resources to implement yet.
While I'm very appreciative of the contributions Apple made to the web with WebKit, most of the recent innovations and upkeep has been thanks to Google. What is the future of WebKit now that Blink has been introduced? Will Apple spend considerable resources keeping an open-source project at the bleeding-edge considering it doesn't really make them any money? Should Safari just be scrapped? It only accounts for http:/…
http://www.netmarketshare.com/browser-market-share.aspx?qpri...
Is webkit written in C++ instead of objective C?
With the clang or gcc compilers, you can easily link ObjC and C++ together. To some extent you can even mix them in one file (ObjC++), though I don't have experience with that.
Earlier quoted context omitted.
I agree with the 'make things const' part, but I would expect m_cachedWidth to be mutable. I'm too lazy to check that now, but if so, that would not help here. Even if it is not, I still think this is an example of "how you should modify your code". Reason? Doing temp = foo(); temp *= bar(); m_member = temp; keeps your state consistent in case bar() throws. I would even use it if bar() is known not to throw, because…
Most low-level C++ projects (including Webkit and Gecko) don't use C++ exceptions.
Obviously the above can be taken too far, but programming for const correctness, mutability, and safety in the face of exceptions should be in everyone's toolkit, and the default way they program in C++ (IMO, naturally).
Earlier quoted context omitted.
Wrong const. He's talking about the gcc function attribute extension, which most of the time is too strict, so recommending its general use isn't a great idea. C++ const has no effect on optimization, since it can be casted away. And being aware of aliasing issues is a good idea in general; nothing the compiler does can fix this in the general case (e.g. if computeWidth() is located in an external shared library it's…
> C++ const has no effect on optimization, since it can be casted away. Modifying an object that has had its const-ness casted away is undefined behaviour.