34

In Nicola Gigante's lecture in 2015, he mentions (at the beginning) that there are no pure virtual functions in the Standard Library (or he's not aware of any). I believe that Alex Stepanov was against this language feature but since the initial STL design, have any pure virtuals creeped into the Standard library?

FWIW (and correct me if I'm wrong) the deleters in unique pointers ultimately use virtual dispatching in most implementations but these are not pure virtuals.

curiousguy
  • 8,038
  • 2
  • 40
  • 58
Lorah Attkins
  • 5,331
  • 3
  • 29
  • 63
  • 1
    Do you mean the entire Standard Library or just the `STL` (iterators, algorithms and containers) part? – Galik Jan 26 '16 at 23:43
  • I'm not aware of any pure virtual functions in the standard library. The default deleters for `unique_ptr` are very non-virtual, so unsafe if you cast up to non-polymorphic base class. `shared_ptr` on the other hand, keeps a type-erased deleter function with the original pointer, so is safe that way. – Cheers and hth. - Alf Jan 26 '16 at 23:44
  • Any class having a pure virtual function wouldn't be instantiable. I'm unaware of any standard classes that are only meant to be used as base classes and not directly usable themselves. – Mark Ransom Jan 26 '16 at 23:56
  • I just watched this yesterday! I should've come here and asked. ;) – erip Jan 27 '16 at 00:07
  • 3
    I have not listened to the lecture but it appears to be about generic programming and the `STL`. I suspect then that the point is that, in `C++` *generic programming* as implemented in the `STL` is completely orthogonal to what might be considered typical methods in *Object Oriented Programming*. – Galik Jan 27 '16 at 00:17
  • Exactly the question I had on my mind after listening to the talk ;) – vsoftco Jan 27 '16 at 00:21
  • 1
    Do you want it to be *specified* as being pure virtual, or would a particular std library implementation using pure virtual methods qualify? – Yakk - Adam Nevraumont Jan 27 '16 at 01:17
  • 1
    STL != Standard Library – K-ballo Jan 27 '16 at 03:15
  • @K-ballo I think I'm making a very clear distiction and only use the term "Standard Library". STL is correctly used to refer to the library designed by Stepanov and created in SGI – Lorah Attkins Jan 27 '16 at 08:03
  • @LorahAttkins: You imply that the STL preceded the Standard Library. That's not exactly the case: there was a significant draft Standard Library back in 1995, when the STL was merged into the Standard Library. – MSalters Jan 27 '16 at 09:05
  • @MSalters No, I'm not. I'm saying that Stepanov, who designed the STL, was not a fan of virtuals, so that part of the Standard libray was likely "virtual-free"; but since then does the stdlib (as a whole - even the parts that evolved from the STL and the legacy C libraries - that are even more difficult to add new styles) have any virtual calls? – Lorah Attkins Jan 27 '16 at 12:47
  • @MSalters the "significant draft Standard Library back in 1995" was mostly the C standard library – Lorah Attkins Jan 27 '16 at 12:49
  • 1
    @LorahAttkins: No it wasn't. Just to name a few parts that are neither derived from C nor part of the STL : The whole of , `std::string`, `std::complex`, exceptions. Now `std::string` and `std::complex` are generally too time-critical to use virtual functions, nor is there a need to - polymorphism simply isn't needed for straightforward values. But and exceptions do use virtual functions. – MSalters Jan 27 '16 at 13:42
  • @MSalters Basic building blocks simply have no use of customization based on virtual function overriding. I suspect that people (typically Java programmers shy with `final`) that make many functions virtual in fundamental concrete classes (like containers) simply wouldn't be able to specify what it means, abstractly, to override these functions, and what the overrider would be allowed to do. – curiousguy Oct 26 '19 at 05:57

2 Answers2

57

[syserr.errcat.overview] has std::error_category

class error_category {
  virtual const char* name() const noexcept = 0;
  virtual string message(int ev) const = 0;
};

There are no others in C++14.

vsoftco
  • 55,410
  • 12
  • 139
  • 252
Igor Tandetnik
  • 50,461
  • 4
  • 56
  • 85
  • 2
    How are you certain there are no others? Just curious. (P.S. +1) – Nemo Jan 27 '16 at 00:45
  • 21
    @Nemo Searched the text of the standard, from chapter 17 onward, for `= 0`. Eyeballed every hit (there are not that many). Good reason to procrastinate on doing actual work. – Igor Tandetnik Jan 27 '16 at 00:48
  • 6
    Note that a typical implementation of `std::function` will use pure virtual functions as an implementation detail (or, reproduce an equivalent with C-style OO). The same may be true of future and other run time concept/type erasure types. – Yakk - Adam Nevraumont Jan 27 '16 at 01:16
  • I guess one question here is, would it be against the standard for these functions *not* to be purely virtual? (Would any program fail to behave correctly if that was the case?) – user541686 Jan 27 '16 at 10:07
  • 2
    @Mehrdad I don't see how it could cause a conforming program to stop working. However, it would allow a non-conforming program to be accepted - a program that has a class derived from `std::error_category` which fails to override one of those methods. This in itself could be argued to be non-conforming on the part of the implementation - the fact that an invalid program is accepted with no diagnostic. – Igor Tandetnik Jan 27 '16 at 13:33
9

C++17 adds std::pmr::memory_resource in [mem.res.class] to the one in C++14, with the following private pure virtual functions:

class memory_resource {
    virtual void* do_allocate(size_t bytes, size_t alignment) = 0;
    virtual void do_deallocate(void* p, size_t bytes, size_t alignment) = 0;
    virtual bool do_is_equal(const memory_resource& other) const noexcept = 0;
};

And yes, private virtual functions can be overridden.

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
P.W
  • 26,289
  • 6
  • 39
  • 76