Thread: [C++11] Delete all parent methods of a given name

I'm writing a sorted vector implementation and trying to do it as simply as possible.

Right now, I'm declaring the sorted vector with a protected subclass of vector, then using the "using" keyword to explicitly inherit all methods that aren't related to adding new elements to the vector (so I can control the order).

Eg:

Code:

template<typename T, class Cmp = std::less<T>>
class sorted_vector : protected std::vector<T>{
public:
    typedef typename std::vector<T>::iterator;

    using std::vector<T>::operator=;
    using std::vector<T>::assign;
    using std::vector<T>::get_allocator;

    using std::vector<T>::at;
    using std::vector<T>::operator[];
//...
};

Obviously, this is annoyingly redundant. So what I'd like to do is something using the new "delete" keyword from C++11. Is there any quick, expressive way of deleting specific methods?

Also, it's pretty annoying to have to
typedef base_class::type type
to inherit a type from a base class. Is there a shorter way to do that?

So something like

Code:

template<typename T>
vector<T>::iterator sorted_insert(vector<T> &vec, T &val){
    // do stuff
}

Is that what you mean?

O_o

If you do go that route, follow in the footsteps `std::make_heap' and friends. You'd have (want) to overload these utility functions with an option for specifying a comparator defaulting to "less than".

That said, I'm against what laserlight suggested because, ultimately, most people who go this path don't do the work. (The standard library doesn't do the work.) Placing the burdens of a special form of container on a new interface using the same typing significantly complicates generalization. For example, the same type of container template and underlying interface is involved so you can't easily generalize the process of reading a file by entry and storing it into all such specializations of a container. (Here the use of "special" and "specialization" isn't referring to templates.) For those not aware, the standard containers do not support inheritance based polymorphisms so that approach will not work.

With that in mind, it is possible to do the work correctly by also implementing iterators generalizing over a container's specialty and simply implementing such processes with the relevant iterator abstraction. So, for example, you might have an `sort_insert_iterator' and the associated `sort_inserter' each optionally binding to a specified comparator. In other words, you change the type on which such processes operate through decoration keeping the interface the same by using already established abstractions. (These would be the type of the iterator and the "inserting iterator" respectively.)

All of that said, I'd recommend just using a class without the inheritance. You can define whatever methods you want and only those methods. You can still "contain" a `std::vector<???>' to do the heavy lifting. With that done, if you implement at least the required methods, existing generalizations (implementations of a process) using the standard container abstraction, like `push_back', will work "out of the box".

Soma

Likely, it means instead of typing out 50 functions, only type out a handful "disallowed" functions.

O_o

I'd argue that inheriting for implementation only to then specifically list a function as "This does not exist!" is the wrong approach even if the language directly supported `deleted' for arbitrary functions.

Sure, it takes a few minutes, but it isn't as if it will consume a lot of time to get this same functionality with `std::vector<???>' still doing the work.

No such feature exists in C++ to my knowledge.

Well, there is a way, but it is up there with binding a reference to null so I will not discuss it.

Soma

Isn't that the point behind inheriting protected?

O_o

No.

Using `protected' inheritance says `public' and `protected' methods of the base class are `protected'.

You aren't saying "This method is fine." and "This method breaks invariants." with `protected' inheritance. You are saying "The following methods are available with normal restrictions.". That is a different beast from saying "The following method does not exist in the interface for this class.". Code is written for people; you should document, by virtue of the value of canonical semantics the interface you make available.

With `protected' inheritance, you are saying that only derived classes should depend on an interface. I believe you are shooting for "The following interface should never be used.". You should do that by not doing that at all; you should say "The following is the interface for this object."; you do that, in this case because you are using another object to do much of the work, by containment or `private' inheritance with `using' directives.

I'm only asking for finer grained control over the visibility of inherited functions.

I know what you are asking.

What you are asking for isn't problematic; that exists, and it is useful.

My problem is how you are asking to accomplish what you wish to accomplish.

If all protected or all public are viable options, why isn't some protected and some public?

There is absolutely nothing wrong with what you describe. I did not suggest otherwise.

I'm saying that the intended interface should be directly specified using canonical semantics.

So why not have something that says, "this messes with the invariants of my design, don't allow it"?

Why are you saying "This interface is available to derived classes." if your class design doesn't allow for them? That's the problem I have with this scenario. You are saying something with the code that you are clearly not intending to say.

For the sake of argument though, let's assume that a fourth form of inheritance was available. (You may call it whatever you like.) I'd still argue that listing a function in the interface as "The following interface does not exist in this object." has poor semantic value versus saying "The following is the interface for this object.".

By "quick" I mean without so much pointless code for something that should be simple. Clean, as someone else has already said, is a better way to put it.

I do not perceive either method as having any "pointless code". (I believe you are using the wrong form of inheritance, but the method of inheritance paired with `using' directives is fine.) I've worked with a lot of libraries that have awful documentation. In some cases, the headers are all you have available. Sometimes the headers are also awful. Sometimes the headers are great. The code you suggest as "pointless" provides valuable documentation of the intended interface.

I know what I'm doing, and can implement a naive vector in a relatively short amount of time. But I'd assume they probably use some heuristics for preallocation and other optimizations that would be a pain to rewrite. That and it's a lot of work for nothing.

Well, that's all really besides the point I was making, and it certainly has nothing to do with my suggestion, but with that in mind, I too suggest you read the link iMalc provided. I no longer use "Loki", but I did for a long time. It has some great facilities.

Soma

Soma