开云体育

The major culprit in bloat is OOP. Tables of pointers to tables of pointers to tables of pointers. In feature rich classes, all those tables of pointers take up a huge amount of memory.

Not necessarily so - well designed class structures in C++ can and often will result in a smaller memory footprint than a traditional C application - stress being on well designed!

A case in point was some code I wrote back in the day (early noughties) in C++. I had to re-implement it in C for one platform whose C++ compiler was not brilliant so the client said it had to be in C. The C code was about 50% larger and had a slightly larger working set (and yes I did work hard to keep both size and working set down).

Multiple inheritance - probably the less used the better - it's one of those things in C++ that can really ruin your week. There are some situations where it can be helpful, but I've seen too many cases of slicing to want to use it unless I am caught between a rock and hard place, and generally there's a better way.

Stupidly long compile times - if you don't use PImpl classes and other good OOD practices, you deserve to suffer!

David

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Reginald Beardsley via groups.io
Sent: 25 April 2020 00:56
To: [email protected]
Subject: Re: Decline, was Re: [HP-Agilent-Keysight-equipment] new File called App notes

At USENIX '95 in NOLA I got a 1.44 MB Plan 9 floppy with the OS, windowing system, editor and basic command line utilities and full Unicode support.

I was very interested in Plan 9 because it intended to support 35,000 users. However, I had a long chat with Dennis Ritchie who told me that they had not implemented that yet and had been diverted to other projects. It was very different, but quite amazing. And is still running on a huge machine at one of the national labs.

The major culprit in bloat is OOP. Tables of pointers to tables of pointers to tables of pointers. In feature rich classes, all those tables of pointers take up a huge amount of memory.

My professional experience led me to conclude that very few programmers actually have any grasp of what the machine is doing when they write a line of code.

Worse than that, if multiple inheritance is used it will require reading *all* the source code, the C++ language standard and the compiler implementation notes to determine what

A = B + C;

actually does. In such cases, the order of execution of constructors is "implementation defined". And the "+" operation is dependent upon the inherited traits of A, B & C and the perversity of the programmer.

This is why I do not use C++ and will not work on C++ codes. I've brought 2.5 million lines of old C & FORTRAN back from the dead and never failed. I've never gotten a C++ code which was more than 1-2 years old to compile. It's probably better now as I've been retired from such misery for 15 years. But I've made very old C and FORTRAN codes run and fixed the bugs. Fundamentally because I knew exactly what the machine was supposed to do when it encountered a statement.

I once wrote a string substitution in C and C++. Very simple, replace "aaa" with "bbb". The C version was 2/3 of a page. The C++ version took 3 pages. At the start of the project I posted a page from the book by John Lakos on large C++ systems where he pointed out the issues with pathological linker dependencies. It was ignored and I took it off my door after a few weeks. About 3 months later, the entire project ground to a complete halt as it would no longer compile overnight leading to urgent team meetings to fix the problem. I was quite amazed when one of the C++ developers pulled a copy of the page that had been on my door some months earlier out of his desk drawer. The team lead and the $100/hr C++ guru had ignored it.

Reg