|
Sorry to disappoint you, but I am a mere mortal programmer.  I don't have time to brute force passwords and such...
|
|
|
|
|
That's because you do not use private and protected inheritance...
|
|
|
|
|
|
I have used private inheritance. The base class public access members are still public access in the derived class. Therefore the derived class still can call the base class functions and access its public data. But the user who instantiates the derived class, cannot access the public member of the base class, hence private inheritance.
Public inheritance is a "is-a" relationship.
Private inheritance is a "implemented-in-terms-of" relationship.
A useful example, is I like .NET string class and like a C++ string class with the same C# methods but I do not want to reimplement from scratch, so I derived from std::wstring with private inheritance to make use of its functionality, so that user of my string class cannot access the base class's std::wstring to avoid the confusion.
class MyString : private std::wstring
{
};
There is an excellent blog about this topic: C++ Tutorial: Private Inheritance - 2020
|
|
|
|
|
|
Hi David,
According to this, private inheritance in C++17 is primarily used whenever you're having a need to make all those public and protected members, in a base class, to become private in all derived descendant classes, and, thus not accessible via a derived class object.
Whist, according to this, all public and protected members of a base class become protected in all derived classes. This is typically needed to make those public members of a base class to become protected in all descendent classes, rather than those methods are accessible via a derived class object.
|
|
|
|
|
One instance where I used private inheritance in pre C++ 11 days was to easily make a class non-copyable:
class fancy_type : private boost::noncopyable
{};
|
|
|
|
|
At the end of the day, it’s a way to implement your public interface to the world without your clients being exposed to the details. You have many options to implement that interface; code directly in the class, delegating to others (composition) or inheriting it.
Imagine parallel universes, there is the public one that clients exist in and another that the non-public stuff lives in. Both (potentially) have a need for inheritance either to represent a natural taxonomy (CheckingAccount isa Account, etc) or for reuse (Account inherits Persistent, Equatable). I say “potentially” because out of all the ways to implement your public interface, inheritance is by far the worst in my opinion - it’s the road to spaghetti code  .
|
|
|
|
|
Basically, public inheritance is an "IS-A" relationship while protected or private inheritance is a "HAS-A" relationship. A "HAS-A" relationship is like aggregation.
|
|
|
|
|
The only time I've used it is when deriving from a class to make use of its functionality, but not wanting to make all of the public base class members accessible. For example, making a fixed vector class that you can iterate over:
#include <iostream>
#include <vector>
template <class T> struct fixed_vector : private std::vector<T> {
using std::vector<T>::vector;
using std::vector<T>::begin;
using std::vector<T>::end;
};
int main() {
auto f = fixed_vector<int>{1,2, 3,4 ,5};
for(const auto i : f) {
std::cout << i << std::endl;
}
f.push_back(10); }
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
David O'Neil wrote: have you ever used protected and private inheritance?
All the time. Public is for the public parts of the interface to the class. The others are for the internal implementation details -- the parts we want to be free to rewrite and refactor without consequence. In my experience, a bigger public interface to a class means tighter coupling over time since other developers don't have to think very carefully about how their usage tightens the coupling, so they don't and just go ahead and use it.
5G -- more lies faster.
|
|
|
|
|
That is a great response, that makes me see things in a new light! Thanks! It is especially helpful breaking free from the 'aggregation/inheritance' argument, that never really made any sense to me since private inheritance is NOT aggregation!
|
|
|
|
|
Generally speaking, they are part of the encapsulation of function of your class - gating the interface is what I call it.
With that said, I live in the embedded world where so little code re-use occurs (other than cut/paste), OOD is routinely ignored.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
|
"The best of life is the simple things..."
|
|
|
|
|
Dim light bulbs or bright light bulbs - Watts the difference?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That one's so bad it's shocking! I just may end up needing an IV to get through this.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
There are some witty answers lumen in the future. Fluorescent, or better, two, I'd say you have gotten your two cents worth in.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Management vs. Engineering?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
OriginalGriff wrote: Dim light bulbs or bright light bulbs - Watts the difference?
Neh! It's cost.
|
|
|
|
|
Watt LED you to post this?
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
Wire you asking?
This question induces resistance in me.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Ohm, maybe you should conduct yourself a little better... 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
|
Questions like this make me incandescent - Joule have to ask somebody else.
|
|
|
|
|
Does anyone else think coding interviews are fundamentally broken? So like, literally I've been doing this (programming) my whole life. We can all go through our accolades I'm sure, but suffice it to say I've done some things over the years to help rebuild departments in large corporations to garner the attention of regional VPs, etc. as we all have. But, I say this because, two days ago, I had an interview with Unnamed Company That Rhymes With Acelook. Don't get me wrong, they were super friendly, and it was a great chat. But I was asked questions like...
Are you comfortable with writing APIs on the backend?
That's a generic question, so of course I say sure. To me this indicates the interviewer doesn't realize the best way to interview. No real probing... just questions like that. Ok, cool. Still was a great, super friendly chat. But, then the tech portion of it came up. I was asked this...
Ok fine... I get how this game works. So, let's get cracking. The first solution I start with used two arrays. Cool, no biggie. But then the interviewer asked for me to do it in-place. Ok, fine. So, I write some code that is like a bubble sort that brute forced it (ie, nested loops). We all know that it sucks to have nested loops. Anyway, the interview was cut short and that was that. I look up the "official" solution online, and it's no better than my first attempt. In fact, my first attempt was quicker due to only one loop. The one I linked to was using two loops that just weren't nested.
So, not only did my original solution avoid two loops (using more memory though), but I found a more elegant solution online and I just know if that interview wasn't cut short I could've tried something like this the third go-round...
void moveZeroes(vector<int>& nums) {
for (int lastNonZeroFoundAt = 0, cur = 0; cur < nums.size(); cur++) {
if (nums[cur] != 0) {
swap(nums[lastNonZeroFoundAt++], nums[cur]);
}
}
}
But since I didn't try something like this first, I got passed on.
Does anyone else think that's a fundamentally broken way to find a good programmer? Let's be real... once you get the job how often to you spend your day doing algorithms for a typical LOB app? Never. No questions about how well you handle problems, how do you deal with other developers, how do you scale, etc. Not to sound sour, but to reduce a 25 year professional to that... something is wrong with the industry. Imagine hiring a lawyer and turning him down because you Googled something online that's obscure and never used.
Anyone else agree this is fundamentally broken?
[Edit] This is not a bash management or people that conduct interviews type post. My recruiter was fantastic. The interviewer was friendly and knowledgeable. I'm just pointing out the broken process we all put ourselves through. [/Edit]
Jeremy Falcon
modified 24-Sep-20 7:59am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
