Libvirt: Adoption of GLib library to replace GNULIB and home grown code

Post by rlkxx » Sat, Jan 23, 2021, 10:27 AM UTC

qalmakka wrote: post #32

I think that 3/4 of their issues would probably be solved by a well thought use of modern C++. I've seen too many C projects (including some of mine) starting by swearing out C++ for one reason or another and then ending out reimplementing half of it using macros or poorly written hashmap implementations taken from somewhere. Glib2 is one excellent example of how people have been shunning C++ due to its complexity, w…

Post by pjmlp » Sat, Jan 23, 2021, 10:38 AM UTC

qalmakka wrote: post #32

I think that 3/4 of their issues would probably be solved by a well thought use of modern C++. I've seen too many C projects (including some of mine) starting by swearing out C++ for one reason or another and then ending out reimplementing half of it using macros or poorly written hashmap implementations taken from somewhere. Glib2 is one excellent example of how people have been shunning C++ due to its complexity, w…

Post by waltersx » Sat, Jan 23, 2021, 10:44 AM UTC

netheril96 wrote: post #42

rlkxx wrote: post #41

Earlier quoted context omitted.

For long applications you get into he realm of tool chain bugs with C++. C compilers are more reliable. If you write C-style C++, which parts of libstdc++ can you safely use without exceptions?

Google writes a lot of C++ code, disables exceptions entirely, and it does not shy away from STL at all.

Post by pjmlp » Sat, Jan 23, 2021, 10:50 AM UTC

rleigh wrote: post #39

qalmakka wrote: post #32

I think that 3/4 of their issues would probably be solved by a well thought use of modern C++. I've seen too many C projects (including some of mine) starting by swearing out C++ for one reason or another and then ending out reimplementing half of it using macros or poorly written hashmap implementations taken from somewhere. Glib2 is one excellent example of how people have been shunning C++ due to its complexity, w…

Absolutely. It makes perfect sense, and in an ideal world this would be the direction which would benefit many, if not most, projects using C and/or GLib2. Unfortunately, there are far too many people who are wedded to the philosophy that C is perfect for every task, and C++ is the devil. Despite the fact that GLib/GObject are more complex than C++, more error-prone than C++, slower than C++ and make static code anal…

Post by pjmlp » Sat, Jan 23, 2021, 10:52 AM UTC

waltersx wrote: post #45

netheril96 wrote: post #42

Earlier quoted context omitted.

Google writes a lot of C++ code, disables exceptions entirely, and it does not shy away from STL at all.

Then they don't care about applications being terminated in case of std::bad_alloc and similar. The crucial applications they use are written by others (like the Linux kernel). Also, having seen the output of several Googlers, I think their code quality is overrated.

   auto ptr = new (std::nothrow) ......
   if (ptr != nullptr) {
       //........
   }