Idea of adding a third-party draw API to a language standard is not a good idea
Chrome Is The New C Runtime
111–120 of 149 posts
Re: Chrome Is The New C Runtime
#112oh just fuck this entire idea
I really don't like the idea of adding a third-party draw API to a language standard
Re: Chrome Is The New C Runtime
#113There is a lot of code in Chromium that covers ground that Qt does not and there are good reason to prefer permissive licensed code for your project that you can directly modify. Qt is a fine library but hardly the be all end all of what is out there. ISO C++ committee recently posted to the Cairo library and C++14 might have a standard 2D based on it. There is a lot of room for different projects
Re: Chrome Is The New C Runtime
#114 But otherwise I still see no reason to use something designed for a specific use-case over something which is designed for general development. Though if it is a proprietary app it might work because there people seldom care about using latest version of libraries, sad as it may be.
Further, I really don't like the idea of adding a third-party draw API to a language standard. Dunno if we really want to blur the line between language and library.
Re: Chrome Is The New C Runtime
#115So you write your mobile apps in C++? and you can't take advantage of iOS or Android STL?
Libraries like STL (which Chromium code uses extensively) and boost are lower-level. Chromium has much higher level abstracts.
The reason to use specialized code is because your needs match them. Not everyone wants to bother linking to a general purpose library and adding a dependency when you can reuse some specific code and be done with it. Also, language standards cover libraries extensively and this is hardly a new trend and once it is standardized, it can no longer be considered third party. This has already happened quite a bit with C++11 which standardized many commonly used portions of the Boost library. Nevertheless, I mentioned the standardization aspect not to debate about it but to use it as an example to point out competing projects.
Re: Chrome Is The New C Runtime
#116This is what mod_pagespeed/ngx_pagespeed does. We need many basic things and we use the Chromium libraries for that.
(You could say that's because we're kind of like a browser, but we don't actually use the most browser-like components of Chromium. We do need an http(s) fetcher and html/css/js parsers but the Chromium ones aren't a good fit for our usage.)
Re: Chrome Is The New C Runtime
#117Earlier quoted context omitted.
> Avoiding exceptions is a worst practice You say this very matter-of-factly. Many (myself included) do not believe in exceptions, and in C++ where they are poorly implemented, think not using them is best practice. I would summarize, but this 10 year old article I've seen on HN a dozen times does a much better job than I: http://www.joelonsoftware.com/items/2003/10/13.html Error handling is essential, but exceptions…
> The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions. The amount of error-unwinding goto spaghetti, ERR_CAST/IS_ERR/PTR_ERR/... and all the bugs coming from it is not "just fine".
But how much of that would be solved by exceptions without convertng to a fully garbage-collected language?
Re: Chrome Is The New C Runtime
#118Earlier quoted context omitted.
Avoiding exceptions is a worst practice. The guide even admits they're only doing it because they're so far beyond a critical mass of exception-unsafe code that they've lost hope of solving the problem. If the profession ever wants to produce anything reliable in C++, one of the first things that needs to happen is to start treating all unsafe legacy code like toxic waste, marking it clearly, handling it carefully in…
> Avoiding exceptions is a worst practice You say this very matter-of-factly. Many (myself included) do not believe in exceptions, and in C++ where they are poorly implemented, think not using them is best practice. I would summarize, but this 10 year old article I've seen on HN a dozen times does a much better job than I: http://www.joelonsoftware.com/items/2003/10/13.html Error handling is essential, but exceptions…
The Linux kernel is an impressively complicated, and robust piece of software and they get along just fine without exceptions
Though I somewhat agree with you, in that C++ exceptions definitely are not the error handling method, such examples don't really mean nor prove much for this subject. Especially since the kernel isn't even written in C++ and is a pretty special beast compared to, say, a typical desktop or app. So now browse to https://en.wikipedia.org/wiki/List_of_fallacies and figure out which one you just used :P
Re: Chrome Is The New C Runtime
#119Earlier quoted context omitted.
Avoiding exceptions is a worst practice. The guide even admits they're only doing it because they're so far beyond a critical mass of exception-unsafe code that they've lost hope of solving the problem. If the profession ever wants to produce anything reliable in C++, one of the first things that needs to happen is to start treating all unsafe legacy code like toxic waste, marking it clearly, handling it carefully in…
>If the profession ever wants to produce anything reliable in C++ This has already been done, so you are obviously wrong. Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you have zillions of functions just waiting to explode your call stack in ways you could never expect. Documentation doesn't fix it either. Even if you could somehow guarantee that every single function has…
Exceptions are cute for small amounts of code. But as soon as you get a sizeable codebase, you start to understand the huge advantage they give: your code shrinks by an order of magnitude vs the same code with manual error propagation.
Re: Chrome Is The New C Runtime
#120Contrary to many, I'm profoundly concerned about the culture around Chrome development, and the attitude here is indicative of that. There really is a belief by those that work on it, or have worked on it, that it's much better than it really is, when what actually happened was it was much better than the competition at launch, but now there isn't much between them at all. This notion that Chrome is decent on mobile is still absolutely bizarre.
The more long term concern is the way it's creating a sort of development priesthood. You have the chosen few that are making decisions and developing the platform largely in secret and pushing the code out to mere mortals from on high. This wouldn't be so bad, except the decisions are not made in the interest of the mortals, but of the priesthood and the strategic interest of their Googly God, and they exhibit a level of contempt for the mortals by disallowing them direct access to things such as the components so lauded here. In an ideal world most of what's mentioned should not be in the C++ layer, but in JS, except the hooks to provide that are simply never going to be exposed (at least in the near term because of the JS performance it would be technically dubious), leading to this them and us situation where they get to develop all the low level stuff, and no one else does, especially if any patches would conflict with the interest of their lord and master. They simply aren't dogfooding their entire development stack. Mozilla, for all their flaws, do actually engage the rest of the world in what they're doing, and early Java, while slow, did have a relatively small JVM with an enormous class library which was mostly written in Java itself. You could argue Sun's error was to Swing too far in the other direction by insisting on being all Java where at the time it really should not have been.
So yes, sadly I've come to view many Chrome devs as smug self serving slightly delusional types persistently confused that the masses don't acknowledge their brilliance, and this piece is evangelism to try and persuade us of this. The truly scary part of this is they just might be right to have this point of view in order to prevent what happened to Android where groups outside succeeded in nullifying many of the expected advantages of a standard open mobile platform, and I suspect it's this which has led to their open but closed approach to things.