I am always a huge fan of standards and think I finally decided on one of the many C++ naming standards. However, it almost seems moot because working with a couple of libraries where the standard use is to inherit the classes, the naming is now off when overriding.

Now, I am not forced to actually inherit these classes, but it did make me wonder and I haven't found this specific question yet.

When having to inherit a third-party's class, how are naming conventions handled? Do you just suck it up and have the one or two functions you need to override be different or do you adopt the library's naming convention for that entire class? Is there some other trick?


That's the challenge with languages where the language community hasn't established a naming convention.

One work around if (like you say in your case) there are only a few offending inherited functions, you could make your subclass a facade

class YourClass: private LibraryClass
      int yourNamingConvention()
         return this->library_naming_convention(); 


I'm definitely not saying this should be a blanket policy. But if (1) there are only a few library methods that are in a different naming convention from yours, and (2) those functions aren't so common that a google search of the exact function would turn up good documentation (so changing the name makes that documentation harder to find), and (3).... etc., then it might be worth it for the sake of naming convention consistency.

Basically I'm saying "here's a thing you could do in the right context, up to you to make that call" not "I think this is the cut and dried solution"


changed to private inheritance as discussed in the comments - I'm not a c++ guy so I had to look up the difference

| improve this answer | |
  • Hmm, but what about when it's a pure virtual function? There is nothing directly for me to call or the library may be attempting to call the method itself. Just saw your big edit and now I am starting to think that there may just not be any other way. Perhaps it is just one of those things where you just have to do it and move on even if it does break consistency across your own objects. – TyCobb Apr 21 '16 at 5:29
  • 1
    Well, I think if you use public inheritance, then you shouldn't wrap the public functions you inherited: After all, those are part of the public interface you inherited and thus not an implementation detail. If you used private inheritance, that's a completely different story, as that would force you to write wrappers for the functions you need to forward anyway. – cmaster - reinstate monica Apr 21 '16 at 5:31
  • 1
    @cmaster you're right. I don't like the idea of identical functions having two different names. Seems like clutter. Either rename them or don't. – candied_orange Apr 21 '16 at 5:33
  • If you're renaming them and using private inheritance I feel I must ask, how much harder would it be at this point to just use composition? Supposed to be more flexible than inheritance. Just requires more typing. – candied_orange Apr 21 '16 at 5:37
  • @CandiedOrange I think you're right. It's been a long time since I worked with c++ so I'm not really making suggestions about the implementation details, just the high level idea of renaming the functions. I guess you could sum up my answer with: "solve it by not exposing the library functions" which is really another way of saying "no, I don't think there is a solution" – alexanderbird Apr 21 '16 at 5:40

When having to inherit a third-party's class, how are naming conventions handled?


It is almost always better to prefer composition over inheritance. Do not inherit from third party software, and that includes classes defined in the std namespace, and your problem will be solved.

Inverting Nike's catchline: Just don't do it.


Don't, just don't. The modern axiom is that composition is (almost always) preferable to inheritance. This applies, in spades, to third party software.

If you use composition as opposed to inheritance and if you obey they widely held notion that, except for POD types, data members should not be public (and preferably should be private), then it just doesn't matter if they use raNDoMStuDLyCaPs and you use something else (or vice versa).

If you follow the general rule of preferring composition over inheritance, you simply should not inherit from any third party software (and that includes stuff in namespace std) unless there is an extremely strong and compelling reason for violating that general rule.

Inverting Nike's catchline: Just don't do it, where 'it' means inheriting from third party software.

| improve this answer | |
  • 2
    A lot of frameworks are designed for inheritance. Just not doing it is not necessarily an option. – Sebastian Redl Apr 21 '16 at 8:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.