Cairo Graphics Library Drops Many Old Backends

[phoronix]

Phoronix: Cairo Graphics Library Drops Many Old Backends

The Cairo graphics library that is used by GNOME/GTK, Mozilla Gecko, and many other projects for vector-based 2D graphics drawing has decided to remove a number of its old drawing back-ends...

https://www.phoronix.com/scan.php?pa...Drops-Old-Code

[oleid]

[...]drop dependency on a C++ compiler in our build systems, as well as removing the complexity of dealing with one.

Huh? How is a dependency on a C++ compiler a complexity with any modern build system?

[lumks]

Huh? How is a dependency on a C++ compiler a complexity with any modern build system?

Everything that requires a functionality that is not required, tested and so practically unsupported is a complexity. This includes at the end of the day some form of CI, too, that may or may not exist.

The changes comes down to "Support only what is (known to be) currently in use, drop whats not"

https://gitlab.freedesktop.org/cairo...e_requests/285

[bug77]

Everything that requires a functionality that is not required, tested and so practically unsupported is a complexity. This includes at the end of the day some form of CI, too, that may or may not exist.

The changes comes down to "Support only what is (known to be) currently in use, drop whats not"

https://gitlab.freedesktop.org/cairo...e_requests/285

That's a bit of circular reasoning, I think. Supporting Qt requires a C++ compiler, so that's not complexity, going by your definition.

That aside, I believe Cairo has bindings for other languages (C++ included), making it awkward to see a C++ compiler required in the first place.

[coder]

Huh? How is a dependency on a C++ compiler a complexity with any modern build system?

Well, I'm just speculating, since I have no detailed knowledge of Cairo, but it could have something to do with C++ no longer being a superset of C, in more modern revisions of either language. Supporting C++ would've meant having to limit their C usage to parts that are C++-compatible, in the guts of Cairo that wouldn't otherwise have to worry about such things (i.e. down at a level the C++ bindings don't see).

[carewolf]

Huh? How is a dependency on a C++ compiler a complexity with any modern build system?

Just nonsense from psycotic C fanatics. They need this irrational thinking to justify wasting time in writting in a more primitive, developer time consuming language. Having parallel C++ code in their codebase exposes their mistake

[Azpegath]

Quite a lot of code removed! Fun to read the thread.

87 files changed, 14 insertions(+), 41395 deletions(-)

[oiaohm]

Just nonsense from psycotic C fanatics. They need this irrational thinking to justify wasting time in writting in a more primitive, developer time consuming language. Having parallel C++ code in their codebase exposes their mistake

This is not really true. There are complexities that come from using C++. Yes you can end up writing more code to deal with C++ issues than coding the same item in pure C.

Like if you are not using classes or STL..... from C++ because they don't suit the use case using C++ compiler can just causes you more problems than what it worth. Think about it you are doing something that STL garbage collection does not suite you are using C++ compiler so someone adds in something using STL it builds but you now have random issue to track down.

So its not always psychotic C fanatics some of this low level stuff some of the extra features of C++ are just headache. C++ does not have the means to declare in header/file that X C++ features are disabled so in cases that they are incompatible developers cannot use them. This is why its not just psychotic C fanatics there is a issue with C++ where its really all or nothing as in you select C and no C++ features or you use C++ and the compiler is now providing all features even in cases when its not safe to use all features. There has always been a need for a proper middle ground between C and C++.

[coder]

Think about it you are doing something that STL garbage collection does not suite you are using C++ compiler so someone adds in something using STL it builds but you now have random issue to track down.

STL doesn't use garbage collection.

The main case for avoiding STL is on embedded platforms with very tight margins.

some of the extra features of C++ are just headache.

C++ exceptions (i.e. throw/catch), but you can put guards in all your C callbacks to trap them. I do that, when using C++ within a C API (GLib stuff, mainly). If you're clever, you can write a generic CallWithCatchall() function template, so you don't have to copy/paste try/catch blocks everywhere. Or, if you simply handle them by aborting, then you can use the noexcept specifier to do a catch-all and call std::terminate() for you.

[brad0]

Huh? How is a dependency on a C++ compiler a complexity with any modern build system?

It is not.