-
Do not confuse the languages with the standard libraries
Java's properties enabled the remarkably rapid creation of complex libraries that had eluded the C++ community for a decade. And, unlike various vendor's C libraries, they all plugged and played nicely with each other.
C is irregular, and has too many "gotchas", i.e. surprises that trip up most programmers.
Java is, by comparison, a simple language where James Gosling took a very well chosen subset of concepts proven over decades, and melded them into a coherent whole. When I read his 1996 whitepaper, I repeatedly said "yes that's what is needed and it will work". C is the heroic sum of many many sticking plasters accredited over the decades. Java is a tasteful collection of concepts, but I will admit some of the newer ones (e.g. Generics) are less pleasing because they are constrained by the JVM axioms.
OTOH the C/C++ community repeated triumphantly reinvents well-known wheels, but makes them ellipical. If you doubt that, consider the belated acceptance that a memory model is necessary! -
C and Java fill almost disjoint niches. Aren't most JVMs written in C even though most of the rest of the "ecosystem" is written in Java itself?
The "problem" of C is that it sort-of-works for lots of people and there is apparently no one with resources or motivation to develop a clearly superior replacement, if that's even possible. If you try to "clean it up" too much sooner or later somebody will be disappointed and it will turn out that not one but at least a few replacements are needed. To an extent this is already happening with Java/C# displacing C in many applications. C is not defined by C standards, them being more like the lowest common denominator that most (and not even all) vendors reluctantly agree to support. Want a memory model? You have one in every operating system written in C. C is a product of evolution, not intelligent design.
As for Java generics, at least Java has generics, unlike most "C incremented" and "better than C" languages which can't even assign a meaningful type to stdlib's qsort. -
C and Java fill almost disjoint niches. Aren't most JVMs written in C even though most of the rest of the "ecosystem" is written in Java itself?
The "problem" of C is that it sort-of-works for lots of people and there is apparently no one with resources or motivation to develop a clearly superior replacement, if that's even possible. If you try to "clean it up" too much sooner or later somebody will be disappointed and it will turn out that not one but at least a few replacements are needed. To an extent this is already happening with Java/C# displacing C in many applications. C is not defined by C standards, them being more like the lowest common denominator that most (and not even all) vendors reluctantly agree to support. Want a memory model? You have one in every operating system written in C. C is a product of evolution, not intelligent design.
As for Java generics, at least Java has generics, unlike most "C incremented" and "better than C" languages which can't even assign a meaningful type to stdlib's qsort.
We are in violent agreement with most of those points I particularly like "C is a product of evolution, not intelligent design" and your equating Java with C#-not-Java-honestly.
I am perfectly happy with more than one "replacement" being needed for C. Use the right tool for the job in hand. Use VHDL/Verilog for describing hardware, Macsyma and derivatives when manipulating algebraic equations, R for statistics, etc, etc, etc. The C/C++ community is rife with people who believe that, since you can (eventually) use C/C++ for a problem, C/C++ is all you need to use. Hammers and screws spring to mind
Java generics are sufficient for container classes, and not much more. Useful, but underwhelming. For C++ generics, I'll refer you to the C++ FQA - and we can both enjoy ourselves reading that over the holidays
One neat counter example to the "importance" of the JVM being written in C is Squeak Smalltalk. The last time I looked that virtual machine was written in a subset of Squeak Smalltalk, which makes it very easy to bootstrap the system and to improve the system. Some people will incorrectly claim that doesn't count, since there are two intermediate languages involved: a small subset of C and an assembler language.
Yesterday's news: "With the upcoming Linux 6.8 kernel cycle, the first Rust network driver is set to be introduced." https://www.phoronix.com/news/Linux-6.8-Rust-PHY-Driver -
One neat counter example to the "importance" of the JVM being written in C is Squeak Smalltalk. The last time I looked that virtual machine was written in a subset of Squeak Smalltalk, which makes it very easy to bootstrap the system and to improve the system. Some people will incorrectly claim that doesn't count, since there are two intermediate languages involved: a small subset of C and an assembler language.
Time was when a large number of compilers were written in the language they compiled. Cheap computers, and the desire to make compilers multi-platform, kinda killed that, but it had huge benefits. It really kept you focussed on how well your compiler was doing on a complex real world problem - your compiler. Even when computers started to become more affordable and available quite a few compilers were built by using a language that makes the job fairly easy - like Snobol - on another machine, to get a very bare bones compiler going. Then you used that to build a basic native language compiler for the target machine, and moved on to only using the target machine and the native language to further develop. Its excellent discipline.
-
Yesterday's news: "With the upcoming Linux 6.8 kernel cycle, the first Rust network driver is set to be introduced." https://www.phoronix.com/news/Linux-6.8-Rust-PHY-Driver
Not sure whether this is a good thing as Rust as a language is pretty obscure. It is good to bring a language that has built-in OO support into the Linux kernel but realistically C++ is a much better choice for the simple reason C++ has been around longer, more people know it and thus make it easier to support the kernel. With Rust only a few can do kernel maintenance so chances are high nobody is going to touch it and the code gets abandoned (especially since the Linux kernel notoriously lacks decent comments). -
Putting C++ in the kernel would be a disaster. It carries so much baggage with it. I haven't used rust, but I understand it is designed to avoid that baggage, and produce a C like target from OO like source code. If it succeeds in that, then maybe its the real incremental step from C that the name C++ was chosen to imply, and C++ miserably failed to live up to.Yesterday's news: "With the upcoming Linux 6.8 kernel cycle, the first Rust network driver is set to be introduced." https://www.phoronix.com/news/Linux-6.8-Rust-PHY-Driver
Not sure whether this is a good thing as Rust as a language is pretty obscure. It is good to bring a language that has built-in OO support into the Linux kernel but realistically C++ is a much better choice for the simple reason C++ has been around longer, more people know it and thus make it easier to support the kernel. With Rust only a few can do kernel maintenance so chances are high nobody is going to touch it and the code gets abandoned (especially since the Linux kernel notoriously lacks decent comments).
-
Quote
On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
>
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
> it's BS.
*YOU* are full of bullshit.
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.
In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.
C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:
- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)
- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.
In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.
So I'm sorry, but for something like git, where efficiency was a primary
objective, the "advantages" of C++ is just a huge mistake. The fact that
we also piss off people who cannot see that is just a big additional
advantage.
If you want a VCS that is written in C++, go play with Monotone. Really.
They use a "real database". They use "nice object-oriented libraries".
They use "nice C++ abstractions". And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess.
But I'm sure you'd like it more than git.
Linus
https://harmful.cat-v.org/software/c++/linus
I still fully agree with Linus.
-
Yesterday's news: "With the upcoming Linux 6.8 kernel cycle, the first Rust network driver is set to be introduced." https://www.phoronix.com/news/Linux-6.8-Rust-PHY-Driver
Not sure whether this is a good thing as Rust as a language is pretty obscure. It is good to bring a language that has built-in OO support into the Linux kernel but realistically C++ is a much better choice for the simple reason C++ has been around longer, more people know it and thus make it easier to support the kernel. With Rust only a few can do kernel maintenance so chances are high nobody is going to touch it and the code gets abandoned (especially since the Linux kernel notoriously lacks decent comments).
Torvalds has good taste, IMNSHO, as per Karel's preceding post.
Way back in 1988 I had severe doubts about C++, and everything I have seen since then merely confirms that suspicion. Fundamentally, if C++ is the answer, you asked the wrong question.
In one respect I'm surprised Torvalds is allowing anything other than C into the kernel. In other respects Rust does bring useful possibilities to the table. Maybe I'll even use Rust someday. If it has an ecosystem as interesting, fun, and easy as xC then it shouldn't be too much of a pain
-
Java generics are sufficient for container classes, and not much more. Useful, but underwhelming.
Containers and std::algorithm stuff would already be a big win for the kind of software that gets written in C, but C doesn't have proper generics so it's void* all over the place.
Linux for instance makes wide use of generic containers (lists, hashtables, trees). Each time you iterate over the container you need to know what elements it holds and cast appropriately. Simple type erasure (aka parametric polymorphism, idea as old as C) could tidy up the code and make it robust against oopsies.
A further detail is that these are intrusive containers - you put "struct list_head list;" in your object and the object can be linked into lists by means of pointers in this member object, using completely generic list code which only cares about list_heads. So they also have a "container_of" macro which takes you from a list_head or similar object back to the object which contains it, provided that you know all the types and member names.
Trivial stuff which could be a language feature but isn't, the closest analog being C++ static_cast<> but it only works with that multiple inheritance nonsense, not ordinary aggregates. And it's unsafe, because the language is stupid and has no concept of "struct list_head which is also the member 'list' of struct Foo".
Simple type system extensions like generics and "member element types" could make existing C code cleaner and safer with zero runtime overhead and only minor editing - remove casts, add more sophisticated type annotations. No one appears to be working on such things, save for obscure research languages, mostly functional, so pretty much guaranteed to never gain mainstream acceptance.For C++ generics
C++ doesn't have generics besides void* it inherited from C and virtual methods, which are syntactic sugar over tables of function pointers that C also has.
C++ has templates, and they do exactly what you'd expect: generate a lot of repetitive code.Yesterday's news: "With the upcoming Linux 6.8 kernel cycle, the first Rust network driver is set to be introduced." https://www.phoronix.com/news/Linux-6.8-Rust-PHY-Driver
Frustration with C is no reason to fall for Rust hype. Rust was created by C++ developers and as such it inevitably amounts to little more than somebody's favorite "safe subset of C++", because your (stereo)typical C++ developer has never known anything other than C++. This includes C.
Rust has no generics either and what they disingenuously call generics is templates. I am at all unconvinced that this language has any ability to produce efficient and lightweight containers of the sort that Linux uses, without resorting to void* trickery, maybe with "unsafe" prepended to it
There was already an attempt to rewrite Linux in C++. -
Way back in 1988 I had severe doubts about C++, and everything I have seen since then merely confirms that suspicion.
When I read the original Bjarne Stroustrup book in the mid 80s I thought it had real potential. It addressed a number of the weaknesses in C, like it bundled both data and its related functions into a class/struct, where they should have been from the start. The problems started when others got hold of it, and there was no longer one person's vision driving it. Even by the time of the first edition of the book he had clearly been pushed to add more than his original vision of a incremental change from C, but it was still looking OK.Fundamentally, if C++ is the answer, you asked the wrong question.
If the question is "how should I develop this elaborate graphics application", C++ isn't such a terrible answer. The problem is people get so focussed on that type of problem when teaching and thinking about C++ that they've built a system that hammers everything into that mould.
-
Magic's post... https://www.eevblog.com/forum/programming/comments/msg5229423/#msg5229423
Understood and accepted.
I don't think it matters who created Rust, but the more languages they knew the better. The more languages the higher the probability they will extract the good bits and avoid the bad bits. That was very clearly demonstrated in Gosling's 1996 Java whitepaper.
If Rust was only a "simple safe subset" of C++, that would be a beneficial step. Rust adds extra novel capabilities on the form of ownership and non-mutability. That is absolutely vital with today's multicore processors and MCUs. C/C++ is painfully inadequate for those. -
Way back in 1988 I had severe doubts about C++, and everything I have seen since then merely confirms that suspicion.
When I read the original Bjarne Stroustrup book in the mid 80s I thought it had real potential. It addressed a number of the weaknesses in C, like it bundled both data and its related functions into a class/struct, where they should have been from the start. The problems started when others got hold of it, and there was no longer one person's vision driving it. Even by the time of the first edition of the book he had clearly been pushed to add more than his original vision of a incremental change from C, but it was still looking OK.
Even then it was only good if you hadn't been exposed to the.existing alternatives, Smalltalk and Objective-C.
Having written a small application in Smalltalk to "kick OOP 's tyres", I tried complementing it in Objective-C and C++. The Objective-C version was quickly and easily completed, partly due to its container classes. The C++ version was never completed, partly because of the lack of container classes but more importantly because it forced me to concentrate on irrelevant details andifwhen I made an inappropriate choice it was exceptionally difficult to reverse the choices.
I prefer to concentrate on satisfying my objectives, not on satisfying the tool.
It took C++ far far too long to have container classes (or even a String class!), and the tooling was incomprehensible, by all accounts.QuoteFundamentally, if C++ is the answer, you asked the wrong question.
If the question is "how should I develop this elaborate graphics application", C++ isn't such a terrible answer. The problem is people get so focussed on that type of problem when teaching and thinking about C++ that they've built a system that hammers everything into that mould.
Around 1992 I saw some people develop a GUI for an SDL (i.e. FSM) compiler. (My contribution was merely to create the hardware interface to the HP8920 GSM testset). They spent many man years on the GUI. I could have done something far better and sooner in Smalltalk. Yup, C++ was the wrong starting point for that GUI application
-
Even then it was only good if you hadn't been exposed to the.existing alternatives, Smalltalk and Objective-C.
I really disliked Objective-C. The functionality was good, but the way the extra syntax was fudged onto the existing C syntax felt horribly wrong.QuoteAround 1992 I saw some people develop a GUI for an SDL (i.e. FSM) compiler. (My contribution was merely to create the hardware interface to the HP8920 GSM testset). They spent many man years on the GUI. I could have done something far better and sooner in Smalltalk. Yup, C++ was the wrong starting point for that GUI application
In the 80s a colleague avoided all that hassle. He made some templates for Autocad, to easily draw ITU standard SDL, and a fairly simple program to compile the drawings into the tables for the FSM.
-
In the end there is no substitute for competent engineers. But you also need to optimise your choices to the kind of engineers available. For example: I'm not a fan (to put it mildly) of Altium for schematics and PCB design and rather not touch it. But if a customer asks what would be a good package for doing simple PCBs themselves or outsource I can't go around the fact that Altium is pretty much industry standard. So unless there is a good reason to recommend something else, I still recommend the customer to outsource to somebody who uses Altium because the chances are high it is easy to find somebody to take over and/or get an in-house engineer to work on the designs.
-
Even then it was only good if you hadn't been exposed to the.existing alternatives, Smalltalk and Objective-C.
I really disliked Objective-C. The functionality was good, but the way the extra syntax was fudged onto the existing C syntax felt horribly wrong.QuoteAround 1992 I saw some people develop a GUI for an SDL (i.e. FSM) compiler. (My contribution was merely to create the hardware interface to the HP8920 GSM testset). They spent many man years on the GUI. I could have done something far better and sooner in Smalltalk. Yup, C++ was the wrong starting point for that GUI application
In the 80s a colleague avoided all that hassle. He made some templates for Autocad, to easily draw ITU standard SDL, and a fairly simple program to compile the drawings into the tables for the FSM.
I don't disagree about the syntax, but I've always been more concerned with semantics than syntax. Besides, the message passing paradigm plus inheritance was a major graft onto C, so a major graft onto the syntax didn't seem inappropriate.
(Syntax exception: where whitespace is semantically significant. Think makefiles and Python),
I don't disagree about post processing some other graphical representation; even I had that concept in ~1984 (before I played with Apple Smalltalk on a Fat Mac. Basically anything but C++ seems to be a sound guiding principle
-
In the end there is no substitute for competent engineers. But you also need to optimise your choices to the kind of engineers available. For example: I'm not a fan (to put it mildly) of Altium for schematics and PCB design and rather not touch it. But if a customer asks what would be a good package for doing simple PCBs themselves or outsource I can't go around the fact that Altium is pretty much industry standard. So unless there is a good reason to recommend something else, I still recommend the customer to outsource to somebody who uses Altium because the chances are high it is easy to find somebody to take over and/or get an in-house engineer to work on the designs.
Agreed, but I'm not competent to comment about Altium.
I've always explicitly avoided being in a position where C++ was required. -
When I read the original Bjarne Stroustrup book in the mid 80s I thought it had real potential. It addressed a number of the weaknesses in C, like it bundled both data and its related functions into a class/struct, where they should have been from the start. The problems started when others got hold of it, and there was no longer one person's vision driving it.
The problem was right at the point when he decided to put code inside data structures, the rest was a consequence.
What you wrote is the basic dogma of object orientation, and it inevitably fails when when you need to do X to two different types A and B. So you have these options:
1. Copy X to both A and B, remember to update both copies when you fix a bug or add features to X. I suppose this can work too...
2. Make X a method of a pointless Xdoer type and reduce types A and B to dumb accessor functions around their data. You are Java.
3. Make X a method of a pointless Xable type and derive types A and B from Xable, which inevitably leads to...
4. Multiple inheritance, because A and C but not B are actually Yable too, and which may also lead to...
5. Templates, because sometimes loads of pointless types and hidden function pointers behind the programmer's back is too much overhead - ask Java.
6. You are C++ now.
Object orientation is cancer and a poor bandaid over lack of foresight and modularity. In Java it reportedly also serves as a hammer to force at least some modularity on programmers lacking in foresight...
What you actually need is:
1. Modularity - restricting which code accesses which data.
2. Interfaces - common way of manipulating different data by generic code.
3. Flexilibity of implementation - sometimes code duplication may be worth the cost, sometimes a single function pointer is enough and there is no justification for dragging along vtables with each piece of data. In some cases this necessitates choosing between languages, like C++ vs Java.
4. Sensible defaults and a way of changing them when justified would be the holy grail.
C actually comes close to the holy grail, but it lacks syntatic sugar for these techniques, lacks templates, and some argue that it makes bypassing abstract interfaces too easy. -
...
C actually comes close to the holy grail, but it lacks syntatic sugar for these techniques, lacks templates, and some argue that it makes bypassing abstract interfaces too easy.
C also adds some other characteristics, including baked in undefined behaviour and implementation behaviour that continues to catch programmers out, the ability to treat a camel as if it is a horse, poor multithread/multiprocessor capabilities, and a complexity that confuses compiler creators.
You can argue the first isn't a problem, iff you only employ "Lake Woebegon"[1] programmers, and they either write all the code in their application or they ensure all libraries are written by Lake Woebegon programmers. Good luck with that!
You can argue the second isn't a problem provided you can prove that a camel==horse in the specific circumstances, and that mistakes reliably cause traps, and that all hardware functions perfectly. Good luck with that! If you can do all that, then you might also be able to spelunk core dumps to figure out what was going on.
You can argue the third isn't a problem with the latest language standards, provided you are allowed to use them and the tools have correctly implemented the language and that the memory model is correct in the hardware you are using.
You can argue the last isn't a problem, provided you don't know where the skeletons are buried because you haven't been in the position of having to fault-find other intelligent programmer's code over decades. Nick MacLaren was in that position at the University of Cambridge where (as always) the High Performance Computing requirements pushed the avallable hardware and software to the limits. He was regularly approached by compiler writers asking him to explain what the standards meant! FFI, see the comp.lang.c and comp.arch usenet archives.
[1] where all children are above average -
This was a rant specifically about modularity, abstraction and object orientation. In this context the disadvantages to Java are arbitrary (and widespread) type casting and lack of syntactic sugar. The disadvantages to C++ are very primitive code generation facilities.
I'm not going to end every post about C with a full list of things that people consider wrong with C
UB is idiotic, as is the fact that both ISO and compiler vendors consider it acceptable instead of at least IDB, lack of memory management is considered dealbreaker by most, some features are obsolete relics of PDPwhatever assembly language, you need to memorize operator precedence to understand type declarations, ...
-
...
C actually comes close to the holy grail, but it lacks syntatic sugar for these techniques, lacks templates, and some argue that it makes bypassing abstract interfaces too easy.
C also adds some other characteristics,
...
[1] where all children are above average
Didn't you leave out some context from that quote? -
This was a rant specifically about modularity, abstraction and object orientation. In this context the disadvantages to Java are arbitrary (and widespread) type casting and lack of syntactic sugar. The disadvantages to C++ are very primitive code generation facilities.
I'm not going to end every post about C with a full list of things that people consider wrong with C
UB is idiotic, as is the fact that both ISO and compiler vendors consider it acceptable instead of at least IDB, lack of memory management is considered dealbreaker by most, some features are obsolete relics of PDPwhatever assembly language, you need to memorize operator precedence to understand type declarations, ...
At least with Java it is impossible to have incorrect type casting. Most incorrect typecasts never even reach the compiler, since the strong typing allows the IDE "cntl-space" to avoid suggesting them. Any incorrect typecasts that cannot be detected at compile time will be trapped at runtime. Then an IDE or stacktrace leads to the cause of the problem, unlike a coredump that was corrupted an arbitrary time in the past.
I'm not so worried about the PDP11's assembler being codified in C syntax. Far more problematical is the PDP11's processing power and "primitive" compiler technology still "corrupting" C's semantics. -
...
C actually comes close to the holy grail, but it lacks syntatic sugar for these techniques, lacks templates, and some argue that it makes bypassing abstract interfaces too easy.
C also adds some other characteristics,
...
[1] where all children are above average
Didn't you leave out some context from that quote?
Yes, quite explicitly, and with a direct pointer to the full post and a direct pointer to the source of the quote.
Which bit do you consider important to the point I made? -
...
C actually comes close to the holy grail, but it lacks syntatic sugar for these techniques, lacks templates, and some argue that it makes bypassing abstract interfaces too easy.
C also adds some other characteristics,
...
[1] where all children are above average
Didn't you leave out some context from that quote?
Yes, quite explicitly, and with a direct pointer to the full post and a direct pointer to the source of the quote.
Ah, I hadn't realised one had to deliberately not quote the full thing.QuoteWhich bit do you consider important to the point I made?
No idea. Perhaps if you'd just quoted that part I'd know. -
I don't think it matters who created Rust, but the more languages they knew the better. The more languages the higher the probability they will extract the good bits and avoid the bad bits. That was very clearly demonstrated in Gosling's 1996 Java whitepaper.
I never said it's simple and it isn't. Maybe simpler than C++ by the looks of it, but that's not saying much and it isn't worth much unless you are migrating from C++ rather than C. My recollection of reading their documentation and tutorials was "lots of language features, lots of jargon, lots of cryptic syntax" and you won't get far without being familiar with it all because the features are tangled with each other and widely used. Deciphering Rust code made me feel like I'm reading STL headers.
If Rust was only a "simple safe subset" of C++, that would be a beneficial step. Rust adds extra novel capabilities on the form of ownership and non-mutability. That is absolutely vital with today's multicore processors and MCUs. C/C++ is painfully inadequate for those.
The part about knowing other languages and extracting good bits from them is actually ironic, because what I forgot previously is that Rust designers were apparently ML fanboys too as the language borrows a bunch of syntax from there. ML has generics, but Rust chose templates and code generation as the answer to everything.
My impression is that it's at best a "sidegrade" from C. May fix some problems, will create others. -
So, you are a deranged fanatic? No middle ground allowed? There are functions so generic they shouldn't be bundled with anything, and there are functions so specific they really should be bundled with the only structures they can possibly work with. Bundling function declarations with the only structures they make sense with is a good practice, used by a number of entirely non-OOP languages which came before C. It can massively speed up getting familiar with code if the implicit association of a function with its related data structures is clearly signalled. I've been there a number of times, and hoped long and hard that the original developers have a painful time on the toilet. Sod comments. They are unreliable, and 5 years in will be mostly misleading. Signalling that gets compiled has to be what the final code is really about, and is a HUGE boon for clarity. I'm highly suspicious of people who use the term "syntactic sugar". They are usually people writing obtuse code, badly laid out on the page, which is easily screwed up by the odd misplaced bracket that is hard to count your way through and check. Syntax means little to a machine, but is means a HUGE amount to a developer trying to keep things clear.When I read the original Bjarne Stroustrup book in the mid 80s I thought it had real potential. It addressed a number of the weaknesses in C, like it bundled both data and its related functions into a class/struct, where they should have been from the start. The problems started when others got hold of it, and there was no longer one person's vision driving it.
The problem was right at the point when he decided to put code inside data structures, the rest was a consequence.
What you wrote is the basic dogma of object orientation, and it inevitably fails when when you need to do X to two different types A and B. So you have these options:
1. Copy X to both A and B, remember to update both copies when you fix a bug or add features to X. I suppose this can work too...
2. Make X a method of a pointless Xdoer type and reduce types A and B to dumb accessor functions around their data. You are Java.
3. Make X a method of a pointless Xable type and derive types A and B from Xable, which inevitably leads to...
4. Multiple inheritance, because A and C but not B are actually Yable too, and which may also lead to...
5. Templates, because sometimes loads of pointless types and hidden function pointers behind the programmer's back is too much overhead - ask Java.
6. You are C++ now.
Object orientation is cancer and a poor bandaid over lack of foresight and modularity. In Java it reportedly also serves as a hammer to force at least some modularity on programmers lacking in foresight...
What you actually need is:
1. Modularity - restricting which code accesses which data.
2. Interfaces - common way of manipulating different data by generic code.
3. Flexilibity of implementation - sometimes code duplication may be worth the cost, sometimes a single function pointer is enough and there is no justification for dragging along vtables with each piece of data. In some cases this necessitates choosing between languages, like C++ vs Java.
4. Sensible defaults and a way of changing them when justified would be the holy grail.
C actually comes close to the holy grail, but it lacks syntatic sugar for these techniques, lacks templates, and some argue that it makes bypassing abstract interfaces too easy.